Cours USDP

Mthodologie de Dveloppement Objet
Premire partie : Unified Software Development Process (USDP)
Christine Solnon
INSA de Lyon - 4IF
2014 - 2015
1/106
Contexte
Domaines denseignement du dpartement IF :
Systme dInformation
Rseaux
Architectures matrielles
Logiciel Systme
Mthodes et Outils Mathmatiques
Formation gnrale
Dveloppement logiciel :
En 3IF :
En 4IF :
C++
Ingnierie des IHM
Modlisation UML
Mthodologie de dvelopmt objet
Gnie logiciel
Qualit logicielle
Grammaires et langages
2/106
Rfrentiel des comptences (1/2)

Utiliser des diagrammes UML pour modliser un objet dtude
Interprter un diagramme UML donn
IF3-UML, IF4-DevOO, IF4-IHM
Concevoir un diagramme UML modlisant un objet dtude

IF3-UML, IF3-C++, IF3-DASI, IF4-DevOO, IF4-IHM, IF4-LG
Vrifier la cohrence de diffrents diagrammes modlisant un mme

objet dtude
IF3-UML, IF4-DevOO, IF4-LG
Concevoir larchitecture dun logiciel orient objet

Structurer un logiciel en paquetages et classes faiblement coupls et
fortement cohsifs
IF3-UML, IF3-C++, IF3-DASI, IF4-DevOO, IF4-LG
Utiliser des Design Patterns

IF3-UML, IF3-C++, IF3-DASI, IF4-DevOO, IF4-LG
3/106
Rfrentiel des comptences (2/2)

Mettre en oeuvre une mthodologie pour concevoir, raliser et
maintenir des logiciels de qualit
Mettre en oeuvre un processus de dveloppement itratif tel que le
Unified Software Development Process" (USDP)
IF3-GL, IF4-DevOO, IF4-IHM
Mettre en uvre les principes du manifeste Agile

IF3-GL, IF4-DevOO
Rdiger un cahier des charges logiciel

IF3-C++, IF3-GL, IF4-DevOO, IF4-QL
Implmenter de bons logiciels

Mettre en uvre bon escient les mcanismes offerts par les langages
de programmation orients objet : hritage, gnricit, surcharge,
polymorphisme, ...
IF3-C++, IF3-GL, IF3-DASI, IF4-DevOO
4/106
Organisation
Cours
du 23/09 au 9/10 : 6 cours DevOO
Partie 1 (3 cours) : USDP
Partie 2 (1 cours) : Mthodes Agiles par S. Sorlin (Esker)
Partie 3 (1 cours) : Ingnierie des modles
Partie 4 (1 cours) : Prsentation du projet
du 22/10 au 07/10 : 6 cours Ingnierie des IHM" par La Laporte
Mise-en-pratique : Projet Gestion de tournes de livraisons"
5 sances de 4h
Dveloppement objet
3 sances de 4h
IHM
Inspir du projet de R&D OptimodLyon pilot par le Grand Lyon

Evaluation
DS le 18 dcembre + Note de projet
5/106
Quelques livres emprunter DOCINSA

Le processus unifi de dveloppement logiciel
Ivar Jacobson, Grady Booch, James Rumbaugh
Description dUSDP par ses concepteurs
UML 2 et les design patterns
Craig Larman
Mise en uvre dUSDP dans un esprit Agile
Bonne introduction aux design patterns
Modlisation Objet avec UML
Pierre-Alain Muller, Nathalie Gaertner
Bon rappel sur UML pour lanalyse et la conception OO
Brve prsentation dUSDP
...et plein dautres !
6/106
Introduction
Motivations
Plan du cours
Introduction
Motivations
Quelques rappels (rapides) sur le contexte
Prsentation gnrale dUSDP
Description dtaille des activits dune itration gnrique
Retour sur les phases
7/106
Introduction
Motivations
Crise du logiciel ?
1979 : Etude du Government Accounting Office sur 163 projets
29% des logiciels nont jamais t livrs
45% des logiciels ont t livrs... mais nont pas t utiliss
19% des logiciels ont t livrs mais ont du tre modifis
... ce qui laisse 7% de logiciels livrs et utiliss en ltat
1994 : Systme de convoyage des bagages / aroport de Denver
193 M$ et 16 mois de retard (1,1 M$ perdus par jour de retard )
Remplac par un systme manuel en 2005
1999
2011 : New York City Automated Payroll (NYCAP) System
Budget estim = 66 M$
Budget rel > 360 M$
Et quelques bugs qui ont cout trs cher...
1996 : Explosion dAriane 5
1999 : Perte de NASA Mars Climate Orbiter
8/106
Introduction
Motivations
Etude du Standish Group (1/3)

Russite des projets informatiques (sur 50000 projets depuis 2004)
Succs
Echec
Mitig
2004
29%
18%
53%
2006
35%
19%
46%
2008
32%
24%
44%
2010
37%
21%
42%
2012
39%
18%
43%
Succs : livr temps, sans surcot et avec toutes les fonctionnalits

Echec : abandonn en cours de route
Mitig : livr avec moins de fonctionnalits + dpassement cot ou tps
Dpassement temps
Dpassement cot
Fonctionnalits livres
2004
84%
56%
64%
2006
72%
47%
68%
2008
79%
54%
67%
2010
71%
46%
74%
2012
74%
59%
69%
On progresse un peu... mais il reste de la marge pour samliorer !

9/106
Introduction
Motivations

Influence de la taille du projet sur la russite (en 2012)
Petit projet : moins de 1 million de dollars

Gros projet : plus de 10 millions de dollars
Conclusion du Standish group :
It is critical to break down large projects into a sequence of smaller ones, prioritized on
direct business value, and install stable, full-time, cross-functional teams that execute
these projects following a disciplined agile and optimization approach.
10/106
Introduction
Motivations

Principales causes des checs
1
Manque dimplication de lutilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12,8%
Exigences et spcifications incompltes . . . . . . . . . . . . . . . . . . . . . . . . . . 12,3%
Changement des exigences et spcifications . . . . . . . . . . . . . . . . . . . . . 11,8%
Extrait des conclusions de ltude :

Research at the Standish Group indicates that smaller time frames, with
delivery of software components early and often, will increase the success
rate. Shorter time frames result in an iterative process of design, prototype,
develop, test and deploy small elements. This process is known as growing
software as opposed to the old concept of developping software. Growing
software engages the user earlier."
Unified Software Development Process (USDP / UP)
Processus itratif populaire pour le dveloppement orient objet
Processus flexible et ouvert
Agile et XP compatible !
11/106
Introduction
Motivations
Etude de S. Ambler sur 173 projets en 2013
Lean
Iterative (UP)
Agile
AdHoc
Traditionnel
0%
20%
Succs
40%
Mitig
60%
80%
100%
Echec
12/106
Introduction
Plan du cours
Introduction
Motivations
13/106
Introduction
Quest-ce quun logiciel ?

Ensemble dartefacts
Codes : Sources, Binaires, Tests, ...
Documentation pour lutilisateur : Manuel utilisateur, manuel de
rfrence, tutoriels, ...
Documentation interne : Cas dutilisation, Modle du domaine,
Diagrammes dinteraction, Diagrammes de classes, ...
...
Conus par et pour diffrents acteurs
Utilisateurs
Analystes et programmeurs
Hotline
...
14/106
Introduction
Quest-ce quun bon logiciel ?

Diffrents points de vue
Lutilisateur
Ce que a fait ?
besoins fonctionnels ou non fonctionnels

besoins exprims ou implicites, prsents ou futurs, ...
Lanalyste/programmeur
Comment a le fait ?
architecture, structuration, documentation, ...

Le fournisseur
Combien a cote/rapporte ?
cots de dveloppement + maintenance, dlais, succs ...

La hotline
Pourquoi a ne le fait pas/plus ?
diagnostic, reproductibilit du pb, administration distance, ...

...
15/106
Introduction
Activits dun processus logiciel (rappel de 3IF) :
Capture des besoins

Cahier des charges
Analyse
Spcifications fonctionnelles et non fonctionnelles du logiciel
Conception
Architecture du logiciel, modles de conception
Ralisation / Implantation
Code
Validation, intgration et dploiement
Logiciel livrable
Maintenance
16/106
Introduction
Enchanements dactivits et Cycle de vie (rappel de 3IF)

Modles linaires
Cycle en cascade
Cycle en V
Modle incrmental
3 premires activits excutes en squence
Spcification et architecture figes
Ralisation, intgration et tests effectus incrmentalement
Problme :
Ces modles supposent que
lanalyse est capable de spcifier correctement les besoins
ces besoins sont stables
Or, 90% des dpenses concernent la maintenance et lvolution !
17/106
Introduction
Maintenance et volution
Utilisation des fonctionnalits spcifies / cycle en cascade [C. Larman] :
Jamais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45%
Rarement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19%
Parfois . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16%
Souvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13%
Toujours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7%
Rpartition des cots de maintenance [C. Larman] :
Extensions utilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41,8%
Correction derreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21,4%
Modification format de donnes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17,4%
Modification de matriel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6,2%
Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5,5%
Efficacit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4%
If you think writing software is difficult, try re-writting software
Bertrand Meyer
18/106
Introduction
Le manifeste Agile (2001) www.agilealliance.com

Nous dcouvrons comment mieux dvelopper des logiciels par la
pratique et en aidant les autres le faire. Ces expriences nous ont
amens valoriser :
Les individus et leurs interactions
... plus que les processus et les outils
Des logiciels oprationnels
... plus quune documentation exhaustive
La collaboration avec les clients
... plus que la ngociation contractuelle
Ladaptation au changement
... plus que le suivi dun plan
Nous reconnaissons la valeur des seconds lments...
...mais privilgions les premiers.
19/106
Introduction
Quelques principes (choisis) du manifeste Agile

Satisfaire le client en livrant rapidement et rgulirement des
fonctionnalits grande valeur ajoute.
Accueillir positivement les changements de besoins, mme tard.
Livrer frquemment un logiciel oprationnel avec des cycles de
quelques semaines quelques mois.
Faire travailler ensemble utilisateurs et dveloppeurs tout au long du
projet.
Un logiciel oprationnel est la principale mesure davancement.
La simplicit (lart de minimiser le travail inutile) est essentielle.
intervalles rguliers, lquipe rflchit aux moyens de devenir plus
efficace, puis rgle et modifie son comportement en consquence.
Attention : Etre agile" ne signifie pas ne pas modliser"
Modliser permet de comprendre, de communiquer et dexplorer
20/106
Vue densemble du processus
Plan du cours
Introduction

Les phases dun cycle
Caractristiques marquantes de la mthode
21/106
Vue globale de la vie dun logiciel avec USDP

La vie dun logiciel est compose de cycles
1 cycle 1 nouvelle version du logiciel
Chaque cycle est compos de 4 phases :
Etude prliminaire (Inception)
Elaboration
Construction
Transition
Chaque phase dun cycle est compose ditrations
1 itration 1 incrment
Chaque itration est une mini cascade dactivits
Capture des besoins
Analyse
Conception
Ralisation
Test et intgration
...en proportions variables en fonction du temps
22/106
Vue graphique dun cycle avec USDP
[figure extraite du livre de C. Larman]
23/106
Plan du cours
Introduction

24/106
Phase 1 : Etude prliminaire (inception)
Phase trs courte (souvent une seule itration)

Etape prliminaire llaboration
Dterminer la faisabilit, les risques et le primtre du projet
Que doit faire le systme ?
A quoi pourrait ressembler larchitecture ?
Quels sont les risques ?
Estimation approximative des cots et des dlais
Accepter le projet ?
25/106
Phase 2 : Elaboration
Quelques itrations courtes et de dure fixe, pilotes par les risques
Identification et stabilisation de la plupart des besoins
Spcification de la plupart des cas dutilisation
Conception de larchitecture de base
Squelette du systme raliser
Programmation et test des lments darchitecture les + importants
Ralisation des cas dutilisation critiques (<10% des besoins)
Tester au plus tt, souvent et de manire raliste
Estimation fiable du calendrier et des cots
Besoins et architecture stables ? Risques contrls ?
26/106
Phase 3 : Construction
Phase la plus coteuse (>50% du cycle)

Dveloppement par incrments
Architecture stable malgr des changements mineurs
Le produit contient tout ce qui avait t planifi
Il reste quelques erreurs
Produit suffisamment correct pour tre install ?
27/106
Phase 4 : Transition
Produit dlivr (version bta)

Correction du reliquat derreurs
Essai et amlioration du produit, formation des utilisateurs, installation
de lassistance en ligne...
Tests suffisants ? Produit satisfaisant ? Manuels prts ?
28/106
Plan du cours
Introduction

29/106
Processus guid par les cas dutilisation
Les cas dutilisation :

Dcrivent les interactions entre les acteurs et le systme
Scnarios dutilisation comprhensibles par tous
Permettent de capturer les vrais besoins des utilisateurs
Rflchir en termes dacteurs et de buts plus que de fonctionnalits
Guident tout le processus de dveloppement
Garantissent la cohrence du processus
Favorisent un dveloppement itratif
Chaque itration est centre sur un sous-ensemble de cas
30/106
Cas dutilisation / activits
[figure extraite du livre de I. Jacobson, G. Booch, J. Rumbaugh]
31/106
Processus centr sur larchitecture
Architecture :
Vue des aspects les plus significatifs du systme
Abstraction des principaux modles du systme
Conue et stabilise lors des premires itrations
Traiter en premier les cas dutilisation pertinents" :
les plus risqus / critiques
les plus importants pour le client
les plus reprsentatifs du systme
32/106
Processus itratif et incrmental

Itration = mini projet donnant lieu un incrment
Avantages :
Gestion des risques importants lors des premires itrations
Construire et stabiliser le noyau architectural rapidement
Feed-back rgulier des utilisateurs
Adaptation permanente du systme aux besoins rels
Feed-back rgulier des dveloppeurs et des tests
Affiner la conception et les modles
Complexit mieux gre
Eviter la paralysie par lanalyse
Etapes plus courtes et moins complexes
Exploitation des erreurs des itrations prcdentes
Amlioration du processus dune itration sur lautre
33/106
Ce quon va voir dans la suite du cours...
Description des diffrentes activits dune itration

Que faut-il dcrire ?
Sous quelle forme ?
Comment faire cela ?
Description technique de la mthode
Description des diffrentes phases
Quel est le but atteindre ?
Quels sont les livrables ?
Quel niveau dabstraction ?
Description du droulement du projet
34/106
Plan du cours
Introduction
35/106
Vue globale dune itration gnrique"

Mini cascade qui enchane diffrentes activits :
Capture et analyse des besoins
Modliser le systme vu de lextrieur
Conception
Modliser le systme vu de lintrieur
Ralisation et tests
Implmenter le systme
Valider limplmentation par rapport aux besoins
La part de ces activits varie en fonction des phases
Itrations Agiles (sprints) :
Itrations de courte dure
Quelques semaines (typiquement entre 2 et 4)
Itrations de dure fixe
Rduire les objectifs de litration si ncessaire
Reporter une partie des objectifs aux itrations suivantes
36/106
Part des activits dune itration / Phases
[Figure extraite de http ://www.ibm.com/developerworks/rational]
37/106
Activit Capture et analyse des besoins"
Plan du cours
Introduction

Activit Conception"
Activit Ralisation et Tests"
Gestion de projet
38/106

Objectif de lactivit : se mettre daccord sur le systme construire
Besoins fonctionnels ( comportementaux)
Besoins non fonctionnels ( tous les autres)
Capture vs analyse des besoins
Capture :
Langage du client
Informel, redondant
Structuration par les cas dutilisation
Analyse :
Langage du dveloppeur
Formel, non redondant
Structuration par les classes
Activit difficile car :
Les utilisateurs ne connaissent pas vraiment leurs besoins
Les dveloppeurs connaissent mal le domaine de lapplication
Utilisateurs et dveloppeurs ont des langages diffrents
Les besoins voluent
Il faut trouver un compromis entre services, cots et dlais
39/106
Buts et Artefacts
Buts
Comprendre le contexte du
systme
Artefacts
Modles du domaine et
du mtier
Glossaire
Apprhender les besoins

fonctionnels
Modle des cas

dutilisation
Apprhender les besoins non

fonctionnels et architecturaux
Exigences
supplmentaires
40/106
Modle du domaine
Quest-ce quun modle du domaine ?
Diagramme de classes conceptuelles
Peu dattributs, pas dopration, pas de classes logicielles
Comment construire un modle du domaine ?
Rutiliser (et modifier) des modles existants !
Utiliser une liste de catgories :
Classes : Transactions mtier, Lignes de transactions, Produits/services
lis aux transactions, Acteurs, Lieux, ...
Associations : est-une-description-de, est-membre-de, ...
Identifier les noms et groupes nominaux des descriptions textuelles
Modlisation itrative et agile
Objectifs : Comprendre les concepts cls et leurs relations... et communiquer !
Il nexiste pas de modle du domaine exhaustif et correct
Le modle du domaine volue sur plusieurs itrations
Travailler en mode esquisse"
41/106
Autres artefacts pour Comprendre le contexte du systme"
Modle dobjets mtier (Business Object Model)

Modle plus gnral que le modle du domaine
Abstraction de la faon dont les travailleurs et les entits mtier doivent
tre mis en relation, et de la faon dont ils doivent collaborer afin
daccomplir une activit
Diagrammes de classe, dactivit, de collaboration et de squence
Plus dinfos dans le cours 4IF-ASI
Glossaire
Dfinit les termes les plus importants
Evite les ambiguits
Driv des cas dutilisation et modles du domaine et du mtier
42/106
Au travail !
Extrait du projet donn en 2011 : Gestion des bagages dun aroport
Lapplication a pour but de grer les bagages dans un aroport depuis le guichet de
lenregistrement de dpart jusque dans lavion, ou bien de larrive de lavion jusquau
carrousel de rcupration des bagages. Les bagages sont transports par des
chariots autonomes circulant sur des rails relis par des embranchements. Chaque
bagage est muni dune puce RFID permettant des capteurs de communiquer sa
position au systme. Les postes de supervision affichent des vues sur lensemble du
systme de transport avec la position des chariots et des bagages, ltat des lments
(panne, batterie dcharge...).
(...)
A lenregistrement, chaque bagage est pos sur un tapis roulant qui lachemine
jusque sur un chariot. Le chariot circule sur des rails de faon autonome jusquau
toboggan de destination ( chaque embranchement, il choisit son chemin).
(...)
A larrive dun avion, les bagages sont achemins par un train jusqu un tapis
roulant sur lequel ils sont dposs un un par un oprateur. Le tapis roulant
achemine chaque bagage jusque sur un chariot qui circule ensuite de faon
autonome jusquau carroussel de rcupration des bagages.
(...)
43/106
Buts et Artefacts
Buts
systme
Artefacts
du mtier
Glossaire

fonctionnels
Modle des cas

dutilisation

Exigences
supplmentaires
44/106
Cas dutilisation (1/2)

Quest-ce quun cas dutilisation ?
Usage quun acteur (entit extrieure) fait du systme
Squence dinteractions entre le systme et les acteurs
Gnralement compos de plusieurs scnarios (instances)
Scnario de base et ses variantes (
cas particuliers)
Pourquoi des cas dutilisation ?

Procd simple permettant au client de dcrire ses besoins
Parvenir un accord (contrat) entre clients et dveloppeurs
Point dentre pour les tapes suivantes du dveloppement
Conception et implmentation
Ralisation de cas dutilisation
Tests fonctionnels
Scnarios de cas dutilisation
45/106
Cas dutilisation (2/2)

Comment dcouvrir les cas dutilisation ?
Dlimiter le systme
Identifier les acteurs principaux
Ceux qui atteignent un but en utilisant le systme
Identifier les buts de chaque acteur principal
Dfinir les cas dutilisation correspondant ces buts
Atelier dexpression des besoins runissant clients, utilisateurs, analystes,
dveloppeurs et architectes
Comment dcrire les cas dutilisation ?
Modle des cas dutilisation :
Diagramme des cas dutilisation
Descriptions textuelles des cas dutilisation
Diagrammes de squence systme des cas dutilisation
46/106
Diagramme des cas dutilisation (rappel 3IF)

Relations entre cas dutilisation et acteurs
Systme XXX
Limites du systme
nom du systme
Client
Traiter une vente
Ouvrir la caisse
Caissier
<<actor>>
Service
dautorisation
des paiements
<<actor>>
Systme des
ressources
humaines
Traiter un retour
notation alternative
pour un acteur
Communication
acteur
Grant
Grer la scurit
cas dutilisation
Administrateur systme
47/106
Relations entre cas dutilisation (rappel 3IF)

Gnralisation : B
Inclusion : - - - - - include - - - - - >
Extension : - - - - - extend - - - - - > (prciser la condition)
A utiliser avec la plus grande modration
Systme XXX
Faire un virement
Client local
<<tend>>
montant > 500 euros
<<inclut>>
Faire un virement par internet
Vrifier solde compte
Identifier client
Client distant
48/106
Description textuelle abrge dun cas dutilisation
Scnario de base dcrit en un paragraphe

Histoire dun acteur qui utilise le systme pour atteindre un but
Exemple : Description abrge de Traiter une vente"
Le caissier utilise le systme pour enregistrer les articles quun client souhaite
acheter. Le systme affiche le dtail des articles et le montant total des
achats, hors taxe et avec taxe. Le client fournit les informations ncessaires
pour le rglement. Le systme valide et enregistre ces informations, puis met
jour les quantits en stock et imprime le ticket de caisse destin au client.
49/106
Description textuelle structure dun cas dutilisation
Martin Fowler :
There is no standard way to write the content of a use case, and different
formats work well in different cases.
Structuration propose par Martin Fowler :
Titre : But que lacteur principal souhaite atteindre avec ce cas
dutilisation
Verbe linfinitif suivi dun complment dobjet
Scnario de base : Liste numrote dinteractions entre les acteurs et le
systme
Extensions : Une liste numrote dinteractions pour chaque cas
particulier possible
50/106
Exemple de description structure dun cas dutilisation

Titre = Traiter une vente
Scnario de base =
1
2
3
Le Caissier indique au systme quil commence une nouvelle saisie

Le Caissier entre le code dun article et une quantit
Le Systme affiche le prix de larticle et le total en cours HT et TTC
Rptition des tapes 2 et 3 jusqu ce que tous les articles soient saisis
4
5
6
Le Systme affiche le total final HT et TTC

Le Caissier slectionne un mode de paiement
...
Extensions :
2a. Le code de larticle est invalide
1
2
3
4
Le Systme signale lerreur et rejette la saisie

Sil existe un code lisible par un tre humain, alors ...
Sinon si le prix est sur larticle, alors ...
...
2b. La quantit saisie est ngative

...
51/106
Diag. de squence systme dun cas dutilisation (rappel 3IF)

Reprsentation graphique dun scnario dun cas dutilisation
: Systme
: Caissier
crerNouvelleVente()
loop [reste des articles]
saisirArticle(codeArt,Qte)
description, total
terminerVente()
total HT et TTC
crerPaiement(montant)
rendu de la monnaie, reu
52/106
Modlisation itrative des cas dutilisation

Le modle des cas dutilisation volue au fil des phases et des itrations :
Itration 1 / Phase dinception :
La plupart des cas sont identifis
Environ 10% des cas sont analyss
Cas les plus significatifs / risqus / importants
Itration 2 / Phase dlaboration :
Environ 30% des cas sont analyss
Conception des cas les plus significatifs / risqus / importants
Implmentation de ces cas
Premier feed-back et premire estimation des cots du projet
Itrations suivantes de la phase dlaboration :
Analyse dtaille de quelques nouveaux cas
Conception et implmentation de nouveaux cas
Dernire itration de la phase dlaboration :
Quasiment tous les cas sont identifis
de 40 80% des cas sont analyss
Les cas les plus significatifs / risqus / importants sont implments
Architecture stabilise et projet planifi
53/106
Cas dutilisation dans les mthodes Agiles ?
User story :
Courte description dune utilisation du logiciel
Potentiellement incomplte ou imprcise
Description informelle dun cas dutilisation, mais pas ncessairement en
termes dinteractions avec le systme
54/106
Au travail !
Extrait du projet donn en 2011 : Gestion des bagages dun aroport
Scnarios et diagrammes de squence systme des cas :

Ajouter manuellement un bagage
Faire avancer la simulation
55/106
Buts et Artefacts
Buts
systme
Artefacts
du mtier
Glossaire

fonctionnels
Modle des cas

dutilisation

Exigences
supplmentaires
56/106
But Apprhender les besoins non fonctionnels"

Exigences supplmentaires :
Certains besoins non fonctionnels sont dj dans les cas dutilisation
Les regrouper pour viter les doublons
Lister galement ceux qui ne sont pas dans les cas dutilisation
Liste pour recenser les besoins : FURPS+
Functionality : Fonctions, capacits, scurit
Usability : Facteurs humains, aide, documentation
Reliability : Frquence des pannes, possibilit de rcupration
Performance : Temps de rponse, dbit, exactitude, ressources
Supportability : Adaptabilit, maintenance, configurabilit
+ : Facteurs complmentaires
Langages et outils, matriel, etc
Contraintes dinterfaage avec des systmes externes
Aspects juridiques, licence
...
57/106
Autres artefacts de la capture et lanalyse des besoins

Vision
Vue globale synthtique du projet
Rsum des cas dutilisation et exigences supplmentaires
Maquette de lIHM
Uniquement si IHM complexe
Validation du client
Tableau des facteurs architecturaux
Rcapitulatif des facteurs pouvant influer sur larchitecture :
Points de variation et dvolution
Fiabilit et possibilits de rcupration
Performance
...
Evaluer les impacts, la priorit et les difficults/risques
58/106
Activit Conception"
Plan du cours
Introduction

Activit Conception"
Gestion de projet
59/106
Activit Conception"
Conception
Objectif premier de la modlisation pendant la conception :
Comprendre et communiquer :
Quelles sont les responsabilits des objets ?
Quelles sont les collaborations entre objets ?
Quels patterns de conception peut-on utiliser ?
La doc. peut tre gnre partir du code (reverse engineering)
Modlisation Agile
Modliser en groupe
Crer plusieurs modles en parallle
Diagrammes dynamiques (interactions)
Diagrammes statiques (classes, packages et dploiement)
Concevoir avec les programmeurs et non pour eux !
60/106
Activit Conception"
Buts et Artefacts
Buts
Artefacts
Apprhender la logique
comportementale (interactions
entre objets)
Diagrammes dinteraction
structurelle
Diagrammes de classes,
de packages et de
dploiement
Documenter larchitecture
Document darchitecture
du logiciel (N+1 vues)
61/106
Activit Conception"
Diagrammes dinteraction (rappels de 3IF)

Point de vue temporel sur les interactions
Pendant la capture des besoins :

Interactions entre acteurs et systme (systme = boite noire)
Dcrire les scnarios des cas dutilisation
Pendant la conception :
Interactions entre objets ( lintrieur du systme)
Rflchir laffectation de responsabilits aux objets
Qui cre les objets ?
Qui permet daccder un objet ?
Quel objet reoit un message provenant de lIHM ?
...
de faon avoir un faible couplage et une forte cohsion
Elaboration en parallle avec les diagrammes de classes
Contrler la cohrence des diagrammes !
62/106
Activit Conception"
Diagrammes de squence vs diagrammes de communication

(rappels de 3IF)
Diagrammes de squence :
Diagrammes de communication :
Structuration en termes de
Structuration en multigraphe
temps
axe vertical
objets
axe horizontal
Numrotation des arcs pour

modliser lordre des interactions
Exemple :
Exemple :
o2:T2
o1:T1
1: ret1=msg1(p1)
o3:T3
o2:T2
o1:T1
msg1(p1)
msg2(p2)
ret2
msg3(p3)
ret1
ret3
1.1: ret2=msg2(p2)
1.2: ret3=msg3(p3)
o3:T3
63/106
Activit Conception"
Buts et Artefacts
Buts
Artefacts
entre objets)
structurelle
de packages et de
dploiement
64/106
Activit Conception"
Diagrammes de classes (rappel de 3IF)

Un diagramme de classes est un graphe :
Nud du graphe = Classe (abstraction dun ensemble dobjets)
Arc du graphe = Relation entre des classes :
Relation dassociation : A B ou A > B
Abstraction dun densemble de liens entre objets
Relation de gnralisation / spcialisation : A B B
Factorisation de proprits communes plusieurs classes
Relation de dpendance : A - - - - - - - - - - > B
La modification de B peut avoir un impact sur A
Trs nombreuses utilisations, diffrents niveaux :
Pendant la capture des besoins : Modle du domaine
Classes correspondant des objets du domaine
Pendant la conception/implmentation : Modle de conception
Classes correspondant des objets logiciels
Rduire le dcalage des reprsentations...
65/106
Activit Conception"
Liens entre diagrammes de classes et

dinteraction
[Figure extraite du livre de C. Larman]
66/106
Activit Conception"
Principes et patrons de conception OO (rappels de 3IF)

Objectif : Concevoir de bons modles orients objet
Faciles comprendre, mettre en uvre, maintenir et rutiliser
Principes de conception GRASP de Craig Larman
GRASP = General Responsability Assignment Software Patterns
Principes de base pour affecter des responsabilits aux objets :
Qui doit savoir ?
Qui doit faire ?
Patrons de conception (Design patterns) du GoF
GoF = Gang of Four : E. Gamma, R. Helm, R. Johnson, J. Vlissides
Catalogue de patrons
Description nomme de pb rcurrents et de solutions standards
Rutiliser des solutions avres
Faciliter le dialogue
Vocabulaire commun entre concepteurs et ralisateurs
67/106
Activit Conception"
Principes GRASP (rappels de 3IF)

Faible couplage :
Affecter les responsabilits de faon viter les couplages inutiles
Forte cohsion :
Faciliter la comprhension, gestion et rutilisation des objets en affectant leurs
proprits pour quils aient une forte cohsion
Polymorphisme :
Manipuler des instances de classes diffrentes de faon uniforme
Protection des variations :
Identifier les points de variation ou dvolution et crer une interface stable autour
Indirection :
Eviter le couplage entre diffrentes entits en ajoutant des objets intermdiaires
Fabrication pure :
Crer des objets logiciels ne correspondant pas des concepts du domaine pour
assurer Forte cohsion et Faible couplage
68/106
Activit Conception"
23 Patterns GoF (rappels de 3IF)

Patterns de cration
Abstract factory : Cration de familles dobjets
Singleton : Assurer quune classe a une seule instance accessible globalement
Factory method : Mthode charge de crer des instances
et aussi : Prototype, Builder
Patterns structuraux
Adapter : Fournir une interface stable un composant dont linterface peut varier
Decorator : Attacher dynamiquement des responsabilits un objet
Composite : Reprsenter des hirarchies et manipuler de faon uniforme
composants et composs
et aussi : Bridge, Facade, Flyweight, Proxy
Patterns comportementaux
Iterator : Accs aux lments dun agrgat indpendamment de limplmentation
Observer : Faire savoir des objets quun objet observable a t modifi
Command : Sparer le code lorigine dune action, du code de laction
et aussi : Visitor, Strategy, Chain of responsiblity, Interpreter, Mediator, Memento,
State, Template method
69/106
Activit Conception"
Diagrammes de packages et Architecture logique

(rappel 3IF)
Quest-ce quune architecture logique ?
Regroupement des classes logicielles en packages
Point de dpart pour un dcoupage en sous-systmes
Objectifs dun dcoupage en packages
Encapsuler et dcomposer la complexit
Faciliter le travail en quipe
Favoriser la rutilisation et lvolutivit
Forte cohsion, Faible couplage et Protection des variations
Utilisation dUML pour dcrire une architecture logique
Diagramme de packages :
Relations dimbrication entre classes et packages ou entre packages
Dpendances entre packages
70/106
Activit Conception"
Exemple darchitecture logique en couches
71/106
Activit Conception"
Patterns darchitectures logiques
Exemples de patterns architecturaux

Layers (stricte ou lche)
Prsentation, Application, Domaine, ServicesTech., ...
Pipes and filters
Multitiers
Model-View-Controller
Peer-to-peer
Blackboard
...
72/106
Activit Conception"
Au travail !
Exemple de simulation pour le projet de gestion des bagages dun aroport
Diagramme de squence modlisant les interactions entre objets pour

raliser le cas "Faire avancer la simulation"
Diagrammes de classes et de packages correspondants
73/106
Activit Conception"
Architecture de dploiement
Objectif
Dcrire :
la distribution des lments logiciels sur les composants physiques
la communication entre les composants physiques (rseau)
Utilisation de diagrammes de dploiement
Nuds physiques
dispositifs physiques (ordinateur, tlphone, ...)
Nuds denvironnement dexcution
Ressource logicielle :
sexcutant au sein dun nud physique
offrant un service pour hberger/excuter dautres logiciels
(par ex. : O.S., Machine virtuelle, Navigateur Web, SGBD, ...)
Liens
Moyens de communication entre les nuds
74/106
Activit Conception"
Exemple de diagramme de dploiement
75/106
Activit Conception"
Buts et Artefacts
Buts
Artefacts
entre objets)
structurelle
de packages et de
dploiement
76/106
Activit Conception"
4+1 vues architecturales [P. Kruchten 95]
[Figure extraite de wiki.cantara.no/display/dev/4+plus+1+View+Model]
77/106
Activit Conception"
Objectif : Dcrire les grandes lignes de larchitecture
Comprendre rapidement les ides essentielles du systme
Structure du Document dArchitecture du Logiciel
Reprsentation architecturale : Comment larchi. est dcrite dans ce doc.
Facteurs architecturaux : Rfrence au Tableau des facteurs
Dcisions architecturales : Ensemble de mmos techniques
Nom du problme
Rsum de la solution
Facteurs architecturaux concerns
Solution
Motivation
Problmes non rsolus
Autres solutions envisages
N+1 vues : Logique, Processus, Implmentation, Physique, ..., + Cas dutil.
Pour chaque vue :
Dcrire les modles les plus importants
Motiver et commenter les choix
78/106
Plan du cours
Introduction

Activit Conception"
Gestion de projet
79/106
De la conception la ralisation
Objectifs :
Ecrire le code implmentant les cas dutilisation cibls
Vrifier que ce code rpond bien aux besoins
Ordre dimplmentation des packages et classes :
Du moins coupl au plus coupl
Gnration automatique dun squelette de code
Diagrammes de classes
Dfinition des classes, attributs, signatures de mthodes, ...
Codage des associations 1-n par des collections
...
Diagrammes dinteraction :
Corps (partiel) des mthodes
Signature des constructeurs
80/106
Dveloppement itratif et Reverse engineering

Le squelette gnr automatiquement doit tre complt
Implmentation de la visibilit
Aptitude dun objet a envoyer un message un objet b
Visibilit persistante :
Visibilit dattribut : b est attribut de a
Visibilit globale : b est un Singleton
Visibilit temporaire :
Visibilit de paramtre : b est paramtre dune mthode de a
Visibilit locale : b est variable locale dune mthode de a
Traitement des exceptions et des erreurs

...
En gnral, il doit aussi tre modifi
Ajout de nouveaux attributs, mthodes, classes, ...
Utiliser des outils de reverse engineering la fin de litration
Mise--jour des modles de conception pour litration suivante
81/106
Dveloppement pilot par les tests (Test-Driven Dev.)

Pratique popularise par XP
Cycle de TDD :
Ecrire le code de tests unitaires
Excuter les tests
Echec !
Complter le code jusqu ce que les tests russissent

Implmentation la plus simple possible par rapport aux tests
Retravailler le code (refactor), et re-tester
Avantages
Les tests unitaires sont rellement crits ( !)
Satisfaction du programmeur :
Objectif clairement dfini... dfi relever !
Spcification du comportement des mthodes
Assurance lors des modifications
Automatisation et rptabilit du processus de test
Utilisation doutils (JUnit, CTest, ...)
82/106
Exemple dautomatisation des tests unitaires : JUnit

Principe de JUnit :
Cration dune classe TestXX pour tester la classe XX
Annotation des mthodes de TestXX :
@Test : mthode de test
@Before : mthode excute avant chaque mthode de test
@After : mthode excute aprs chaque mthode de test
@BeforeClass : mthode excute avant tous les tests
@AfterClass : mthode excute aprs tous les tests
Vrification dassertions dans les mthodes de test :
assertEquals(x,y) : vrifie que x et y ont la mme valeur
assertSame(x,y) : vrifie que x et y pointent sur le mme objet
assert(not)Null(o) : vrifie que o == Null (o != Null)
...
Ce que JUnit ne fournit pas :
Un moyen de gnrer un jeu de test
Une valuation de la couverture des tests ( cobertura)
83/106
Quelques conseils pour lcriture des tests...

Couvrir tous les cas possibles : cas moyens" (happy path tests), cas
invalides, cas limites, ...
Ecrire des tests simples... qui nont pas besoin dtre tests !
Ajouter une procdure de test chaque fois quun bug est dcouvert
Eviter (proscrire ?) les effets de bord dans les procdures de test
Tester le contrat et non limplmentation
Pile p = new Pile();
Object o1 = new Object();
Object o2 = new Object():
p.empile(o1);
p.empile(o2);
assertEquals(o2,o.depile());
assertEquals(o1,o.depile());
assertTrue(p.estVide());
Pile p = new Pile();

Object o = new Object();
p.empile(o);
List l = p.getElts();
assertEquals(1,l.size());
assertEquals(o,l.get(0));
p.depile();
assertTrue(p.estVide());
84/106
Refactoring rgulier
Objectif :
Transformer/restructurer du code sans en modifier le comportement
Supprimer les code smells"
Attention : re-excuter les tests aprs chaque tape
Transformations par tapes
Eliminer la duplication de code
Amliorer la lisibilit
Cration de procdures
Renommer
Assurer le principe de responsabilit unique (single responsability)

Raccourcir les mthodes trop longues
Supprimer lemploi des constantes codes en dur
Rduire le nombre de variables dinstance dune classe
Renforcer lencapsulation
...
cf http://refactoring.com/catalog
85/106
Transparents emprunts Laurent Cottereau
86/106
Gestion de projet
Plan du cours
Introduction

Activit Conception"
Gestion de projet
87/106
Gestion de projet
Gestion de projet
Gestion des versions
Structurer les artefacts par discipline
un rpertoire / discipline
(sauf implmentation qui est parfois sur plusieurs rpertoires)
Utiliser un outil de gestion de versions / travail collaboratif (Git, SVN, ...)
Crer un point de contrle la fin de chaque itration
Planification deux niveaux diffrents :
Plan de phase
Macro plan visible de lextrieur sur lequel lquipe sengage
Jalons et objectifs gnraux
Peu de jalons : fins de phases, tests pilotes" mi-phase
1re estimation peu fiable des jalons la fin de linception
Estimation fiable et contractuelle la fin de llaboration
Engagement de lquipe sur la livraison du projet
Plan ditration
Micro organisation interne dune itration
Le plan de litration n est fait la fin de litration n 1
Adapter les plans ditrations en fonction des volutions
88/106
Gestion de projet
Plan ditration
En fin ditr. n, planifier litr. n+1 avec toutes les parties prenantes :
Clients, Developpeurs, Architecte, Chef de projet, ...
Dterminer la dure de litration (en gnral de 2 6 semaines)
Lister les objectifs potentiels :
nouvelles fonctionnalits / cas dutilisation / scnarios de cas
dutilisation, traitement danomalies, ...
Classer les objectifs par ordre de priorit :
Obj. commerciaux du client / Obj. techniques de larchitecte
Pour chaque objectif pris par ordre de priorit :
Etudier rapidement lobjectif
Estimer les tches faire pour latteindre
Quantifier temps ncessaire / ressources humaines disponibles
Planning poker (http ://www.planningpoker.com/)
Jusqu ce que volume de travail total = dure de litration
Impliquer toute lquipe dans le processus de planification, et non juste le
chef de projet
89/106
Gestion de projet
Vue globale dune itration Agile
90/106
Phase 1 : Etude prliminaire (Inception)
Plan du cours
Introduction

91/106
Objectif : lancer le projet

tablir les contours du systme et spcifier sa porte
Estimer les risques les plus importants
Phase trs courte (1 itration)
A la fin de cette phase on dcide de continuer ou non
[Figure emprunte J.-L. Sourrouille]
92/106
Activits principales de ltude prliminaire

Comprendre le contexte du systme ( 50-70% du contexte)
Identifier les cas dutilisation ( 80%)
Identifier les besoins non fonctionnels ( 80%)
Dtailler et analyser les cas les plus importants ( 10%)
Mieux comprendre le systme raliser
Guider le choix de larchitecture
Analyse et Conception Orientes Objet
Ebaucher la conception architecturale
Architectures logique et de dploiement
Examen des aspects importants et plus haut risque
93/106
Livrables (potentiels) de ltude prliminaire
Liste des besoins potentiels

Premire version du modle du domaine / mtier
Liste ordonne de cas dutilisation (description abrge)
Description dtaille de quelques cas
Esquisse des architectures logique et de dploiement
Liste ordonne de risques
Premire estimation (peu fiable) des cots et dlais
Planification de la premire itration de llaboration
...
94/106
Plan du cours
Introduction

95/106
Objectif : Cerner le projet

Identifier et stabiliser les besoins
Attnuer ou liminer les risques majeurs
Planifier les phases du projet et estimer les cots
tablir les fondations de larchitecture
Raliser un squelette du systme
Phase courte : quelques itrations de quelques semaines
96/106
Activits principales de llaboration

Complter la liste des cas dutilisation
Description abrge de tous
Description dtaille / Diag. de squences de 40 80%
Faire un prototype de linterface utilisateur (ventuellement)
Stabiliser la conception architecturale
Architectures logique et de dploiement
Effectuer la conception des cas slectionns
Ralisation et test
Limits au squelette de larchitecture
Valider les choix
97/106
Livrables de llaboration
Modle du domaine / mtier quasi complet
Modle des cas dutilisation quasi complet
Modles de conception (diagrammes de classes et dinteractions,
diagramme de dploiement, ...) partiels
Architecture de base excutable
Implmentation de quelques fonctionnalits
Document darchitecture du logiciel / modles en cours
Planification des phases
valuation du cot du projet
...
98/106
Plan du cours
Introduction

99/106
Objectif : Raliser une version bta
100/106
Activits principales de la construction

Capture et Analyse des besoins
Spcifier linterface utilisateur (cf. cours IHM)
Terminer lanalyse de tous les cas dutilisation
Larchitecture est fixe
Concevoir les packages et classes pour raliser les cas
Selon lordre de priorit
Ralisation et Tests
Raliser et tester les cas, intgrer les incrments
101/106
Livrables de la construction
Un excutable
Tous les documents et les modles du systme
Document darchitecture du logiciel jour
Un manuel utilisateur suffisamment dtaill pour les tests
...
102/106
Plan du cours
Introduction

103/106
Objectif : Mise en service chez lutilisateur

Test de la bta-version, correction des erreurs
Prparer la formation, la commercialisation
104/106
Activits principales de la transition

Prparer la version bta tester
Installer la version sur le site, convertir et faire migrer les donnes
ncessaires...
Grer le retour des sites
Le systme fait-il ce qui tait attendu ?
Erreurs dcouvertes ?
...
Adapter le produit corrig aux contextes utilisateurs (installation...)
Terminer les livrables du projet (modles, documents...)
Dterminer la fin du projet
Reporter la correction des erreurs trop importantes
...
Planifier le prochain cycle de dveloppement ! ?
105/106
Livrables de la transition
Lexcutable et son programme dinstallation

Les documents lgaux : contrat, licences, garanties...
Un jeu complet de documents de dveloppement jour
Les manuels utilisateur, administrateur et oprateur et le matriel
denseignement
Les rfrences pour le support utilisateur (site Web...)
...
106/106

Cours USDP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cours USDP

Uploaded by

Copyright:

Available Formats

Mthodologie de Dveloppement Objet

Premire partie : Unified Software Development Process (USDP)

Ingnierie des IHM

Mthodologie de dvelopmt objet

Rfrentiel des comptences (1/2)

Concevoir un diagramme UML modlisant un objet dtude

Vrifier la cohrence de diffrents diagrammes modlisant un mme

Concevoir larchitecture dun logiciel orient objet

Utiliser des Design Patterns

Rfrentiel des comptences (2/2)

Mettre en uvre les principes du manifeste Agile

Rdiger un cahier des charges logiciel

Implmenter de bons logiciels

Inspir du projet de R&D OptimodLyon pilot par le Grand Lyon

Quelques livres emprunter DOCINSA

Prsentation gnrale dUSDP

Description dtaille des activits dune itration gnrique

Retour sur les phases

Etude du Standish Group (1/3)

Succs : livr temps, sans surcot et avec toutes les fonctionnalits

On progresse un peu... mais il reste de la marge pour samliorer !

Etude du Standish Group (2/3)

Petit projet : moins de 1 million de dollars

Etude du Standish Group (3/3)

Manque dimplication de lutilisateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12,8%

Exigences et spcifications incompltes . . . . . . . . . . . . . . . . . . . . . . . . . . 12,3%

Changement des exigences et spcifications . . . . . . . . . . . . . . . . . . . . . 11,8%

Extrait des conclusions de ltude :

Etude de S. Ambler sur 173 projets en 2013

Quelques rappels (rapides) sur le contexte

Prsentation gnrale dUSDP

Description dtaille des activits dune itration gnrique

Retour sur les phases

Quelques rappels (rapides) sur le contexte

Quest-ce quun logiciel ?

Quelques rappels (rapides) sur le contexte

Quest-ce quun bon logiciel ?

besoins fonctionnels ou non fonctionnels

architecture, structuration, documentation, ...

cots de dveloppement + maintenance, dlais, succs ...

Pourquoi a ne le fait pas/plus ?

diagnostic, reproductibilit du pb, administration distance, ...

Quelques rappels (rapides) sur le contexte

Activits dun processus logiciel (rappel de 3IF) :

Capture des besoins

Quelques rappels (rapides) sur le contexte

Enchanements dactivits et Cycle de vie (rappel de 3IF)

Quelques rappels (rapides) sur le contexte

Quelques rappels (rapides) sur le contexte

Le manifeste Agile (2001) www.agilealliance.com

Quelques rappels (rapides) sur le contexte

Quelques principes (choisis) du manifeste Agile

Prsentation gnrale dUSDP

Vue densemble du processus

Prsentation gnrale dUSDP

Description dtaille des activits dune itration gnrique

Retour sur les phases

Prsentation gnrale dUSDP

Vue densemble du processus

Vue globale de la vie dun logiciel avec USDP

Prsentation gnrale dUSDP

Vue densemble du processus

Vue graphique dun cycle avec USDP