PROCESSUS

UNIFIÉ

R É A L I S É E PA R :
AMENI BEN SALAH & HAHDEMI SLIM & RANIA KHLIFI
SOMMAIRE

• Pourquoi une méthodologie / processus?

• Le processus Unifié
Itération
Phases
Activités
POURQUOI UNE MÉTHODOLOGIE /
PROCESSUS?
• Les techniques (diagrammes d’UML) de développement de système doivent être organisées si
elles doivent fonctionner ensemble,
• UML même ne contient rien qui aide à prendre cette décision,
• L'organisation des tâches n'est pas contenue dans les techniques,
• Elle doit être décrite à un plus haut niveau d'abstraction,
• Méthode/Processus = description pas-à-pas des étapes impliquées dans l'accomplissement
d'une tâche particulière
• Elle ne peut être la même pour deux projets différents, la méthode est spécifique à un projet,
POURQUOI UNE MÉTHODOLOGIE /
PROCESSUS?
De nombreux avantages sont avancés :
 Aide à produire un produit de meilleure qualité
 Logiciel mieux documenté
 Plus acceptable par l'utilisateur
 Plus facile à maintenir/entretenir
 Logiciel plus homogène
 Aide à assurer que les spécifications des utilisateurs sont suivies
 Aide le manager du projet à contrôler le projet
 Réduit les coûts de développement
 Encourage la communication entre les personnes
PROCESSUS UNIFIÉ
LE PROCESSUS UNIFIÉ UTILISE LES NOTATIONS UML

Équipe de
développement

Langage de
Modélisation Processus unifié
LE PROCESSUS UNIFIÉ

• Les auteurs principaux d'UML, I. Jacobson, G. Booch et J. Rumbaugh, proposent une

démarche de développement pouvant être facilement associée à UML : le Processus Unifié
(Unified Software Development Process ).
• L'essentiel du Processus Unifié provient des méthodes Objectory, Booch, et OMT, auxquelles
s'ajoutent quelques apports issus des travaux d'élaboration d'UML.Le Processus Unifié ne fait
pas partie intégrante du standard UML.
• Processus du domaine public pour le développement Orienté-Objet de logiciel
• Maintenant largement surpassé par le Processus Unifié Rational (similaires dans leurs aspects
principaux)
LE PROCESSUS UNIFIÉ

• Les itérations peuvent être regroupées en 4 phases :

 création (objectifs du projet, et coûts),
 élaboration (besoins),
 construction (obtention du produit quasi finalisé),
 transition (mise au point et livraison).
 Profil d’un projet typique montrant les tailles relatives des quatre phases
LE PROCESSUS UNIFIÉ

• Chaque itération consiste à enchaîner 5 activités principales:

Besoins
Analyse
Conception
Implémentation
Tests.
Différentes activités plus spécifiques peuvent s'enchaîner dans chacune de ces 5 activités
principales. Elles sont effectuées par différents travailleurs.
ORGANISATION EN PHASES,
ITÉRATIONS ET ACTIVITÉS
• Pour mener efficacement un tel cycle, les développeurs ont besoins de toutes les représentations
du produit logiciel.
 un modèle de cas d'utilisation.
 un modèle d'analyse : détailler les cas d'utilisation.
 un modèle de conception : finissant la structure statique du système sous forme de sous systèmes, de classes
et interfaces.
 un modèle d'implémentation : intégrant les composants
 un modèle de déploiement : définissant les nœuds physiques des ordinateurs
 un modèle de test : décrivant les cas de test vérifiant les cas d'utilisation
 une représentation de l'architecture.
LES PHASES
 PHASE DE « CRÉATION »
Création Élaboration Construction Transition
temps
Vision - Besoins

• Objectifs
– Définir les limites du système
– Identifier les usages
• cas d’utilisation
• interfaces utilisateurs
– Esquisser une architecture initiale
– Identifier les risques principaux
• Résultats
– Vision : glossaire, liste des acteurs, liste des cas d’utilisation classée, 10 % des cas d’utilisation
représentatifs documentés, contraintes non fonctionnelles, liste des risques principaux, premier diagramme
de classes, interfaces utilisateurs
– Feu vert du commanditaire
PHASE «ELABORATION»
Création Élaboration Construction Transition
temps
Vision Architecture
• Objectifs Besoins

– Définir l’architecture de référence

– Préciser les cas d’utilisation (80 % des besoins fonctionnels)
– Planifier le projet
– Préciser les risques du projet (besoins, technologiques, compétences, politiques)
• Résultats
– Architecture de référence : concerne les cas d’utilisation centraux avec l’ensemble de
leurs modèles d’analyse
– Un planning du projet intégrant le calendrier, les coûts, le personnel
– Une évaluation des risques et des éléments de protection
PHASE DE « CONSTRUCTION »
Création Élaboration Construction Transition
temps
Vision Produit
Architecture
Besoins

• Objectifs
– Finalisation de la description et de la réalisation des cas d’utilisation
– Finalisation de l’analyse, de la conception, de l’implantation et des tests informatiques
– Validation par rapport aux risques
– Validation par rapport à l’architecture de référence
• Résultats
– Produit version Béta, logiciel testé en interne, manuels
PHASE DE « TRANSITION »
Création Élaboration Construction Transition
temps
Vision Architecture Produit Produit
Besoins validé
• Objectifs
– Correction des derniers bugs liés au béta test
– Validation par rapport aux besoins du client
• Logiciel
• Manuels

• Résultats
– Produit validé par les utilisateurs
LES ACTIVITÉS
LES ACTIVITÉS PRODUISENT DES MODÈLES

Besoins ………….
Modèle des cas d’utilisation

Analyse …………………………..
Modèle d’analyse

Conception ………………………………. Modèle de déploiement

Modèle de conception

Implémentation ………………………………………………………....... Modèle d’implémentation

Tests ………………………………………………………................................................... Modèle des tests

 Expression des besoins :

 L'expression des besoins comme son nom l'indique, permet de définir les différents besoins :

inventorier les besoins principaux et fournir une liste de leurs fonctions

 recenser les besoins fonctionnels (du point de vue de l'utilisateur) qui conduisent à

l'élaboration des modèles de cas d'utilisation

 appréhender les besoins non fonctionnels (techniques) et livrer une liste des exigences.

 Le modèle de cas d'utilisation présente le système du point de vue de l'utilisateur et représente

sous forme de cas d'utilisation et d'acteur, les besoins du client

Analyse:

 L'objectif de l'analyse est d'accéder à une compréhension des besoins et des exigences du client. Il

s'agit de livrer des spécifications pour permettre de choisir la conception de la solution.

 Un modèle d'analyse livre une spécification complète des besoins issus des cas d'utilisation et les

structure sous une forme qui facilite la compréhension (scénarios), la préparation (définition de

l'architecture), la modification et la maintenance du futur système. Il s'écrit dans le langage des

développeurs et peut être considéré comme une première ébauche du modèle de conception.
 Conception

 La conception permet d'acquérir une compréhension approfondie des contraintes liées au

langage de programmation, à l'utilisation des composants et au système d'exploitation. Elle

détermine les principales interfaces et les transcrit à l'aide d'une notation commune.

• Elle constitue un point de départ à l'implémentation :

 elle décompose le travail d'implémentation en sous-système

 elle créée une abstraction transparente de l'implémentation

 Implémentation:

• L'implémentation est le résultat de la conception pour implémenter le système sous formes de

composants, c'est-à-dire, de code source, de scripts, de binaires, d'exécutable et d'autres

éléments du même type.

• Les objectifs principaux de l'implémentation sont de planifier les intégrations des composants

pour chaque itération, et de produire les classes et les sous-systèmes sous formes de codes

sources.
 Test:

• Les tests permettent de vérifier des résultats de l'implémentation en testant la construction.

Pour mener à bien ces tests, il faut les planifier pour chaque itération, les implémenter en créant

des cas de tests, effectuer ces tests et prendre en compte le résultat de chacun.
LES MODÈLES SONT PRINCIPALEMENT CONSTITUÉS
DE DIAGRAMMES UML
Diagramme
de classes
Modèle des cas d’utilisation Diagramme d’objets
Diagramme de
composants

Modèle d’analyse Diagrammes de

déploiement

Diagrammes de
séquence
Modèle de conception
Diagrammes de
collaboration
Modèle de déploiement
Diagrammes
Etat-transition

Modèle d’implémentation
Diagrammes
d’activité
Modèle des tests
MODÈLE DES CAS D’UTILISATION
Diagramme de
Modèle des cas d’utilisation cas d’utilisation
Diagramme de Diagramme
classes d’objets
Modèle d’analyse Diagramme de
composants
Diagrammes de
Modèle de conception déploiement
Diagrammes de
séquence
Modèle de déploiement Diagrammes de
collaboration
Diagrammes
Modèle d’implémentation Etat-transition
Diagrammes
d’activité
Modèle des tests
 MODÈLE D’ANALYSE
Diagramme de
Modèle des cas d’utilisation cas d’utilisation
Diagramme de Diagramme
classes d’objets
Modèle d’analyse Diagramme de
composants
Diagrammes de
Modèle de conception déploiement
Diagrammes de
séquence
Modèle de déploiement Diagrammes de
collaboration
Diagrammes
Modèle d’implémentation Etat-transition
Diagrammes
d’activité
Modèle des tests
MODÈLE DE CONCEPTION
Diagramme de
Modèle des cas d’utilisation cas d’utilisation
Diagramme de Diagramme
classes d’objets
Modèle d’analyse Diagramme de
composants
Diagrammes de
Modèle de conception déploiement
Diagrammes de
séquence
Modèle de déploiement Diagrammes de
collaboration
Diagrammes
Modèle d’implémentation Etat-transition
Diagrammes
d’activité
Modèle des tests
MODÈLE DE DÉPLOIEMENT
Diagramme de
Modèle des cas d’utilisation cas d’utilisation
Diagramme de Diagramme
classes d’objets
Modèle d’analyse Diagramme de
composants
Diagrammes de
Modèle de conception déploiement
Diagrammes de
séquence
Modèle de déploiement Diagrammes de
collaboration
Diagrammes
Modèle d’implémentation Etat-transition
Diagrammes
d’activité
Modèle des tests
MODÈLE D’IMPLÉMENTATION
Diagramme de
Modèle des cas d’utilisation cas d’utilisation
Diagramme de Diagramme
classes d’objets
Modèle d’analyse Diagramme de
composants
Diagrammes de
Modèle de conception déploiement
Diagrammes de
séquence
Modèle de déploiement Diagrammes de
collaboration
Diagrammes
Modèle d’implémentation Etat-transition
Diagrammes
d’activité
Modèle des tests
MODÈLE DES TESTS
Diagramme de
Modèle des cas d’utilisation cas d’utilisation
Diagramme de Diagramme
classes d’objets
Modèle d’analyse Diagramme de
composants
Diagrammes de
Modèle de conception déploiement
Diagrammes de
séquence
Modèle de déploiement Diagrammes de
collaboration
Diagrammes
Modèle d’implémentation Etat-transition
Diagrammes
d’activité
Modèle des tests
 MODÈLE D’ANALYSE

* *
Packages d’analyse
Modèle d’analyse

*
*

Réalisation de cas d’utilisation

(diagrammes de classes, diagrammes de collaborations)
Classe d’analyse
(attributs, association, responsabilités,
stéréotypes Frontière, Contrôle, Entité )
MODÈLE DE CONCEPTION

* *
Modèle de conception Package de conception

*
* Interface
(opérations fournies)
*

Classes d’analyse Réalisation de cas d’utilisation

(méthodes, visibilité des attributs, (diagrammes de classes,
stéréotypes) diagrammes de séquence)
MODÈLE D’IMPLÉMENTATION

* *
Sous-système
Modèle d’implémentation
d’implémentation

*
Interface
(opérations fournies)
*

Composant
MODÈLE DE TEST
Cas de test

*
Modèle des tests Procédure de test

Composant de test
EXEMPLE DE BESOINS

35
 SCÉNARIO NOMINAL
1. Le porteur de CB introduit sa carte dans le lecteur du GAB.
2. Le GAB vérifie que la carte introduite est bien une CB.
3. Le GAB demande au porteur de saisir son code.
4. Le porteur de CB saisit son code.
5. Le GAB compare le code saisi avec celui inscrit sur la puce.
6. Le GAB demande une autorisation au SA CB.
7. Le SA CB donne son accord et indique le solde hebdomadaire.
 AUTRES SCÉNARIOS
• Scénario alternatif : code momentanément erroné
 Cet enchaînement démarre au point 5 du scénario nominal.
 6.Le GAB indique au client que le code est erroné, pour la première
ou deuxième fois.
 7.Le GAB enregistre l’échec sur la carte.
 Le scénario nominal reprend au point 3.
• Scénario exceptionnel : carte non valide
 Cet enchaînement démarre au point 2 du scénario nominal.
 3.Le GAB indique au porteur que la carte n ’est pas valide et la
confisque.
 Le cas d ’utilisation est terminé.
L'INTERFACE

Besoins en IHM
 lecteur de carte bancaire,
 clavier numérique avec touches validation, correction et
annulation,
 écran,
 touches autour de l’écran pour la sélection d’un montant,
 distributeur de billets,
 distributeur de ticket.
: PorteurCB : GAB : SA CB

introduction carte
vérification carte
demander code

code(valeur)
demande autorisation

autorisation(solde)

demander montant retrait

montant retrait(valeur)
proposer ticket

Ok
éjecter carte

récupérer carte
éjecter carte + billets
récupérer carte + billets
signaler retrait (valeur)
ANALYSE : ARTEFACTS
CONCEPTION : ARTEFACTS
MODÈLE DE DÉPLOIEMENT : ARTEFACTS
IMPLÉMENTATION : ARTEFACTS
CONCLUSION

Le langage UML nous apporte une aide à toutes les étapes d’un projet, comme il nous offre ainsi

de nombreux avantages pour l’analyse et la conception d’un système, Le couple UML et le

processus unifié propose une approche pour conduire la réalisation de systèmes orienté objet. Le

chapitre suivant définit la conception de notre système