V.3.Le processus Unifié
V.3.1.Différentes Approches
Dans une démarche traditionnelle, le processus de
développement était caractérisé par :
? Un processus de type séquentiel :
développement organisé en phases qui regroupent des
étapes, elles-mêmes décomposées en tâche.
? Les niveaux de découpage coïncident : la fin
d'une phase correspond à la conclusion de ses étapes, qui
elles-mêmes se terminent avec l'accomplissement des tâches qui les
composent.
Dans une approche objet tout change : Le processus est de type
itératif ;
? Les découpages ne coïncident pas : les
activités (taches, phases, étapes, etc...) se déroulent
dans plusieurs dimensions.
La maîtrise des processus de développement
implique pourtant une organisation et un suivi des activités : c'est ce
à quoi s'attachent les différentes méthodes qui s'appuient
sur l'utilisation du langage UML pour modéliser un système
d'information.
UP (Unified Process) est une méthode
générique de développement de logiciel.
V.3.2. Méthodes Issues du Processus Unifié.
V.3.2.1. Le processus unifié : cadre général
Le processus unifié est un processus de
développement logiciel : il regroupe les activités à mener
pour transformer les besoins d'un utilisateur en système logiciel.
Caractéristiques essentielles du processus unifié :
70
? Le processus unifié est à base de composants,
? Le processus unifié utilise le langage UML (ensemble
d'outils et de
diagramme),
? Le processus unifié est piloté par les cas
d'utilisation,
? Le processus Unifié est Centré sur
l'architecture,
? Le processus Unifié est Itératif et
incrémental.
V.3.2.2. Le processus unifié est piloté par
les cas d'utilisation a) Présentation
L'objectif principal d'un système logiciel est de
rendre service à ses utilisateurs ; il faut par conséquent bien
comprendre les désirs et les besoins des futurs utilisateurs. Le
processus de développement sera donc centré sur l'utilisateur. Le
terme utilisateur ne désigne pas seulement les utilisateurs humains mais
également les autres systèmes. L'utilisateur représente
donc une personne ou une chose dialoguant avec le système en cours de
développement.
Figure 18:Exemple d'une itération de cas
d'utilisation
V.3.2.3.Le processus unifié est centré sur
l'architecture
Dès le démarrage du processus, on aura une vue
sur l'architecture à mettre en place. L'architecture d'un système
logiciel peut être décrite comme les différentes vues du
système qui doit être construit. L'architecture logicielle
équivaut aux aspects statiques et dynamiques les plus significatifs du
système. L'architecture émerge des besoins de l'entreprise, tels
qu'ils sont exprimés par les utilisateurs et autres intervenants et tels
qu'ils sont reflétés par les cas d'utilisation.
71
Elle subit également l'influence d'autres facteurs :
? la plate-forme sur laquelle devra s'exécuter le
système ;
? les briques de base réutilisables disponibles pour le
développement
? les considérations de déploiement, les
systèmes existants et les besoins
non fonctionnels (performance, fiabilité.)
? Liens entre cas d'utilisation et
architecture
Tout produit est à la fois forme et fonction. Les cas
d'utilisation doivent une fois réalisés, trouver leur place dans
l'architecture. L'architecture doit prévoir la réalisation de
tous les cas d'utilisation. L'architecture et les cas d'utilisation doivent
évoluer de façon concomitante.
? Marche à suivre :
L'architecte crée une ébauche grossière
de l'architecture, en partant de l'aspect qui n'est pas propre aux cas
d'utilisation (plate-forme). Bien que cette partie de l'architecture soit
indépendante des cas d'utilisation. L'architecte doit avoir une
compréhension globale de ceux-ci avant d'en esquisser l'architecture. Il
travaille ensuite, sur un sous ensemble des cas d'utilisations
identifiés, ceux qui représentent les fonctions essentielles du
système en cours de développement. L'architecture se
dévoile peu à peu, au rythme de la spécification et de la
maturation des cas d'utilisation, qui favorisent, à leur tour, le
développement d'un nombre croissant de cas d'utilisation. Ce processus
se poursuit jusqu'à ce que l'architecture soit jugée stable.
| 
