ANALYSE DES DEMARCHES DE TYPE XUP

METHODES DE DEVELOPPEMENT CENTREES COMPOSANTS

Livrable 5.1. du projet TRAFIC

Transports : Réutilisation, Adaptation, Fiabilité,
Intermodalité et Coopération inter-systèmes

Projet de la Région Rhône-Alpes 2003-2005

Thématiques prioritaires
Thème 6 : Aide à la décision – Transports

Auteurs : Emmanuel Jausseran, Agnès Front, Jean-Pierre Giraudin,

Dominique Rieu.

Date : Mars 2005

1
 TABLE DES MATIERES
Table des Matières ............................................................................................................................... 2
Introduction.......................................................................................................................................... 3
Partie A Comparatif orienté méthode.............................................................................................. 5
1 Critères d’évaluation.............................................................................................................. 5
1.1 Origines et évolutions ....................................................................................................... 5
1.2 Utilisation industrielle ou académique.............................................................................. 6
1.3 Cycle de développement ................................................................................................... 7
1.4 Adaptabilité du processus de développement ................................................................... 8
1.5 Langages de modélisation ............................................................................................... 11
1.6 Outils de modélisation..................................................................................................... 11
1.7 Plateformes de développement cibles ............................................................................. 13
1.8 Complexité d’apprentissage ............................................................................................ 13
2 Tableau de synthèse ............................................................................................................. 14
Partie B Comparatif orienté composants....................................................................................... 15
1 Critères d’évaluation............................................................................................................ 15
1.1 « Design for reuse » versus « Design by reuse » ............................................................ 15
1.2 Composants et architecture logicielle ............................................................................. 17
1.3 Patterns ........................................................................................................................... 18
1.4 Niveaux d’introduction et représentation des composants.............................................. 20
1.5 Traçabilité des composants ............................................................................................. 22
1.6 Gestion des configurations.............................................................................................. 22
2 Tableau de synthèse ............................................................................................................. 24
Conclusion ......................................................................................................................................... 25
Abréviations ....................................................................................................................................... 27
Bibliographie...................................................................................................................................... 28
Annexes.............................................................................................................................................. 30
A.1 Fiche signalétique : Catalysis.......................................................................................... 30
A.2 Fiche signalétique : Rational Unified Process (RUP) ..................................................... 31
A.3 Fiche signalétique : Select Perspective ........................................................................... 33
A.4 Fiche signalétique : Two Tracks Unified Process (2TUP).............................................. 35
A.5 Fiche signalétique : eXtreme Programming (XP)........................................................... 37

2
 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, M. McIlroy, dans une conférence de l’OTAN (Organisation du
Traité de l’Atlantique Nord) sur l’ingénierie du logiciel (article réédité en 1976 [MCI 76]), annonce
une idée tout à fait nouvelle pour l’époque : celle de développer les logiciels « à partir de
bibliothèques de composants logiciels produits en masse ».

Cette idée a mis un certain temps pour faire son chemin. L’industrie du composant n’a vraiment
émergé que dans les années 90. En effet, le développement des logiciels à base de composants
(CBDSE, Component-Based Development Software Engineering) est devenu une réalité avec
l’évolution des technologies web et Java qui ont facilité la distribution, la recherche, et
l’interopérabilité des composants.

De nombreuses technologies à base de composants sont aujourd’hui proposées : CORBA de

l’OMG, EJB de SUN, COM/DCOM et .NET de Microsoft, etc.

Aujourd’hui, dans tous les systèmes, quel que soit le secteur d’activité concerné, les ventes de
logiciels à base de composants augmentent constamment [AVA 02].

Les avantages potentiels sont en effet multiples :

diminution considérable des coûts et du temps de conception par la réutilisation ou l’achat de
composants déjà réalisés,

augmentation de la fiabilité des logiciels par l’utilisation de composants largement testés,

réduction des coûts de maintenance et d’évolution des systèmes par le remplacement de
composants,

rentabilisation des développements par la vente de « COTS Components » (Commercial Of The
Shelf Component, ou composants sur étagère en français).

Il existe donc un réel enjeu sur l’utilisation et la réutilisation de composants. De plus, cela va dans
le sens des entreprises qui, actuellement, doivent régulièrement et rapidement s’adapter à de
nouveaux besoins. Ces évolutions nécessitent la mise en œuvre de systèmes d’information flexibles
et rapidement adaptables. Créer et faire évoluer des logiciels par assemblage de composants est
devenu incontournable.

Si les technologies à base de composants ont atteint un niveau de maturité et d’utilisation important
dans le monde industriel, les méthodes de développement à base de composants existantes tardent à
s’imposer dans les entreprises. Pourquoi ? Quels sont les points forts et les points faibles de ces
méthodes ? A partir de quel moment ces méthodes considèrent-elles et intègrent-elles la notion de
composant ? De quelle manière ? Quelle est ou quelles sont, aujourd’hui, les meilleures méthodes ?
Quelle serait la méthode idéale ? Du moins, quelles sont les améliorations attendues dans les
prochaines années ?

L’objectif de ce livrable consiste à apporter des éléments de réponse à ces questions. Pour cela,
nous établissons un comparatif des méthodes de développement à base de composants suivantes :

Catalysis proposé en son temps par la société Icon Computing,

Rational Unified Process (RUP) proposé par la société IBM Rational Software,

Select Perspective proposé par la société Select Business Solutions Inc.,

Two Track Unified Process (2TUP) proposé par la société Valtech,

eXtreme Programming (XP), proposé par la société First Class Software Inc.

3
La première partie de ce comparatif permet de se familiariser avec ces différentes méthodes en
faisant abstraction des composants. La deuxième partie s’attache plus particulièrement à étudier
l’implication des composants dans chaque processus de développement. Enfin, la conclusion apport
des réponses aux questions posées dans cette introduction. Les annexes proposent une fiche
signalétique pour chaque méthode prise en compte dans ce comparatif.

4
 Partie A Comparatif orienté méthode

Cette première partie du comparatif s’attache aux aspects généraux relatifs à toutes les méthodes de
développement. Il convient donc, au préalable, de préciser ce qu’est une méthode de
développement. Pierre-Alain Muller [MUL 98] explique qu’une méthode, au sens large du terme,
définit une démarche reproductible pour obtenir des résultats fiables. De manière plus précise, une
méthode d’élaboration de logiciels décrit :

les règles de modélisation et de construction de systèmes logiciels de manière fiable et
reproductible,

les règles de mise en œuvre qui décrivent l’enchaînement des actions, l’ordonnancement des
tâches et la répartition des responsabilités.

Cette partie se décompose en deux sections :

présentation et application des critères d’évaluation aux méthodes en présence,

consolidation des informations recueillies dans un tableau de synthèse.

1 Critères d’évaluation
Les critères retenus pour ce comparatif orienté méthode sont les suivants :

origines et évolutions,

utilisation industrielle ou académique,

cycle de développement,

adaptabilité du processus de développement,

langages de modélisation,

outils de modélisation,

plateformes de développement cible,

complexité d’apprentissage.

1.1 Origines et évolutions

La figure 1 présente de manière chronologique l’apparition et les évolutions des différentes
méthodes concernées par ce comparatif et en parallèle les différentes versions du langage de
modélisation unifié UML (Unified Modeling Language).
UML 0.8 UML 1.1 UML 1.2 UML 1.3 UML 1.4 UML 1.5 UML 2.0 (en cours de validation)

XP

2TUP avec UML 1.3 2TUP avec UML 1.4

CATALYSIS CATALYSIS avec UML 1.0

RUP 4.0 RUP 4.0 RUP 5.0 RUP 5.5 RUP 2000 RUP 2001 RUP 2002 RUP 2003

SELECT PERSPECTIVE SELECT PERSPECTIVE (approche orientée objet et composants)

... 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 ...

Temps

Figure 1 : Chronologie des méthodes comparées

5
Contrairement aux autres méthodes toujours utilisées actuellement, nous pouvons remarquer que le
développement de la méthode Catalysis a été arrêté en juin 1998 (suite au rachat de la société Icon
Computing par la société Computer Associates).

Nous pouvons également voir que la méthode RUP [KRU 03] évolue régulièrement en terme de
nouvelles versions.

RUP et Select Perspective [SEL01 03] constituent les méthodes les plus anciennes et les plus
utilisées.

XP et 2TUP peuvent être considérées comme les méthodes les plus récentes et innovantes.

Il est intéressant de voir que toutes les méthodes de ce comparatif ne sont pas nées de rien. Elles ont
emprunté et capitalisé des concepts, des modèles et des démarches de méthodes plus anciennes. La
figure 2 permet de s’en rendre compte.

Périmètre du comparatif des méthodes de développement à base de composants

XP
Beck, 2TUP
Cunningham Rocques, Vallée
Select Perspective 1999
2000 RUP
(orienté CBD)
Allen, Frost Booch, Jacobson,
Catalysis
1997 Rumbaugh
D'Souza et Wills
1996
1992 - 1999

UML
Temps

Booch, Jacobson,
Rumbaugh OORAM
DSDM Select Perspective 1996 Reenskaugh,
Consortium DSDM Allen, Frost Wold, Lehne
1995 1994 Syntropy Fusion
1995
Cook et Coleman
Daniels et al.
1994 1994
Objectory
RAD Catalyst Booch Jacobson et al. OMT
Circa CSC Booch 1992 Rumbaugh
1991 1991 1991 1991
BON
Meyer
Spécification 1988
formelle
Larch, Z, VDM
1980

Figure 2 : Origines des méthodes comparées

Nous pouvons remarquer que la majeure partie des méthodes de développement à base de
composants de ce comparatif utilise le langage de modélisation UML [OMG 03a], [MUL 98].

Catalysis s’appuie sur un large éventail de démarches (Bon, Fusion, OMT, OORAM, Syntropy,
UML) qui fait d’elle une méthode particulièrement riche.

XP est le seul à se démarquer de par ses origines RAD (Rapid Application Development) et une
approche dénuée de modélisation.

1.2 Utilisation industrielle ou académique

Compte tenu de ce qui a été dit dans le paragraphe précédent, la méthode Catalysis a vécu pendant
une période limitée, de 1992 à 1999. Effectivement sa société adoptive, Icon Computing Inc, a fait
l’objet d’un rachat par le groupe Computer Associates en juin 1998.

Depuis, Catalysis n’est plus utilisée dans le monde industriel. En revanche, cette démarche
constitue encore aujourd’hui un formidable gisement d’informations et d’idées utilisé couramment
par le milieu universitaire [CAT01 99].

Les autres méthodes sont utilisées en milieu industriel, dans le cadre de projets concrets.

6
En terme de nombre d’entreprises utilisant ces méthodes, les informations sont approximatives. Per
Kroll et Philippe Kruchten indiquent dans leur livre [KRO 03] que le RUP est utilisé par une
dizaine de milliers d’entreprises.

Pour 2TUP, Pascal Rocques et Franck Vallée de la société Valtech [ROC 02], parlent d’un retour
d’expérience sur deux cents projets dans des secteurs variés (banque, assurance, administration,
industrie, etc.).

Select Business Solutions, avec Select Perspective, reste discret sur le nombre de clients ou de
projets.

En ce qui concerne XP, cette méthode en est encore à une phase de lancement pour ce qui est de
son application à grande échelle [BEN 02a].

1.3 Cycle de développement

Toutes les méthodes de ce comparatif utilisent un cycle de développement incrémental itératif.
Avant de confronter chaque démarche sur ce point, il convient de se familiariser avec certaines
notions fondamentales telles q’un processus de développement, des phases, des itérations ou bien
encore un incrément.

Un processus de développement logiciel regroupe les activités à mener pour transformer les
besoins d’un utilisateur en système logiciel [JAC 00], comme illustré en figure 3.

Besoins Processus Système

de l'utilisateur de développement logiciel logiciel

Figure 3 : Processus de développement logiciel

Le développement d’un produit logiciel, destiné à la commercialisation, est une vaste entreprise qui
peut s’étendre sur plusieurs mois, voire sur une année ou plus. Il n’est pas inutile de découper le
travail en plusieurs phases qui sont autant de mini-projets. Chacun d’entre eux représente une
itération qui donne lieu à un incrément. Les itérations désignent des étapes de l’enchaînement
des activités, tandis que les incréments correspondent à des stades de développement du produit
[JAC 00]. La figure 4 présente un processus de développement générique proche de celui du RUP.

Processus de développement logiciel itératif incrémental

Phase 1 Phase ... Phase n

Itération Itération Itération Itération

... ...
1 ... ... n

Incrément 1 Incrément ... Incrément ... Incrément ... Incrément n-1 Incrément n

Temps

Ac
1

tiv
ité

ité
tiv

2
Ac

Itération
1
n
ité

...
iv
ct
A

Figure 4 : Exemple de processus de développement itératif incrémental

L’utilisation d’un processus itératif présente de nombreux avantages :

limitation des coûts en terme de risques, aux strictes dépenses liées à une seule itération,

limitation des risques de retard de mise sur le marché du produit développé,

accélération du rythme de l’ensemble du développement,

7

adaptation aux évolutions des besoins et prise en compte des exigences au fur et à mesure des
itérations,

amélioration de la qualité du produit final.

Pour en revenir à notre comparatif, il faut savoir que RUP et 2TUP s’appuient sur une
implémentation du processus unifié [JAC 00] qui est un processus de développement logiciel
modélisé avec le langage de modélisation unifié UML (Unified Modeling Language). En plus d’être
itératif et incrémental, ce processus est également conduit par les cas d’utilisation, piloté par les
risques et centré sur l’architecture [ROC 01].

2TUP se distingue du RUP et des autres méthodes par son cycle de vie en Y [ROC 01]. L’avantage
de ce cycle, présenté dans la fiche signalétique du 2TUP en annexes, permet de paralléliser et de
dissocier les besoins fonctionnels des besoins techniques et donc de mieux répartir les contraintes
initiales en amont du projet.

Avec son modèle SMaC (Supply Manage Consume) figurant en annexes, Select perspective
présente un processus de développement résolument orienté CBD (Component Based
Development). De plus, ce modèle a pour avantage de séparer clairement le service de fourniture de
composants, le service d’administration de composants et le service d’utilisation des composants
pour les assembler et offrir une solution logicielle [SEL02 03]. Nous reviendrons sur ce cycle de
développement particulier dans le chapitre « comparatif orienté composants ».

A l’opposé de toutes les autres méthodes, XP met en avant un processus de développement réduit
au maximum, c’est-à-dire aux étapes de conception (légère et sans modélisation), d’implémentation
et de déploiement [BEN 02a].

Pour terminer sur ce critère d’évaluation, nous allons reprendre le cycle de vie du RUP qui, comme
il a été dit précédemment, est le plus riche de toutes les méthodes. La figure 5 permet de voir la
couverture, en terme d’activités et de phases, des différentes méthodes sur le processus de
développement en matrice du RUP.
Phases
Analyse des
Elaboration Construction Transition
Activités besoins

RUP
Modélisation métier
Catalysis
Exigences

Analyse et conception
2TUP
Implémentation
XP
Tests

Déploiement
Gestion de la configuration Select Perspective
et des changements
Gestion de projet

Environnement

It. 1 It. 2 ... ... ... ... ... ... ... ... ... ... It. n

Itérations

Figure 5 : Projection comparative sur la matrice du RUP

NB : les courbes de la figure 5 représentent, à titre indicatif et pour un projet donné, la montée en
charge des activités dans chaque itération de phase.

1.4 Adaptabilité du processus de développement

Grâce à ses patterns de processus (par exemple, pattern 13.3 « cycle de développement court »
[D’SO 98]), Catalysis permet d’étendre et de spécialiser son processus de développement. Il est
également possible d’utiliser des patterns pour la modélisation métier. L’utilisation (ou la

8
réutilisation) de pattern est abordée plus amplement dans la section 2 consacrée au comparatif
orienté composants.

Comme en atteste sa fiche signalétique dans les annexes, RUP s’appuie sur un processus avec un
large spectre d’activités (disciplines). Cette méthode est paramétrable afin d’utiliser tout ou partie
des différentes activités, en fonction des besoins de l’entreprise et de la taille du produit logiciel
cible [KRO 03].

Par ailleurs, différents acteurs sont impliqués dans le développement d’un produit logiciel tout au
long de son cycle de vie. Certains financent le produit, tandis que d’autres le planifient, le
développent, le gèrent, le testent, l’utilisent ou en bénéficient [JAC 00].

Il est également intéressant de prendre en compte les acteurs qui interviennent directement ou
indirectement sur le projet et par conséquent au sein même du processus de développement.

A ce propos, trois méthodes prennent en compte les ressources humaines directement dans la
configuration de leur processus de développement, formalisant ainsi les acteurs du développement :
RUP, Select Perspective et XP.

XP se préoccupe du rôle du client et d’une équipe de développement composée de programmeur(s),

testeur(s), traqueur(s)1 (trackers), d’un manager et d’un entraîneur2 (coach). Un acteur peut cumuler
plusieurs rôles [BEN 02a].

Select Perspective et RUP vont plus loin avec la personnalisation du processus de développement
et la possibilité de préciser les intervenants d’un projet, leur(s) rôle(s), leur(s) responsabilité(s) dans
les différentes activités. C’est notamment le cas, grâce à des outils logiciels tels que « Process
Workbench » avec « RUP Modeler » pour le RUP [KRO 03] et « Process Director » avec « Process
Studio » pour Select Perspective [SEL04 03].

La figure 6, ci-après, présente la copie d’écran du produit IBM Rational RUP dans laquelle est
détaillé le rôle du chef de projet.

1
Rôle du traqueur : assurer le suivi de l’avancement des tâches de développement, détecter et faire
remonter les problèmes le cas
échéant [BEN 02a].
2
Rôle de l’entraîneur : mettre en place la méthode XP, organiser et animer les séances de planification,
assister le client dans la
rédaction de ses premiers scénarii, vérifier que chaque membre de l’équipe remplit bien son rôle
[BEN 02a].

9
 Arborescence des
informations
relatives à l’équipe
et au cycle de
développement Liste des artéfacts
(documents dans ce cas
de figure) dont le chef
de projet est
responsable
Accès aux informations
concernant le(s) rôle(s)
et les activités du chef Liste des
de projet activités du chef
de projet

Figure 6 : Formalisation des rôles dans RUP

La figure 7 présente la copie d’écran, de l’utilitaire « Process Studio », produit « Process Director »,
pour la méthode Select Perspective avec les informations sur le rôle du chef de projet.

Accès aux informations

du rôle de chef de
projet

Fenêtre de
gestion et
d’habilitation des
Accès à des documentations rôles
de référence le cas échéant

Figure 7 : Formalisation des rôles dans Select Perspective

10
 1.5 Langages de modélisation
Comme il a été vu dans la section Origines et évolutions, et à l’exception d’XP, toutes les méthodes
de ce comparatif utilisent le langage de modélisation UML pour les activités d’analyse, de
conception et d’implémentation.

Le tableau 1 présente la liste des diagrammes proposés par UML et leur utilisation par les
différentes méthodes [D’SO 98], [KRO 03], [ROC 01], [SEL03 02].

Select
Catalysis RUP 2TUP
Perspective

Cas d’utilisation

Séquence

Activités


Objets



Collaboration

Etats





transitions

Classes

Composants

Déploiement

: utilisation du diagramme incontournable

 : utilisation du diagramme optionnelle

Tableau 1 : Utilisation des diagrammes UML

Les méthodes Catalysis, RUP, et 2TUP ont rajouté des extensions spécifiques au langage UML.
Par exemple, 2TUP a définit la notion de catégorie3 et la représente à l’aide d’un package avec un
stéréotype « Category » [ROC 01].

Au niveau de son processus de développement « Consume » (développement de système

d’information par assemblage de composants), Select Perspective utilise en plus la notation CSC
Catalyst pour la modélisation de processus métier (BPM, Business Process Modeling). Lors de la
définition des besoins métiers, la méthode se sert des diagrammes BPM suivants : hiérarchie des
processus (PHD, Process Hierarchy Diagram), et enchaînement des processus (PTD, Process
Thread Diagram) [SEL08 02].

1.6 Outils de modélisation

Pour toutes les méthodes, sauf XP, les étapes d’expression des besoins, d’analyse et de conception
se traduisent par un travail de modélisation.

3
une catégorie consiste en un regroupement logique de classes à forte cohérence interne et faible
couplage externe.
11
Cette modélisation permet de décomposer graphiquement une application logicielle en différentes
vues. Par exemple en UML, il est question des vues suivantes : des cas d’utilisation, logique, de
réalisation, des processus, et de déploiement [MUL 98].

Ce travail de modélisation produit un nombre important de diagrammes liés les uns aux autres. Des
outils d’aide à la modélisation, plus couramment appelés outils CASE (Component Aided Software
Engineering), deviennent alors indispensables en offrant notamment les possibilités suivantes :

édition graphique de diagrammes de modélisation,

aide à la validation des diagrammes,

organisation des diagrammes,

génération automatisée des documents,

génération automatique d’une partie du code source.

Le tableau 2 présente les outils de modélisation proposés et / ou utilisables par méthode.

Méthodes Outils de modélisation

Cool:Spex (modélisation composants métiers),

Catalysis
Cool:Gen (catalogue et administration de composants)

IBM Rational Rose XDE Modeler et Rational Rose

RUP
(modélisation logicielle en UML)

Select Component Factory comprenant Select Component Architect

Select Perspective
(SCA) et Select Component Manager (SCM)

IBM Rational Rose (modélisation logicielle UML)

2TUP
ou autres outils de modélisation UML

XP Non concerné car aucune modélisation en analyse et conception

Tableau 2 : Outils de modélisation

12
 1.7 Plateformes de développement cibles
Le tableau 3 présente les plateformes de développement sur lesquelles peuvent s’appuyer ou
collaborer avec les outils CASE des différentes méthodes de ce comparatif.
Méthodes Plateformes de développements cibles

Catalysis Plus concerné (méthode arrêtée en 1998)

RUP IBM WebSphere, plateforme J2EE, intégré

Microsoft Visual Studio .NET, intégré
Sun Netbeans, plateforme J2EE, intégré
Toute plateforme de développement orienté objet

Select Perspective IBM WebSphere, plateforme J2EE, intégré

Microsoft Visual Studio .NET, intégré
Sun Netbeans, plateforme J2EE, intégré
Toute plateforme de développement orienté objet

2TUP Dépendant de l’outil CASE utilisé (IBM Rational Rose, Objecteering,

etc.)
Toute plateforme de développement orienté objet

XP Pas d’utilisation d’outils CASE

Toute plateforme de développement par conséquent

Tableau 3 : Plateformes de développement cibles

RUP et Select Perspective sont les deux méthodes dont les entreprises commercialisent et
développent des outils CASE intégrés dans les plateformes de développement les plus courantes.

1.8 Complexité d’apprentissage

La complexité d’apprentissage des méthodes croît en fonction des pré-requis nécessaires avec
notamment l’utilisation partielle ou complète des langages de modélisation utilisés, des extensions
rajoutées, et du nombre d’activités compris dans le cycle de développement.

Cette complexité influe considérablement dans la pratique. Catalysis, bien qu’étant une méthode
complète, est jugée très complexe à apprendre. En effet, comme nous l’avons déjà vu, Catalysis
s’appuie sur un large éventail de démarches déjà existantes.

Les méthodes 2TUP, RUP et Select Perspective sont jugées moyennement complexes [BAR 02].
Pour ces démarches, il convient de maîtriser les langages de modélisation d’une part, et les outils
« CASE » associés d’autre part.

Compte tenu de son cycle de développement léger, XP apparaît comme la méthode la plus simple.
En effet, elle est réputée légère dans sa mise en œuvre et fait une large place aux aspects techniques,
au prototypage, aux règles de développement et aux tests [CN01 01].

13
 2 Tableau de synthèse
Le tableau suivant reprend de manière synthétique les différents éléments de comparaison abordés
dans le chapitre précédent, auquel a été rajouté un critère sur le gabarit de projet cible [CN01 01].
Select
Catalysis RUP 2TUP XP
Perspective

BON
Fusion
Objectory DSDM RUP DSDM
Origines OORAM
UML RAD UML RAD
Syntropy
UML

Utilisation Universitaire Industrielle

Processus Unifié Processus Unifié

Processus de Processus en spirale en cascade Processus SMaC en Y Itératif
développement Itératif incrémental Itératif Itératif incrémental Itératif incrémental
incrémental incrémental

Oui
Adaptabilité du Oui Non
Patterns de Non
processus Processus et rôles configurables 6 rôles formalisés
processus

Langage de UML + UML UML + Pas de

UML + extensions
modélisation extensions CSC Catalyst extensions modélisation

IBM Rational
Cool :Spex, IBM Rational
Outils de Select Component Rose XDE,
Cool :Gen Rose XDE Non concerné
modélisation Factory Ou autres outils
(à l’époque) Rational Rose
CASE

Pas d’utilisation
Intégré dans d’outils CASE.
Plateformes de
IBM WebSphere, plateforme J2EE Dépendant de Toute plateforme
développement Plus concerné
MS Visual Studio, plateforme.NET l’outil CASE utilisé de
cibles
Sun Netbeans, plateforme J2EE développement
par conséquent

Complexité
Très complexe Moyennement complexe Simple
d’apprentissage

Projet de plus de Projets de toute Projets de moins

Projets cibles Non concerné Non communiqué
10 personnes taille de 10 personnes

Tableau 4 : Comparatif orienté méthode

14
 Partie B Comparatif orienté composants

Cette deuxième partie du comparatif traite plus précisément de l’intégration des composants dans
les méthodes de développement. Il convient au préalable de préciser ce qu’est une méthode de
développement dite à base de composants. Diamond F. D’Souza [D’SO 98] définit ce type de
méthode comme :

« Une approche en développement logiciel dans laquelle tous les artéfacts – du code exécutable aux
spécifications d’interfaces, d’architectures, et de modèles métiers, à l’échelle d’applications
complètes et de systèmes jusqu’à de petites parties – peuvent être assemblés, adaptés, et « câblés »
ensemble avec des composants existants dans une variété de configurations »

Concernant la notion de composant, Catalysis [D’SO 98], RUP [IBM 03], Select Perspective
[SEL06 03] et 2TUP [OMG 03a] se rejoignent sur une définition quasi identique. Il s’agit d’un
paquetage cohérent d’implémentation logicielle qui :

constitue une unité exécutable remplaçable du système,

peut être développé et délivré indépendamment,

réalise un ensemble d’interfaces spécifiant les services fournis et les services attendus par
d’autres composants,

peut être assemblé à l’aide d’autres composants, sans les modifier.

La présente partie se décompose en deux sections :

présentation et application des critères d’évaluation aux méthodes en présence,

consolidation des informations recueillies dans un tableau de synthèse.

1 Critères d’évaluation
Les critères retenus pour ce comparatif orienté composants sont les suivants :

« Design for reuse » versus « Design by reuse »,

composants et architecture logicielle,

patterns,

niveaux d’introduction et représentation des composants,

traçabilité des composants,

gestion des configurations.

1.1 « Design for reuse » versus « Design by reuse »

Les méthodes de développement dites à base de composants se doivent de remplacer les démarches
traditionnelles de développement par deux types de processus de développement [BAI 89] :

un processus de développement POUR la réutilisation, appelé également « design for reuse »,
dont l’objectif est d’identifier, de spécifier et de développer des composants réutilisables. Cette
recherche de composants réutilisables est généralement faite au sein d’une organisation ou plus
largement au sein d’un métier,

15

un processus de développement PAR la réutilisation, appelé également « design by reuse », dont
l’objectif est d’utiliser les composants réutilisables issus du processus précédent pour spécifier
et implémenter un système d’information.

Du point de vue du processus, il convient alors de distinguer les deux types d’activité
complémentaires appelés « l’ingénierie des composants réutilisables » (design for reuse) et
« l’ingénierie des systèmes d’information par réutilisation » (design by reuse).

Ces deux types d’activité et leur couplage à travers une infrastructure de réutilisation sont illustrés
dans la figure 8 [OUS 99].

Ingénierie des composants réutilisables

Applications Connaissances
existantes de domaines

Identification

Infrastructure
de réutilisation
Conception

Recherche

Adaptation

Applications en cours Intégration

de développement

Ingénierie de S.I. par réutilisation

Figure 8 : Ingénierie de composants réutilisables versus ingénierie de S.I. par réutilisation

Il se trouve qu’une seule méthode, Select Perspective, répond à ce modèle de processus de

réutilisation. La fiche signalétique (en annexes) présente le modèle SMaC (Supply Manage
Consume) qui se rapproche très sensiblement du processus représenté ci-dessus. Chaque partie de
SMaC comprend son cycle de développement, celui de l’ingénierie de système d’information étant
itératif incrémental.

Par l’intermédiaire de son pattern 10.2 « Gestion d’une bibliothèque de composants » [D’SO 98],
Catalysis encourage à la mise en oeuvre d’une librairie de composants afin de favoriser le plus
possible la réutilisation. Mais il s’agit seulement de conseils. La notion de pattern est abordée dans
le chapitre 2.1.2 suivant.

Pour Catalysis, RUP et 2TUP, les deux activités « design for » et « design by » sont amalgamées.
Ces trois méthodes n’utilisent pas clairement d’infrastructure de réutilisation. La conception de
composants passe par la modélisation en langage UML avec quelques extensions. La consigne est
donnée de construire une solution logicielle par assemblage et construction de composants.

Pour XP, les concepts de la réutilisation restent intuitifs. A ce niveau, la méthode se base sur le
savoir faire et l’expérience des programmeurs.

La majeure partie des méthodes de ce comparatif utilise essentiellement un processus de

développement par la réutilisation (design by reuse), la spécification et la conception de composants
demeurant intuitive et non systématique.

16
 1.2 Composants et architecture logicielle
L’architecture correspond à un ensemble de décisions significatives concernant l’organisation d’un
système logiciel, la sélection des éléments structurels dont est composé le système, de leurs
interfaces et de leurs comportements. L’architecture logicielle se soucie également de l’utilisation,
des fonctions, des performances, de la capacité à réagir aux changements, de la réutilisation, de la
clarté, des contraintes et compromis économiques et technologiques, et enfin de la préoccupation
esthétique [JAC 00].

Les composants sont donc concernés car ils doivent s’intégrer et être correctement répartis au sein
de l’architecture logicielle. D’ailleurs, toutes les méthodes, sauf XP, s’accordent à définir une
architecture technique au plus tôt. Il est donc intéressant de se pencher sur ce que proposent les
différentes méthodes, sur les modèles d’architecture proposés et sur leur apparition dans leur
processus de développement.

Catalysis propose des règles de bonne conduite, comme par exemple, séparer l’architecture
technique des éléments métiers, ou encore définir, implémenter et valider l’architecture technique
au plus tôt [D’SO 98].

Select Perspective s’avance un peu plus et propose la mise en œuvre, au début du processus de
développement, d’une architecture d’application trois tiers : présentation, métier, données [SEL05
02].

2TUP détaille un modèle d’architecture en cinq couches [ROC 01] de la manière suivante (cf. figure
9).
Restitue les donnés à l'utilisateur et transforme
ses actions en évènements de l'application

Représente les objets de contrôle et pilote

Présentation les règles de l'application, y compris les
règles d'échanges entre applications

Application Représente les objets du métier et

implémente leurs règles de gestion

Métier Restitue les représentations métier

à partir du moyen de stockage

Accés aux données

Assure la persistance des données

Stockage des données

Figure 9 : Architecture d’application proposée par 2TUP

La première étape de modélisation de 2TUP, l’étude préliminaire, pose tout de suite la

problématique. L’étape suivante de capture des besoins techniques (en parallèle de l’étape de
capture des besoins fonctionnels, cycle en Y oblige) spécifie de manière détaillée le découpage de
l’architecture technique en couches logicielles.

Un prototype d’architecture technique résulte de l’étape suivante de conception générique. Cette

étape permet notamment d’identifier et de modéliser les frameworks techniques. L’implémentation
de l’architecture technique s’effectue en deuxième itération.

Selon le modèle d’architecture d’application proposé, la réutilisation de l’architecture technique

devient possible. C’est ce que permettent des frameworks d’architecture. En effet, si l’on se reporte
à la définition donnée par B. Appleton [APP 00] : un framework est une architecture réutilisable qui
fournit la structure générique et le comportement d’une famille d’abstractions logicielles, dans un
contexte qui spécifie leurs collaborations et leur utilisation à l’intérieur d’un domaine donné.

A ce propos, RUP propose une ligne de conduite formalisée avec une architecture en cinq couches
et met en évidence la partie framework de l’application [KRO 03] (cf. figure 10).

17
 5
Code spécificique à
client léger, navigateur Internet l'équipement et
(présentation html) code spécifique au

Application
client

4
Processus et autre
Service de l'application banque en ligne,
code de
composants d'authentification d'un client,
l'application
consultation d'un compte, ...

3
Abstractions
Composants métier : client, compte, ...
majeures, classes,
etc.

Framework d'application
2
Composants de connexion à la base de
Mécanismes,
données relationnelle, ...

Infrastructure
services

Code spécifique 1
au matériel
Base de données relationnelle, ... Code spécifique
au système
d'exploitation
Code généraliste
Exemples pour un système d'information
bancaire intranet

Figure 10 : Architecture et framework d’application proposés par RUP

Concrètement au niveau des étapes du RUP, l’architecture technique est réfléchie dès la phase
d’inception (étude du périmètre et des objectifs du projet) puis conçue, implémentée et validée lors
de la phase suivante d’élaboration. Les phases suivantes servent aux tests, aux corrections et aux
mises au point le cas échéant.

On remarque que 2TUP et plus spécialement RUP insistent sur une architecture technique orientée
framework. Il convient également de noter que l’architecture technique est définie lors de la
première itération du processus de développement. La mise en œuvre de l’architecture technique
constitue ensuite une priorité dans les itérations suivantes. Ces processus de développement
appliquent une démarche qui est centrée sur l’architecture.

Dans l’ensemble, les méthodes ont la possibilité de recourir à des patterns d’architecture (cf.
paragraphe 1.3) également appelés style d’architecture [SHA 96]. Les styles d’architecture proposés
sont plus ou moins précis, allant de règles de bonne conduite (Catalysis), à une architecture en
couches bien identifiées (RUP).

1.3 Patterns
La notion de pattern a été définie par Christopher Alexander comme suit [ALE 77] :

« Chaque pattern 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 ».

Un pattern est défini comme une solution à un problème dans un contexte [ACM 96] où :

le contexte se réfère à un ensemble de situations récurrentes,

le problème définit un but à atteindre,

la solution se réfère à un modèle ou à un processus que l’on peut adapter pour résoudre le
problème.

Il est intéressant d’avoir un critère d’évaluation portant sur les patterns. En effet, ces derniers
peuvent être avantageusement utilisés dans les méthodes de développement à base de

18
composants (réutilisation de patterns pour spécifier ou pour transformer des composants par
raffinement successif).

Il existe deux grandes catégories de patterns (cf. figure 11) :

les patterns de processus qui décrivent un savoir-faire sous forme d’actions et / ou des tâches à
suivre pour le développement des logiciels (par exemple [AMB 98]),

les patterns produit qui offrent une prescription que l’on adopte ou pas pour construire tout ou
partie des spécifications ou de l’implantation d’un système d’information.

Les patterns produit sont classifiés selon leur portée, c’est à dire l’étape d’ingénierie à laquelle ils
s’adressent : patterns d’analyse (par exemple [COA 95]), patterns de conception (ou design
patterns, par exemple [GAM 95]), patterns d’architecture (par exemple [SHA 96]), patterns
d’implantation (ou idiomes, par exemple [COP 92]).

Pattern

{ type de connaissance } { portée }

XOR XOR XOR XOR

Pattern Pattern Pattern Pattern Pattern Pattern

produit processus analyse architecture conception implantation

Figure 11 : Une classification de patterns

Le tableau 5 présente l’utilisation des patterns par niveau pour chacune des méthodes étudiées
[D’SO 98], [IBM 03], [ROC 01], [SEL07 03].

Pattern Pattern produit

Méthodes
processus Analyse Conception Architecture Implantation
Catalysis Oui Oui Oui Non précisé Oui
patterns patterns patterns
proposés proposés proposés par
par la par la la méthode
méthode méthode elle-même.
elle-même. elle-même.
RUP Non précisé Possible Oui Oui Possible

Select Non précisé Oui Oui Non précisé Oui

Perspective patterns patterns patterns
proposés proposés proposés par
par la par la la méthode
méthode méthode elle-même.
elle-même elle-même.
2TUP Non précisé Possible Oui Oui Possible

XP Non précisé Non précisé Non précisé Non précisé Possible

Tableau 5 : Utilisation de patterns

19
Toutes les méthodes incitent et permettent l’utilisation et la création de patterns. La notation UML
permet de modéliser les patterns, mais elle n’inclue pas les aspects importants des patterns, comme
l’utilisation et les exemples. Ces derniers ne peuvent alors être exprimés que par des commentaires.

Certaines méthodes, comme Catalysis [D’SO 98] et Select Perspective [SEL07 03], proposent
leurs propres patterns d’analyse et de conception. Catalysis propose en plus des patterns orientés
processus de développement.

Par rapport à la notion de composant, en tant qu’unité exécutable autonome et remplaçable, il est
important de noter que les patterns sont réutilisables tout au long du cycle de développement, de
l’expression des besoins, jusqu’à l’implémentation.

Aucune des méthodes de ce comparatif ne gère de démarche propre à l’ingénierie de réutilisation

des patterns (comment sélectionner un pattern, l’imiter, l’intégrer, …).

1.4 Niveaux d’introduction et représentation des composants

Le tableau 6 présente le niveau d’introduction des composants dans les différentes étapes de la
modélisation d’un système d’information.
Tableau 6 :
Niveaux Expression
d’introduction Méthodes des Analyse Conception Implémentation
des composants
besoins
En terme Catalysis



d’analyse et
RUP



de
conception, Select




RUP, Select Perspective
Perspective 2TUP


et 2TUP
formalisent, XP
(ad hoc)
(ad hoc)
en langage de modélisation UML, les composants en se basant sur les notions de classes, ou de
sous-systèmes assortis d’une ou plusieurs interfaces permettant de préciser ou non les services
proposés (cf. exemples figures 12 et 13).
interface détaillée
<<interface>>
ICalendrierInstructeur
spécification des
opérations
ajoutEvenement(d1 : Date, d2: Date, instr : Instructeur, info : Object) : Evenement
supprimerEvenement(e : Evenement)
....

sous-système
<<subsystem>>
CalendrierInstructeur
classes
de réalisation
Evenement planification 1 Instructeur

debut, fin : Date * instructeur nom, prenom : String

info : Object
libre(Date) : Boolean
creer(Date,Date,Object)
superposition(Date) : Boolean
supprimer()

Figure 12 : Exemple UML de composants d’analyse et de conception avec un sous-système

20
 interface interface
(formalisme non détaillé) (formalisme détaillé)

UNE_CLASSE UNE_CLASSE << interface >>

INomInterface
INomInterface
Propriétés Propriétés
Opérations
Méthodes Méthodes

Figure 13 : Exemples UML de composants d’analyse et conception avec des classes

Les classes et les sous-systèmes sont présentés dans les diagrammes statiques de classes partiels et
détaillés. Dans ce formalisme, il n’y a pas de distinction entre les interfaces de services proposés et
de services attendus par d’autres composants.

Select Perspective et 2TUP apportent des extensions supplémentaires très proches des sous-
systèmes, comme des paquetages avec le nom du composant précédé par le stéréotype « category »
pour 2TUP [ROC 01], ou « process control » et « business » pour Select Perspective [SEL09 03].

En terme d’implémentation, RUP, Select Perspective et 2TUP ont recours aux diagrammes
d’implémentation et de déploiement d’UML [OMG 03a], dans lesquels la notation d’un composant
est illustrée par la figure 14.
ICalendrierInstructeur

CalendrierInstructeur

Figure 14 : Exemple UML de composant d’implémentation

Les composants sont représentés en tant que type dans les diagrammes de composants et en tant
qu’instances d’exécution dans les diagrammes de déploiement.

Dans Catalysis, le formalisme en conception au niveau logique apparaît de manière différente. En

effet, il est question de spécification de comportement externe d’un composant. Pour ce faire, la
méthode utilise la notion de type [D’SO 98] (exemple illustré dans la figure 15).
Spécification du CalendrierInstructeur <<type>>
composant
en tant que type 1 calendrier
Evenement planification 1 Instructeur
planification * instructeur
Dictionnaire debut, fin : Date nom, prenom : String
* info : Object
Un évènement libre(Date) : Boolean
représente une
activité de travail
creer(Date,Date,Object)
d'un instructeur superposition(Date) : Boolean inv Instructeur::libre(d : Date) =
Invariants sur plusieurs jours supprimer() (self.planification[superposition(d)]->IsEmpty
inv Evenement::debut <= fin
inv Evenement::superposition(d : Date) = (debut <= d & fin >= d)
Spécification
précise des function ajoutEvenement(d1 : Date, d2: Date, instr : Instructeur, info : Object) : Evenement
opérations pre: d1 < d2 & {d1..d2}->forAll (d | i.libre(d))
post:
result: Evenement.new [info = o & debut = d1 & fin = d2 & instructeur = i & calendrier = self]

action supprimerEvenement(e : Evenement)

pre: planification->includes(e)
post: not planification->includes(e) and not e.instructeur.planification@pre->includes(e)

action ...

Figure 15 : Exemple Catalysis de composant de conception avec la notion de type

Un type se distingue d’une classe car il ne fait pas de choix sur l’implantation et reste donc à un
niveau plus élevé d’abstraction [OUS 99]. Il s’agit de la spécification de composant la plus
complète (collaboration de classes ou de types, dictionnaire, invariant, pré et post condition) mais
également la plus complexe.

Au niveau de la vue d’implémentation, Catalysis est très proche de la notation UML (dans sa
version actuelle 1.5) et précise en plus des éléments de notation supplémentaires, comme les

21
connecteurs et les ports qui permettent de distinguer les interfaces de services attendus, des
interfaces de services fournis à d’autres composants [D’SO 98] (cf. exemple figure 16).
spécification spécification
courte d'interface étendue d'interface

Client I1 Composant I1 <<type>>

op1
op2
Composant
(type ou instance)
connecteur

RunawayControl AircraftDisplay
current : Plane show : Aircraft

ApproachControl
clear : boolean ready : boolean

Figure 16 : Exemples de composants d’implémentation avec Catalysis

NB : la prochaine spécification d’UML 2.0 [OMG 03b] (en cours de validation) comprend les
nouvelles notions de port et de connecteur.

De manière générale, un composant est défini dans différentes vues. En effet, nous avons
principalement regardé les modèles statiques en matière de modélisation des composants. Le
comportement de ces derniers se situe au niveau des diagrammes dynamiques (de séquences par
exemple).

1.5 Traçabilité des composants

Dans ce contexte, la traçabilité correspond à la capacité de retrouver, à tous les niveaux de
modélisation, les diagrammes qui ont donné lieu à un composant.

L’enjeu porte d’une part sur l’effort de développement et d’autre part sur la maintenance le cas
échéant.

Le langage de modélisation UML, dans sa version actuelle 1.5, offre la possibilité de lier les
éléments des différents diagrammes en utilisant un lien stéréotypé « Trace » [OMG 03a] (cf.
exemple figure 17).

Modèle de conception Modèle d'implémentation

TransfertDeComptes << file >>

<< trace >>
c

TransfertDeComptes

ITransferts ITransferts

Figure 17 : Exemple de traçabilité des composants en UML

Potentiellement, toutes les méthodes utilisant UML, peuvent utiliser cette notation de traçabilité,
mais aucune d’entre elles ne le mentionne.

1.6 Gestion des configurations

La gestion des configurations concerne plus particulièrement les mécanismes de publication, de
contrôle des versions et de construction. Les composants sont donc concernés.

22
Catalysis prend en compte la gestion des configurations au niveau des paquetages (notation UML).
La méthode fixe comme règle que chaque paquetage comporte une version et un attribut d’état de
publication (éditable ou publié). Une fois publié, un paquetage ne peut plus être altéré. Tous les
paquetages importés doivent être également publiés.

Toute modification donne alors lieu à une nouvelle version du paquetage [D’SO 98].

2TUP utilise la notion de sous-système (notation UML) comme élément de structuration du modèle
de configuration logicielle. Les sous-systèmes se caractérisent en outre par un numéro de version
qui fixe son état d’évolution au sein de la construction globale du système [ROC 02].

RUP dispose d’une gestion de la configuration [KRU 03] (CM, Configuration Management) qui
consiste à :

identifier les artéfacts (classes, paquetages, etc.) et leur attribuer un numéro de version,

identifier les configurations (ensembles cohérents d’artéfacts),

gérer les dépendances entre les artéfacts,

gérer les constructions.

Dans Select Perspective, la gestion des configurations relève du processus de gestion des
composants. Il s’agit en l’occurrence de gérer les dépendances, les configurations et la compatibilité
entre les composants et les différentes versions associées [SEL06 03].

Pour ces quatre méthodes, cette gestion des configurations touche la spécification, l’implémentation
des composants, ainsi que les exécutables correspondants.

XP ne précise pas de règle particulière en la matière.

23
 2 Tableau de synthèse

Catalysis RUP Select Perspective 2TUP XP

Processus de
Oui
réutilisation de Non Non Non Non
Modèle SMaC
composants

Règles de conduite :
Architecture
Architecture séparation de
d’application en 5 Modèle d’architecture Non
technique et l’architecture Architecture 3 tiers
couches en 5 couches (ou ad hoc)
framework technique des
(Framework compris)
éléments métiers

Patterns processus Patterns produit +

Utilisation de proposé par la patterns produit Patterns produit
Patterns produit Patterns produit
patterns méthode proposés par la (implantation)
Patterns produit méthode

Introduction des
Niveau
composants dans conception et
Analyse, conception et implémentation implémentation
le cycle de implémentation
le cas échéant
développement

Analyse, conception :
Analyse, conception : Analyse, conception :
classe, sous-système
Représentation type classe, sous-système + extensions Aucune
avec interface
des composants Implémentation : avec interface représentation
Implémentation :
package, composant Implémentation : composants
composants

Oui avec UML

Traçabilité
Liaison entre les artéfacts avec le stéréotype « Trace » Non
des composants
Mais aucune ligne de conduite précise dans ce sens

Oui
Oui Oui Oui
Gestion des au niveau de la
au niveau des au niveau des tous au niveau des sous- Non précisé
configurations gestion des
paquetages les artefacts systèmes
composants

Tableau 7 : Comparatif orienté composants

Il semble que la méthode XP ne soit pas à sa place dans ce comparatif. En effet, il s’agit d’une
méthode qui se rapproche plus du développement rapide d’application (RAD) que d’un
développement systématique à base de composants. Or, de par sa simplicité, XP joue, en quelque
sorte, les « trouble-fêtes ». Des méthodes, comme RUP et Select Perspective, prennent
sérieusement et stratégiquement en considération XP. En effet, ces méthodes n’hésitent pas à
proposer des processus allégés et orientés XP.

24
 CONCLUSION
Au fur et à mesure du comparatif, nous avons vu que la plupart des méthodes souffrent d’un certain
nombre de faiblesses avec notamment :

la complexité d’utilisation des méthodes en raison du nombre important de connaissances à
maîtriser. Catalysis est certainement la méthode la plus riche et la plus aboutie en matière de
développement à base de composants. Mais, revers de la médaille, cette méthode est devenue
trop complexe,

l’introduction des composants dans le cycle de développement se faisant après l’expression
des besoins, d’où une identification des composants plutôt intuitive et non systématique,

un processus de développement principalement axé « design by reuse». Seul, le processus de
Select Perspective inclue les activités de réutilisation de composants, mais reste vague sur
l’identification et la construction de composants réutilisables,

un manque de guidage du concepteur pour identifier les composants. Les méthodes ont
tendance à se baser sur l’expertise du concepteur,

pas d’ingénierie en matière de réutilisation des patterns,

une arrivée tardive des méthodes de développement à base de composants. En effet, les
entreprises ont pris l’habitude de développer leurs applications avec des composants techniques
sans pour autant utiliser des méthodes de développement à base de composants.

A part Catalysis dont le développement a été arrêté, les méthodes ont tendance à donner plus des
lignes de bonne conduite que des règles systématiques de spécification et de construction des
composants. Bien que les enjeux en matière d’utilisation et de réutilisation de composants soient
compris de tous, ces méthodes de développement à base de composants tardent à s’imposer car elles
sont perçues comme complexes et restent surtout plus des méthodes de développement orientées
objets que composants.

Malgré tout, la majeure partie des méthodes abordées, dans ce comparatif, dispose également de
points forts avec :

une prise de conscience académique et industrielle de l’intérêt et des enjeux en matière de
développement à base de composants,

un processus de développement itératif incrémental, qui permet de développer des applications
de bonne qualité grâce à un contrôle du temps, des coûts et des risques,

la flexibilité du processus de développement. A l’exception d’XP, toutes les méthodes disposent
d’un processus de développement configurable et par extension adaptable à différentes tailles de
projets,

la formalisation des rôles afin d’identifier précisément les acteurs d’un projet et leurs activités,

un langage de modélisation standard : UML,

des outils d’aide à la modélisation intégrés aux grandes plateformes de développement actuelles.

Les faiblesses actuelles des méthodes de développement à base de composants sont temporaires et
l’on peut raisonnablement penser que dans les prochaines années, ces méthodes arriveront à
maturité. Le développement de systèmes d’information s’en trouvera bouleversé. Dans sa thèse,
Philippe Ramadour [RAM 01] évoque une rupture aux conséquences à la fois techniques,
industrielles et économiques. En matière d’organisation industrielle, cette rupture conduira à une
profonde évolution des méthodes de développement de logiciels et des métiers associés. Les métiers

25
du développement verront leur importance décroître au profit des métiers de spécification,
d’architecture, de test et d’assemblage des composants. Enfin, d’un point de vue économique, le
développement à base de composants devrait fortement modifier le mode de fonctionnement aussi
bien des entreprises de type SSII (société de services et d’ingénierie en informatique) que des
éditeurs de progiciels. Les solutions propriétaires développées au cas par cas seront rapidement
abandonnées au profit de solutions intégrant des « composants logiciels du commerce » ou « COTS
(Components On The Shelf) ».

26
 ABREVIATIONS
2TUP Two Tracks Unified Process
Processus unifié à deux chemins
DSDM Dynamic Systems Development Method
Méthode de développement de systèmes dynamiques
BON Business Object Notation
Notation objet métier
BPM Business Process Modeling
Modélisation de processus métier
CASE Component Aided Software Engineering
Outil d’aide à la modélisation d’ingénierie logicielle
CBD Component Based Development
Développement à base de composants
CBDSE Component Based Development Software Engineering
Ingénierie en développement logiciel à base de composants
CM Configuration Management
Gestion de la configuration (méthode RUP)
COM/DCOM Common Object Model / Distributed Common Object Model
Technique de Microsoft, utilisée pour le développement objet. Définit les spécifications pour la distribution
et l’accès de composants d’une application aux ordinateurs en réseau
CORBA Common Object Request Broker Architecture
Standard de l’OMG définissant l’architecture logicielle nécessaire pour permettre à des parties de
programmes (objets) de communiquer avec d’autres, issues d’environnements différents
COTS Commercial of the shelf (component)
Composant sur étagère
CSC Computer Sciences Corporation (société)
EJB Enterprise JavaBeans
Standard Java définissant, côté serveur, la structure des composants logiciels et les interfaces permettant
aux programmeurs de développer et de gérer des applications distribuées
OMG Object Management Group (organisation)
OMT Object Modeling Technique
Technique de modélisation objet (méthode)
OORAM Object Oriented Role Analysis and Modeling
Méthode basée sur le concept de rôle pour l’analyse et la modélisation orientées objet
OTAN Organisation du Traité de l’Atlantique Nord
PHD Process Hierarchy Diagram
Diagramme hiérarchique des processus utilisés dans la modélisation des processus métiers (BPM)
PTD Process Thread Diagram
Diagramme des enchaînements de processus utilisés dans la modélisation des processus métiers (BPM)
RAD Rapide Application Development
Méthode de développement rapide d’application
RUP Rational Unified Process
Méthode de développement à base de composants de la société IBM Rational
SMaC Supply, Manage, Consume
Processus de développement à base de composants Select Perspective proposé par la société Select
Business Solutions
SI Système d’Information
SSII Société de Services et d’Ingénierie en Informatique
UML Unified Modeling Langage
Langage de modélisation unifié
XP eXtreme Programming
Méthode de développement logiciel

27
 BIBLIOGRAPHIE
 [ACM 96] « Software Patterns », Communications of the ACM, vol. 39, n° 10, 1996
 [ALE 77] C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson et al., « A pattern Language »,
Oxford University Press, 1977
 [AMB 98] S.W. Ambler, « Process Patterns building Large Scale Systems using Object technology »,
SIGS Books, Cambridge University Press, décembre 1998
 [APP 00] B. Appleton, « Patterns and Software : Essentials Concepts and Terminology »,
http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html
dernière mise à jour 2000, consultation février 2004
 [AVA 02] Site Internet Avantek Systems, page « Analysts on Components Technologies »,
http://www.avanteksys.com/analysts.html, dernière mise à jour 2002, consultation mars 2004
 [BAI 89] S.C. Bailin, J.M. Moore, « The KAPTUR Environment : An Operation Concept », rapport pour
la NASA Goddard Space Flight Center, CTA Incorporeted, Tockville, 1989
 [BAR 02] F. Barbier, C. Cauvet, M. Oussalah, D. Rieu, S. Bannasri, Souveyet, « Composants des
l’ingénierie des Système d’Information : concepts clés et techniques de réutilisation »,
chapitre Démarche d’ingénierie de systèmes à base de composants
Actes des deuxièmes assises nationales du GdR I3, 2002
 [BEN 02a] J.L. Bénard, L.Bossavit, R. Médina, D. Williams, « L’eXtreme Programming »,
Eyrolles, mai 2002
[BEN 02b] J.L. Bénard, « Méthodes agiles (2) - eXtreme Programming », article dans Développeur
 Référence v 2.06, 14 janvier 2002
 [CAT01 99] Site Internet Catalysis,
http://www.catalysis.org, dernière mise à jour 1999, consultation février 2004
 [CN01 01] Site du CNRS – Direction des Systèmes d’Information, « Etat de l’art des méthodologies »,
http://www.dsi.cnrs.fr/bureau_qualite/developpement-web/methodologie/veille-methodologie.asp
Dernière mise à jour inconnue, consultation février 2004.
 [COA 95] P. Coad, « Objet Models : Strategies, Patterns and Applications »,
Yourdon Press Computing Series, 1995
 [COP 92] J.O. Coplien, « Advanced C++ Programming Styles and idioms »,
Addison-Wesley, Reading, MA, 1992
 [D’SO 98] D.F. D’Souza, A Cameron Wills, « Objects, Components and Frameworks with UML, the
Catalysis Approach », Addison Wesley, octobre 1998
 [GAM 95] E. Gamma, R. Helm, R. Johnson, J. Vlissides, « Design Patterns : Element of Reusable
Object-Oriented Software », Addison-Wesley Professional Computing Series, 1995
 [IBM 03] Site Internet IBM Rational, logiciel d’évaluation RUP version 2003.06.01.04,
http://www.rational.com, dernière mise à jour 2004, consultation février 2004
 [JAC 00] I. Jacobson, G. Booch, J. Rumbaugh, « Le Processus Unifié de développement logiciel »,
Eyrolles, juin 2000.
 [KRO 03] P. Kroll, P. Kruchten, « Guide pratique du RUP », CampusPress, septembre 2003
 [KRU 03] P. Kruchten, « Rational Unified Process, A Introduction », 3ème édition, Addison Wesley
Professional, décembre 2003
 [MCI 76] M. McIlory, « Mass-Produced Software Components », dans Software Engineering Concepts
and Techniques, 1968 NATO Conference on Software Engineering, J.M. Buxton & al (eds), 1976
 [MUL 98] P.A. Muller, « Modélisation objet avec UML », Eyrolles, décembre 1998
 [OMG 03a] Site Internet Object Management Group (OMG), « OMG Unified Modeling Langage
Spécifications - version 1.5 », http://www.omg.org/cgi-bin/doc?formal/03-03-01,
dernière mise à jour 3 mars 2003, consultation février 2004
 [OMG 03b] Site Internet Object Management Group (OMG), « UML superstructure 2.0 Draft adopted
Specification », http://www.omg.org/cgi-bin/doc?formal/03-03-02,
dernière mise à jour 7 août 2003, consultation février 2004
 [OUS 99] E. Andonnof, F. Barbier, Z. Bellahsene, B. Benatallah, H. Briand, X. Castellani, C. Cauvet, B.
Dano, C. Dony, M.C. Fauvet, A. Front-Conte, J.P. Giraudin, M.S. Hacid, M. Huchard, G.
Hubert, H. Jiang, A. Le Parc, T. Libourel, G. Nachouki, C. Oussalah, S. Rideau, D. Rieu, C.
Saint-Marcel, A. Saoudi, F. Semmak, D. Tamzalit, C. Urtado, G. Zurfluh, « Genie objet –
analyse et conception de l’évolution », Hermes, septembre 1999
 [RAM 01] P. Ramadour, « Modèles et langages pour la conception et la manipulation de composants
réutilisables de domaine », thèse, Université de Droits d’Economie et des Sciences d’Aix-
Marseille III, décembre 2001
 [ROC 01] P. Rocques, F. Vallée, « UML en action », Eyrolles, mars 2001
 [ROC 02] P. Rocques, F. Vallée, « UML en action » 2ème édition, Eyrolles, mars 2001
 [SEL01 03] Site Internet Select Business Solutions, White paper « Select Perspective and DSDM - a
comparison Mapping v1.0 », http://www.selectbs.com/downloads/download_docs.htm,
dernière mise à jour 2003, consultation février 2004
 [SEL02 03] Site Internet Select Business Solutions, white paper « Software Reuse - Measuring Return
On Investment », http://www.selectbs.com/downloads/download_docs.htm,
dernière mise à jour 2003, consultation février 2004
 [SEL03 02] « Select Component Factory – Getting Started Guide », Aonix Corporation, juin 2002
 [SEL04 03] Site Internet Select Business Solutions, description du produit Process Director plus,
http://www.selectbs.com/products/products/select_process_director_plus.htm,
dernière mise à jour 2003, consultation février 2004
 [SEL05 02] Site Internet Select Business Solutions, produit « Process Director v 2.1 »,
Directives « CBD Guidelines Architectural Layers »,
http://www.selectbs.com/products/products/process_director.htm
dernière mise à jour 2002, consultation février 2004
 [SEL06 03] Site Internet Select Business Solutions, white paper « Managing Components v 3.1 »
http://www.selectbs.com/downloads/download_docs.htm,
dernière mise à jour 2003, consultation février 2004

28
 [SEL07 03] Site Internet Select Business Solutions, produit « Process Director »
Directives « CBD Guidelines Perspective Patterns for Technical Architecture »,
http://www.selectbs.com/products/products/process_director.htm
dernière mise à jour 2003, consultation février 2004
 [SEL08 02] Site Internet Select Business Solutions, tutorial du produit « Select Component Factory »
http://www.selectbs.com/fr/downloads/download_files.htm
dernière mise à jour 2002, consultation février 2004
 [SEL09 03] Site Internet Select Business Solutions, white paper « UML for Components and Process
Control v 4.0 », http://www.selectbs.com/downloads/download_docs.htm,
dernière mise à jour 2003, consultation février 2004
 [SHA 96] M. Shaw, D. Garlan, « Software Architecture : Perspective of an Emerging Disciple »,
Prentice Hall, avril 1996

Légende :  : Ouvrage  : Article de presse  : Site Internet

29
 ANNEXES
A.1 Fiche signalétique : Catalysis

Informations générales

Fondateur(s) Desmond F. D’Souza (société Platinum Technology)

Alan Cameron Wills (société TriReme International Ltd.)
Ascendance Bon, Fusion, OMT, OORAM, Syntropy, UML
Apparue en 1992 (fin des développements en 1998)
Usage Académique
Langage(s) de UML (Unified Modeling Langage)
modélisation OCL (Object Constraint Langage)
Complexité Très complexe
d’apprentissage
Lien Internet http://www.catalysis.org

Processus de développement

Cycle de développement en spirale, itératif et incrémental :

Spécification Planification

Recette

Conception Implémentation

Cycle en spirale proposé dans Catalysis [D’SO 98]

Catalysis propose également des patterns orientés processus de développement

afin de compléter et d’adapter le cycle de vie en fonction des projets.

30
A.2 Fiche signalétique : Rational Unified Process (RUP)

Informations générales

Fondateur(s) Ivar Jacobson (société Rational)

Grady Booch (société Rational)
James Rumbaugh (société Rational)
Ascendance Booch, Objectory, OMT, UML
Apparue en 1996
Usage Industriel (environ 10 000 références clients)
Société IBM Rational
Langage(s) de UML (Unified Modeling Langage)
modélisation
Complexité Moyennement complexe
d’apprentissage
Lien Internet http://www.rational.com

Processus de développement

31
Cycle de développement en cascade, itératif et incrémental :

Inception
Elaboration
Construction
Transition

Temps

Jalon LCO : Jalon LCA : Jalon IOC : Jalon PR :

objectifs définis architecture définie première version livraison finale
opérationnelle

Jalons et phases du cycle de vie du RUP [KRO 03]

Phases

Disciplines Inception Elaboration Construction Transition

Modélisation métier

Exigences

Analyse et conception

Implémentation

Tests

Déploiement

Gestion des la configuration et

des changements
Gestion de projet

Environnement

Itér. initiale Elab 1 Elab 2 Cons 1 Cons 2 Cons 3 Trans 1 Trans 2

Itérations

Vue en deux dimensions du RUP [KRO 03]

NB : les courbes de cette figure représentent, à titre indicatif et pour un projet donné,
la montée en charge des activités dans chaque itération de phase.

32
A.3 Fiche signalétique : Select Perspective

Informations générales

Fondateur(s) Société Select Business Solutions

Ascendance DSDM, OMT, Objectory, RAD
Apparue en 1994
Usage Industriel
Société Select Business Solutions
Langage(s) de UML (Unified Modeling Langage) + extensions
modélisation BPM (Business Process Modeling)
Catalys CSC
Complexité Moyennement complexe
d’apprentissage
Lien Internet http://www.selectbs.com

Processus de développement

Cycle de développement, itératif et incrémental.

Besoins
métiers

Fournir Administrer Consommer

Demandes de services
Cadrage métier

Services de données
Architecture métier

Architecture technique
Administration des composants Planification incrémentale

Architecture des données

Livraison de solution métier

Livraison de composants
Recadrage de solution métier
Composants

Solutions
métiers

Framework de processus de développement SMaC (Supply Manage Consume) [SEL02 03]

33
 Processus de développement (suite)

Fournir Administrer Consommer

(ingéniérie des composants réutilisables) (infrastructure de réutilisation) (ingéniérie des systèmes d'information par réutilisation)

5. Conception de 1. Définition des

composant besoins métiers

Modélisation
processus métier

Select Modélisation avec cas

Component d'utilisation
Digrammes utilisés : Manager
4. Réutilisation des 3. Recherche et
. classes spécification(s) de réutilisation de
. séquence composant(s) composant(s) OU
2. Conception
. objets
solution métier
. collaboration Publication des
. états transitions spécification(s) de
Modélisation de
6. Publication des 9. Administration composant(s) composant métier
spécification(s) de des composants
composant(s)
7. Réutilisation de
composant(s) 8. Assemblage de
la solution

Collaborations dans SMaC [SEL04 03]

Cycle de vie « Fournir » Cycle de vie « Administrer » Cycle de vie « Consommer »

Ingénierie de composants réutilisables Infrastructure de réutilisation Ingénierie du Système d’Information par
réutilisation

Acquisition de Recherche de Planification

Spécification de Gestion composant composant composant incrémentale
composant obsolète
Cadrage métier
Certification de
Conception de composant
composant Architecture métier Recadrage de solution
Composant
candidat
Composant
Classification de
Construction de Livraison de solution
candidat composant
Maintenance et
composant
Composant
support
Maintenance de publié

composant
Demande de
changement

34
A.4 Fiche signalétique : Two Tracks Unified Process (2TUP)

Informations générales

Fondateur(s) Société Valtech

Ascendance RUP, UML
Apparue en 1999
Usage Industriel (environ 200 références clients)
Société Valtech
Langage(s) de UML (Unified Modeling Langage)
modélisation
Complexité Moyennement complexe
d’apprentissage
Lien Internet http://www.valtech.fr

Processus de développement

35
Cycle de développement en Y, itératif et incrémental :

Contraintes Branche Branche Contraintes

Etude préliminaire
fonctionnelles fonctionnelle technique techniques

Capture des besoins Capture des besoins

fonctionnels techniques

Conception
Analyse
générique

Conception
préliminaire
Prototype

Conception détaillée

Codage et tests

Recette

Le processus de développement en Y [ROC 01]

36
A.5 Fiche signalétique : eXtreme Programming (XP)

Informations générales

Fondateurs(s) Kent Beck (société First Class Software Inc.)

Ward Cunningham (Cunningham & Cunningham Inc.)
Ascendance DSDM, RAD
Apparue en 2000
Usage Industriel
Société First Class Software Inc.
Langage(s) de Aucun langage imposé ou requis
modélisation
Complexité Peu complexe
d’apprentissage
Lien Internet http://www.extremeprogramming.org

Processus de développement

37
Cycle de développement itératif et incrémental :

Itérations de 1 à 4 semaines
Itération de 1
semaine

Itérations jusqu'à la première

Exploration Planning Mise en production Maintenance Mort
release

Maintenance = ajouter des fonctionnalités
nouvelle release

Utilise le même processus que pour la release 1

cycle de vie d’XP [BEN 02b]

38