Vous êtes sur la page 1sur 8

Méthode de conception de système d’information : une

approche orientée-composant

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

Résumé : Les méthodes et les techniques de œuvre d’une approche par réutilisation conduit
développement de systèmes d’information ont atteint nécessairement à une reformulation des méthodes de
une certaine maturité. Pourtant ces méthodes restent conception actuelles.
inadaptées dans de nombreux contextes, les logiciels
qu’elles produisent ne sont pas toujours satisfaisants et Par ailleurs les méthodes apparaissent aujourd’hui
elles ont des difficultés à évoluer pour prendre en très monolithiques : elles proposent une unique
compte de nouveaux modes de conception comme démarche de développement, le plus souvent
l’approche par réutilisation. Dans ce papier, nous séquentielle et peu itérative. En conséquence, elles ne
définissons une méthode comme un ensemble de supportent pas des adaptations qui leur permettraient de
composants auxquels nous associons un graphe de prendre en compte différents types de situations.
réutilisation pour en assurer la recherche, l’adaptation et
Dans ce papier, nous proposons une nouvelle
l’assemblage. Cette nouvelle approche de la notion de
approche de la notion de méthode. Cette approche
méthode rend la réutilisation de composants plus
systématique, elle offre la possibilité d’adapter le considère une méthode comme un ensemble de
processus de développement en fonction du contexte et composants associé à un graphe de réutilisation. Les
elle fournit un guidage efficace dans la recherche de composants définissant une méthode sont de deux
solutions à des problèmes récurrents de développement. types : les composants-produit et les composants
Mots Clés : Systèmes d’information, Méthode de processus. Les premiers fournissent des solutions à des
conception de systèmes d’information, Conception par problèmes récurrents de développement, les seconds
réutilisation, Composant réutilisable, Composant- guident le déroulement du développement. Un graphe
produit, Composant-processus, But. de réutilisation supporte la recherche, l’adaptation et
l’assemblage des composants. Cette définition orientée
1 INTRODUCTION composant d’une méthode de conception présente
plusieurs avantages :
Les méthodes et les techniques de développement de i) Elle permet la mise en œuvre systématique d’une
Systèmes d’Information (S.I.) ont atteint une certaine approche par réutilisation,
maturité [Wolle, 1990], [Nanci, 2001]. Ces méthodes et
ces techniques sont largement utilisées dans les ii) Elle offre la possibilité d’adapter le processus de
entreprises et de nombreuses méthodes sont aujourd’hui développement à différents contextes,
instrumentées. Pourtant ces méthodes restent inadaptées iii) Elle guide le développeur dans la conduite du
dans de nombreux contextes, les résultats qu’elles processus et dans la recherche de solutions.
produisent ne sont pas toujours satisfaisants et elles ont
des difficultés à évoluer pour prendre en compte de Le papier est organisé en 5 sections. Dans la partie
nouveaux modes de conception. Basées sur l’hypothèse 2, nous donnons les limites des méthodes utilisées
que le développement d’un système d’information se actuellement en ingénierie des S.I. Dans la partie 3
fait à partir de rien, elles n’intègrent ni l’existence de nous introduisons la définition d’une méthode de
bibliothèques de composants ni même que le nouveau conception orientée composant. Dans les parties 4 et 5
système d’information doit s’intégrer à des briques nous présentons respectivement la base de composants
logicielles existantes. et le graphe de réutilisation, les deux éléments essentiels
d’une méthode orientée composant. La dernière partie
Les méthodes de développement utilisées présente les perspectives de recherche de ce travail.
actuellement intègrent peu de manière systématique
cette nouvelle approche. Nous pensons que la mise en

-1-
2 LES LIMITES DES METHODES rôle croissant et diversifié que vont jouer le Web et
ACTUELLES l’Internet (et l’Intranet) dans la conception et la mise en
ligne d’applications va amplifier ce phénomène. Cette
En conception de S.I., il est usuel de définir une approche vise bien sûr à améliorer la qualité des
méthode de conception comme un ensemble produits de développement mais aussi à apporter un
cohérent comportant: support méthodologique dans le processus de
i) Des modèles et des langages, il s’agit des développement de S.I.. Ainsi beaucoup de bibliothèques
concepts et des règles pour les utiliser de composants fournissent soit des solutions
permettant de décrire un S.I. à différents réutilisables soit des fragments de processus qui aident à
niveaux d’abstraction (conceptuel, résoudre des problème-types de développement. En
architecture, physique…), fonction de l’activité de développement pour laquelle
ii) Une démarche, il s’agit du processus ces composants sont réutilisables, ils peuvent prendre la
opératoire pour conduire le travail de forme soit de fragments de code, d’architecture ou de
conception, spécification soit de fragments de processus guidant la
iii) Des outils logiciels pour faciliter la mise spécification des besoins, la modélisation, ou encore la
en œuvre des modèles, des langages et de définition d’architectures.
la démarche.
Toutes les méthodes des années 80 ont été définies L’approche par réutilisation fait apparaître des
sur ce modèle [Rolland, 1988]. Elles ont permis une ruptures importantes à la fois dans les processus
meilleure maîtrise de la complexité, des coûts et des d’ingénierie mais aussi dans les produits d’ingénierie.
délais des projets informatiques. Elles ont aussi apporté On constate que les méthodes actuelles prennent peu en
une plus grande rigueur du développement en compte ce nouveau mode de conception rendant la
introduisant notamment des modèles de représentation réutilisation de composants peu systématique. Il devient
et des niveaux d’abstraction. Enfin elles ont largement nécessaire d’introduire explicitement dans le processus
contribué à une meilleure compréhension du métier de de développement des activités de recherche,
concepteur. d’adaptation et d’assemblage de composants.

Pourtant ces méthodes doivent évoluer pour plusieurs Elles n’apportent que peu d’aide dans la mise en
raisons. D’abord les systèmes d’information ont évolué œuvre des activités de développement. Cette limite est
en terme d’architecture (ils sont hétérogènes et très présente dans l’approche UML qui apparaît comme
distribués) et d’usage (ils sont ouverts et donc trop générale, ne donnant pas ou peu de directives pour
accessibles à une large variété d’usagers). Ensuite ces conduire le processus de développement. UML apparaît
méthodes ont été construites sur des hypothèses qui sont davantage comme une boite à outils, sans véritable règle
fausses aujourd’hui, par exemple, on sait que d’utilisation. Le processus unifié a été élaboré en partie
l’ensemble des besoins ne peut pas être donné une fois pour combler cette limite. Néanmoins, il reste encore
pour toute au début du développement, les besoins assez général. Par ailleurs, la maturité des méthodes se
évoluent et cette évolution doit être prise en compte traduit aujourd’hui par l’existence d’un savoir faire
durant le développement même du projet. Enfin ces important. La formalisation de ce savoir faire est faible,
méthodes présentent plusieurs limites importantes : rendant les bonnes pratiques et les bonnes solutions peu
partageables et peu réutilisables. Il semble intéressant de
Elles sont monolithiques. Elles proposent une capitaliser ces connaissances et de les décrire sous
démarche de développement figée et séquentielle. En forme de composants.
effet, la démarche est définie comme un ensemble
d’étapes formant un « bloc » indécomposable. Ces L’évolution des méthodes de conception laisse
méthodes sont souvent qualifiées de « lourdes » car envisager des ruptures importantes dans le
elles ne permettent pas de prendre en compte les développement des systèmes d’information. L’approche
particularités de certains projets. Aujourd’hui les par réutilisation, la mise en œuvre d’une démarche
équipes de développement ont besoin de démarches plus adaptable et le guidage du développement sont
génériques autorisant des adaptations (par exemple ne caractéristiques du renouveau de ces méthodes.
pas nécessairement passer par toutes les étapes) en
fonction du contexte. Plusieurs stratégies de 3 VERS UNE NOUVELLE
développement différentes devraient être proposées en DEFINITION DES METHODES DE
fonction des objectifs fixés, du domaine d’application CONCEPTION
ou de la nature du projet (taille, caractère novateur,
compétences des acteurs…).
Nous proposons dans cette section une nouvelle
définition de la notion de méthode. Cette définition
Elles ne supportent pas la réutilisation de s’appuie sur le langage UML (Unified Modeling
composants. L’utilisation de composants dans de Language) et sur le processus unifié UPM (Unified
nombreux domaines d’ingénierie s’impose peu à peu. Process Model). Elle peut être considérée comme une
L’approche à base de composants est particulièrement proposition visant à associer au langage UML une
utilisée en ingénierie des systèmes d’information. Le véritable démarche méthodologique.

-2-
dans le processus. Les activités de recueil des besoins,
Nous définissons une méthode par un quadruplet d’analyse… sont appelées « workflows », elles
{LProd, LProc, {BC}, Gr}. LProd est le langage de produit constituent des « mini » processus au sein du processus
c’est à dire des concepts et des notations pour décrire unifié.
des solutions. LProc est le langage de processus, il permet Le cycle de développement comporte plusieurs
de décrire toute démarche de développement conduisant itérations et les itérations sont organisées en quatre
au système d’information final. {BC} est une base de phases : Initialisation, Elaboration, Construction, et
composants qui fournit durant le développement des Transition. Tout d’abord, la phase d’initialisation
solutions prédéfinies, ou des fragments de démarches consiste essentiellement à recueillir et analyser les
guidant le développement. Enfin Gr est le graphe de besoins. Lors de cette phase, le pourcentage d’exécution
réutilisation, il suggère différentes stratégies de des workflows d’implémentation et de tests est très
développement, il guide le développeur à mettre en faible. Puis, la phase d’élaboration affine et
œuvre les stratégies et il préconise la réutilisation de opérationalise les besoins. Ensuite, la phase de
composants. construction crée le produit. Enfin, la phase de transition
se concentre sur l’optimisation et les tests du produit
3.1 Le langage de produit créé. Il est important de noter que chaque itération
Le langage de produit comporte un ensemble de contient les activités de recueil des besoins, d’analyse,
concepts qui supportent la spécification et la de conception,…
modélisation du système d’information à tous les
niveaux d’abstraction. Nous utilisons le langage UML Le langage du processus unifié est un langage générique
[Booch, 1998] comme langage de produit. Nous qui permet de définir différents processus de
pensons qu’il fournit un ensemble complet de concepts développement. Il supporte des mécanismes d’extension
pour modéliser un système d’information selon et d’adaptation pour spécifier des processus adaptés à
différents points de vue (fonctionnel, logiciel, matériel), différents contextes. En effet, il est possible de choisir,
selon différentes dimensions (statique ou dynamique), d’ajouter, et/ou de supprimer des workflows en fonction
selon différents niveaux d’abstraction (conceptuel, du domaine d’application. Par exemple, dans [Ambler,
logique, physique) ou encore selon différents niveaux de 2004], le processus unifié a été étendu avec un
détail. Le langage de produit permet de spécifier le workflow de modélisation d’entreprise pour évaluer
modèle de besoins, le modèle d’analyse, le modèle de notamment le coût du système à produire. Dans
conception… [Naiburg 2002], le processus unifié a été adapté pour le
domaine des applications bases de données.
Le langage de produit exploite la notion de stéréotype
définie dans UML pour créer de nouveaux concepts 3.3 La base de composants
adaptés à différents contextes d’utilisation. Par exemple, La base de composants constitue le noyau de la
le stéréotype « but » peut être créé dans le cadre de méthode. Elle est définie comme un ensemble de
l’utilisation d’une méthode de modélisation à base de composants fournissant des fragments de produit et des
buts. fragments de processus. Les premiers sont des solutions
« prêtes à l’emploi » pour élaborer les modèles de
3.2 Le langage de processus produit, les seconds proposent des démarches de
Le langage de processus est composé d’un ensemble de résolution de problèmes types de développement. Par
concepts et d’une notation pour définir la démarche de exemple, un composant fournissant le diagramme de
développement. La démarche organise la construction classe pour la modélisation d’un objet complexe est un
des différents produits de développement, décrits avec composant-produit, en revanche un composant décrivant
le langage de produit. Nous utilisons le langage du les tâches nécessaires à la construction d’un diagramme
processus unifié [Jacobson, 1999]. Ce langage est basé de cas d’utilisation est un composant-processus.
sur les notions d’itération et de « workflows ».
Il devient usuel de spécifier un composant comme un
Traditionnellement, les projets sont organisés en un triplet <Problème, Solution, Contexte> [Gamma, 1993],
ensemble de tâches : le recueil des besoins, l’analyse et [OMG, 2003], [Fowler, 1996]... Dans ce triplet, le
la conception, l’implémentation, les tests... L’exécution problème est un objectif de développement que
de ces tâches correspond au cycle de vie du système. souhaite atteindre le concepteur en réalisant un système
L’organisation des tâches est séquentielle et le d’information. La solution est un artéfact réutilisable
démarrage d’une activité est conditionné par la exprimé dans le langage de produit ou dans le langage
terminaison d’une autre. de processus. Le contexte définit la situation pour
laquelle la solution décrite dans le composant est
Dans le processus unifié, on retrouve les mêmes tâches adaptée.
organisées de manière itérative. Les activités de recueil
des besoins, d’analyse…sont donc mises en œuvre tout Cette approche -orientée problème- de la notion de
au long du processus de développement autorisant ainsi composant est intéressante, d’une part, parce qu’elle fait
par exemple l’ajout d’un nouveau besoin très tard dans clairement la distinction entre la spécification (partie
le processus ou encore un travail de prototypage très tôt problème) et la réalisation (partie solution) du

-3-
composant et d’autre part, l’orientation problème fournit être mises en œuvre par les concepteurs. Par exemple,
une forme d’abstraction dans laquelle il est possible de dans la mise en oeuvre du processus unifié
considérer les différentes solutions d’un même « opérationnaliser le cas d’utilisation Gérer les
problème comme un tout mais aussi de considérer demandes de prêt » est un but de développement qui
chaque solution avec ses spécificités. Nous considérons peut être réalisé de différentes manières.
que tous les composants de la base peuvent être décrits
selon cette approche. La Figure 1 illustre le modèle de composants et la
notation sur un exemple de composants métier. Ce
3.4 Le graphe de réutilisation composant propose plusieurs solutions pour le but
Le graphe de réutilisation définit plusieurs stratégies de « opérationnaliser le cas d’utilisation Gérer les
développement qui exploitent la base de composants. demandes de prêt » (noté sur la figure DG1) dans le
cadre d’une gestion de bibliothèques. Ce composant
Ce graphe est complémentaire de la base : il définit un fournit 4 scénarios possibles. Graphiquement, nous
ensemble de processus de développement possibles, utilisons des arcs-OU pour montrer les différents
chaque processus guide la recherche, l’adaptation et scénarios possibles de réalisation d’un but de
l’assemblage des composants de la base. Ce graphe développement. Chaque scénario est spécifié par un
comble donc certaines limites des méthodes actuelles, couple <Cj, Sj> où Cj est le contexte dans lequel le but
puisqu’il autorise différentes démarches et qu’il suggère de développement est réalisé et Sj est la solution
d’utiliser la base de composants. réutilisable basée sur le langage de produit.

Nous présentons plus en détail dans les sections Dans la Figure 1, les 4 contextes C1, C2, C3 et C4 sont
suivantes le modèle de composants, la typologie des définis à l’aide des buts métier G1, G2, G3, G4. Le
composants de la base, le modèle d’organisation de la contexte C1 est composé du but G1 « Contrôler
base des composants et le graphe de réutilisation. l’enregistrement de l’abonné » et de G4 « Contrôler la
disponibilité de l’exemplaire avec gestion de file
d’attente ». Le contexte C2 est constitué des buts G1 et
4 LA BASE DE COMPOSANTS
G3 « Contrôler la disponibilité de l’exemplaire sans
gestion de file d’attente ». Le contexte C3 utilise G1, G2
4.1 Le modèle de composants « Vérifier la validité de l’abonné » et G4. Le contexte
La base de composants est vue comme un ensemble de C4 utilise G1, G2 et G3. Les contextes permettent de
services pouvant être utilisés dans la mise en œuvre de discriminer les quatre scénarios et aident le concepteur à
la méthode. La méthode peut suggérer d’utiliser des choisir une solution.
composants très variés comme les patterns de
conception de Gamma [Gamma, 1993], les « analysis
patterns » [Fowler, 1996], les patterns architecturaux Composant « opérationnaliser le cas d’utilisation
[Larman, 2003], les « process patterns » [bergner, Gérer les demandes de prêt »
1998]…
« DG1 »
«C1»= G1 G4
Le modèle de composants permet de considérer toute
forme de composant (composants métier, composants
«C3»= G1 G2 G4
de conception, composants logiciels, ….) de manière « S1»
homogène. Ces composants peuvent être accessibles via
le Web dans des banques de composants universelles.
Ces composants peuvent aussi simplement être partagés «C2»=G1 G3 «C4»= G1 G2 G3
par un collectif ciblé au sens d’une communauté de
pratique [Wenger, 1998]. « S2 » « S3 » « S4 »
Le modèle de composants est basé sur une orientation
problème [Guzelian, 2004] et les problèmes de
développement sont exprimés sous forme de buts
[Grosz, 2001]. Figure 1 : Illustration d’un composant orienté buts
Un composant réutilisable est défini par un couple
Les solutions Sj sont en général composées d’artefacts.
<DGi, {Sc}> où DGi est un but de développement et
Un artéfact est spécifié à l’aide du langage de produit ou
{Sc} est un ensemble de scénarios. Nous désignons un
du langage de processus. Il peut s’agir d’un diagramme
composant par le nom du but de développement.
de séquence, d’une description narrative d’un cas
Chaque scénario décrit une manière particulière de
d’utilisation, ou encore d’un diagramme de classes
satisfaire le but de développement dans un contexte
UML.
précis. Il peut donc exister plusieurs façons de réaliser le
même but de développement. Les buts de
Nous distinguons deux types de contexte : les contextes
développement correspondent aux activités qui
décomposables et les contextes non décomposables. Si
jalonnent le processus de développement et qui doivent

-4-
le contexte d’un scénario d’un composant est utilisés en conception et les composants de type
décomposable, cela signifie que le composant peut être programmation ont des solutions de type diagrammes
raffiné. Dans le cas contraire, le composant est « fini » classes Java ou C++ utilisées en programmation.
et sa solution est réutilisable. Suivant le type de
contexte nous utilisons une flèche pleine (contexte non
décomposable) ou en pointillés (contexte Composant-méthode
décomposable). Par exemple, le contexte C3 de la
Figure 1 est décomposable puisqu’il contient au moins
un but complexe qui peut être décomposé d’une ou
plusieurs façons. En effet, le but G2 contenu dans C3 Composant-produit Composant-processus
peut être décomposé en deux sous buts : vérifier l’état
des cotisations et vérifier le quota d’emprunt en cours.
Ainsi, le composant « DG1 » peut être raffiné par un
autre composant nommé « opérationnaliser le cas Composant- Composant-
d’utilisation Vérifier la validité de l’abonné » et métier Initialisation
contenant les différentes solutions de réalisation du but
G2. Composant- Composant-
logiciel Elaboration
4.2 Typologie des composants
En conception de systèmes d’information, deux types de Composant-
Composant- Construction
connaissance peuvent être réutilisées :
architecturaux
- Les connaissances de domaine, ce sont les
connaissances qui caractérisent une classe de systèmes
et qui sont réutilisables dans le développement des Composant-
systèmes d’une même classe. Il peut s’agir des Transition
connaissances métier (le métier de la Banque, de la
gestion de bibliothèque…), des connaissances en Figure 2 : Typologie de composants
architecture (Client / serveur, Objets distribués…) ou
encore des connaissances en programmation De façon analogue, nous distinguons plusieurs types de
(représentation d’objets complexes, partage des composants-processus relativement aux phases du
responsabilités entre classes…). développement. Ainsi les composants-processus
- Les connaissances de processus, ce sont des peuvent être des composants d’initialisation, des
pratiques, des manières de résoudre un problème qui composants d’élaboration, des composants de
sont récurrentes dans le développement de systèmes. Par construction, et des composants de transition. Par
exemple la démarche de construction d’un diagramme exemple un composant de type initialisation propose un
de cas d’utilisation suggère i) d’identifier les acteurs, ii) fragment de démarche permettant de guider
de définir les usages (ou cas d’utilisation) du système l’identification des besoins ou bien la construction d’un
souhaités par chaque acteur et iii) d’effectuer un diagramme préliminaire de classes d’analyse.
diagramme de séquence pour modéliser l’interaction
entre les acteurs et le système pour chaque cas 4.3 L’organisation des composants
d’utilisation. L’ensemble des composants de la base est exprimé dans
Relativement à ces deux types de connaissances, nous les termes du modèle de composants. Cette base peut
distinguons dans une base deux types de composant : les être complexe car elle intègre en général une large
composants-produit et les composants-processus variété de composants. Dans cette sous-section, nous
(Figure 2). définissons une structure d’organisation de la base de
composants. L’organisation des composants est basée
Dans les composants-produit, la partie solution contient sur deux types de graphe sans cycle : les arbres et les
des artefacts réutilisables tels que des diagrammes de graphes.
classe, des cas d’utilisation… A la différence, la
solution fournie par les composants-processus contient L’organisation des composants est dirigée par le
des fragments de démarche. Les composants-produit ont raffinement des composants. Le contexte associé à une
une partie solution exprimée avec le langage de produit solution peut être décomposable, dans ce cas, le
et les composants processus contiennent des solutions composant peut être raffiné. Un contexte peut être
exprimées dans le langage de processus. Nous complexe et plusieurs de ses éléments peuvent être
distinguons aussi dans les composants produits ceux qui décomposés, dans ce cas le composant peut être raffiné
permettent la réutilisation de connaissance métier, de par plusieurs composants. Nous avons précisé
connaissance d’architecture et de connaissances de précédemment (cf. section 4.1) dans l’exemple de la
programmation. Selon leur type, ces composants seront Figure 1, que le contexte C3 du composant
utilisés dans un « workflow » particulier. Par exemple, « opérationnaliser le cas d’utilisation Gérer les
les solutions des composants-produit de type demandes de prêt » était décomposable. Ainsi, ce
architecture sont des diagrammes de déploiement UML composant peut être raffiné par un autre composant.

-5-
composants métier, la forêt des composants
Lien de raffinement architecturaux…mais aussi pour les composants-
«ET Cj » processus la forêt des composants d’initialisation, la
Cp1 forêt des composants d’élaboration…

«ET C2» Profondeur 1 «DG1»


Cp11 Représentation
Cp12
« C1 » « C2 » du composant
(arbre de
« OU » décision
«ETC22 » Profondeur 2
« ET C23 » OU)
S1 S2
Figure 3 : Raffinement de composant Raffinement
du composant
(arbre de « ET C2 »
Nous symbolisons le lien de raffinement pour un
décision ET)
contexte précis par une double flèche « ET Cj » (Figure «DG11»
3). Le raffinement d’un composant est décrit par un Profondeur 3 «DG12»
arbre de décisions ET. Le résultat du raffinement d’un
composant donne une hiérarchie de composants. Il « C21 » « OU »
existe une hiérarchie de composants pour chaque but de « OU
Profondeur 4 « C23 » « C24 »
développement. « C22 »
S21 S22 S23 S24
D’autre part, chaque composant intègre plusieurs
solutions possibles pour un même but de
développement. Un composant peut être vu comme un
«ET C22 » «ET C23 »
arbre de décisions OU dans lequel les arcs-OU
symbolisent les différentes solutions possibles d’un
problème de développement.
Au moment de la réutilisation, les arcs-OU guident le Figure 4 : Arbre de décisions ET/OU
concepteur à choisir une solution selon le contexte alors
que les arcs-ET guident le concepteur dans le Les arbres et les forêts permettent de définir une
raffinement de contexte. L’alternance de ces deux types structure de composants. Cette structure ne prédéfinit
d’arbre conduit à un arbre de décision ET/OU. Nous pas de manière particulière de réutiliser les composants
nommons les arbres par le but racine c'est-à-dire par le pour développer un système d’information. Cette
but de développement de plus haut niveau. structure supporte en effet plusieurs stratégies de
développement à base de composants, par exemple on
La Figure 4 représente un arbre de décision ET/OU peut choisir soit d’identifier les cas d’utilisation et
où le but DG1 pourrait être « opérationnaliser le cas ensuite de les opérationnaliser pour trouver les classes
d’utilisation Gérer les demandes de prêt ». Cet arbre de soit de commencer directement par les diagrammes de
décisions ET/OU contient un ensemble de solutions classes. Le graphe de réutilisation a pour objet de définir
possibles qui opérationnalisent le cas d’utilisation gérer les différentes manières de développer un système par
les demandes de prêts. Ces différentes solutions réutilisation des composants de la base.
correspondent à la variabilité des règles de gestion qui
sont utilisées dans les différentes bibliothèques (gérer 5 LE GRAPHE DE REUTILISATION
les demandes en attente, prendre en compte l’état des
cotisations des abonnés pour traiter une demande…). La base de composants est un ensemble de
composants organisés en arbres et forêts. Gr est un
Le nombre de buts de développement jalonnant le graphe de réutilisation qui définit plusieurs stratégies de
processus de développement est important si l’on développement.
considère une méthode couvrant la globalité des
activités de développement, en conséquence le nombre Le graphe de réutilisation Gr est un graphe
d’arbres de décisions ET/OU est lui aussi important. Le Etat/transition [Harel, 1987] dans lequel les états sont
concept de forêt constitue un mécanisme de des activités et les transitions expriment le passage
structuration des arbres de décisions ET/OU. d’une activité à une autre. Chaque chemin de ce graphe
définit une manière particulière de développer un
Une forêt est un ensemble d’arbres de décisions système d’information en réutilisant les composants de
ET/OU. Les forêts sont utilisées pour regrouper les la base. Gr est composé de deux sous graphes : Le
composants selon différents critères. Nous regroupons graphe-produit Gprod et le graphe processus Gproc
les composants-produit et les composants-processus (Figure 5).
conformément à la typologie de la Figure 2. On trouve
ainsi pour les composants-produit, la forêt des

-6-
ces forêts est guidé par la solution choisie dans un des
[sinon ] composants-processus sélectionné dans le graphe Gproc.
Gproc Gprod
[Fin du parcours de Gr ]
[chercher des [chercher des
[Fin du parcours de Gr ] composants-métier] composants-logiciel]
Gr
Figure 5 : Graphe de réutilisation [chercher des composants-architecturaux]
[sinon] [sinon]
Les deux sous graphes Gprod et Gproc sont composés Parcourir Parcourir Parcourir
de chemins permettant de parcourir les arbres et les la forêt F1 la forêt F2 la forêt F3
forêts de la base de composants BC. Gproc exprime
différentes stratégies possibles. Le choix d’une solution [parcourir Gproc]
des composants-processus mène à des fragments de
démarche. Chaque fragment de démarche choisi est [parcourir Gproc] [parcourir Gproc]
exécuté dans Gprod afin d’obtenir des fragments de
Gprod
produit réutilisable. Après avoir choisi et assemblé les
solutions de type produit, le graphe Gproc est parcouru à Figure 7 : Graphe-produit Gprod
nouveau pour continuer à choisir et à construire une
stratégie de développement et ainsi de suite... Au fur et Dans Gprod, les activités de type « parcourir forêt »
à mesure que la démarche est construite dans Gproc, elle sont complexes : elles consistent à sélectionner des
est exécutée dans Gprod. On alterne donc le parcours des arbres et à les parcourir. Ces activités font l’objet d’une
activités de Gproc et de Gprod. description par un sous graphe-produit. Par exemple
l’activité de type “ Parcourir la forêt F1 ” peut être
Le graphe de processus Gproc (Figure 6) est constitué explicitée par un sous graphe-produit que nous ne
de 4 activités de type « parcourir la forêt F ». Ces détaillons pas ici. Ce sous graphe décrit différents
activités concernent la forêt Fi des composants- parcours des arbres contenus dans la forêt F1.
initialisation, la forêt Fe des composants-élaboration, la
forêt Fc des composants-construction et la forêt Ft des En associant dans une méthode, une base de
composants-transition. Chaque activité peut-être itérée composants à un graphe de réutilisation, nous
une ou plusieurs fois et consiste à sélectionner des définissons une approche systématique de
composants-processus puis à choisir une solution au développement par réutilisation. Par ailleurs, les
sein de ces composants. Ces solutions sont des composants-processus définis dans la base de
fragments de démarche. Il suffit alors d’appliquer ces composants permettent de considérer la méthode
solutions dans le graphe Gprod pour obtenir des comme un ensemble de briques autorisant différentes
fragments de produit. façons de les assembler. Les composants-processus
rendent la méthode non monolithique et le graphe de
réutilisation apporte les directives pour organiser ces
[parcourir Gprod] composants selon un processus cohérent.

[parcourir Gprod] [parcourir 6 CONCLUSION


Gprod]
Dans cet article, nous avons présenté une définition de
Parcourir Parcourir Parcourir méthode orientée composant. Une méthode est
la forêt Fi la forêt Fe la forêt Fc considérée comme un ensemble de composants associé
à un graphe de réutilisation. Les composants-produit
[sinon ] [sinon ] répondent à des problèmes de développement que doit
[itérer ] [itérer ] [itérer ] résoudre le concepteur de systèmes d’information. Les
composants-processus fournissent des démarches pour
[sinon ] conduire le développement.
Parcourir
la forêt Ft Le raffinement des composants induit alors une
[sinon ] Gproc organisation des composants en arbres de décisions
ET/OU. Les composants organisés en arbres et en forêts
Figure 6 : Graphe-processus Gproc sont associés à un graphe de réutilisation qui supporte
d’une part, différentes stratégies de développement
Le graphe de produit Gprod (Figure 7) est constitué (sous graphe de processus) et d’autre part, la recherche
de 3 activités de type « parcourir la forêt F ». Ces de solutions réutilisables pour résoudre un problème de
activités concernent la forêt F1 des composants-métier, développement dans un contexte particulier (sous
la forêt F2 des composants-architecturaux et la forêt F3 graphe de produit). En alternant le parcours des deux
des composants-logiciel. Le choix du parcours d’une de

-7-
sous graphes, la réutilisation de composants devient [Jacobson, 1999] Jacobson I. , Booch G., Rumbaugh J.,
systématique. The unified Software Development Process, Addison-
Wesley Publishing Company, ISBN 0-201-57169-2,
Nous travaillons actuellement dans trois directions : (1999).
— Tout d’abord, nous devons étendre le modèle [Larman, 2003] Larman C., “UML et les Design
d’organisation des composants et le graphe de Patterns”, 2nd Ed, CampussPress , (2003).
réutilisation. Nous cherchons à exploiter la notion de [Naiburg, 2002] Naiburg E.J., Maksimchuk R.A.,
forêt pour gérer des composants de différents domaines “Bases de données avec UML”, CampusPress, (2002).
d’applications et de différentes méthodes. Le graphe de [Nanci, 2001] Nanci D., Espinasse E., “Ingénierie des
réutilisation doit être étendu en conséquence. systèmes d’information : MERISE 2ème génération”,
— Puis, nous souhaitons enrichir le graphe de processus Vuibert (2001).
Gproc en définissant un sous graphe-processus tel que [OMG, 2003] OMG, “Reusable Asset Specification
nous avons défini un sous graphe-produit au niveau des (RAS)”, Draft RFC submitted to OMG, version 2.1,
forêts. L’affinement de Gproc faciliterait le choix d’une August 2003. Copyright © 2003 IBM, Flashline,
stratégie de développement et guiderait l’utilisation du LogicLibrary, ComponentSource, and Adaptive,
graphe Gprod. available at :
— Enfin nous développons un outil qui supporte la www.rational.com/media/products/Resuable_Asset_Spe
spécification et la mise en œuvre de méthodes orientées cification_draft.pdf.
composant. Les composants sont implantés en XML. Le [Rolland, 1988] Rolland C., Foucaut O., Benci G.,
prototype doit permettre de mettre en œuvre une “Conception de systèmes d’information : La méthode
méthode selon le graphe de réutilisation et de guider le REMORA”, Eyrolles 88 (1988).
concepteur dans le développement de systèmes par [Wolle, 1990] Wolle T., Hagelstein J., Macdonald J.G.,
réutilisation. Rolland C., Sol H.G., Van Assche F.J.M., Verrijn-Stuart
“Méthodologies pour les systèmes d’information”,
BIBLIOGRAPHIE guide de référence et d’évaluation, Dunod, (1990).
[Wenger, 1998] Wenger E., “Communauties of
[Ambler, 2004] Ambler Scott W., Nalbone J. practices, learning, meaning and identity”, Cambridge
“Enterprise Unified Process: Enhancing The Rational University Press, (1998).
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”, München, (29
th July 1998).
[Booch, 1998] Booch G., Rumbaugh J., Jacobson I.,
“The Unified Modeling Language UserGuide”, The
Addison-Wesley Object Technology Series, Addison-
Wesley 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, ECOOP’93 Conference Proceedings,
p.406-431, Zurich, Switzerland, July 26-30 (1993).
[Grosz, 2001] Grosz G., Roland C., “ de la modélisation
conceptuelle à l’ingénierie des besoins ”, chapter 4 in
Cauvet C., Rosenthal-sabroux C., Ingénierie des
systèmes d’information, éditions Hermès, ISNB 2-7462-
0219-0, (02/2001).
[Guzelian, 2004] Guzelian G., Cauvet C., Ramadour P.,
“Conception et réutilisation de composants : une
approche par les buts”, Actes du XXIIème Congrès
INFORSID, Biarritz, (2004).
[Harel, 1987] Harel D., Statecharts: “A visual formalism
for complex systems”, Science of Computer
Programming, 8(3):231–274, (June 1987).

-8-

Vous aimerez peut-être aussi