RUP Rational Unified Process

Chapitre 02
RUP : Rational Unified Process
L.GOUDJIL Chapitre 02: RUP : Rational Unified Process Génie Logiciel 2 2019/2020 1 / 84
Processus Unifié UP (Unified Process)
 C'est un patron de processus pouvant être adaptée:

 à une large classe de systèmes logiciels,
 à différents domaines d'application,
 à différents types d'entreprises,
 à différents niveaux de compétences et
 à différentes tailles de l'entreprise.
Chapitre 02: RUP : Rational Unified Process Génie Logiciel 2 2019/2020 2 / 84

Cycle de vie Cycle de vie en cascade
 Le processus unifié est un processus de développement

logiciel construit sur UML.
 Il est itératif, centré sur l'architecture, piloté par des cas
d'utilisation et orienté vers la diminution des risques.
 Il regroupe les activités à mener pour transformer les besoins
d’un utilisateur en système logiciel.
3 / 84
 Caractéristiques essentielles du processus unifié :

 Le processus unifié est à base de composants,
 Le processus unifié utilise le langage UML
 Le processus unifié est piloté par les cas d’utilisation,
 Centré sur l’architecture, Itératif et incrémental.

 UP est piloté par les cas d’utilisation
 Les cas d’utilisation ne sont pas un simple outil de

spécification des besoins du système.
 Ils vont complètement guider le processus de
développement à travers l’utilisation de modèles basés
sur l’utilisation du langage UML.


RUP : Rational Unified Process
Rational Unified Process (RUP)
 implémentation commerciale du processus de

développement unifié (UP),
 Developper par Jacobson ……..
 Produit d’IBM
RUP, Domaines d’utilisations
 dans tous les projets complexes,

 dans le cas où l’exigence client est très forte,
 Les coûts sont bien maîtrisés

 les retards de livraison, sont généralement
très réduits.

RUP,les caractéristiques
 Itératif et incrémental
 Pilotés par les cas d’utilisations
 Centré sur l’architecture.
 Le projet est découpé en plusieurs phases
très courtes à l'issue desquelles un
incrément est livré.
L.GOUDJIL 11 / 84
 Chaque itération prend en compte un certain nombre de cas
d'utilisations.
 Les risques majeurs sont traités en priorité.
 Chaque itération donne lieu à un incrément et produit une

nouvelle version exécutable.
Démarche de construction du modèle des cas d’utilisations
UML :DIAGRAMME DE CONTEXTE
 Le diagramme de contexte constitue une étape

intermédiaire entre le cahier des charges et la
construction des premiers cas d’utilisation.
 Il n’est donc pas indispensable. D’ailleurs, il ne

correspond pas à un des 14 diagrammes de la
normeUML 2.5.
UML :DIAGRAMME+ DE CONTEXTE STATIQUE
diagramme de cas d'utilisation

2. diagramme de package
3. diagramme de classe
4. diagramme d'objet
5. diagramme de séquence
6. diagramme de communication
7. diagramme global d’interaction
8. diagramme d'activité
9. diagramme d'état-transition
10. diagramme de structure composite
11. diagramme de timing
12. diagramme de composant
13. diagramme de déploiement
UML :DIAGRAMME DE CONTEXTE STATIQUE
Le diagramme de contexte statique délimite le domaine d’étude en

précisant
ce qui est à la charge du système et
en identifiant l’environnement extérieur au système étudié
avec lequel ce dernier
communique.
On représente les interactions des acteurs avec le système

étudié. Mais pas les interactions entre acteurs.
UML :DIAGRAMME DE CONTEXTE DYNAMIQUE
UML :CLASSE PRINCIPALE DU SYSTÈME
Nom de sys
Adminstration système()
Confirmation commande en
cours()
Gestion des resources()
Statistiques()
………….
RUP Vues du système
CLASSES D’ANALYSE DE JACOBSON
 Diagramme de cas d'utilisation du système de gestion des demandes de

formation
 représentation des stéréotypées sur un diagramme de classes
 Division du modèle statique d'étude de cas
 Ajout de navigabilités sur les associations qui traversent deux packages
Démarche d’élaboration du modèle statique
 suivant les préconisations de Jacobson reprises dans le RUP,

différencient dès l’analyse trois types de classes :
CLASSES D’ANALYSE DE JACOBSON: Boundary
 Les classes qui permettent les interactions entre

l’application et ses utilisateurs sont qualifiées de
boundary.
 Il y a au moins une boundary pour chaque paire
(acteur - cas d’utilisation).
Stefano Zacchiroli (Paris 7)

CLASSES D’ANALYSE DE JACOBSON : Control
 Celles qui contiennent la cinématique de l’application sont

appelées control.
 Elles font la transition entre les boundary et les classes métier.
 Les control ne donneront pas forcément lieu à de vrais objets
de conception,
 mais assurent que nous n’oublions pas de fonctionnalités ou
de comportements requis par les cas d’utilisation.
CLASSES D’ANALYSE DE JACOBSON :Entity
 Celles qui représentent les objets métier sont qualifiées

d’entity.
 Ce sont très souvent des entités persistantes, c’est-à-dire
qui vont survivre à l’exécution d’un cas d’utilisation
particulier.
CLASSES D’ANALYSE DE JACOBSON : Règles Interactions
 Les acteurs ne peuvent interagir (envoyer des

messages) qu’avec les boundary.
 Les boundary peuvent interagir avec les control ou
exceptionnellement avec d’autres boundary.
 Les control peuvent interagir avec les boundary,
les entity, ou d’autres control.
 Les entity ne peuvent interagir qu’entre elles et
ne sont reliées qu’aux classes « Control ».
UML : DIAGRAMME DE COMMUNICATION
 Diagramme de collaboration (UML 1.X)

 Diagramme de communication (UML 2.X)
 Version simplifié du diagramme de séquence
 2 vues différentes mais logiquement identiques : isomorphe

UML : DIAGRAMME DE COMMUNICATION


 Illustration of Jacobson’s three stereotypes on a communication

diagram
 la figure suivante, mettant en œuvre les notations graphiques

proposées par Jacobson pour ses classes d’analyse.
 Illustration of Jacobson’s three stereotypes on a communication

diagram


 représentation des stéréotypées sur un diagramme de classes
Schéma de dépendances entre composants métier
Identification des composants
RUP est centré sur l'architecture
 Modélisation de différente perspectives

indépendantes et complémentaires
 Architecture en couches et vues de Krutchen
 Architecture à trois niveaux de la caisse enregistreuse
 Vue cas d'utilisation

- Description du système comme un ensemble
de transactions du point de vue de l'utilisateur.
 Vue logique
- Créée lors de la phase d'élaboration et

raffinée lors de la phase de construction,
 Vue composants
- Description de l'architecture logicielle.
 Vue déploiement
- Description de l'architecture matérielle du système.
 Vue implémentation
- Description des algorithmes, code source .
Aperçu des phases de RUP
L.GOUDJIL Chapitre 02: RUP : Rational Unified Process Génie Logiciel 2 2019/2020 55/ 84
Phase d'initialisation : Objectifs
 Définition du cadre du projet, son concept, et
inventaire du contenu
 Réalisation d'un ou de plusieurs prototypes démontrant
les fonctionnalités décrites par les cas d'utilisation
principaux
 Estimation détaillée de la charge de travail, du coût,
 Estimation des risques
Phase d'initialisation : Activités
 Formulation du cadre du projet, des besoins, des
contraintes et des critères d'acceptation
 Synthèse des architectures candidates, évaluation des

coûts
Phase d'initialisation : Activités
 Planification et préparation de la justification

économique du projet et évaluation des alternatives
en termes de gestion des risques, ressources,
planification
Phase d'initialisation : Livrables
 Un document de justification économique
 Une évaluation des risques
 Un plan de projet présentant phases et itérations
 Un ou plusieurs prototypes
Phase d'initialisation : Livrables
 Un document de vision présentant les besoins de base, les
contraintes et fonctionnalités principales
 Une première version du modèle de cas d'utilisation
 Un glossaire de projet
Phase d'initialisation : Critères d'évaluation
 Un consensus sur :
• la planification,
• les coûts
 la définition de l'ensemble des projets et des parties
concernées
 La compréhension commune des besoins
Phase d'élaboration : objectifs
 Définir, valider et arrêter l'architecture
 Démontrer l'efficacité de cette architecture à répondre à
notre besoins
 Planifier la phase de construction
Phase d'élaboration : activités
 Elaboration de la vision générale du système, les cas

d'utilisation principaux sont compris et validés
 Le processus de projet, l'infrastructure, les outils et
l'environnement de développement sont établis et mis en
place
 Elaboration de l'architecture et sélection des composants
Phase d'élaboration : livrables
 Le modèle de cas d'utilisation est produit au moins à 80 %

 La liste des contraintes non fonctionnelles identifiées
 Une description de l'architecture
 Un exécutable permettant de valider l'architecture du logiciel
 La liste des risques revue et la mise à jour de la justification
économique du projet
 Le plan de réalisation, y compris un plan de développement
présentant les phases, les itérations et les critères d'évaluation
Phase d'élaboration : Critères d'évaluation
 La stabilité de la vision du produit final
 La stabilité de l'architecture
 La prise en charge des risques principaux est adressée par
le(s) prototype(s)
 La définition et le détail du plan de projet pour la phase de
construction
Phase de construction : objectifs
 La minimisation des coûts de développement
par :
 l'optimisation des ressources
 la minimisation des travaux non nécessaires
 Le maintien de la qualité
 Réalisation des versions exécutables
Phase de construction : Activités
 La gestion et le contrôle des ressources et l'optimisation du
processus de projet
 Evaluation des versions produites en regard des critères
d'acceptation définis
Phase de construction : Livrables
 Les versions exécutables du logiciel correspondant à

l'enrichissement itération par itération des fonctionnalités
 Les manuels d'utilisation réalisés en parallèle à la livraison
incrémentale des exécutables
 Une description des versions produites
Phase de construction : Critères d'évaluation
 La stabilité et la qualité des exécutables
 La préparation des parties prenantes
 La situation financière du projet en regard du budget initial
Phase de transition : Objectifs
 Le déploiement du logiciel dans l'environnement

d'exploitation des utilisateurs
 La prise en charge des problèmes liés à la transition
 Atteindre un niveau de stabilité tel que l'utilisateur
est indépendant
 Atteindre un niveau de stabilité et qualité tel que les
parties prenantes considèrent le projet comme
terminé
Phase de transition : Activités
 Activités de « packaging » du logiciel pour le
mettre à disposition des utilisateurs et de l'équipe
d'exploitation
 Correction des erreurs résiduelles et amélioration de
la performance et du champ d'utilisation
 Evaluation du produit final en regard des critères
d'acceptation définis
Phase de transition : Livrables
 La version finale du logiciel
 Les manuels d'utilisations
Phase de transition : Critères d'évaluation
 La satisfaction des utilisateurs
 La situation financière du projet en regard
du budget initial
Organisation en Activités de développement
 Chaque phase comprend plusieurs itérations

 Pour chacune des itérations, on se livre à plusieurs
activités :
• Expression des besoins
• Analyse
• Conception
• Implémentation
• Test
• Déploiement
Expression des besoins
 Cibler les besoins des utilisateurs et du clients grâce à une
série d'interviews.
 L'ensemble des parties prenantes du projet, maîtrise d'oeuvre
et maîtrise d'ouvrage, est acteur de cette activité.
 ce que doit faire le système (question « QUOI ? »)
 Utilisation des cas d'utilisation pour :
• Schématiser les besoins

• Structurer les documents de
spécifications fonctionnelles.
 Les cas d'utilisation sont décomposés en scénarios d'usage du
système, dans lesquels l'utilisateur raconte ce qu'il fait grâce
au système et ses interactions avec le système.
 Un maquettage est réalisable pour mieux « immerger »
l'utilisateur dans le futur système.
 Une fois posées les limites fonctionnelles, le projet est
planifié et une prévision des coûts est réalisée
Analyse
 Transformer les besoins utilisateurs en modèles UML
 Analyse objet servant de base à une réflexion sur les
mécanismes internes du système
 Peut envisagé comme une première ébauche du modèle de
conception
 Principaux livrables:
• Modèles d'analyse, neutre vis à vis d'une technologie.

• Livre une spécification plus précise des besoins
Conception
 Modéliser comment le système va fonctionner
 Exigences non fonctionnelles
 Choix technologiques.
 Le système est analysé et on produit :
 Une proposition d'architecture.
 Un découpage en composants.
Implémentation
 Implémenter le système par composants.
 Le système est développé par morceaux dépendant les
uns des autres.
 Optimisation de l'utilisation des ressources selon leurs
expertises.
Test
 Vérifier des résultats de l'implémentation en testant
la construction.
 Tests unitaires : tests composants par composants
 Tests d'intégration : tests de l'interaction de
composants préalablement testés individuellement
Test
• Planification pour chaque itération
• Implémentation des tests en créant des cas de tests
• Exécuter les tests
• Prendre en compte le résultat de chacun.
Déploiement
 Déployer les développements une fois réalisés.

 Peut être réalisé très tôt dans le processus dans une sous
activité de prototypage dont :
 l'objectif est de valider
 l'architecture physique
 les choix technologiques

RUP Rational Unified Process

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RUP Rational Unified Process

Uploaded by

Copyright:

Available Formats

Chapitre 02

RUP : Rational Unified Process

 C'est un patron de processus pouvant être adaptée:

Chapitre 02: RUP : Rational Unified Process Génie Logiciel 2 2019/2020 2 / 84

Processus Unifié UP (Unified Process)

 Le processus unifié est un processus de développement

Processus Unifié UP (Unified Process)

 Caractéristiques essentielles du processus unifié :

Chapitre 02: RUP : Rational Unified Process Génie Logiciel 2 2019/2020 4 / 84

Processus Unifié UP (Unified Process)

 UP est piloté par les cas d’utilisation

 Les cas d’utilisation ne sont pas un simple outil de

Chapitre 02: RUP : Rational Unified Process Génie Logiciel 2 2019/2020 5 / 84

Processus Unifié UP (Unified Process)

Chapitre 02: RUP : Rational Unified Process Génie Logiciel 2 2019/2020 6 / 84

 implémentation commerciale du processus de

 dans tous les projets complexes,

 Les coûts sont bien maîtrisés

Chapitre 02: RUP : Rational Unified Process Génie Logiciel 2 2019/2020 9 / 84

 Pilotés par les cas d’utilisations

 Centré sur l’architecture.

 Le projet est découpé en plusieurs phases

très courtes à l'issue desquelles un

incrément est livré.

 Les risques majeurs sont traités en priorité.

 Chaque itération donne lieu à un incrément et produit une

 Le diagramme de contexte constitue une étape

 Il n’est donc pas indispensable. D’ailleurs, il ne

diagramme de cas d'utilisation

Le diagramme de contexte statique délimite le domaine d’étude en

On représente les interactions des acteurs avec le système

 Diagramme de cas d'utilisation du système de gestion des demandes de

 représentation des stéréotypées sur un diagramme de classes

 Division du modèle statique d'étude de cas

 Ajout de navigabilités sur les associations qui traversent deux packages

 suivant les préconisations de Jacobson reprises dans le RUP,

 Les classes qui permettent les interactions entre

Stefano Zacchiroli (Paris 7)

 Celles qui contiennent la cinématique de l’application sont

 Celles qui représentent les objets métier sont qualifiées

 Les acteurs ne peuvent interagir (envoyer des

 Diagramme de collaboration (UML 1.X)

Stefano Zacchiroli (Paris 7)

Stefano Zacchiroli (Paris 7)

Stefano Zacchiroli (Paris 7)

 Illustration of Jacobson’s three stereotypes on a communication

 la figure suivante, mettant en œuvre les notations graphiques

 Illustration of Jacobson’s three stereotypes on a communication

 la figure suivante, mettant en œuvre les notations graphiques

 la figure suivante, mettant en œuvre les notations graphiques

 représentation des stéréotypées sur un diagramme de classes

 Modélisation de différente perspectives

 Architecture à trois niveaux de la caisse enregistreuse

 Vue cas d'utilisation

- Créée lors de la phase d'élaboration et

- Description de l'architecture matérielle du système.

- Description des algorithmes, code source .

 Synthèse des architectures candidates, évaluation des

 Planification et préparation de la justification

 Un document de justification économique

 Une évaluation des risques

 Un plan de projet présentant phases et itérations

 Un document de vision présentant les besoins de base, les

contraintes et fonctionnalités principales