GP UnifiedProcess PDF

Sommaire
Conduite de projet
Mthode danalyse et de conception
!!Objectifs dun processus dingnierie

logicielle
! Modles UML (rappels)
! Processus de dveloppement Unifi
Processus unifi
G. Picard
SMA/G2I/ENS Mines Saint-Etienne
gauthier.picard@emse.fr
Octobre 2009
Une partie du matriau de ce cours est issue du cours de Corinne CAUVET - Universit d'Aix-Marseille
Objectifs dun processus de

dveloppement
Activits de dveloppement (rappel)

!
!
!
!
!
!
!
!
!
! Un processus dfinit QUI fait QUOI, QUAND

et COMMENT pour atteindre un certain
objectif
! Construction des modles dun ou de plusieurs
systmes
! Organisation du projet
! Grer le cycle de vie du projet de A Z
! Grer les risques
! Obtenir de manire rptitive des produits de
qualit constante
3
Planification (tude de la faisabilit)

Spcification des besoins
Analyse (Spcification formelle)
Conception (Spcification technique)
Implmentation (Codage)
Tests unitaires
Intgration et tests
Livraison
Maintenance
4
Dveloppement (rappel)
Modle en cascade
Modle en V
Expression
des besoins
Analyse
Conception
Conception
Du Systme
Tests
Validation
fonctionnelle
vrifie
Analyse
Implmentation
Validation
des besoins
vrifie
Tests du
systme
vrifie
vrifie
Conception
des composants
Tests des
composants
Maintenance
Implmentation
5
Modle en spirale
Sommaire
!!Objectifs dun processus dingnierie
logicielle
!!Modles UML (rappels)
! Processus de dveloppement Unifi
Analyse
Conception
Spcifications
Implmentation
Validation
Tests
7
Diagrammes disponibles
(rappel)
Vocabulaire UML (rappel)
Possibilit de reprsenter le mme

diagramme des niveaux de dtail
diffrents.
Constituants de base
Annot.note
Struct.
Group.
Cas d'utilisation
Classe
Classe Active
Interface
Composant
Collaboration
Noeud
statique
Relations
Dpendances
Associations
Gnralisation
Package
Modle
Comp.
Sous-systme
Interaction Framework
Machine d'tat
+ des mcanismes dextensions
Diagrammes
D. Cas d'utilisation
D. de classe
D. d'objet
D. de squence
D. de collaboration
D. d'tat/transition
D. d'activit
D. de composant
D. de dploiement
Diagrammes
de Composants
Modles
dynamique
9
Diagramme de cas dutilisation

objectifs
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
10
Diagramme de cas dutilisation

notation
! Description
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
! de ce que l'application doit (ou ne doit

pas) tre capable de prendre en
compte
! de la manire dont une organisation
ou un systme externe doivent
interagir avec le systme
! Point de vue de lutilisateur

! pour mettre en vidence les services
rendus par le systme
! pour fixer le primtre entre le
systme et son environnement
Cas
! Le diagramme est accompagn

d'un texte organis dcrivant le cas
dutilisation et permettant de mettre
en vidence les scnarios (flots
dvnements)
! Un scnario est un CAS
DUTILISATION, ce quun objet est
sa classe
11
12
Diagramme de squences
objectifs
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
Diagramme de squences
notation
! Validation des cas d'utilisation,

pour comprendre la logique de
l'application
! Complte le diagramme des cas
dutilisation en mettant en
vidence les objets et leurs
interactions dun point de vue
temporel
! Outils de documentation, peu
rigoureux, pas tout le temps
ncessaires
! Pas de flots de contrle dans un
diagramme de squence, en faire
plutt un autre
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
Objet ou classe
Acteur
Augmenter(3,5)
crer
getValue(a)
Autre objet ou
classe
5,5
Modifier(b)
dtruire
temps
13
Diagramme de collaboration
objectifs
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
14
Diagramme de collaboration
notation
! Faire apparatre les classes,

spcifier lusage des instances
! Montrer les interactions entre
objets par leurs liens et les
messages changs
! Mmes conseils d'utilisation que
les diagrammes de squences
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
15
1:augmenter(3,5)
Un acteur
Un Objet
2 : <<crer>>
3 :modifier
Un Objet
Un Autre Objet
16
Diagramme de classes
objectifs
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
notation
! Point central de la modlisation

du systme pour dcrire ce que le
systme doit faire (analyse) et
comment il va le faire (conception)
! Reprsentation de la structure
statique du systme dinformation
! Modlisation des classes et de
leurs relations
! un Diagramme de package
permet de reprsenter les
dpendances entre les diffrents
package du systme
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
17
Diagramme dobjets
objectifs
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
18
Diagramme dobjets
notation
! Appel aussi diagramme

dinstances, il reprsente aussi la
structure statique
! reprsentation des instances
! Sutilise de manire ponctuelle
pour
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
! montrer leffet dune interaction

! reprsenter des structures
complexes (rcursives)
19
20
Diagramme dtats-transitions
objectifs
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
Diagramme dtats-transitions
notation
! Reprsentation du cycle de vie

des instances dune classe
! Spcification des tats, des
transitions entre ces tats et des
actions associes aux transitions
! Sutilise pour la modlisation de la
dynamique de certaines classes
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
Le premier tat
Entre/Action
do/Action
Evnement/Action
Sortie/Action
[garde]venement/action
Un autre tat
21
Diagramme dactivits
objectifs
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
22
Diagramme dactivits
notation
! Reprsentation
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
! un processus dune organisation

! du comportement doprations d'une
classe
! Plusieurs points de vue

! pour analyser un processus
! pour concevoir un objet
!! Plusieurs acceptions de la notion

dactivit
! une opration
! une tape dans une opration
! une action dun scnario dun cas
d'utilisation
Une activit
Une autre activit
Une activit rsultant

d'une synchronisation
Une transition
Une activit nouvelle
23
24
Diagramme de composants
objectifs
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
Diagramme de composants
notation
! Description des composants

logiciels et de leurs
dpendances
! Composant : un fichier de
programme source, une
bibliothque, un programme
excutable, rutilisable
! Utilis en conception de logiciel
pour allouer les classes et
objets aux composants
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
Un composant
Une dpendance fait rfrence aux services

offerts par un composant. La flche va de
l'utilisateur vers le fournisseur.
Un autre
composant
25
Diagramme de dploiement
objectifs
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
26
Diagramme de dploiement
notation
! Description
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
! de la configuration matrielle des

units de traitements (hard et soft).
! de larchitecture technique, des
nuds et de leur interconnexion
! Nuds de larchitecture :
serveurs, postes de travail et
priphriques
! Les composants sont allous aux
diffrents nuds
27
Un noeud
Un composant
Un autre noeud
Un autre
composant
28
Liens entre les diagrammes

Diagramme
Composants
Diagramme
Dploiement
Diagramme
Cas Utilisation
Sommaire
!!Objectifs dun processus dingnierie logicielle
!!Processus de dveloppement Unifi
Diagramme
Classes
!!Principes
!!Recueil des besoins, Analyse, Conception
!!Utilisation des diagrammes
!!Processus pilot par les cas dutilisation
!!Processus centr sur larchitecture
!!Processus guid par les Patterns
Cas dUtilisation
Diagramme
Squences
Diagramme
Etats
Diagramme
Collaboration
est utilis par
29
Processus Unifi Principes (1)
30
! Il n'existe pas un seul processus de

dveloppement, ni de processus standard
! CEPENDANT
des caractristiques essentielles peuvent tre
mises en avant :
Cas
d'utilisation
pilot par
Langage
UML
! Pilotage par les cas d'utilisation

! Focalisation sur l'architecture
! Utilisation de patrons de conception (Design
Patterns)
! Droulement itratif et incrmental
bas sur
Processus A
! Accent mis sur les phases plus que sur les

activits danalyse, conception,
Conseils
Patterns
Architecture
centr sur
Processus
Unifi
guid par
se droule
Itratif et
incrmental
Processus B
* Facteurs organisationnels
* Facteurs de domaine
* Facteurs techniques
31
32

Pilot par les cas dutilisation

Centr sur larchitecture
! Larchitecture regroupe les diffrentes vues du
systme qui doit tre construit.
! Elle doit prvoir la ralisation de tous les cas
dutilisation.
! Marche suivre:
! Le processus de dveloppement est centr sur lutilisateur.
! Crer une bauche grossire de larchitecture.

! Travailler sur les cas dutilisation reprsentant les
fonctions essentielles.
! Adapter larchitecture pour quelle prenne en compte ces
cas dutilisation.
! Slectionner dautres cas dutilisation et refaire de mme.
! Larchitecture et les cas dutilisation voluent de

faon concommitante.
A partir des cas dutilisation, les

dveloppeurs crent une srie de
modles UML.
33

Itratif et incrmental
34

! Dcoupe du projet en mini-projet :
! Segmentation du travail
! Concentration sur les besoins et les risques,
! Les premires itrations sont des prototypes
! des ITRATIONS qui donnent lieu un INCRMENT
! Chaque itration comprend un certain nombre de cas

dutilisation et doit traiter en priorit les risques
majeurs.
! Une itration reprend les livrables dans ltat o les a
laiss litration prcdente et les enrichit
progressivement (incrmental).
! Les itrations sont regroupes dans une phase.
Chaque phase est ponctue par un jalon qui
marquera la dcision que les objectifs (fixs
pralablement) ont t remplis.
! exprimentation et validation des technologies,

! planification,
! Les prototypes dfinissent le noyau de

l'architecture.
35
36

Phases
! Ordonnancement des itrations bas sur les

priorits entre cas d'utilisation et sur l'tude
du risque
Pr-Etude
Pr-Etude
Pr-Etude
Elaboration
Elaboration
Intgration
Construction
Intgration
Intgration
Construction Construction
temps
Vision
! Pr-tude :
!
!
!
!
!
!
Dfinition de
l'itration
Evaluation
Elaboration
Dlimiter la porte du systme,

Dfinir les frontires et identifier les interfaces
Dvelopper les cas dutilisation
Dcrire et esquisser larchitecture candidate
Identifier les risques les plus srieux
Dmontrer que le systme propos est en mesure de rsoudre les problmes
ou de prendre en charge les objectifs fixs
! Vision : Glossaire, Dtermination des parties prenantes et des utilisateurs,

Dtermination de leurs besoins, Besoins fonctionnels et non fonctionnels,
Contraintes de conception
37
38
Phases
Phases
temps
temps
Vision
Architecture
Vision
! Elaboration :
Architecture
Premires
fonctionnalits
! Construction :
! Spcification des fondements de larchitecture, crer une architecture de rfrence

! Identifier les risques, ceux qui sont de nature bouleverser le plan, le cot et le
calendrier,
! Dfinir les niveaux de qualit atteindre,
! Formuler les cas dutilisation pour couvrir environ 80% des besoins fonctionnels et de
planifier la phase de construction,
! Planification du projet, laborer une offre abordant les questions de calendrier, de
personnel et de budget
! Architecture : Document darchitecture Logicielle, Diffrentes vues selon la partie prenante,
Une architecture candidate, Comportement et conception des composants du systme
! Extension de lidentification, de la description et de la ralisation des cas

dutilisation
! Finalisation de lanalyse, de la conception, de limplmentation et des tests
! Prservation de lintgrit de larchitecture
! Surveillance des risques critiques et significatifs identifis dans les dex
premires phases et rduction des risques
# Produit
39
40
Phases
Activits (1)
! Modlisation mtier :
temps
Vision
Architecture
Premires
fonctionnalits
Livraison
Produit
! Transition :
! Comprhension de la structure et la dynamique de

l'organisation
! Comprendre les problmes poss dans le contexte de
l'organisation
! Conception dun glossaire
! Recueil et expression des besoins :
! Prparation des activits

! Recommandations au client sur la mise jour de lenvironnement logiciel
! Elaboration des manuels et de la documentation concernant la version du
produit
! Adaptation du logiciel
! Correction des anomalies lies au bta test
! Dernires corrections
!
!
!
!
!
!
!
!
# Livraison du produit aux utilisateurs
Auprs des clients et parties prenantes du projet

Ce que le systme doit faire
Expression des besoins dans les cas d'utilisation
Spcifications des cas d'utilisation en scnarios
Limites fonctionnelles du projet
Spcifications non fonctionnelles
Planification et prvision de cot
Production de Maquettes de lIHM
41
42
Activits (1)
Production de maquettes IHM
Activits (2)
! La production de maquettes peut tre ralise avec

nimporte quel outil graphique :
! Analyse et conception :
! Transformation des besoins utilisateurs en modles UML
! Modle d'analyse et modle de conception
! ce sont de simples dessins d'crans et descriptions de

contenu de fentres ;
! prototype d'interface gnr par un outil
! Intressant pour dcrire les interfaces avec des acteurs
non humains et notamment les notions de protocoles de
communication.
! Implmentation :
! Dveloppement itratif
! Dcoupage en couches
! Composants d'architecture
! Retouche des modles et des besoins
! Units indpendantes, quipes diffrentes
! Pourquoi si tt dans le processus ?

! Aide la description et validation des Cas dUtilisation
! moyen de communication avec le client
! permet l'identification de classes
! montre au client la progression du travail
! Test, Dploiement, Configuration et gestion des

changements, Gestion de projet, Environnement,
Dploiement
43
44
Itrations (2)
Itrations (1)
Enchanement des
Phases
Activits dIngnierie
Pr-tude Elaboration
Une itration
dans la phase
d'laboration
Construction
Transition
Modlisation Mtier
Prelim
Iteration
...
Arch
Iteration
...
Cons
Cons
Iteration Iteration
...
Trans
Iteration
Recueil des besoins
...
Analyse & Conception

Implmentation
Test
Release
Release Release Release Release Release
Release
Dploiement
Release
Configuration Mgmt
Management
Environment
Une itration est une squence dactivits selon un plan

pr-tabli et des critres dvaluation, rsultant en un
produit excutable.
Enchanement des
Preliminary
Iteration(s)
Iter.
#1
Iter.
#2
Iter.
#n
Iter. Iter.
#n+1 #n+2
Iter.
#m
Iter.
#m+1
Iterations
activits Support
45
46
Sommaire
Modles

!!Principes
47
Recueil
Besoins
Modles des
Use Case
Analyse
Modles
dAnalyse
Conception
Modles de
Conception
Implmentation
Modles
Dimplmentation
Test
Modles
de test
Modles de
Dploiement
48
Recueil des besoins
Recueil des besoins
Recueil des besoins
Rle
! Identifier les diffrents intervenants : client(s), utilisateurs, matre
duvre, dveloppeurs, ...
! Identifier le rle de chacun, ventuellement leur associer des
priorits
! Identifie les services que le systme devrait fournir et dfinit les
contraintes sur le systme.
! Runit toute l'information du domaine disponible pour les
membres du projet.
! tablit une base contractuelle sur laquelle le client et
l'organisation du projet s'appuient lors des ngociations.
! Permet l'estimation des cots et des chanciers
! Procure les critres de validation et vrification
! Facilite le transfert des connaissances et la gestion des
configurations
! Sert de base aux amliorations futures.
! L'une des tapes les plus importantes

! dterminante pour la suite
! sert la dfinition des aspects contractuels
! L'une des tapes les plus difficiles

! intervenants multiples : client, utilisateurs,
dveloppeurs
! le problme nest pas encore formalis
! Rgle dor respecter : Les informaticiens

sont aux services du client, pas linverse
Section issue du cours de J.M. Favre (IMAG)
49
50
Recueil des besoins
Exigences (1)
Recueil des besoins
Exigences (2)
! Selon IEEE 610.12, une exigence est :
! Exigences fonctionnelles
! Une condition ou une capacit ncessaire un utilisateur pour rsoudre un

problme ou atteindre un objectif
! Une condition ou une capacit que doit possder un systme afin de
satisfaire aux termes d'un contrat, dune norme ou dune spcification
formellement impose.
! La reprsentation documente de cette condition ou capacit.
! quoi sert le systme

! ce que doit faire le systme, les fonctions utiles
! Exigences non fonctionnelles
! Selon IEEE 830, une spcification dexigences comprend :

! Les fonctionnalits : services et fonctions que le systme doit fournir.
! Les interfaces externes : identification des interactions avec les utilisateurs
et les autres systmes avec lesquels le nouveau systme doit s'intgrer.
! La performance : contraintes d'opration du systme en disponibilit et en
temps rponse.
! Les attributs du systme : caractristiques intrinsques telles que la
portabilit, l'exactitude, la maintenabilit, la scurit, etc.
! Les contraintes de conception: contraintes sur la faon de dvelopper le
systme.
! performance, sret, confidentialit, portabilit,

etc.
! chercher des critres mesurables
51
52
Recueil des besoins
Exigences non fonctionnelles
Etapes :
vue densemble
Recueil des besoins
! Capture des besoins
! Exigences qui ne concernent pas spcifiquement le

comportement du systme.
! collecte des informations : interviews, lecture de

documentation
! chercher comprendre : (1) le domaine (2) le
problme
! Elles identifient des contraintes internes et externes du systme.

! Elles doivent avoir des valeurs quantitatives.
! Types dexigences non fonctionnelles

! Utilisabilit : Capacit pour un utilisateur dexcuter une tche dans
un temps donn aprs une formation dune dure dtermine.
! Performance : Temps dattente < 10s.
! Fiabilit : Systme critique
! Disponibilit : 24/7
! Scurit : Accs personnaliss, connexions scurises
! Maintenabilit : Modularit, commentaires, complexit, interfaces
! Portabilit : Utilisable avec plusieurs systmes dexploitation
! Dfinition des besoins

! restitution dans un langage comprhensible par le
client
! identification, structuration, dfinition d'un
dictionnaire
! Spcification des besoins

! spcification dtaille des besoins, plus formel
! utile pour le client, mais aussi pour les dveloppeurs
53
Recueil des besoins

Etapes :
Capture des besoins (1)
54
Recueil des besoins

Etapes :
Capture des besoins (2)
!! Ragir et tre actif !
! Objectifs : comprendre le domaine, comprendre le

problme
! # Collecter le maximum d'informations
! tablir la liste des documents consults, les

classer
! laborer une liste de questions prcises
! Lecture des documents fournis, Consulter les documents

pertinents au systme
! Interviews du client, des utilisateurs, discuter avec le
client ou lutilisateur afin de btir une comprhension
commune des exigences du systme.
! Runions de travail
! Collecter des exemples pour valider
! tudier les systmes existants le cas chant,
! observer lexcution des tches des utilisateurs que le
systme doit soutenir.
! les numroter, les dater,

! faire rfrence aux documents concerns
! crire un ou plusieurs documents et les diffuser

! Provoquer les runions et les mener
! tablir lordre du jour
! prendre des notes
! faire systmatiquement des comptes rendus crits
55
56
Recueil des besoins

Etapes :
Dfinition des besoins (1)
! Restituer les informations sous forme synthtique
Recueil des besoins

Etapes :
! Les besoins doivent tre compris par tous

! utiliser la langue naturelle
! Scnarios et cas dutilisation :
!
!
!
!
Faire des phrases courtes,

Eviter le conditionnel, le futur, les termes ambigus ou subjectifs, ...
Parler en termes de rles plutt que de personnes
Numroter les paragraphes si ncessaire, Utilisation de rfrences
prcises
! Elaborer un dictionnaire
! Identifier une squence d'actions effectues par le systme qui

rsultent en un rsultat observable,
! Utiliser et simuler l'utilisation du systme afin dexpliciter et de
clarifier Exigences
! Ce qui nest pas crit nexiste pas !

! Prciser les besoins, pas la solution
! Prciser ce que doit faire le systme
! utiliser des schmas si ncessaire
! tout schma doit tre comment et comporter une

lgende
! Structurer le document de dfinition
! et aussi ce quil nest pas sens faire.

! mais surtout pas comment il doit le faire.
! suivre un plan standard si disponible

! numroter les sections, rfrences, index,
! Etablir des priorits

! Arriver un consensus avec le client
57
Recueil des besoins

Etapes :
! Dfinir un dictionnaire
58
Recueil des besoins

Etapes :
! Conseils pour la construction du

dictionnaire :
! Indispensable d'avoir un langage commun

! dfinition d'un vocabulaire prcis
! client, quipe de dveloppement, utilisateurs
! Partir de la description du problme

! Reprer les groupes nominaux $ notion
! Reprer les groupes verbaux $ action ou notion
! Eliminer les synonymes
! Eliminer les termes inutiles
! Donner des dfinitions simples
! Permet de se concentrer sur l'essentiel
! Doit tre complt et mis jour !
! Utilisation dans les documents et aussi le logiciel !

! analyse des besoins (clients)
! base pour le dveloppement du logiciel (dveloppeurs)
! base pour l'interface du logiciel (utilisateurs)
! Technique simple mais efficace !

! Intrt :
! Outil de dialogue, Informel, facile raliser, facile faire voluer
! Permet de dcrire la terminologie du domaine
! rutilisable dans un autre projet
! Permet de dtecter les ambiguts
! Montre l'essentiel du domaine d'application

! Permet d'assurer la traabilit
59
60
Recueil des besoins

Etapes :
Notion
Dfinition
Nom. Info.
Type entit
Pilotage
Action de piloter un avion en

enchanant des manoeuvres
lmentaires
Pilotage
paquetage
Instrument
Organe dinteraction entre

le pilote et lavion
Instrument
Classe
abstraite
Manche
balai
Intrument permettant au
pilote de diriger lavion
MancheABa
Classe
lai
Action
Dfinition
Nom info.
Type entit
Augmenter
les gaz
Action permettant
dinjecter du carburant
pour augmenter la vitesse
de lavion
IncrGaz
opration
Recueil des besoins

Etapes :
Spcification des besoins
! Interface entre le client et les dveloppeurs

! doit tre compris par les deux
! dfinit dans le dtail ce qui doit tre ralis
! doit tre prcis car contractuel
! Utilisation de techniques semi-formelles

! ex. diagrammes de cas d'utilisation UML
! ex. diagrammes de classes UML
61
62
Recueil des besoins
Analyse
Intervenants et tapes
Modle dAnalyse
Modle d'analyse
Packages d'analyse
Ralisation de cas d'utilisation

Diagrammes de classes
Classes d'analyse
Diagrammes de collaboration
%!
Responsabilits
%!
attributs
%!
associations
63
64
Analyse
Modle dAnalyse
vs Modle des cas dutilisation
Modle des cas dutilisation

! Formul dans le langage du
client
! Structure la vue externe du
systme
! Structur avec les cas
d'utilisation
! Contrat entre le client et les
dveloppeurs : ce que le
systme doit faire et ne pas
faire
! Exprime les caractristiques
du systme
Analyse
Classes dAnalyse
! Classes candidates partir des descriptions
des Use Cases
! 3 types de classes :
Modle d'analyse
! Formul dans le langage du
dveloppeur
! Structure la vue interne du
systme
! Structur avec des paquetages
et des strotypes
! Indication aux dveloppeurs
de la forme du systme (pour
conception et implmentation)
! Esquisse une ralisation des
caractristiques du systme
! Classes'entit
! classes donnes du systme (dure de vie plus
longue que celle des UC)
! Classes'frontire
! interfaces entre acteur et systme
! Classes'contrle
! encapsulent le comportement d'un Use Case
65
Classes danalyse :
Classes Entits
Analyse
! Informations dont la dure de vie dpasse celle des

UC
! Mthodes pour manipuler ces informations
! Elles
66
Classes danalyse :
Classes Frontires
Analyse
! Connexion des autres classes du systme un acteur

! conversion des entres des acteurs en vnements ou en messages
internes
! transformation des messages de sortie pour quils soient compris
des acteurs
! Elles proviennent directement de lanalyse de la maquette IHM
! sidentifient en structurant judicieusement les

informations impliques dans chaque UC en classes et
attributs
! ne sont pas trop nombreuses (utiliser les UC, les autres
sources servent pour confirmation)
! apparaissent couramment dans plusieurs UC
! Au moins une classe frontire par paire (acteur-cas dutilisation). En

gnral, ces classes vivent aussi longtemps que le cas dutilisation
concern
! Possibilit davoir des objets subalternes auxquels il dlgue une

partie de ses responsabilits
! Les classes frontires peuvent possder
! des attributs qui reprsentent les champs de saisie ou des rsultats.
Les rsultats sont reprsents en utilisant la notation des attributs
drivs (/)
! des oprations qui reprsentent les actions que lutilisateur pour
utiliser sur lIHM
! Les responsabilits et les attributs sont diffrents dun

UC lautre
! Une fois lensemble de classes de chaque UC
identifi, on peut les combiner
67
68
Classes danalyse :
Classes Contrle
Analyse
Analyse
Description des classes danalyse
! Contiennent un scnario de UC
! Mettre jour les spcifications des classes et

de leurs attributs au fur et mesure que le
modle volue
! Rle de la classe par rapport au problme
! Dtails de la vie des objets
! Responsabilits des classes dcrites plus
tard, une fois la ralisation des UC termine
! liaison entre interface et objets entit
! Les objets de contrle ont une dure de vie

gale celle du UC
! Les UC simples nont pas besoins de classe
contrle
! on place le comportement dans les classes entit et
frontire
! Chaque attribut est document

69
Analyse
Ralisation des cas dutilisation (1)
70
Analyse
! Construire la ralisation des UC
! Une fois les classes identifies et dcrites

pour chaque UC, elles sont utilises pour
raliser les cas d'utilisation
! crer les diagrammes de collaboration et des

descriptions de flux dvnements
! Gnrer des diagrammes de classe pour

chaque UC
! analyse du UC dans le comportement et la

structure
! partir des diagrammes de collaboration et de
classe
! trouver les associations entre classes

ncessaires chaque ralisation de UC
71
72
Analyse
Analyse
! Les diagrammes dinteractions sont bass

sur lanalyse des interactions
! Les diagrammes de classes sont bass sur

l'analyse des classes
! instances des acteurs, les objets de l'analyse et

les liaisons impliques dans un UC particulier
! Ils montrent la squence dvnements entre
objets dans des scenarii de UC
! Le comportement est dcrit dans les descriptions
des UC
! classes, associations et attributs impliqus dans

un UC donn
73
74
Analyse
Analyse des interactions
Analyse
Analyse des classes
! Les diagrammes de collaboration montrent

les interactions entre objets
! Lanalyse de classes est l'tape du

processus qui attache les diagrammes de
classes chaque ralisation de UC
! acteurs, objets et liaisons

! Squences numrotes de messages qui se
propagent entre les objets pour raliser le UC
! En analyse, on utilise les strotypes des
classes d'analyse (entit, frontire et contrle)
! classes, attributs et associations

! identification et documentation des
responsabilits de chaque classe
! Les classes et leurs instances apparaissent

souvent dans plusieurs ralisations de UC
! Elles ont alors des responsabilits, attributs et
associations propres chaque UC
75
76
Analyse
Identification des responsabilits
Analyse
Identification des proprits
! Pour chaque classe, trouver les ralisations

de UC o elles apparat
! Ajouter les attributs et leurs types aux

classes
! lister les responsabilits (permet de choisir les

mthodes et signatures)
! chaque flche qui arrive un objet de la classe
invoque une partie des responsabilits de cette
classe
! cf diagrammes dinteractions (collaborations et
squences)
! souvent trouvs lors de lidentification des

classes
! lister et dcrire chaque attributs partir de
chaque ralisation de UC
77
78
Analyse
Identification des proprits
Analyse
Identification des relations
! Remarques :
! Observer les liaisons dans les diagrammes

de collaboration :
! les attributs des classes qui sinterfacent des

humains sont souvent des champs de donnes
comme ceux des botes de dialogue
! les attributs de classes qui s'interfacent des
quipements sont souvent des valeurs ou les
tats de capteurs, ou les paramtres dun
protocole de communication
! les attributs des classes contrle sont des
donnes temporaires de UC
! chaque liaison peut tre une instance d'une

association sous-jacente
! elle peut mme dans certains cas impliquer une
agrgation ou une gnralisation
79
80
Analyse
Analyse
Identification des relations
! Toutes les liaisons du diagramme ne sont

pas des associations
! Une association est une rfrence entre

deux classes, utiliser :
! certaines peuvent tre temporaires
! les descriptions de UC et les descriptions de

scnarios
! les diagrammes d'interaction
! la modlisation mtier
! Crer un diagramme de classe contenant les

classes, les associations et les attributs
pertinents pour chaque ralisation de usecase
! Les associations doivent tre documentes

dans les descriptions des ralisations des
UC
81
82
Analyse
Analyse
Construction modle danalyse

1.!
! Types dassociation :
Identifier les classes

! Au dpart, ne pas tre trop slectif et noter tout ce qui vient lesprit
! Ne pas se soucier trop de lhritage ni des classes de haut niveau
! association
2.!
! connexion logique de longue dure entre 2 classes

! associations les plus importantes, elles permettent de
trouver toutes les relations entre les classes et donc
construisent le modle de classe
Conserver les classes pertinentes

! Elimination des :
! Classes redondantes : classes exprimant le mme concept / Conservation du nom le
plus vocateur
! Classes sans intrt : classe sans lien avec le contexte ou ne faisant pas partie du
primtre du logiciel
! Classes vagues : classes ayant des frontires mal dfinies ou une porte trop large
! Attributs : re-formulation des noms dcrivant originellement des objets individuels sous
la forme dattributs
! Oprations : appliques des objets et non manipules en tant quoprations
! une association temporaire

! elle n'existe que pour quune classe envoie un
message spcifique une autre
! type d'association rencontre trs souvent dans les
descriptions de UC
! trouver les associations statiques sous-jacentes.
3.!
Poursuivre le dictionnaire de donnes

! Dcrire prcisment chaque classe par un paragraphe
! Dcrire la porte de chaque classe dans le problme courant, en incluant
toutes les hypothses et les restrictions quant son utilisation
! Dcrire galement les attributs, associations, oprations et valeurs
numres
83
84
Analyse
Analyse
4.! Identifier les associations et conserver les associations

pertinentes
5.! Identifier les attributs des objets et les liens

!
!
!
!
!
!
!
! Elimination des :
!
!
!
!
Associations non pertinentes ou relevant de limplmentation

Actions
Associations ternaires par dcomposition associations binaires, associations
qualifies ou classes-associations
Associations drives : associations dfinies en termes dautres associations
(car redondance) Attention : Toutes les associations formant plusieurs chemins
entre des classes nindiquent pas une redondance
! Prcision de la smantique des associations :

!
!
!
!
!
!
Ne pas pousser la recherche des attributs lextrme.

Ne considrer que les attributs pertinents pour lapplication
Rechercher en premier les attributs les plus importants ;
Repousser les dtails plus tard
Omettre les attributs drivs
Rechercher les attributs des associations
limination des attributs inutiles ou incorrects :
!
!
!
!
Diffrencier les objets de leurs valeurs

Utiliser des qualificateurs
Ne pas prciser les attributs identificateurs excepts ceux du domaine de lapplication
liminer les valeurs internes et les dtails fins
6.! Organiser et simplifier les classes en utilisant lhritage

7.! Vrifier que tous les chemins daccs existent pour les requtes probables
8.! Itrer et affiner le modle
9.! Rexaminer le niveau dabstraction
10.!Regrouper les classes en package
viter les associations mal nommes : choix des noms primordial pour la
comprhension
Indiquer les noms dextrmits dassociations
Identifier les associations qualifies
Prciser les multiplicits
Ajouter les associations manquantes
Transformer certaines associations en agrgations
85
86
Conception
Fin analyse
Modle de Conception
! La phase danalyse fournit une comprhension

des exigences, des concepts et du
comportement de lapplication.
! Un ensemble minimal de documents relatifs au
modle danalyse dune application comprend :
Modle de conception
! Document de description des besoins

! Document de description des cas dutilisation
! Document de description des diagrammes de classe
danalyse pour chaque cas dutilisation
! Les diagrammes de squence du systme
! Description de larchitecture logicielle souhaite
Sous-systme de conception
Interface
Classes de conception
%!
mthodes
%!
visibilits des attributs
87
Ralisation de cas d'utilisation

Diagrammes de classes
Diagrammes de squences
88
Modle danalyse vs
Modle de conception
Modle danalyse
! Modle conceptuel
! Autorise plusieurs
conceptions
! Peu de strotypes de
classes
! Peu de couches
Conception
Etapes suivre
1.!
2.!
3.!
4.!
Estimer les performances du systme

Mettre au point un plan de rutilisation
Organiser le systme en sous-systmes
Identifier les questions de concurrence inhrentes au
problme
5.! Allouer les sous-systmes aux quipements matriels
6.! Grer le stockage des donnes
7.! Grer les ressources globales
8.! Choisir une stratgie de contrle du logiciel
9.! Traiter les cas limites
10.!Arbitrer les priorits
11.! Slectionner un style architectural
Modle de conception
! Modle physique
! Spcifique une
implantation
! Strotypes dpendant de
lenvironnement cible
dimplantation
! Plusieurs couches
89
Conception des classes
90
Sommaire
! Finalisation de la dfinition des classes et des

associations
! Choix des algorithmes des oprations
! Ajout de dtails et prise de dcisions fines
! Choix des diffrentes faons dimplmenter les
classes danalyse
! Ncessit davoir plusieurs itrations des niveaux
successifs dabstraction
! Critres de facilit dimplmentation, de
maintenabilit et dextensibilit

!!Principes
91
92
Utilisation des diagrammes (1)

utilise
Modles des
Use Case
Modles
dAnalyse
utilise
Modles de
Conception
Modles des
Use Case
utilise
Modles
dAnalyse
Diagrammes
de Composants
Modles de
Conception
utilise
Modles de
Dploiement
Modles
Dimplmentation
Modles de
Dploiement
utilise
Modles
Dimplmentation
Modles
de test
Diagrammes
de Composants
utilise
utilise
utilise
utilise
Modles
de test
93
94
Modles des
Use Case
Modles
dAnalyse
Modles de
Conception
Modles de
Dploiement
Modles
Dimplmentation
Modles des
Use Case
utilise
Modles
dAnalyse
Diagrammes
de Composants
Modles de
Conception
utilise
Modles de
Dploiement
utilise
utilise
Modles
Dimplmentation
utilise
Modles
de test
Diagrammes
de Composants
utilise
utilise
utilise
Modles
de test
95
96
Modles des
Use Case
Modles des
Use Case
Modles
dAnalyse
Modles
dAnalyse
Modles de
Conception
Modles de
Dploiement
Modles
Dimplmentation
Diagrammes
de Composants
Diagrammes
de Composants
utilise
Modles de
Conception
utilise
Modles de
Dploiement
utilise
utilise
Modles
Dimplmentation
utilise
Modles
de test
utilise
Modles
de test
utilise
97
98
Processus pilot par les cas

dutilisation (1)
Sommaire
Phases
Workflows Ingnierie

Pr-tude Elaboration
Construction
Transition
Modlisation Mtier
Recueil des besoins
Implmentation
!!Principes
Test
Dploiement
Workflows Support
Configuration Mgmt
Management
Environment
! les analystes identifient la

plupart des UC pour
dlimiter le systme, et
dtaillent les plus
importants
Preliminary
Iteration(s)
Iter.
#1
Iter.
#2
Iter.
#n
Iter. Iter.
#n+1 #n+2
Iter.
#m
Iter.
#m+1
Iterations
99
100

dutilisation (2)

dutilisation (3)
Phases
Workflows Ingnierie
Pr-tude Elaboration
Construction
Phases
Workflows Ingnierie
Transition
Pr-tude Elaboration
Modlisation Mtier
Modlisation Mtier
Recueil des besoins
Recueil des besoins

Implmentation
Test
Dploiement
Workflows Support
Configuration Mgmt
Management
Environment
! les analystes trouvent les

UC restant (objectif :
80%) et les dcrivent pour
estimer l'effort de
dveloppement en fin de
phase
Preliminary
Iteration(s)
Iter.
#1
Iter.
#2
Iter.
#n
Iter. Iter.
#n+1 #n+2
Iter.
#m
Implmentation
Test
Dploiement
Construction
Transition
! le reste des UC est

exprim et implment
Workflows Support
Configuration Mgmt
Management
Environment
Iter.
#m+1
Preliminary
Iteration(s)
Iter.
#1
Iterations
Iter.
#2
Iter.
#n
Iter. Iter.
#n+1 #n+2
Iter.
#m
Iter.
#m+1
Iterations
101

dutilisation (4)
102

d'utilisation (5)
Phases
Workflows Ingnierie
Pr-tude Elaboration
Construction
Transition
Modle
des cas
dutilisation
spcialis par
Modlisation Mtier
Recueil des besoins
Implmentation
Test
Dploiement
Workflows Support
! sauf changement,
aucun UC ne doit
rester dcouvrir
Modle
dAnalyse
ralis par
Modle de
Conception
distribu par
ralis par
vrifi par
Modle de
Dploiement
Configuration Mgmt
Management
Environment
Preliminary
Iteration(s)
Iter.
#1
Iter.
#2
Iter.
#n
Iter. Iter.
#n+1 #n+2
Iter.
#m
Modle
d'implantation
Iter.
#m+1
Iterations
103
! Les cas d'utilisation sont le fil

conducteur de toutes les activits
Modle de
Test
104

d'utilisation (6)
Processus dirig par les cas

d'utilisation (7) : org. travail
! Dcoupage et organisation du travail selon
les cas d'utilisation :
!"#$%&'(
30"4'+-20"('-(
56#$2&#-20"(
:'&-(
<'&(4#&(.=/-2$2&#-20"&(,'$2'"-(4'&(->47'&('"&'1?$'(
)*+',-&(./(.01#2"'(
!,472-'4-'&(
30"4'+-'/,&(
8,09,#11'/,&(
;"-69,#-'/,&('-(
-'&-'/,&(
105
Processus dirig par les cas

d'utilisation (8) : conclusion
106
Sommaire
! Les cas d'utilisation recentrent l'expression des

besoins sur les utilisateurs
! Outil d'aide l'identification et la structuration des
besoins. On structure la dmarche par rapport aux
interactions d'une seule catgorie d'utilisateurs la
fois
! Outil d'aide l'analyse et la conception objet. On
s'intresse un ensemble de classes qui collaborent
dans un certain contexte (celui du cas d'utilisation)

!!Principes
! Description de la structure de la collaboration

! Description du comportement de la collaboration
! Outil de communication
107
108
Processus centr sur larchitecture (1)
! La description de l'architecture est explicite. C'est un

artefact du processus
! Les choix d'architecture sont pris trs tt dans le processus
! La notion de paquetage permet dorganiser la spcification
! Recherche de la forme gnrale du systme

ds le dbut
! Approche systmatique pour trouver une
bonne architecture qui soit :
!
!
!
!
Processus centr sur (1)

l'architecture : moyens UML
! Forte cohsion
! Faible couplage
! Notion de couches
! Composition de paquetages
support des cas d'utilisation

adaptable aux changements
pour et avec la rutilisation
comprhensible intuitivement
Couche application
Couche service
109

110

! R1 : les packages strotyps ou non peuvent se dcomposer en
packages et/ou classes,
! R2 : un package contient une classe d'interface modlisant les
services offerts,
! R3 : une classe d'interface reprsente l'ensemble des mthodes
et d'attributs publics fournis par les classes du package,
! R4 : les packages actifs contiennent au moins une classe active,
! R5 : une classe active a un comportement propre, elle est dcrite
par un diagramme d'tats/transitions, et elle fournit des mthodes
contraintes,
! R6 : une mthode est contrainte par un protocole (synchrone,
asynchrone, ) ou un tat interne (gr par une machine
tats).
! Des diagrammes spcifiques

! Diagramme de dploiement
! nuds physiques et connexions
! Diagramme de composants
! composants logiciels et dpendances
! fichier,table de base de donnes, excutable, librairie de
fonctions, document
! Respect de rgles d'architecture et

structuration des modles tous les niveaux
du processus.
111
112
Processus centr sur l'architecture (2)
! Abstraction et encapsulation,
! Modlisation des lments et mcanismes
principaux du systme,
! Expression des aspects statiques et
dynamiques
! Utilisation :
! Plusieurs manires de voir un systme :
Vue logique
Vue des processus

Vue des cas
d'utilisation
Vue de ralisation

l'architecture : vue logique
! diagrammes d'objets et de classes

! diagrammes de collaborations
! interactions,
! paquetages catgories
Vue de dploiement
113

l'architecture : vue ralisation
114

l'architecture : vue processus
! Identification des modules qui ralisent les

classes de la vue logique,
! Organisation des modules dans
l'environnement de dveloppement
! Elments manipuls :
! Importante dans les environnements multitches,

! Dcomposition en flots d'excution et
synchronisation entre ces flots,
! modules,
! sous-programmes,
! tches (en tant qu'units de programme)
! paquetage sous-systmes
! tches
! threads,
! processus,
! interactions.
115
116

l'architecture : vue dploiement

larchitecture : vue Use Case
! Importante dans les environnements

distribus,
! Ressources matrielles et l'implantation
(distribution) du logiciel dans ces ressources,
! Besoins des utilisateurs, justification de

l'architecture,
! Colle entre les autres vues
! acteurs,
! cas d'utilisation,
! classes,
! diagrammes de collaboration.
! nuds,
! modules,
! programmes principaux.
117
Processus centr sur l'architecture (10)

Classes, Objets,
Collaboration, Squences
Vision
Logique
Utilisateus finaux
Fonctionalits
Composants
Vision
cas dutilisation
Etats-Transitions
Activit
Vision Processus
Intgrateurs systme
Performance
Changement dchelles
Throughput
Conceptuel
Sommaire
Vision
Implmentation
Cas d'utilisation
118
Programmeurs
Gestion du logiciel
!!Principes
Dploiement
Vision Dploiement
Ingnieur systme
Topologie du systme
Installation
Communication
Physique
121
122
Processus guid par les patterns (1)
Processus guid par les patterns (2)

Le composite pattern
La notion de patron (ou pattern )

Nom_du_Pattern
Le nom
Un problme rcurrent
de conception O.O.
Le problme
Une solution exprime

en UML
Les bnfices
Composite Pattern
Reprsenter des objets complexes
! Construction rcursive de hirarchies
! Considrer de manire homogne les nuds
simples et complexes
Les bnfices
Les bonnes pratiques, les bonnes solutions

La plupart des patrons visent la rutilisabilit et l'extensibilit
Un moyen de transfrer des comptences
La solution
123
Objetcomplexe
Element
Objetsimple
124

GP UnifiedProcess PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

GP UnifiedProcess PDF

Transféré par

Droits d'auteur :

Formats disponibles

Sommaire

!!Objectifs dun processus dingnierie

Objectifs dun processus de

Activits de dveloppement (rappel)

! Un processus dfinit QUI fait QUOI, QUAND

Planification (tude de la faisabilit)

Vocabulaire UML (rappel)

Possibilit de reprsenter le mme

+ des mcanismes dextensions

Diagramme de cas dutilisation

Diagramme de cas dutilisation

! de ce que l'application doit (ou ne doit

! Point de vue de lutilisateur

! Le diagramme est accompagn

! Validation des cas d'utilisation,

! Faire apparatre les classes,

! Point central de la modlisation

! Appel aussi diagramme

! montrer leffet dune interaction

! Reprsentation du cycle de vie

! un processus dune organisation

! Plusieurs points de vue

!! Plusieurs acceptions de la notion

Une autre activit

Une activit rsultant

! Description des composants

Une dpendance fait rfrence aux services

! de la configuration matrielle des

Liens entre les diagrammes

est utilis par

Processus Unifi Principes (1)

Processus Unifi Principes (2)

! Il n'existe pas un seul processus de

! Pilotage par les cas d'utilisation

! Accent mis sur les phases plus que sur les

Processus Unifi Principes (3)

Processus Unifi Principes (4)

! Le processus de dveloppement est centr sur lutilisateur.

! Crer une bauche grossire de larchitecture.

! Larchitecture et les cas dutilisation voluent de

A partir des cas dutilisation, les

Processus Unifi Principes (5)

Processus Unifi Principes (5)

! Dcoupe du projet en mini-projet :

! des ITRATIONS qui donnent lieu un INCRMENT

! Chaque itration comprend un certain nombre de cas

! exprimentation et validation des technologies,

! Les prototypes dfinissent le noyau de

Processus Unifi Principes (5)

! Ordonnancement des itrations bas sur les

Dlimiter la porte du systme,

! Vision : Glossaire, Dtermination des parties prenantes et des utilisateurs,

! Spcification des fondements de larchitecture, crer une architecture de rfrence

! Extension de lidentification, de la description et de la ralisation des cas

! Comprhension de la structure et la dynamique de

! Recueil et expression des besoins :

! Prparation des activits

# Livraison du produit aux utilisateurs

Auprs des clients et parties prenantes du projet

! La production de maquettes peut tre ralise avec

! ce sont de simples dessins d'crans et descriptions de

! Pourquoi si tt dans le processus ?

! Test, Dploiement, Configuration et gestion des