Mthode de conception de systme dinformation : une approche oriente-composant

Gwladys Guzelian
LSIS Universit dAix-Marseille III avenue Escadrille Normandie Niemen 13397 Marseille cedex 20 gwladys.guzelian@lsis.org

Rsum : Les mthodes et les techniques de dveloppement de systmes dinformation ont atteint une certaine maturit. Pourtant ces mthodes restent inadaptes dans de nombreux contextes, les logiciels quelles produisent ne sont pas toujours satisfaisants et elles ont des difficults voluer pour prendre en compte de nouveaux modes de conception comme lapproche par rutilisation. Dans ce papier, nous dfinissons une mthode comme un ensemble de composants auxquels nous associons un graphe de rutilisation pour en assurer la recherche, ladaptation et lassemblage. Cette nouvelle approche de la notion de mthode rend la rutilisation de composants plus systmatique, elle offre la possibilit dadapter le processus de dveloppement en fonction du contexte et elle fournit un guidage efficace dans la recherche de solutions des problmes rcurrents de dveloppement. Mots Cls : Systmes dinformation, Mthode de conception de systmes dinformation, Conception par rutilisation, Composant rutilisable, Composantproduit, Composant-processus, But.

uvre dune approche par rutilisation conduit ncessairement une reformulation des mthodes de conception actuelles. Par ailleurs les mthodes apparaissent aujourdhui trs monolithiques : elles proposent une unique dmarche de dveloppement, le plus souvent squentielle et peu itrative. En consquence, elles ne supportent pas des adaptations qui leur permettraient de prendre en compte diffrents types de situations. Dans ce papier, nous proposons une nouvelle approche de la notion de mthode. Cette approche considre une mthode comme un ensemble de composants associ un graphe de rutilisation. Les composants dfinissant une mthode sont de deux types : les composants-produit et les composants processus. Les premiers fournissent des solutions des problmes rcurrents de dveloppement, les seconds guident le droulement du dveloppement. Un graphe de rutilisation supporte la recherche, ladaptation et lassemblage des composants. Cette dfinition oriente composant dune mthode de conception prsente plusieurs avantages : i) Elle permet la mise en uvre systmatique dune approche par rutilisation, ii) Elle offre la possibilit dadapter le processus de dveloppement diffrents contextes, iii) Elle guide le dveloppeur dans la conduite du processus et dans la recherche de solutions. Le papier est organis en 5 sections. Dans la partie 2, nous donnons les limites des mthodes utilises actuellement en ingnierie des S.I. Dans la partie 3 nous introduisons la dfinition dune mthode de conception oriente composant. Dans les parties 4 et 5 nous prsentons respectivement la base de composants et le graphe de rutilisation, les deux lments essentiels dune mthode oriente composant. La dernire partie prsente les perspectives de recherche de ce travail.

INTRODUCTION

Les mthodes et les techniques de dveloppement de Systmes dInformation (S.I.) ont atteint une certaine maturit [Wolle, 1990], [Nanci, 2001]. Ces mthodes et ces techniques sont largement utilises dans les entreprises et de nombreuses mthodes sont aujourdhui instrumentes. Pourtant ces mthodes restent inadaptes dans de nombreux contextes, les rsultats quelles produisent ne sont pas toujours satisfaisants et elles ont des difficults voluer pour prendre en compte de nouveaux modes de conception. Bases sur lhypothse que le dveloppement dun systme dinformation se fait partir de rien, elles nintgrent ni lexistence de bibliothques de composants ni mme que le nouveau systme dinformation doit sintgrer des briques logicielles existantes. Les mthodes de dveloppement utilises actuellement intgrent peu de manire systmatique cette nouvelle approche. Nous pensons que la mise en

-1-

LES LIMITES DES METHODES ACTUELLES

En conception de S.I., il est usuel de dfinir une mthode de conception comme un ensemble cohrent comportant: i) Des modles et des langages, il sagit des concepts et des rgles pour les utiliser permettant de dcrire un S.I. diffrents niveaux dabstraction (conceptuel, architecture, physique), ii) Une dmarche, il sagit du processus opratoire pour conduire le travail de conception, iii) Des outils logiciels pour faciliter la mise en uvre des modles, des langages et de la dmarche. Toutes les mthodes des annes 80 ont t dfinies sur ce modle [Rolland, 1988]. Elles ont permis une meilleure matrise de la complexit, des cots et des dlais des projets informatiques. Elles ont aussi apport une plus grande rigueur du dveloppement en introduisant notamment des modles de reprsentation et des niveaux dabstraction. Enfin elles ont largement contribu une meilleure comprhension du mtier de concepteur. Pourtant ces mthodes doivent voluer pour plusieurs raisons. Dabord les systmes dinformation ont volu en terme darchitecture (ils sont htrognes et distribus) et dusage (ils sont ouverts et donc accessibles une large varit dusagers). Ensuite ces mthodes ont t construites sur des hypothses qui sont fausses aujourdhui, par exemple, on sait que lensemble des besoins ne peut pas tre donn une fois pour toute au dbut du dveloppement, les besoins voluent et cette volution doit tre prise en compte durant le dveloppement mme du projet. Enfin ces mthodes prsentent plusieurs limites importantes : Elles sont monolithiques. Elles proposent une dmarche de dveloppement fige et squentielle. En effet, la dmarche est dfinie comme un ensemble dtapes formant un bloc indcomposable. Ces mthodes sont souvent qualifies de lourdes car elles ne permettent pas de prendre en compte les particularits de certains projets. Aujourdhui les quipes de dveloppement ont besoin de dmarches plus gnriques autorisant des adaptations (par exemple ne pas ncessairement passer par toutes les tapes) en fonction du contexte. Plusieurs stratgies de dveloppement diffrentes devraient tre proposes en fonction des objectifs fixs, du domaine dapplication ou de la nature du projet (taille, caractre novateur, comptences des acteurs). Elles ne supportent pas la rutilisation de composants. Lutilisation de composants dans de nombreux domaines dingnierie simpose peu peu. Lapproche base de composants est particulirement utilise en ingnierie des systmes dinformation. Le -2-

rle croissant et diversifi que vont jouer le Web et lInternet (et lIntranet) dans la conception et la mise en ligne dapplications va amplifier ce phnomne. Cette approche vise bien sr amliorer la qualit des produits de dveloppement mais aussi apporter un support mthodologique dans le processus de dveloppement de S.I.. Ainsi beaucoup de bibliothques de composants fournissent soit des solutions rutilisables soit des fragments de processus qui aident rsoudre des problme-types de dveloppement. En fonction de lactivit de dveloppement pour laquelle ces composants sont rutilisables, ils peuvent prendre la forme soit de fragments de code, darchitecture ou de spcification soit de fragments de processus guidant la spcification des besoins, la modlisation, ou encore la dfinition darchitectures. Lapproche par rutilisation fait apparatre des ruptures importantes la fois dans les processus dingnierie mais aussi dans les produits dingnierie. On constate que les mthodes actuelles prennent peu en compte ce nouveau mode de conception rendant la rutilisation de composants peu systmatique. Il devient ncessaire dintroduire explicitement dans le processus de dveloppement des activits de recherche, dadaptation et dassemblage de composants. Elles napportent que peu daide dans la mise en uvre des activits de dveloppement. Cette limite est trs prsente dans lapproche UML qui apparat comme trop gnrale, ne donnant pas ou peu de directives pour conduire le processus de dveloppement. UML apparat davantage comme une boite outils, sans vritable rgle dutilisation. Le processus unifi a t labor en partie pour combler cette limite. Nanmoins, il reste encore assez gnral. Par ailleurs, la maturit des mthodes se traduit aujourdhui par lexistence dun savoir faire important. La formalisation de ce savoir faire est faible, rendant les bonnes pratiques et les bonnes solutions peu partageables et peu rutilisables. Il semble intressant de capitaliser ces connaissances et de les dcrire sous forme de composants. Lvolution des mthodes de conception laisse envisager des ruptures importantes dans le dveloppement des systmes dinformation. Lapproche par rutilisation, la mise en uvre dune dmarche adaptable et le guidage du dveloppement sont caractristiques du renouveau de ces mthodes.

VERS UNE NOUVELLE DEFINITION DES METHODES DE CONCEPTION

Nous proposons dans cette section une nouvelle dfinition de la notion de mthode. Cette dfinition sappuie sur le langage UML (Unified Modeling Language) et sur le processus unifi UPM (Unified Process Model). Elle peut tre considre comme une proposition visant associer au langage UML une vritable dmarche mthodologique.

Nous dfinissons une mthode par un quadruplet {LProd, LProc, {BC}, Gr}. LProd est le langage de produit cest dire des concepts et des notations pour dcrire des solutions. LProc est le langage de processus, il permet de dcrire toute dmarche de dveloppement conduisant au systme dinformation final. {BC} est une base de composants qui fournit durant le dveloppement des solutions prdfinies, ou des fragments de dmarches guidant le dveloppement. Enfin Gr est le graphe de rutilisation, il suggre diffrentes stratgies de dveloppement, il guide le dveloppeur mettre en uvre les stratgies et il prconise la rutilisation de composants.

3.1

Le langage de produit

Le langage de produit comporte un ensemble de concepts qui supportent la spcification et la modlisation du systme dinformation tous les niveaux dabstraction. Nous utilisons le langage UML [Booch, 1998] comme langage de produit. Nous pensons quil fournit un ensemble complet de concepts pour modliser un systme dinformation selon diffrents points de vue (fonctionnel, logiciel, matriel), selon diffrentes dimensions (statique ou dynamique), selon diffrents niveaux dabstraction (conceptuel, logique, physique) ou encore selon diffrents niveaux de dtail. Le langage de produit permet de spcifier le modle de besoins, le modle danalyse, le modle de conception Le langage de produit exploite la notion de strotype dfinie dans UML pour crer de nouveaux concepts adapts diffrents contextes dutilisation. Par exemple, le strotype but peut tre cr dans le cadre de lutilisation dune mthode de modlisation base de buts.

dans le processus. Les activits de recueil des besoins, danalyse sont appeles workflows , elles constituent des mini processus au sein du processus unifi. Le cycle de dveloppement comporte plusieurs itrations et les itrations sont organises en quatre phases : Initialisation, Elaboration, Construction, et Transition. Tout dabord, la phase dinitialisation consiste essentiellement recueillir et analyser les besoins. Lors de cette phase, le pourcentage dexcution des workflows dimplmentation et de tests est trs faible. Puis, la phase dlaboration affine et oprationalise les besoins. Ensuite, la phase de construction cre le produit. Enfin, la phase de transition se concentre sur loptimisation et les tests du produit cr. Il est important de noter que chaque itration contient les activits de recueil des besoins, danalyse, de conception, Le langage du processus unifi est un langage gnrique qui permet de dfinir diffrents processus de dveloppement. Il supporte des mcanismes dextension et dadaptation pour spcifier des processus adapts diffrents contextes. En effet, il est possible de choisir, dajouter, et/ou de supprimer des workflows en fonction du domaine dapplication. Par exemple, dans [Ambler, 2004], le processus unifi a t tendu avec un workflow de modlisation dentreprise pour valuer notamment le cot du systme produire. Dans [Naiburg 2002], le processus unifi a t adapt pour le domaine des applications bases de donnes.

3.3

La base de composants

3.2

Le langage de processus

Le langage de processus est compos dun ensemble de concepts et dune notation pour dfinir la dmarche de dveloppement. La dmarche organise la construction des diffrents produits de dveloppement, dcrits avec le langage de produit. Nous utilisons le langage du processus unifi [Jacobson, 1999]. Ce langage est bas sur les notions ditration et de workflows . Traditionnellement, les projets sont organiss en un ensemble de tches : le recueil des besoins, lanalyse et la conception, limplmentation, les tests... Lexcution de ces tches correspond au cycle de vie du systme. Lorganisation des tches est squentielle et le dmarrage dune activit est conditionn par la terminaison dune autre. Dans le processus unifi, on retrouve les mmes tches organises de manire itrative. Les activits de recueil des besoins, danalysesont donc mises en uvre tout au long du processus de dveloppement autorisant ainsi par exemple lajout dun nouveau besoin trs tard dans le processus ou encore un travail de prototypage trs tt -3-

La base de composants constitue le noyau de la mthode. Elle est dfinie comme un ensemble de composants fournissant des fragments de produit et des fragments de processus. Les premiers sont des solutions prtes lemploi pour laborer les modles de produit, les seconds proposent des dmarches de rsolution de problmes types de dveloppement. Par exemple, un composant fournissant le diagramme de classe pour la modlisation dun objet complexe est un composant-produit, en revanche un composant dcrivant les tches ncessaires la construction dun diagramme de cas dutilisation est un composant-processus. Il devient usuel de spcifier un composant comme un triplet <Problme, Solution, Contexte> [Gamma, 1993], [OMG, 2003], [Fowler, 1996]... Dans ce triplet, le problme est un objectif de dveloppement que souhaite atteindre le concepteur en ralisant un systme dinformation. La solution est un artfact rutilisable exprim dans le langage de produit ou dans le langage de processus. Le contexte dfinit la situation pour laquelle la solution dcrite dans le composant est adapte. Cette approche -oriente problme- de la notion de composant est intressante, dune part, parce quelle fait clairement la distinction entre la spcification (partie problme) et la ralisation (partie solution) du

composant et dautre part, lorientation problme fournit une forme dabstraction dans laquelle il est possible de considrer les diffrentes solutions dun mme problme comme un tout mais aussi de considrer chaque solution avec ses spcificits. Nous considrons que tous les composants de la base peuvent tre dcrits selon cette approche.

tre mises en uvre par les concepteurs. Par exemple, dans la mise en oeuvre du processus unifi oprationnaliser le cas dutilisation Grer les demandes de prt est un but de dveloppement qui peut tre ralis de diffrentes manires. La Figure 1 illustre le modle de composants et la notation sur un exemple de composants mtier. Ce composant propose plusieurs solutions pour le but oprationnaliser le cas dutilisation Grer les demandes de prt (not sur la figure DG1) dans le cadre dune gestion de bibliothques. Ce composant fournit 4 scnarios possibles. Graphiquement, nous utilisons des arcs-OU pour montrer les diffrents scnarios possibles de ralisation dun but de dveloppement. Chaque scnario est spcifi par un couple <Cj, Sj> o Cj est le contexte dans lequel le but de dveloppement est ralis et Sj est la solution rutilisable base sur le langage de produit. Dans la Figure 1, les 4 contextes C1, C2, C3 et C4 sont dfinis laide des buts mtier G1, G2, G3, G4. Le contexte C1 est compos du but G1 Contrler lenregistrement de labonn et de G4 Contrler la disponibilit de lexemplaire avec gestion de file dattente . Le contexte C2 est constitu des buts G1 et G3 Contrler la disponibilit de lexemplaire sans gestion de file dattente . Le contexte C3 utilise G1, G2 Vrifier la validit de labonn et G4. Le contexte C4 utilise G1, G2 et G3. Les contextes permettent de discriminer les quatre scnarios et aident le concepteur choisir une solution. Composant oprationnaliser le cas dutilisation Grer les demandes de prt DG1
C3= G1

3.4

Le graphe de rutilisation

Le graphe de rutilisation dfinit plusieurs stratgies de dveloppement qui exploitent la base de composants. Ce graphe est complmentaire de la base : il dfinit un ensemble de processus de dveloppement possibles, chaque processus guide la recherche, ladaptation et lassemblage des composants de la base. Ce graphe comble donc certaines limites des mthodes actuelles, puisquil autorise diffrentes dmarches et quil suggre dutiliser la base de composants. Nous prsentons plus en dtail dans les sections suivantes le modle de composants, la typologie des composants de la base, le modle dorganisation de la base des composants et le graphe de rutilisation.

4 4.1

LA BASE DE COMPOSANTS Le modle de composants

La base de composants est vue comme un ensemble de services pouvant tre utiliss dans la mise en uvre de la mthode. La mthode peut suggrer dutiliser des composants trs varis comme les patterns de conception de Gamma [Gamma, 1993], les analysis patterns [Fowler, 1996], les patterns architecturaux [Larman, 2003], les process patterns [bergner, 1998] Le modle de composants permet de considrer toute forme de composant (composants mtier, composants de conception, composants logiciels, .) de manire homogne. Ces composants peuvent tre accessibles via le Web dans des banques de composants universelles. Ces composants peuvent aussi simplement tre partags par un collectif cibl au sens dune communaut de pratique [Wenger, 1998]. Le modle de composants est bas sur une orientation problme [Guzelian, 2004] et les problmes de dveloppement sont exprims sous forme de buts [Grosz, 2001]. Un composant rutilisable est dfini par un couple <DGi, {Sc}> o DGi est un but de dveloppement et {Sc} est un ensemble de scnarios. Nous dsignons un composant par le nom du but de dveloppement. Chaque scnario dcrit une manire particulire de satisfaire le but de dveloppement dans un contexte prcis. Il peut donc exister plusieurs faons de raliser le mme but de dveloppement. Les buts de dveloppement correspondent aux activits qui jalonnent le processus de dveloppement et qui doivent -4-

C1=

G1

G4

S1 G3

G2

G4

C2=G1

C4=

G1

G2
S4

G3

S2

S3

Figure 1 : Illustration dun composant orient buts Les solutions Sj sont en gnral composes dartefacts. Un artfact est spcifi laide du langage de produit ou du langage de processus. Il peut sagir dun diagramme de squence, dune description narrative dun cas dutilisation, ou encore dun diagramme de classes UML. Nous distinguons deux types de contexte : les contextes dcomposables et les contextes non dcomposables. Si

le contexte dun scnario dun composant est dcomposable, cela signifie que le composant peut tre raffin. Dans le cas contraire, le composant est fini et sa solution est rutilisable. Suivant le type de contexte nous utilisons une flche pleine (contexte non dcomposable) ou en pointills (contexte dcomposable). Par exemple, le contexte C3 de la Figure 1 est dcomposable puisquil contient au moins un but complexe qui peut tre dcompos dune ou plusieurs faons. En effet, le but G2 contenu dans C3 peut tre dcompos en deux sous buts : vrifier ltat des cotisations et vrifier le quota demprunt en cours. Ainsi, le composant DG1 peut tre raffin par un autre composant nomm oprationnaliser le cas dutilisation Vrifier la validit de labonn et contenant les diffrentes solutions de ralisation du but G2.

utiliss en conception et les composants de type programmation ont des solutions de type diagrammes classes Java ou C++ utilises en programmation.

Composant-mthode

Composant-produit

Composant-processus

Composantmtier Composantlogiciel

ComposantInitialisation ComposantElaboration ComposantConstruction

4.2

Typologie des composants

Composantarchitecturaux

En conception de systmes dinformation, deux types de connaissance peuvent tre rutilises : - Les connaissances de domaine, ce sont les connaissances qui caractrisent une classe de systmes et qui sont rutilisables dans le dveloppement des systmes dune mme classe. Il peut sagir des connaissances mtier (le mtier de la Banque, de la gestion de bibliothque), des connaissances en architecture (Client / serveur, Objets distribus) ou encore des connaissances en programmation (reprsentation dobjets complexes, partage des responsabilits entre classes). - Les connaissances de processus, ce sont des pratiques, des manires de rsoudre un problme qui sont rcurrentes dans le dveloppement de systmes. Par exemple la dmarche de construction dun diagramme de cas dutilisation suggre i) didentifier les acteurs, ii) de dfinir les usages (ou cas dutilisation) du systme souhaits par chaque acteur et iii) deffectuer un diagramme de squence pour modliser linteraction entre les acteurs et le systme pour chaque cas dutilisation. Relativement ces deux types de connaissances, nous distinguons dans une base deux types de composant : les composants-produit et les composants-processus (Figure 2). Dans les composants-produit, la partie solution contient des artefacts rutilisables tels que des diagrammes de classe, des cas dutilisation A la diffrence, la solution fournie par les composants-processus contient des fragments de dmarche. Les composants-produit ont une partie solution exprime avec le langage de produit et les composants processus contiennent des solutions exprimes dans le langage de processus. Nous distinguons aussi dans les composants produits ceux qui permettent la rutilisation de connaissance mtier, de connaissance darchitecture et de connaissances de programmation. Selon leur type, ces composants seront utiliss dans un workflow particulier. Par exemple, les solutions des composants-produit de type architecture sont des diagrammes de dploiement UML -5-

ComposantTransition

Figure 2 : Typologie de composants De faon analogue, nous distinguons plusieurs types de composants-processus relativement aux phases du dveloppement. Ainsi les composants-processus peuvent tre des composants dinitialisation, des composants dlaboration, des composants de construction, et des composants de transition. Par exemple un composant de type initialisation propose un fragment de dmarche permettant de guider lidentification des besoins ou bien la construction dun diagramme prliminaire de classes danalyse.

4.3

Lorganisation des composants

Lensemble des composants de la base est exprim dans les termes du modle de composants. Cette base peut tre complexe car elle intgre en gnral une large varit de composants. Dans cette sous-section, nous dfinissons une structure dorganisation de la base de composants. Lorganisation des composants est base sur deux types de graphe sans cycle : les arbres et les graphes. Lorganisation des composants est dirige par le raffinement des composants. Le contexte associ une solution peut tre dcomposable, dans ce cas, le composant peut tre raffin. Un contexte peut tre complexe et plusieurs de ses lments peuvent tre dcomposs, dans ce cas le composant peut tre raffin par plusieurs composants. Nous avons prcis prcdemment (cf. section 4.1) dans lexemple de la Figure 1, que le contexte C3 du composant oprationnaliser le cas dutilisation Grer les demandes de prt tait dcomposable. Ainsi, ce composant peut tre raffin par un autre composant.

Lien de raffinement ET Cj

Cp1
ET C2

composants mtier, la fort des composants architecturauxmais aussi pour les composantsprocessus la fort des composants dinitialisation, la fort des composants dlaboration Profondeur 1 Cp12 C1 Profondeur 2 S1 Raffinement du composant
(arbre de dcision ET) S2

Cp11

DG1

C2 OU

ETC22

ET C23

Reprsentation du composant (arbre de dcision OU)

Figure 3 : Raffinement de composant Nous symbolisons le lien de raffinement pour un contexte prcis par une double flche ET Cj (Figure 3). Le raffinement dun composant est dcrit par un arbre de dcisions ET. Le rsultat du raffinement dun composant donne une hirarchie de composants. Il existe une hirarchie de composants pour chaque but de dveloppement. Dautre part, chaque composant intgre plusieurs solutions possibles pour un mme but de dveloppement. Un composant peut tre vu comme un arbre de dcisions OU dans lequel les arcs-OU symbolisent les diffrentes solutions possibles dun problme de dveloppement. Au moment de la rutilisation, les arcs-OU guident le concepteur choisir une solution selon le contexte alors que les arcs-ET guident le concepteur dans le raffinement de contexte. Lalternance de ces deux types darbre conduit un arbre de dcision ET/OU. Nous nommons les arbres par le but racine c'est--dire par le but de dveloppement de plus haut niveau. La Figure 4 reprsente un arbre de dcision ET/OU o le but DG1 pourrait tre oprationnaliser le cas dutilisation Grer les demandes de prt . Cet arbre de dcisions ET/OU contient un ensemble de solutions possibles qui oprationnalisent le cas dutilisation grer les demandes de prts. Ces diffrentes solutions correspondent la variabilit des rgles de gestion qui sont utilises dans les diffrentes bibliothques (grer les demandes en attente, prendre en compte ltat des cotisations des abonns pour traiter une demande). Le nombre de buts de dveloppement jalonnant le processus de dveloppement est important si lon considre une mthode couvrant la globalit des activits de dveloppement, en consquence le nombre darbres de dcisions ET/OU est lui aussi important. Le concept de fort constitue un mcanisme de structuration des arbres de dcisions ET/OU. Une fort est un ensemble darbres de dcisions ET/OU. Les forts sont utilises pour regrouper les composants selon diffrents critres. Nous regroupons les composants-produit et les composants-processus conformment la typologie de la Figure 2. On trouve ainsi pour les composants-produit, la fort des -6-

ET C2
DG11 DG12

Profondeur 3 C21 Profondeur 4 S21 S22

ET C22

OU OU C22 S23
ET C23

C23

C24 S24

Figure 4 : Arbre de dcisions ET/OU Les arbres et les forts permettent de dfinir une structure de composants. Cette structure ne prdfinit pas de manire particulire de rutiliser les composants pour dvelopper un systme dinformation. Cette structure supporte en effet plusieurs stratgies de dveloppement base de composants, par exemple on peut choisir soit didentifier les cas dutilisation et ensuite de les oprationnaliser pour trouver les classes soit de commencer directement par les diagrammes de classes. Le graphe de rutilisation a pour objet de dfinir les diffrentes manires de dvelopper un systme par rutilisation des composants de la base.

LE GRAPHE DE REUTILISATION

La base de composants est un ensemble de composants organiss en arbres et forts. Gr est un graphe de rutilisation qui dfinit plusieurs stratgies de dveloppement. Le graphe de rutilisation Gr est un graphe Etat/transition [Harel, 1987] dans lequel les tats sont des activits et les transitions expriment le passage dune activit une autre. Chaque chemin de ce graphe dfinit une manire particulire de dvelopper un systme dinformation en rutilisant les composants de la base. Gr est compos de deux sous graphes : Le graphe-produit Gprod et le graphe processus Gproc (Figure 5).

[sinon ] Gproc [Fin du parcours de Gr ] [Fin du parcours de Gr ] Gr Figure 5 : Graphe de rutilisation Les deux sous graphes Gprod et Gproc sont composs de chemins permettant de parcourir les arbres et les forts de la base de composants BC. Gproc exprime diffrentes stratgies possibles. Le choix dune solution des composants-processus mne des fragments de dmarche. Chaque fragment de dmarche choisi est excut dans Gprod afin dobtenir des fragments de produit rutilisable. Aprs avoir choisi et assembl les solutions de type produit, le graphe Gproc est parcouru nouveau pour continuer choisir et construire une stratgie de dveloppement et ainsi de suite... Au fur et mesure que la dmarche est construite dans Gproc, elle est excute dans Gprod. On alterne donc le parcours des activits de Gproc et de Gprod. Le graphe de processus Gproc (Figure 6) est constitu de 4 activits de type parcourir la fort F . Ces activits concernent la fort Fi des composantsinitialisation, la fort Fe des composants-laboration, la fort Fc des composants-construction et la fort Ft des composants-transition. Chaque activit peut-tre itre une ou plusieurs fois et consiste slectionner des composants-processus puis choisir une solution au sein de ces composants. Ces solutions sont des fragments de dmarche. Il suffit alors dappliquer ces solutions dans le graphe Gprod pour obtenir des fragments de produit. Gprod

ces forts est guid par la solution choisie dans un des composants-processus slectionn dans le graphe Gproc.

[chercher des composants-mtier]

[chercher des composants-logiciel]

[chercher des composants-architecturaux] [sinon] [sinon]

Parcourir la fort F1 Parcourir la fort F2 Parcourir la fort F3

[parcourir Gproc] [parcourir Gproc] [parcourir Gproc] Gprod Figure 7 : Graphe-produit Gprod Dans Gprod, les activits de type parcourir fort sont complexes : elles consistent slectionner des arbres et les parcourir. Ces activits font lobjet dune description par un sous graphe-produit. Par exemple lactivit de type Parcourir la fort F1 peut tre explicite par un sous graphe-produit que nous ne dtaillons pas ici. Ce sous graphe dcrit diffrents parcours des arbres contenus dans la fort F1. En associant dans une mthode, une base de composants un graphe de rutilisation, nous dfinissons une approche systmatique de dveloppement par rutilisation. Par ailleurs, les composants-processus dfinis dans la base de composants permettent de considrer la mthode comme un ensemble de briques autorisant diffrentes faons de les assembler. Les composants-processus rendent la mthode non monolithique et le graphe de rutilisation apporte les directives pour organiser ces composants selon un processus cohrent.

[parcourir Gprod] [parcourir Gprod] [parcourir Gprod]

Parcourir la fort Fc

CONCLUSION

Parcourir la fort Fi

Parcourir la fort Fe

[sinon ] [itrer ] [itrer ]

[sinon ] [itrer ] [sinon ]

Dans cet article, nous avons prsent une dfinition de mthode oriente composant. Une mthode est considre comme un ensemble de composants associ un graphe de rutilisation. Les composants-produit rpondent des problmes de dveloppement que doit rsoudre le concepteur de systmes dinformation. Les composants-processus fournissent des dmarches pour conduire le dveloppement. Le raffinement des composants induit alors une organisation des composants en arbres de dcisions ET/OU. Les composants organiss en arbres et en forts sont associs un graphe de rutilisation qui supporte dune part, diffrentes stratgies de dveloppement (sous graphe de processus) et dautre part, la recherche de solutions rutilisables pour rsoudre un problme de dveloppement dans un contexte particulier (sous graphe de produit). En alternant le parcours des deux

[sinon ]

Parcourir la fort Ft

Gproc

Figure 6 : Graphe-processus Gproc Le graphe de produit Gprod (Figure 7) est constitu de 3 activits de type parcourir la fort F . Ces activits concernent la fort F1 des composants-mtier, la fort F2 des composants-architecturaux et la fort F3 des composants-logiciel. Le choix du parcours dune de -7-

sous graphes, la rutilisation de composants devient systmatique. Nous travaillons actuellement dans trois directions : Tout dabord, nous devons tendre le modle dorganisation des composants et le graphe de rutilisation. Nous cherchons exploiter la notion de fort pour grer des composants de diffrents domaines dapplications et de diffrentes mthodes. Le graphe de rutilisation doit tre tendu en consquence. Puis, nous souhaitons enrichir le graphe de processus Gproc en dfinissant un sous graphe-processus tel que nous avons dfini un sous graphe-produit au niveau des forts. Laffinement de Gproc faciliterait le choix dune stratgie de dveloppement et guiderait lutilisation du graphe Gprod. Enfin nous dveloppons un outil qui supporte la spcification et la mise en uvre de mthodes orientes composant. Les composants sont implants en XML. Le prototype doit permettre de mettre en uvre une mthode selon le graphe de rutilisation et de guider le concepteur dans le dveloppement de systmes par rutilisation.

BIBLIOGRAPHIE
[Ambler, 2004] Ambler Scott W., Nalbone J. Enterprise Unified Process: Enhancing The Rational Unified Process (RUP) to meet the Real-World Needs of Your Organisation, A Ronin internantional, Inc. White Paper, January 15, (2004). [Bergner, 1998] Bergner K., Raush A., Sihling M., Vilbig A., A Componentware Developement Methodology based on Process Patterns, Mnchen, (29 th July 1998). [Booch, 1998] Booch G., Rumbaugh J., Jacobson I., The Unified Modeling Language UserGuide, The Addison-Wesley Object Technology Series, AddisonWesley Publishing Company, ISBN 0-201-57168-4, (1998). [Fowler, 1996] Fowler M., Analysis Patterns Reusable Object Models, Addison-Wisley Publishing Company, ISBN 0-201-89542-0, (1996). [Gamma, 1993] Gamma E., Helm R., Johnson R., Vlissides J., Design Patterns : Abstraction and Reuse of Object-Oriented Design, Proceedings of the 7th European Conference on Object-Oriented Programming, ECOOP93 Conference Proceedings, p.406-431, Zurich, Switzerland, July 26-30 (1993). [Grosz, 2001] Grosz G., Roland C., de la modlisation conceptuelle lingnierie des besoins , chapter 4 in Cauvet C., Rosenthal-sabroux C., Ingnierie des systmes dinformation, ditions Herms, ISNB 2-74620219-0, (02/2001). [Guzelian, 2004] Guzelian G., Cauvet C., Ramadour P., Conception et rutilisation de composants : une approche par les buts, Actes du XXIIme Congrs INFORSID, Biarritz, (2004). [Harel, 1987] Harel D., Statecharts: A visual formalism for complex systems, Science of Computer Programming, 8(3):231274, (June 1987). -8-

[Jacobson, 1999] Jacobson I. , Booch G., Rumbaugh J., The unified Software Development Process, AddisonWesley Publishing Company, ISBN 0-201-57169-2, (1999). [Larman, 2003] Larman C., UML et les Design Patterns, 2nd Ed, CampussPress , (2003). [Naiburg, 2002] Naiburg E.J., Maksimchuk R.A., Bases de donnes avec UML, CampusPress, (2002). [Nanci, 2001] Nanci D., Espinasse E., Ingnierie des systmes dinformation : MERISE 2me gnration, Vuibert (2001). [OMG, 2003] OMG, Reusable Asset Specification (RAS), Draft RFC submitted to OMG, version 2.1, August 2003. Copyright 2003 IBM, Flashline, LogicLibrary, ComponentSource, and Adaptive, available at : www.rational.com/media/products/Resuable_Asset_Spe cification_draft.pdf. [Rolland, 1988] Rolland C., Foucaut O., Benci G., Conception de systmes dinformation : La mthode REMORA, Eyrolles 88 (1988). [Wolle, 1990] Wolle T., Hagelstein J., Macdonald J.G., Rolland C., Sol H.G., Van Assche F.J.M., Verrijn-Stuart Mthodologies pour les systmes dinformation, guide de rfrence et dvaluation, Dunod, (1990). [Wenger, 1998] Wenger E., Communauties of practices, learning, meaning and identity, Cambridge University Press, (1998).