IV. PRESENTATION DES METHODES D'ANALYSE
Une méthode de développement définit
à la fois un langage de modélisation et la marche à suivre
lors de la conception. Le langage UML propose uniquement une notation dont
l'interprétation est définie par un standard, mais pas une
méthodologie complète. Plusieurs processus de
développement complets fondés sur UML existent, comme le Rational
UnifiedProcess (RUP), de Booch, Jacobson et Rumbaugh, ou l'approche MDA (Model
Driven Architecture) proposée par l'OMG, mais ils ne font pas partie du
standard UML. Le processus RUP propose de bien maîtriser les
étapes successives de la modélisation et du développement
par une approche itérative. L'approche MDA propose une architecture du
développement en deux couches : le PIM (Platform Indepent Model)
représente une vision abstraite du système, indépendante
de l'implémentation ; le PSM (Platform Specific Model) représente
les programmes exécutables, qui doivent être obtenus en partie
automatiquement à partir du PIM ; à cela s'ajoute le PDM
(Platform Definition Model), en l'occurrence une description de l'architecture
physique voulue (langages de programmation, architecture
matérielle...).
Dans la suite de notre travail nous allons utiliser le
processus 2TUP parce qu'il est complet et adapter au genre de logiciel que l'on
veut concevoir.
V. LE PROCESSUS 2
TUP
2TUP signifie « 2 Track Unified Process ». C'est un
processus UP qui répond aux caractéristiques que nous venons de
citer. Le processus 2TUP apporte une réponse aux contraintes de
changement continuel imposées aux systèmes d'information de
l'entreprise. En ce sens, il renforce le contrôle sur les
capacités d'évolution et de correction de tels systèmes.
« 2 Track » signifie littéralement que le processus suit deux
chemins. Il s'agit des chemins « fonctionnels » et
« d'architecture technique », qui correspondent aux deux axes de
changement imposés au système informatique.
Figure 3 Le
système d'information soumis à deux natures de
contraintes
À l'issue des évolutions du modèle
fonctionnel et de l'architecture technique, la réalisation du
système consiste à fusionner les résultats des deux
branches. Cette fusion conduit à l'obtention d'un processus de
développement en forme de Y, comme illustré par la figure
suivante.
Figure 4 : Le
processus de développement en Y
La branche gauche (fonctionnelle) comporte :
· la capture des besoins fonctionnels, qui produit un
modèle des besoins focalisé sur le métier des
utilisateurs. Elle qualifie au plus tôt le risque de produire un
système inadapté aux utilisateurs. De son côté, la
maîtrise d'oeuvre consolide les spécifications et en
vérifie la cohérence et l'exhaustivité l'analyse, qui
consiste à étudier précisément la
spécification fonctionnelle de manière à obtenir une
idée de ce que va réaliser le système en termes de
métier. Les résultats de l'analyse ne dépendent d'aucune
technologie particulière.
La branche droite (architecture technique) comporte :
· la capture des besoins techniques, qui recense toutes
les contraintes et les choix dimensionnant la conception du système. Les
outils et les matériels sélectionnés ainsi que la prise en
compte de contraintes d'intégration avec l'existant conditionnent
généralement des prérequis d'architecture technique
· la conception générique, qui
définit ensuite les composants nécessaires à la
construction de l'architecture technique. Cette conception est la moins
dépendante possible des aspects fonctionnels. Elle a pour objectif
d'uniformiser et de réutiliser les mêmes mécanismes pour
tout un système. L'architecture technique construit le squelette du
système informatique et écarte la plupart des risques de niveau
technique.
La branche du milieu comporte :
· la conception préliminaire, qui
représente une étape délicate, car elle intègre le
modèle d'analyse dans l'architecture technique de manière
à tracer la cartographie des composants du système à
développer.
· la conception détaillée, qui
étudie ensuite comment réaliser chaque composant
· l'étape de codage, qui produit ces composants et
teste au fur et à mesure les unités de code
réalisées ;
· l'étape de recette, qui consiste enfin à
valider les fonctions du système développé.
| 
