UML ET LE PROCESSUS

UNIFIE
HRICHI Mohamed
 Agenda

• Présentation générale d’UML

o Définition et Historique
o Vue statique
o Vue dynamique
• Présentation de Processus Unifie
o Définition
o Vue d’ensemble
o Démarche de processus unifie
• Démarche à suivre dans le PFE
hrichi.mohamed@gmail.com 2
 Définition
UML est un langage de modélisation graphique
Un langage universel pouvant servir de support
pour tout langage orienté objet
Une notation graphique simple, compréhensible
même par des non informaticiens
UML facilite la communication entre Client et
concepteur

hrichi.mohamed@gmail.com 3
Historique

hrichi.mohamed@gmail.com 4
 Vues d’UML
Vue Statique
Diagramme de cas d’utilisation
Diagramme de classe
Diagramme de composants
Diagramme d’objets
Diagramme de déploiement

Vue dynamique
Diagrammes de séquence
Diagrammes de collaboration
Diagrammes d'états-transitions
Diagrammes d'activités

hrichi.mohamed@gmail.com 5
 Vue Statique
Diagramme de cas d’utilisation

• Comportement de système de point de vue utilisateur

• Structurer les besoins des utilisateurs et les objectifs correspondants du
système
• Un cas d’utilisation spécifie une séquence d’interactions, entre les
acteurs et le système

cas
d’utilisation

Fonctionnalité
système
Acteur

hrichi.mohamed@gmail.com 6
 Vue Statique
Diagramme de classe

• Structure statique de système

• Décrit le type des objets ou données du système ainsi que les différentes
formes de relation statiques qui les relient entre eux
• Déterminer les attributs des classes
• Déterminer les méthodes et leurs paramètres

hrichi.mohamed@gmail.com 7
 Vue Statique
Diagramme de composants

• Le diagramme de composant permet de représenter les composants

logiciels d’un système ainsi que les liens existant entre ces composants.
• Les composants logiciels peuvent être de deux origines :
• soit des composants métiers propres à une entreprise
• soit des composants disponibles sur le marché comme par
exemple les composants .NET, WSDL, etc.

hrichi.mohamed@gmail.com 8
 Vue Statique
Diagramme d’objets

• permet de représenter les instances des classes

• exprime les relations qui existent entre les objets et leurs relations à un
moment donné.
• permet d'exprimer des contextes d'exécution

hrichi.mohamed@gmail.com 9
 Vue Statique
Diagramme de déploiement

• permet de représenter l’architecture physique du système

• comprend des nœuds correspondant aux supports physiques (serveurs,
routeurs…)
• la répartition des artefacts logiciels (bibliothèques, exécutables…) sur
ces nœuds
JBDC Save/load the
Connection highscore

Game Computer

SGBD computer

Play the Maybe a Remote

game File a file system
System

hrichi.mohamed@gmail.com 10
 Vue Dynamique
Diagramme de séquence

• représenter les interactions entre objets en indiquant la chronologie

des échanges
• capturer le comportement de tous les objets et acteurs impliqués dans
un cas d’utilisation
• Il constitue une spécification utile pour le codage d’un algorithme

hrichi.mohamed@gmail.com 11
 Vue Dynamique
Diagramme de collaboration

• mettre en évidence les interactions entre objets, ainsi que les messages
échangés
• permet de décrire les interactions entre objets intervenant dans la
réalisation d’un scénario d’un cas d’utilisation

hrichi.mohamed@gmail.com 12
 Vue Dynamique
Diagramme d'états-transitions

• L’état d’un objet est défini, à un instant donné, par l’ensemble des
valeurs de ses propriétés
• Le passage d’un état à un autre état s’appelle transition
• Un événement est un fait survenu qui déclenche une transition

hrichi.mohamed@gmail.com 13
 Vue Dynamique
Diagramme d'activités

• présente un certain nombre de points communs avec le diagramme

d’état-transition
• il concerne le comportement interne des opérations ou des cas
d’utilisation
• le comportement visé s’applique aux flots de contrôle et aux flots de
données

hrichi.mohamed@gmail.com 14
 Présentation de processus unifie
Définition :

Le processus unifié a été élaboré par Jacobson

piloté par des cas d'utilisation

un processus de développement logiciel itératif et incrémental

centré sur l'architecture

orienté vers la diminution des risques

hrichi.mohamed@gmail.com 15
 Vue d’ensemble d’UP
L'objectif d'un processus unifié est de maîtriser la complexité
des projets informatiques en diminuant les risques.
UP répond aux préoccupations suivantes :
- QUI participe au projet ?
- QUOI, qu'est-ce qui est produit durant le projet ?
- COMMENT doit-il être réalisé ?
- QUAND est réalisé chaque livrable ?

hrichi.mohamed@gmail.com 16
Vue d’ensemble d’UP

hrichi.mohamed@gmail.com 17
Démarche de processus unifie

hrichi.mohamed@gmail.com 18
 Démarche UP pour le PFE
En fonction de temps le processus unifie est divisé en quatre phase :
Phase Lancement
Phase Elaboration
Phase Construction
Phase Transition
En fonction d’activités en cinq :
Expression des besoins
Analyse
Conception
Implémentation
Test
hrichi.mohamed@gmail.com 19
 Phase Lancement
Initialiser le projet
porte essentiellement sur les besoins principaux du point de vue de
l'utilisateur
Identifier les risques les délais et les coûts
une identification des principaux cas d’utilisation accompagnée
d’une description générale
Il est possible réaliser des maquettes sur les cas d’utilisation
identifiés

hrichi.mohamed@gmail.com 20
 Phase Elaboration
permet de préciser la plupart des cas d’utilisation
de concevoir l’architecture du système
Définition les besoins fonctionnels et non fonctionnels
(performance , sécurité, etc.)
raffiner le modèle initial de cas d'utilisation

hrichi.mohamed@gmail.com 21
 Phase Construction

la production d’une première version du produit

 capturer tous les besoins restants

centrée sur les activités de conception, d’implémentation

implémentation de tous les cas d'utilisation identifiés

hrichi.mohamed@gmail.com 22
 Phase Transition
Traiter tout les actions liées au déploiement
vérifier si le système offre véritablement les services exigés par les
utilisateurs
Détecter les anomalies
livrer le produit pour une exploitation réelle

hrichi.mohamed@gmail.com 23
 Les Diagrammes suffisants pour un PFE
1. Cas d’utilisation

hrichi.mohamed@gmail.com 24
 Les Diagrammes suffisants pour un PFE
2. Modèle de traçabilité du cas d’utilisation

hrichi.mohamed@gmail.com 25
 Les Diagrammes suffisants pour un PFE
3. Diagramme de classe d’analyse du cas d’utilisation

hrichi.mohamed@gmail.com 26
 Les Diagrammes suffisants pour un PFE
4. Diagramme de collaboration

PEC = Prise en charge

BT = Bouton
UI = User Interface

hrichi.mohamed@gmail.com 27
 Les Diagrammes suffisants pour un PFE
5. Diagramme de classe de conception

hrichi.mohamed@gmail.com 28
 Les Diagrammes suffisants pour un PFE
6. Diagramme de séquence

hrichi.mohamed@gmail.com 29
 Les Diagrammes suffisants pour un PFE
7. Diagramme de classe entité

hrichi.mohamed@gmail.com 30
 Les Diagrammes suffisants pour un PFE
8. Diagramme de composant

hrichi.mohamed@gmail.com 31
 Les Diagrammes suffisants pour un PFE
9. Diagramme de déploiement

hrichi.mohamed@gmail.com 32
 MERCI

hrichi.mohamed@gmail.com 33