You are on page 1of 31

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

Dveloppement (rappel)
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

Dveloppement (rappel)
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

Diagramme de classes
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
!!Modles UML (rappels)
!!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

Processus Unifi Principes (2)

! 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

Processus Unifi Principes (3)


Pilot par les cas dutilisation

Processus Unifi Principes (4)


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

Processus Unifi Principes (5)


Itratif et incrmental

34

Processus Unifi Principes (5)


Itratif et incrmental

! 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

Processus Unifi Principes (5)


Itratif et incrmental

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

!!Objectifs dun processus dingnierie logicielle


!!Modles UML (rappels)
!!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

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 :
Dfinition des besoins (2)

! 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 :
Dfinition des besoins (3)

! Dfinir un dictionnaire

58

Recueil des besoins


Etapes :
Dfinition des besoins (4)

! 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 :
Dfinition des besoins (5)
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

Ralisation des cas dutilisation (2)

! 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

Ralisation des cas dutilisation (3)

Analyse

Ralisation des cas dutilisation (4)

! 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

Diagramme de classes

! 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

Diagramme de classes

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

Construction modle danalyse

Construction modle danalyse

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

!!Objectifs dun processus dingnierie logicielle


!!Modles UML (rappels)
!!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

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

Utilisation des diagrammes (2)

Modles de
Dploiement

utilise

Modles
Dimplmentation

Modles
de test

Diagrammes
de Composants
utilise
utilise
utilise
utilise

Modles
de test
93

94

Utilisation des diagrammes (3)

Utilisation des diagrammes (4)

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

Utilisation des diagrammes (5)

Utilisation des diagrammes (6)

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

!!Objectifs dun processus dingnierie logicielle


!!Modles UML (rappels)
!!Processus de dveloppement Unifi

Pr-tude Elaboration

Construction

Transition

Modlisation Mtier
Recueil des besoins
Analyse & Conception
Implmentation

!!Principes
!!Recueil des besoins, Analyse, Conception
!!Utilisation des diagrammes
!!Processus pilot par les cas dutilisation
!!Processus centr sur larchitecture
!!Processus guid par les Patterns

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

Processus pilot par les cas


dutilisation (2)

Processus pilot par les cas


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

Analyse & Conception


Implmentation
Test
Dploiement

Workflows Support
Configuration Mgmt
Management
Environment

Analyse & Conception

! 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

Processus pilot par les cas


dutilisation (4)

102

Processus pilot par les cas


d'utilisation (5)

Phases
Workflows Ingnierie

Pr-tude Elaboration

Construction

Transition

Modle
des cas
dutilisation
spcialis par

Modlisation Mtier
Recueil des besoins
Analyse & Conception
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

Processus pilot par les cas


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)

!!Objectifs dun processus dingnierie logicielle


!!Modles UML (rappels)
!!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

! 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

Processus centr sur (2)


l'architecture : moyens UML

110

Processus centr sur (3)


l'architecture : moyens UML
! 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

Processus centr sur (3)


l'architecture : vue logique

! diagrammes d'objets et de classes


! diagrammes de collaborations
! interactions,
! paquetages catgories

Vue de dploiement

113

Processus centr sur (4)


l'architecture : vue ralisation

114

Processus centr sur (5)


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,
! Elments manipuls :

! modules,
! sous-programmes,
! tches (en tant qu'units de programme)
! paquetage sous-systmes

! tches
! threads,
! processus,
! interactions.
115

116

Processus centr sur (6)


l'architecture : vue dploiement

Processus centr sur (7)


larchitecture : vue Use Case

! Importante dans les environnements


distribus,
! Ressources matrielles et l'implantation
(distribution) du logiciel dans ces ressources,
! Elments manipuls :

! Besoins des utilisateurs, justification de


l'architecture,
! Colle entre les autres vues
! Elments manipuls :
! 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
!!Objectifs dun processus dingnierie logicielle
!!Modles UML (rappels)
!!Processus de dveloppement Unifi

Vision
Implmentation

Cas d'utilisation

118

Programmeurs
Gestion du logiciel

!!Principes
!!Recueil des besoins, Analyse, Conception
!!Utilisation des diagrammes
!!Processus pilot par les cas dutilisation
!!Processus centr sur larchitecture
!!Processus guid par les Patterns

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