Diapositive 1

Version 1.0

Programmation et
Développement orientés objets
Cours B4
Chapitre 5: Le processus et la
méthode UML
Extrait du livre UML en action*
* UML en ACTION
Pascal ROQUES et Franck VALLEE
Editeur EYROLLES
ISBN 2-212-09127-3
Diapositive 2

Le processus UP
UP = Unified Process
„ RUP = Rational Unified Process
C’est un processus de développement
logiciel construit sur la méthode UML
„ Itératif
„ Centré sur l’architecture,
„ Conduit par les cas d’utilisation
„ Piloté par les risques

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 2/12

Dans le processus UP, les activités de développement sont organisée suivant 5 workflows
qui décrivent:
La capture des besoins,
L’analyse,
La conception,
L’implémentation
Et le test.

Le UP est une trame des meilleures pratiques de développement, il doit être utilisé comme
un guide pour réaliser un projet et non comme l’arme ultime et universelle de
développement.

Incrémental: Il favorise la définition d’incréments de réalisation utilisables et fonctionnels. Un

projet ne produisant rien de tangible dans les 9 mois court un risque majeur d’échec. Les
incréments garantissent que les équipes sont capables de développer et d’intégrer le produit,
ils garantissent aussi des résultats tangibles aux utilisateurs et permettent de détecter tôt les
écarts par rapport aux spécifications fonctionnelles. Enfin ce sont d’excellents moyens de
contrôle des coûts et des délais. Chaque itération porte sur la conception et la réalisation
d’une fonctions
Piloté par les risques: Les causes majeures d’échec d’un projet logiciel sont: l’incapacité du
système à répondre au exigences opérationnelles (défaillance de l’architecture technique du
système) et l’inadéquation du système aux attentes des utilisateurs (non respect des
exigences fonctionnelles). Ces causes d’échec doivent être contrôlées et supprimées.
Ces processus sont organisés autour du développement et du maintien de modèles plutôt
qu’autour d’une montagne de documents. Ces modèles ont une densité d’informations
importante et nécessite l’utilisation d’une méthode pour maintenir une organisation stricte
des différents points de vue du système au différents niveaux d’abstractions.

Bien entendu les processus UP sont orientés composants pour assurer le niveau de
souplesse et de réutilisabilité nécessaire aux différents incréments

Les processus UP orientés utilisateurs car les spécifications et la conception sont bâtis à
partir des modes d’utilisation attendus par les utilisateur du système (décrits par les cas
d’utilisation).
Diapositive 3

Exemple de processus UP:

Le processus 2TUP

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 3/12

2TUP = 2 Tracks Unified Process

Le processus 2TUP constate que toute évolution imposée au système peut se décomposer
et se traiter parallèlement, suivant un axe fonctionnel et un axe technique.
On peut donc étudier indépendamment les évolutions liées aux changements des besoins
fonctionnels et celle liées aux besoins techniques. A l’issue de ces étapes d’analyse, la
conception fusionne les besoins pour réaliser le système.

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’œuvre 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. Celle conception est complètement indépendante 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. L'importance de sa réussite est telle qu'il
est conseillé de réaliser un prototype pour assurer sa validité.
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é.

PROCESSUS UNIFIÉ (UNIFIED PROCESS)

Un processus unifié est un processus de développement logiciel construit sur UML ; il est
itératif centré sur l'architecture, conduit par les cas d'utilisation et piloté par les risques.
La gestion d'un tel processus est organisée suivant les 4 phases suivantes: pré-étude,
élaboration, construction et transition.
Ses activités de développement sont définies par 5 workflows fondamentaux qui décrivent la
capture des besoins, l'analyse, la conception, l'implémentation et le test.
Le processus unifié doit donc être compris comme une trame commune des meilleures
pratiques de développement, et non comme l'ultime tentative d'élaborer un processus
universel. La définition d'un processus UP est donc constituée de plusieurs workflows
d'activités de production et de contrôle de cette production. Tout processus UP répond aux
caractéristiques ci-après.
Il est incrémental. La définition d'incréments de réalisation est en effet la meilleure pratique
de gestion des risques d'ordre à la fois technique et fonctionnel. On peut estimer qu'un projet
qui ne produit rien d'exécutable dans les 9 mois court un risque majeur d'échec. Chaque
incrément garantit que les équipes sont capables d'intégrer l'environnement technique pour
développer un produit final et fournit aux utilisateurs un résultat tangible de leurs
spécifications. Le suivi des incréments constitue par ailleurs un excellent contrôle des coûts
et des délais.

Nous identifions une première cause provenant de l'incapacité de l'architecture technique à

répondre aux contraintes opérationnelles, et une seconde cause liée à l'inadéquation du
développement aux besoins des utilisateurs.

Il est construit autour de la création et de la maintenance d'un modèle, plutôt que de la

production de montagnes de documents. Le volume d'informations de ce modèle nécessite
une organisation stricte qui présente les différents points de vue du logiciel à différents
degrés d'abstraction. L'obtention de métriques sur le modèle fournit par ailleurs des moyens
objectifs d'estimation.

Il est itératif. Chaque itération porte sur des degrés d'abstraction de plus en plus précis et
permet de produire des traces nécessaires au contrôle du changement.

Il est orienté composant. Tant au niveau modélisation que production, c'est une garantie de
souplesse pour le modèle lui-même et le logiciel qu'il représente. Cette pratique constitue le
support nécessaire à la réutilisation logicielle et offre des perspectives de gains non
négligeables.

Il est orienté utilisateur, car la spécification et la conception sont construites à partir des
modes d'utilisation attendus par les acteurs du système.
Le processus 2TUP

2TUP signifie « 2 Tracks Unifed 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 Tracks » signifie littéralement que le processus suit deux chemins. II s'agit des
chemins « fonctionnels » et « d'architecture technique », qui correspondent aux deux axes
des changements imposés au système informatique.
L'axiome fondateur du 2TUP consiste à constater que toute évolution imposée au système
d'information peut se décomposer et se traiter parallèlement, suivant un axe fonctionnel et un
axe technique. Pour illustrer cet axiome, prenons les trois exemples suivants
I. une agence de tourisme passe des accords avec une compagnie aérienne de sorte
que le calcul des commissions change. En l'occurrence, les résultats issus de la branche
fonctionnelle évoluent pour prendre en compte la nouvelle spécification ;
2. cette même entreprise décide d'ouvrir la prise de commande sur le Web Si rien ne
change fonctionnellement, en revanche, l'architecture technique du système évolue ;
3. cette entreprise décide finalement de partager son catalogue de prestations avec les
vols de la compagnie aérienne. D'une part, la fusion des deux sources d'informations
imposera une évolution de la branche fonctionnelle, d'autre part, les moyens techniques de
synchronisation des deux systèmes conduiront à étoffer l'architecture technique du système.
L'étude de ces évolutions pourra être menée indépendamment, suivant les deux branches
du 2TUP.

A 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 2-2.

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’œuvre 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. Celle conception est complètement indépendante 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. L'importance de sa réussite est telle qu'il
est conseillé de réaliser un prototype pour assurer sa validité.
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é.
L'ensemble de ces étapes de développement sera illustré tout au long de cet ouvrage par la
mise en application du processus 2TUP à l'étude de cas SIVEx. Seules les deux dernières
étapes, ne relevant pas de l'utilisation d'UML, ne seront pas abordées dans cet ouvrage.

LES BRANCHES DU "Y" PRODUISENT DES MODÈLES RÉUTILISABLES

La branche gauche capitalise la connaissance du métier de l'entreprise. Elle constitue

généralement un investissement pour le moyen et le long terme. Les fonctions dit système
d'informations sont en effet indépendantes des technologies utilisées. L'entreprise qui
maintient le modèle fonctionnel de sa branche gauche est à même de le réaliser sous
différentes technologies. Il suffit de « greffer » une nouvelle architecture technique pour
mettre à jour un système existant.

La branche droite capitalise quant à elle un savoir-faire technique. Elle constitue un

investissement pour le court et le moyen terme. Les techniques développées pour le
système peuvent l'être en effet indépendamment des fonctions à réaliser. Une architecture
technique est en effet immédiatement réutilisable pour les différentes composantes
fonctionnelles d'un même système d'entreprise.

C’est un processus incrémental:

Un incrément constitue un ensemble d'étapes de développement qui aboutit à la construction
de tout ou partie du système. Le contenu d'un incrément est porteur d'améliorations ou
d'évolutions du système et il peut être évalué par les utilisateurs. En général, les incréments
s’inscrivent dans une phase du projet et sont cohérents avec elle: en phase de pré-étude
l’incrément conduit à l’évaluation des problèmes techniques et du bien fondé de la
réalisation; en phase d’analyse, l’incrément consiste à étudier l’adéquation du système aux
besoins des utilisateurs…

Par définition, chaque incrément passe en revue toutes tes activités du processus en Y. Mais
l'effort consacré à chaque activité n'est pas identique suivant la phase de développement du
projet. On peut estimer que l'incrément de pré-étude consacre relativement plus d'effort à la
capture des besoins que les incréments d'élaboration.

Les incréments conduisent à une vue de plus en plus précise et riche du système à réaliser.
Chaque incrément correspond à une niveau d’abstraction (la vision du système est de plus
en plus concrète après chaque itération). Chaque itération utilise un modèle adapté au
niveau d’abstraction considéré:
capture des besoins fonctionnels -> boite noire de définition des contours du système et cas
d’utilisations;
Capture des besoins techniques -> cas d’utilisations
Analyse -> diagrammes de classes et d’objets
Conception générique -> diagrammes de déploiement et diagrammes de composants
Conception préliminaire -> diagrammes de classes, de séquence et d’activité
Conception détaillée -> diagrammes de classes, de séquence et d’activité

C’est un processus qui permet de contrôler les risques :

C’est un processus qui permet de contrôler les risques tout au long du déroulement du
projet: la nécessité de produire régulièrement des incréments conduit à contrôler les risques
d’inadéquation aux besoins des utilisateurs (risques fonctionnels) et les risques d’incapacité
à intégrer techniquement la solution (risques techniques).

C’est un processus centré sur les besoins des utilisateurs:

Comme les risques d’échec d’un projet proviennent souvent de la non adéquation du
système réalisé aux besoin des utilisateurs, le process 2TUP prend en compte deux groupes
d’utilisateurs: l’utilisateur fonctionnel du système et l’exploitant.
Cette prise en compte permet d’assurer un système qui réponde aux besoin du métier et aux
besoins de l’exploitation (administration, sécurité, sauvegardes, performances…)
Les deux sommets du Y sont modélisés à l’aide de cas d’utilisation centrés sur les acteurs
fonctionnels et sur les acteurs exploitants. Ces cas d’utilisation forment les points de départ
de l’analyse. Pendant la phase de conception préliminaire, on vérifie que les interactions
entre les classes identifiées respectent les contraintes exprimées dans les cas d’utilisation.
Diapositive 4

Les Diagrammes d’UML

Les diagrammes de cas d’utilisation

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 4/12

UML s'articule autour de neuf diagrammes différents, chacun d'eux étant dédié à la
représentation des concepts particuliers d'un système logiciel.

Par ailleurs, UML modélise le système suivant deux modes de représentation:

la structure du système pris « au repos »,
La dynamique de fonctionnement.
Les deux représentations sont nécessaires et complémentaires pour schématiser la façon
dont est composé le système et comment ses composantes fonctionnent entre elles.

Le diagramme de cas d'utilisation représente la structure des fonctionnalités nécessaires aux

utilisateurs du système. Il est utilisé dans les deux étapes de capture des besoins
fonctionnels et techniques.

Le cas d’utilisation est utilisé pour spécifier le comportement du système en interaction avec
les acteurs externes (humains ou matériels).
Diapositive 5

Les Diagrammes d’UML

Le diagramme de classes

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 5/12

Le diagramme de classes représente le concept le plus important dans un développement

orienté objet.
Il permet pendant l’analyse fonctionnelle de représenter les entités connues des utilisateurs
Il permet ensuite dans les phases de conception de décrire la représentation objet du
système
Diapositive 6

Les Diagrammes d’UML

Le diagramme d’objets

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 6/12

Le diagramme d'objets sert à illustrer des structures de classes compliquées.

Ce diagramme est utilisé en analyse pour vérifier l'adéquation d'un diagramme de classes à
différents cas possibles
Ce modèle permet d’illustrer concrètement des exemples de structures de données
Diapositive 7

Les Diagrammes d’UML

Le diagramme de composants

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 7/12

Le diagramme de composants représente en premier lieu les concepts connus de l'exploitant

pour installer et dépanner le système. I! s'agit dans ce cas de déterminer la structure des
composants d'exploitation que sont les librairies dynamiques, les instances de bases de
données, les applications, les progiciels, les objets distribués, les exécutables, etc.
Le diagramme de composants représente en second lieu les concepts de configuration
logicielle, pour fabriquer une version de composant d'exploitation ou tout autre produit
intermédiaire tel qu'une librairie ou un archive. Il s'agit de montrer comment s'agencent des
composants comme les fichiers source, les packages de code ou les librairies.
Le modèle de composants représente le lien entre le modèle logique issu de l’analyse et de
la conception et le modèle physique (d’implémentation). Il permet de spécifier l’architecture
logicielle dans un environnement de développement donné. Ce modèle n’est pas toujours
utilisable car tous les langages ne supportent pas nécessairement le concept de module et
de composant.
Diapositive 8

Les Diagrammes d’UML

Le diagramme de déploiement

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 8/12

Le diagramme de déploiement correspond à la fois à la structure physique qui prend en

charge le système logiciel, et la façon dont les composants d'exploitation y sont installés.
Le modèle de déploiement constitue un diagramme de l’organisation matérielle du système
ou de l’application. Il constitue une sorte de synoptique du système. Un diagramme de
déploiement permet de donner l’architecture de la plate-forme technique, de préciser où se
trouvent les processus et de montrer comment les objets se déplacent dans une architecture
distribuée.
Diapositive 9

Les Diagrammes d’UML

Le diagramme d’états

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 9/12

Le diagramme d'états représente le cycle de vie commun aux objets d'une même classe. Ce
diagramme complète la connaissance des classes en analyse et en conception.
Diapositive 10

Les Diagrammes d’UML

Le diagramme d’activités

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 10/12

Diapositive 11

Les Diagrammes d’UML

Le Diagramme de séquences

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 11/12

Les diagrammes de séquences expriment le déroulement de plusieurs messages pour une

exécution données.
Ces diagrammes sont équivalents aux diagrammes de collaboration mais autorisent une
appréciation visuelle du temps (il s’écoule de « haut en bas » du diagramme).
Diapositive 12

Les Diagrammes d’UML

Le diagramme de collaboration

07/05/2001 Chapitre 5: Le processus et la méthode unifiés 12/12

Ils présentent la collaboration entre objets pour une exécution donnée sans mettre l’accent
sur la chronologie des messages (à la différence des diagrammes de séquence).
L’apport du diagramme de collaboration est la possibilité de préciser les règles de visibilité
d’un objet.