GP UnifiedProcess PDF

Conduite de projet
Mthode danalyse et de conception

Processus unifi
G. Picard
SMA/G2I/ENS Mines Saint-Etienne
gauthier.picard@emse.fr
Octobre 2009
1
Sommaire
!!Objectifs dun processus dingnierie
logicielle
! Modles UML (rappels)
! Processus de dveloppement Unifi
Une partie du matriau de ce cours est issue du cours de Corinne CAUVET - Universit d'Aix-Marseille
2
Objectifs dun processus de
dveloppement
! 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
Activits de dveloppement (rappel)
! 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
5
Analyse
Conception
Implmentation
Tests
Maintenance
Modle en V
6
Implmentation
Expression
des besoins
Validation
des besoins
Validation
fonctionnelle
Analyse
Conception
Du Systme
Tests du
systme
Tests des
composants
Conception
des composants
vrifie
vrifie
vrifie
vrifie
Modle en spirale
7
Conception
Analyse
Spcifications
Validation
Tests
Implmentation
Sommaire
!!Objectifs dun processus dingnierie
logicielle
!!Modles UML (rappels)
! Processus de dveloppement Unifi
8
Vocabulaire UML (rappel)
9
Constituants de base
Relations
Diagrammes
Struct.
Comp.
Group.
Annot.
Cas d'utilisation
Classe
Classe Active
Interface
Composant
Collaboration
Noeud
Interaction
Machine d'tat
Package
Modle
Sous-systme
Framework
note
Dpendances
Associations
Gnralisation
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
+ des mcanismes dextensions
Diagrammes disponibles
(rappel)
10
Diagrammes
de Composants
Modles
dynamique
statique
Possibilit de reprsenter le mme
diagramme des niveaux de dtail
diffrents.
Diagramme de cas dutilisation
objectifs
! Description
! 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
11
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
Diagramme de cas dutilisation
notation
12
! 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
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
Cas
Diagramme de squences
objectifs
! 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
13
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
Diagramme de squences
notation
14
Acteur Objet ou classe
Autre objet ou
classe
Augmenter(3,5)
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
crer
X
dtruire
temps
getValue(a)
5,5
Modifier(b)
Diagramme de collaboration
objectifs
! 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
15
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
Diagramme de collaboration
notation
16
Un Objet
Un Autre Objet
Un acteur
1:augmenter(3,5)
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
Un Objet
2 : <<crer>>
3 :modifier
Diagramme de classes
objectifs
! 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
17
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
notation
18
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
Diagramme dobjets
objectifs
! Appel aussi diagramme
dinstances, il reprsente aussi la
structure statique
! reprsentation des instances
! Sutilise de manire ponctuelle
pour
! montrer leffet dune interaction
! reprsenter des structures
complexes (rcursives)
19
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
Diagramme dobjets
notation
20
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
Diagramme dtats-transitions
objectifs
! 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
21
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
Diagramme dtats-transitions
notation
22
Le premier tat
Entre/Action
Sortie/Action
Un autre tat
[garde]venement/action
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
do/Action
Evnement/Action
Diagramme dactivits
objectifs
! Reprsentation
! 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
23
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
Diagramme dactivits
notation
24
Une activit Une autre activit
Une activit rsultant
d'une synchronisation
Une activit nouvelle
Une transition
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
Diagramme de composants
objectifs
! 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
25
Diagramme de composants
notation
26
Un composant
Un autre
composant
Une dpendance fait rfrence aux services
offerts par un composant. La flche va de
l'utilisateur vers le fournisseur.
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
Diagramme de dploiement
objectifs
! Description
! 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
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
Diagramme de dploiement
notation
28
Un noeud
Un autre noeud
Un composant
Un autre
composant
"!Cas dutilisation
"!Squences
"!Collaboration
"!Classes
"!Objets
"!tats/transitions
"!Activits
"!Composants
"!Dploiement
Liens entre les diagrammes
Diagramme
Composants
Diagramme
Cas Utilisation
Cas dUtilisation
Diagramme
Squences
Diagramme
Collaboration
Diagramme
Classes
Diagramme
Etats
Diagramme
Dploiement
est utilis par
29
Sommaire
!!Objectifs dun processus dingnierie logicielle
!!Processus de dveloppement Unifi
!!Principes
!!Recueil des besoins, Analyse, Conception
!!Utilisation des diagrammes
!!Processus pilot par les cas dutilisation
!!Processus centr sur larchitecture
!!Processus guid par les Patterns
30
Processus Unifi Principes (1)
! Il n'existe pas un seul processus de
dveloppement, ni de processus standard
! CEPENDANT
des caractristiques essentielles peuvent tre
mises en avant :
! Pilotage par les cas d'utilisation
! Focalisation sur l'architecture
! Utilisation de patrons de conception (Design
Patterns)
! Droulement itratif et incrmental
! Accent mis sur les phases plus que sur les
activits danalyse, conception,
31
32
Langage
UML
Cas
d'utilisation
Architecture
Itratif et
incrmental
Processus
Unifi
Processus A Processus B
bas sur
pilot par
se droule
centr sur
* Facteurs organisationnels
* Facteurs de domaine
* Facteurs techniques
Conseils
Patterns
guid par
Pilot par les cas dutilisation
! Le processus de dveloppement est centr sur lutilisateur.
33
A partir des cas dutilisation, les
dveloppeurs crent une srie de
modles UML.
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:
! 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.
34
Itratif et incrmental
! Dcoupe du projet en mini-projet :
! 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.
35
! Segmentation du travail
! Concentration sur les besoins et les risques,
! Les premires itrations sont des prototypes
! exprimentation et validation des technologies,
! planification,
! Les prototypes dfinissent le noyau de
l'architecture.
36
! Ordonnancement des itrations bas sur les
priorits entre cas d'utilisation et sur l'tude
du risque
37
Pr-Etude
Elaboration
Intgration
Construction
Pr-Etude
Elaboration
Intgration
Pr-Etude
Elaboration
Intgration
Construction
Construction
Dfinition de
l'itration
Evaluation
Phases
38
temps
Pr-tude :
! 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
Vision
Phases
39
temps
! Elaboration :
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
Vision Architecture
Phases
temps
Construction :
! 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
Vision Architecture Premires
fonctionnalits
40
Phases
temps
Transition :
! 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
Vision Architecture Premires
fonctionnalits
Livraison
Produit
41
Activits (1)
! Modlisation mtier :
! 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 :
! 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
42
Activits (1)
Production de maquettes IHM
! La production de maquettes peut tre ralise avec
nimporte quel outil graphique :
! 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.
! 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
43
Activits (2)
! Analyse et conception :
! Transformation des besoins utilisateurs en modles UML
! Modle d'analyse et modle de conception
! Implmentation :
! Dveloppement itratif
! Dcoupage en couches
! Composants d'architecture
! Retouche des modles et des besoins
! Units indpendantes, quipes diffrentes
! Test, Dploiement, Configuration et gestion des
changements, Gestion de projet, Environnement,
Dploiement
44
Itrations (1)
Une itration est une squence dactivits selon un plan
pr-tabli et des critres dvaluation, rsultant en un
produit excutable.
Arch
Iteration
... Cons
Iteration
Cons
Iteration
... Trans
Iteration
...
Release Release Release Release Release Release Release Release
Prelim
Iteration
...
45
Itrations (2)
46
Management
Environment
Modlisation Mtier
Implmentation
Test
Analyse & Conception
Preliminary
Iteration(s)
Iter.
#1
Phases
Enchanement des
Activits dIngnierie
Iterations
Enchanement des
activits Support
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Dploiement
Configuration Mgmt
Recueil des besoins
Elaboration Transition Pr-tude Construction
Une itration
dans la phase
d'laboration
Sommaire
!!Principes
47
Modles
48
Recueil
Besoins
Analyse
Conception
Implmentation
Test
Modles
de test
Modles des
Use Case
Modles
dAnalyse
Modles de
Conception
Modles de
Dploiement
Modles
Dimplmentation
Recueil des besoins
! 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
49
Section issue du cours de J.M. Favre (IMAG)
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.
50
Recueil des besoins
Exigences (1)
Selon IEEE 610.12, une exigence est :
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.
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.
51
Recueil des besoins
Exigences (2)
! Exigences fonctionnelles
! quoi sert le systme
! ce que doit faire le systme, les fonctions utiles
! Exigences non fonctionnelles
! performance, sret, confidentialit, portabilit,
etc.
! chercher des critres mesurables
52
Recueil des besoins
Exigences non fonctionnelles
! Exigences qui ne concernent pas spcifiquement le
comportement du systme.
! 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
53
Recueil des besoins
Etapes :
vue densemble
! Capture des besoins
! collecte des informations : interviews, lecture de
documentation
! chercher comprendre : (1) le domaine (2) le
problme
! 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
54
Recueil des besoins
Etapes :
Capture des besoins (1)
! Objectifs : comprendre le domaine, comprendre le
problme
! # Collecter le maximum d'informations
! 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.
55
Recueil des besoins
Etapes :
Capture des besoins (2)
!! Ragir et tre actif !
! tablir la liste des documents consults, les
classer
! laborer une liste de questions prcises
! 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
56
Recueil des besoins
Etapes :
Dfinition des besoins (1)
! Restituer les informations sous forme synthtique
! Scnarios et cas dutilisation :
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
! et aussi ce quil nest pas sens faire.
! mais surtout pas comment il doit le faire.
! Etablir des priorits
! Arriver un consensus avec le client
57
Recueil des besoins
Etapes :
! Les besoins doivent tre compris par tous
! utiliser la langue naturelle
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
! utiliser des schmas si ncessaire
! tout schma doit tre comment et comporter une
lgende
! Structurer le document de dfinition
! suivre un plan standard si disponible
! numroter les sections, rfrences, index,
58
Recueil des besoins
Etapes :
! Dfinir un dictionnaire
! Indispensable d'avoir un langage commun
dfinition d'un vocabulaire prcis
client, quipe de dveloppement, utilisateurs
! 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
Recueil des besoins
Etapes :
! Conseils pour la construction du
dictionnaire :
! 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 !
60
Recueil des besoins
Etapes :
61
opration IncrGaz
Action permettant
dinjecter du carburant
pour augmenter la vitesse
de lavion
Augmenter
les gaz
Type entit Nom info. Dfinition Action
Classe
MancheABa
lai
Intrument permettant au
pilote de diriger lavion
Manche
balai
Classe
abstraite
Instrument
Organe dinteraction entre
le pilote et lavion
Instrument
paquetage Pilotage
Action de piloter un avion en
enchanant des manoeuvres
lmentaires
Pilotage
Type entit Nom. Info. Dfinition Notion
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
62
Recueil des besoins
Intervenants et tapes
63
Recueil des besoins
Modle dAnalyse
64
*
Classes d'analyse
%! Responsabilits
%! attributs
%! associations
Ralisation de cas d'utilisation
Diagrammes de classes
Diagrammes de collaboration
Packages d'analyse
*
Modle d'analyse
Analyse
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
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
Modle des cas dutilisation Modle d'analyse
Modle dAnalyse
vs Modle des cas dutilisation
65
Analyse
Classes dAnalyse
! Classes candidates partir des descriptions
des Use Cases
! 3 types de classes :
! 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
66
Analyse
Classes danalyse :
Classes Entits
! Informations dont la dure de vie dpasse celle des
UC
! Mthodes pour manipuler ces informations
! Elles
! 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
! Les responsabilits et les attributs sont diffrents dun
UC lautre
! Une fois lensemble de classes de chaque UC
identifi, on peut les combiner
67
Analyse
Classes danalyse :
Classes Frontires
! 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
! 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
68
Analyse
Classes danalyse :
Classes Contrle
! Contiennent un scnario de UC
! 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
69
Analyse
Description des classes danalyse
! 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
! Chaque attribut est document
70
Analyse
Ralisation des cas dutilisation (1)
! Construire la ralisation des UC
! crer les diagrammes de collaboration et des
descriptions de flux dvnements
! Gnrer des diagrammes de classe pour
chaque UC
! trouver les associations entre classes
ncessaires chaque ralisation de UC
71
Analyse
! Une fois les classes identifies et dcrites
pour chaque UC, elles sont utilises pour
raliser les cas d'utilisation
! analyse du UC dans le comportement et la
structure
! partir des diagrammes de collaboration et de
classe
Analyse
72
! Les diagrammes dinteractions sont bass
sur lanalyse des interactions
! 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
73
Analyse
! Les diagrammes de classes sont bass sur
l'analyse des classes
! classes, associations et attributs impliqus dans
un UC donn
74
Analyse
Analyse des interactions
! Les diagrammes de collaboration montrent
les interactions entre objets
! 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)
75
Analyse
Analyse des classes
! Lanalyse de classes est l'tape du
processus qui attache les diagrammes de
classes chaque ralisation de UC
! 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
76
Analyse
Identification des responsabilits
! Pour chaque classe, trouver les ralisations
de UC o elles apparat
! 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)
77
Analyse
Identification des proprits
! Ajouter les attributs et leurs types aux
classes
! souvent trouvs lors de lidentification des
classes
! lister et dcrire chaque attributs partir de
chaque ralisation de UC
78
Analyse
Identification des proprits
! Remarques :
! 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
79
Analyse
Identification des relations
! Observer les liaisons dans les diagrammes
de collaboration :
! chaque liaison peut tre une instance d'une
association sous-jacente
! elle peut mme dans certains cas impliquer une
agrgation ou une gnralisation
80
Analyse
Identification des relations
! Toutes les liaisons du diagramme ne sont
pas des associations
! certaines peuvent tre temporaires
! Crer un diagramme de classe contenant les
classes, les associations et les attributs
pertinents pour chaque ralisation de use-
case
81
Analyse
! Une association est une rfrence entre
deux classes, utiliser :
! les descriptions de UC et les descriptions de
scnarios
! les diagrammes d'interaction
! la modlisation mtier
! Les associations doivent tre documentes
dans les descriptions des ralisations des
UC
82
Analyse
! Types dassociation :
! association
! 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
! 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.
83
Analyse
Construction modle danalyse
1.! 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
2.! 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
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
84
Analyse
4.! Identifier les associations et conserver les associations
pertinentes
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 :
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
Analyse
85
5.! Identifier les attributs des objets et les liens
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
Analyse
86
Fin analyse
! 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 :
! 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
87
Modle de Conception
88
*
Classes de conception
%! mthodes
%! visibilits des attributs
Ralisation de cas d'utilisation
Diagrammes de classes
Diagrammes de squences
Sous-systme de conception
*
Modle de conception
Interface
Conception
Modle danalyse vs
Modle de conception
89
! Modle conceptuel
! Autorise plusieurs
conceptions
! Peu de strotypes de
classes
! Peu de couches
! Modle physique
! Spcifique une
implantation
! Strotypes dpendant de
lenvironnement cible
dimplantation
! Plusieurs couches
Modle danalyse Modle de conception
Conception
Etapes suivre
1.! Estimer les performances du systme
2.! Mettre au point un plan de rutilisation
3.! Organiser le systme en sous-systmes
4.! 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
90
Conception des classes
! 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
91
Sommaire
!!Principes
92
Modles
de test
Modles des
Use Case
Modles
dAnalyse
Modles de
Conception
Modles de
Dploiement
Modles
Dimplmentation
Diagrammes
de Composants
utilise
utilise
utilise
utilise
Utilisation des diagrammes (1)
93
Modles
de test
Modles des
Use Case
Modles
dAnalyse
Modles de
Conception
Modles de
Dploiement
Modles
Dimplmentation
Diagrammes
de Composants
utilise
utilise
utilise
utilise
utilise
94
Modles
de test
Modles des
Use Case
Modles
dAnalyse
Modles de
Conception
Modles de
Dploiement
Modles
Dimplmentation
Diagrammes
de Composants
utilise
utilise
utilise
utilise
utilise
95
Modles
de test
Modles des
Use Case
Modles
dAnalyse
Modles de
Conception
Modles de
Dploiement
Modles
Dimplmentation
Diagrammes
de Composants
utilise
utilise
utilise
96
Modles
de test
Modles des
Use Case
Modles
dAnalyse
Modles de
Conception
Modles de
Dploiement
Modles
Dimplmentation
Diagrammes
de Composants
utilise
utilise
utilise
97
Modles
de test
Modles des
Use Case
Modles
dAnalyse
Modles de
Conception
Modles de
Dploiement
Modles
Dimplmentation
Diagrammes
de Composants
utilise
utilise
utilise
utilise
98
Sommaire
!!Principes
99
Processus pilot par les cas
dutilisation (1)
100
Management
Environment
Modlisation Mtier
Implmentation
Test
Preliminary
Iteration(s)
Iter.
#1
Phases
Workflows Ingnierie
Iterations
Workflows Support
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Dploiement
Configuration Mgmt
Recueil des besoins
! les analystes identifient la
plupart des UC pour
dlimiter le systme, et
dtaillent les plus
importants
dutilisation (2)
101
Management
Environment
Modlisation Mtier
Implmentation
Test
Preliminary
Iteration(s)
Iter.
#1
Phases
Workflows Ingnierie
Iterations
Workflows Support
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Dploiement
Configuration Mgmt
Recueil des besoins
! les analystes trouvent les
UC restant (objectif :
80%) et les dcrivent pour
estimer l'effort de
dveloppement en fin de
phase
dutilisation (3)
102
Management
Environment
Modlisation Mtier
Implmentation
Test
Preliminary
Iteration(s)
Iter.
#1
Phases
Workflows Ingnierie
Iterations
Workflows Support
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Dploiement
Configuration Mgmt
Recueil des besoins
! le reste des UC est
exprim et implment
dutilisation (4)
103
Management
Environment
Modlisation Mtier
Implmentation
Test
Preliminary
Iteration(s)
Iter.
#1
Phases
Workflows Ingnierie
Iterations
Workflows Support
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Dploiement
Configuration Mgmt
Recueil des besoins
! sauf changement,
aucun UC ne doit
rester dcouvrir
d'utilisation (5)
! Les cas d'utilisation sont le fil
conducteur de toutes les activits
Modle
dAnalyse
Modle de
Conception
Modle de
Dploiement
Modle
d'implantation
Modle de
Test
spcialis par
ralis par
distribu par
ralis par
vrifi par
Modle
des cas
dutilisation
104
d'utilisation (6)
105
Processus dirig par les cas
d'utilisation (7) : org. travail
! Dcoupage et organisation du travail selon
les cas d'utilisation :
106
Analyse
Experts du domaine
Conception et
Ralisation
Architectes
Concepteurs
Programmeurs
Test
lntgrateurs et
testeurs
Les cas d'utilisations relient ces tches ensemble
Processus dirig par les cas
d'utilisation (8) : conclusion
! 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)
! Description de la structure de la collaboration
! Description du comportement de la collaboration
! Outil de communication
107
Sommaire
!!Principes
108
Processus centr sur larchitecture (1)
! Recherche de la forme gnrale du systme
ds le dbut
! Approche systmatique pour trouver une
bonne architecture qui soit :
! support des cas d'utilisation
! adaptable aux changements
! pour et avec la rutilisation
! comprhensible intuitivement
109
Processus centr sur (1)
l'architecture : moyens UML
! 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
! Forte cohsion
! Faible couplage
! Notion de couches
! Composition de paquetages
110
Couche service
Couche application
! 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
! 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).
112
Processus centr sur l'architecture (2)
! Plusieurs manires de voir un systme :
113
Vue logique Vue des processus
Vue de dploiement Vue de ralisation
Vue des cas
d'utilisation
l'architecture : vue logique
! Abstraction et encapsulation,
! Modlisation des lments et mcanismes
principaux du systme,
! Expression des aspects statiques et
dynamiques
! Utilisation :
! diagrammes d'objets et de classes
! diagrammes de collaborations
! interactions,
! paquetages catgories
114
l'architecture : vue ralisation
! Identification des modules qui ralisent les
classes de la vue logique,
! Organisation des modules dans
l'environnement de dveloppement
! Elments manipuls :
! modules,
! sous-programmes,
! tches (en tant qu'units de programme)
! paquetage sous-systmes
115
l'architecture : vue processus
! Importante dans les environnements multi-
tches,
! Dcomposition en flots d'excution et
synchronisation entre ces flots,
! tches
! threads,
! processus,
! interactions.
116
l'architecture : vue dploiement
! Importante dans les environnements
distribus,
! Ressources matrielles et l'implantation
(distribution) du logiciel dans ces ressources,
! nuds,
! modules,
! programmes principaux.
117
larchitecture : vue Use Case
! Besoins des utilisateurs, justification de
l'architecture,
! Colle entre les autres vues
! acteurs,
! cas d'utilisation,
! classes,
! diagrammes de collaboration.
118
Processus centr sur l'architecture (10)
121
Vision
Logique
Utilisateus finaux
Fonctionalits
Vision
Implmentation
Programmeurs
Gestion du logiciel
Vision Processus
Performance
Changement dchelles
Throughput
Intgrateurs systme
Vision Dploiement
Topologie du systme
Installation
Communication
Ingnieur systme
Conceptuel Physique
Vision
cas dutilisation
Classes, Objets,
Collaboration, Squences
Etats-Transitions
Activit
Composants
Dploiement
Cas d'utilisation
Sommaire
!!Principes
122
Processus guid par les patterns (1)
123
La notion de patron (ou pattern )
Les bonnes pratiques, les bonnes solutions
La plupart des patrons visent la rutilisabilit et l'extensibilit
Un moyen de transfrer des comptences
Nom_du_Pattern
Un problme rcurrent
de conception O.O.
Une solution exprime
en UML
Les bnfices
Processus guid par les patterns (2)
124
Le composite pattern
Le nom
Le problme
Les bnfices
La solution
Composite Pattern
Reprsenter des objets complexes
Objet-
complexe
Objet-
simple
Element
! Construction rcursive de hirarchies
Considrer de manire homogne les nuds
simples et complexes
*

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

Conduite de projet

Mthode danalyse et de conception

Vous aimerez peut-être aussi