You are on page 1of 34

Master 1/ISI 1

Le Processus Unifié de Développement Logiciel:


Une Démarche Orientée Modèle

Afef Awadid
Centre de Recherche en Informatique
Université Paris 1 – Panthéon Sorbonne
afef.awadid@univ-paris1.fr

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 2

Présentation
• Bibliographie
• Le processus unifié de développement logiciel: Ivar Jacobson,
Grady Booch, James Rumbaugh
• UML 2 et les design patterns Craig Larman
• Cours “PLD Agile” (Christine Solnon)- INSA de Lyon - 4IF - 2016 /
2017
• Les cours IBM sur le RUP
• Processus de conception de SI M1 MIAGE - SIMA - 2005-2006
Yannick Prié UFR Informatique - Université Claude Bernard Lyon 1
• Processus Unifié Unified Software Development Process / Unified
Process (UP) (M. Blay-Fornarino)
• Le Processus unifié Une démarche orienté modèle IUP NTIE -
Master 1 - Jérémie Guiochet -
• P. Kroll et P. Kruchten, Guide pratique du RUP, CampussPress, 2003
• P. Kruchten, Introduction au Rational Unified Process, Eyrolles, 2000
• Craig Larman, Applying UML and patterns – An introduction to
object oriented analysis and design and the Unified Process,
Prentice Hall, 2004
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 3

Description du contexte

• Qu’est-ce qu’un logiciel?


• Ensemble d'artéfacts (entités) nécessaires au fonctionnement
d’un processus de traitement automatique de l'information. Cet
ensemble contient, entre autres, les codes (sources, binaires,
tests,…), la documentation pour l'utilisateur (manuel utilisateur,
manuel de référence, tutoriels,…) et la documentation interne
(cas d'utilisation, modèle du domaine, diagrammes
d'interaction, diagrammes de classes,…)

• Le logiciel est conçu par et pour différents acteurs y compris les


utilisateurs et les programmeurs.

• Ilréalise une spécification: son comportement vérifie un


ensemble de critères qui régissent ses interactions avec son
environnement.

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 4

Description du contexte

• Qu’est-ce qu’un bon logiciel?


- Un bon logiciel peut être observé selon différents points de vue:
• L’utilisateur Ce que ça fait ?
~ Besoins fonctionnels ou non fonctionnels.
~ Besoins exprimés ou implicates, presents ou futurs,…

• Le programmeur Comment ça le fait ?


~ Architecture, structuration, documentation,…
• Le fournisseur Combien ça coûte/ rapporte ?
~ Coûts de développement + maintenance, délais, succès,…
• …
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 5

Description du contexte

• De quoi dépend la qualité d’un logiciel?


En plus du respect (essentiel) de sa spécification, la qualité d’un
logiciel dépend des 4 critères suivants :

• Maintenabilité: Peut-on faire évoluer le logiciel ?

• Robustesse: Le logiciel est-il sujet à des dysfonctionnements ?

• Efficacité: Le logiciel fait-il bon usage de ses ressources ?

• Utilisabilité: Est-il facile à utiliser ?

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 6

Description du contexte

• Qu’est-ce qu’un processus de développement


logiciel?
Un processus de développement logiciel est un ensemble (structuré)
d’activités que conduisent à la production d’un logiciel.

• Il n’existe pas de processus idéal.


• La plupart des entreprises adapte les processus existants à leurs
besoins.
• Ces besoins varient en fonction du domaine, des contraintes de
qualité, des personnes impliquées.
• Ce qui est essentiel, c’est de comprendre quel est son rôle dans
ce processus et d’en saisir les rouages.
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 7

Description du contexte

• Pourquoi utiliser un processus de développement


logiciel?
 Planifier les travaux d’une équipe

 Spécifier les artéfacts à réaliser

 Guider dans leurs tâches les développeurs

 Offrir des critères et des outils pour le suivi et l'évaluation

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 8

Description du contexte

• Activités du développement logiciel


1. La spécification du logiciel définit ses fonctionnalités et leurs
contraintes.
2. La conception …
3. …et l'implémentation sont chargées de réaliser le logiciel, en
conformité avec sa spécification.
4. La validation s'assure effectivement du respect de la
spécification par le logiciel produit.
5. L'évolution adapte le logiciel aux besoins futurs de ses clients.
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 9

Description du contexte

• Schéma général d’un processus de développement

 Il est très rare d’appliquer un processus comme une unique


séquence des 5 activités précédentes.

 En général, un logiciel complet est le fruit de plusieurs itérations.

 Chaque itération contient les 5 activités de spécification,


conception, implémentation, validation et évolution.

 Il existe différents modèles de processus qui organisent de façon


différentes ces activités, entre eux : le modèle en cascade, le
modèle de développement évolutif et le modèle de
développement par composants.

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 10

Description du contexte
• Modèle en cascade
Définition
des besoins

Conception

Implémentation
et tests unitaires

Intégration et
test du système

Livraison et
maintenance

 Chaque phase doit se terminer pour commencer la suivante.


 Des documents sont produits pour concrétiser la réalisation de chaque
phase.
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 11

Description du contexte
• Modèle en cascade — caractéristiques
• Le modèle en cascade est hérité des méthodes classiques
d’ingénierie.
 Il s’adapte donc bien dans un contexte où le logiciel fait partie
d’un système complexe englobant.
• La production de documents entre chaque phase améliore le suivi
du projet.
• Lorsqu’une erreur a été commise dans une phase et qu’elle est
détectée dans une phase suivante, il faut faire remonter cette
information dans la phase incriminée et recommencer le processus à
partir de celle-ci. On doit alors reproduire de nouveaux documents…
• Ce modèle de processus impose donc une importante réflexion sur
les choix faits en amont car le coût de la correction d’une erreur est
important.
 Typique d’un développement industriel pour lequel les coûts de la
construction du produit sont trop importants pour se permettre une
erreur de choix de conception.

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 12

Description du contexte
• Modèle en cascade — critique

 Le modèle en cascade rend coûteux le développement itératif


puisque la rédaction des documents de validation de chaque
phase demande beaucoup de travail.

 Ce modèle est inadapté au développement de systèmes dont


la spécification est difficile à formuler à priori.
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 13

Description du contexte
• Modèle de développement évolutif

Spécification

Développement

Validation

 Ces trois activités sont entrelacées.

 Un prototype est écrit rapidement et est confronté à l’utilisateur.

 En fonction du résultat, on raffine la spécification.

 On reprend le prototype ou on le réécrit jusqu’à l’obtention du


système final.

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 14

Description du contexte
• Modèle de développement évolutif — caractéristiques
• Ce modèle augmente les chances de répondre aux besoins de
l’utilisateur car il permet de les comprendre plus rapidement.
 Are we building the right product ?

• Il remplit le critère d’incrémentalité.

• Ce modèle ne dispense d’écrire la spécification du système car il faut


s’assurer que l’implémentation est correct.
 Are we building the product right ?

• C’est un processus particulièrement adapté aux projets de taille


moyenne (inférieur à 100 000 lignes de code) comme par exemple des
grosses applications Web ou encore les solutions intégrées pour les
petites entreprises.
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 15

Description du contexte
• Modèle de développement évolutif — critique
• Il est plus difficile de gérer un projet utilisant ce modèle car la visibilité
de l’avancement du développement est peu clair.
 Dans ce cadre, encore plus que dans un autre, un chef de projet
doit aussi être un bon programmeur puisqu’il doit être capable de se
faire une idée de l’état du système en observant le développement
(possiblement chaotique) des prototypes.

• Il est difficile de structurer correctement le logiciel (définir de bonnes


abstractions, modulariser efficacement) car les prototypes sont par
définition des produits “bricolés”.

• Le coût en termes de tests et de validation du produit final peuvent


être très importants.
 Des approches mixtes intégrant modèle de développement évolutif
pour produire un premier prototype validé et un modèle en
cascade pour reconstruire correctement un produit final constituent
en général de bons compromis.

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 16

Description du contexte
• Modèle de développement à livraison incrémentale
Spécification 1ère version

Versions
Développement
intermédiaires

Validation Version finale

• Une approche à mi-chemin entre les modèles cascade et


évolutif s’appuie sur une livraison incrémentale du produit.
 On hiérarchise les besoins du client en termes de priorité.
 Chaque itération du modèle vise à obtenir un ensemble de
fonctionnalités par ordre de priorité.
 Traiter les parties les plus critiques du système en premier
minimise les risques d’inadéquation avec le produit final.
 Cependant, il se peut que les choix pris en amont, trop
focalisés sur ce noyau de fonctionnalités, compromettent le
développement des fonctionnalités secondaires.
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 17

Description du contexte
• Modèle de développement par composants

Définition des besoins

Analyse des composants

Modification des besoins

Conception pas réutilisation

Développement et intégration

Validation du système

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 18

Description du contexte
• Modèle de développement par composants-
caractéristiques
• Ce modèle vise à développer un logiciel en grande partie à l’aide
d’une base de composants génériques pré-existants.
• L’élaboration de la spécification est dirigée par cette base : une
fonctionnalité est proposée à l’utilisateur en fonction de sa facilité à
l’obtenir à l’aide d’un composant existant.

 Situation typique chez les sociétés de services (hébergement de


serveurs, déploiement automatique de site Web, . . . ).
• Ce modèle permet d’obtenir rapidement des produits de bonne
qualité puisqu’ils sont construits à partir de composants qui ont fait leur
preuve.
• Le travail d’intégration peut s’appuyer sur des outils dirigés par des
descriptions de haut niveau du système qui génèrent le code de “glue”
par exemple.
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 19

Description du contexte
• Modèle de développement par composants- critique

• Le principal défaut de ce modèle est de ne pas


construire un produit adapté aux besoins du client.

 Un travail complexe de configuration et d’adaptation


peut être nécessaire.

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 20

Description du contexte
• Modèle de développement itératif et incrémental: Le
Processus Unifié (PU)
• (1997) UP : Rumbaugh, Booch, Jacobson (les concepteurs d’UML)

 une trame commune des meilleures pratiques de developpement


(pas une méthode)

 Issu des travaux de l’Object Management Group et de Rational

 Plusieurs variantes (RUP,UPEDU,…) toutes intégrant l’UML


M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 21

L'essentiel du Processus Unifié


• Qu’est ce que le Processus Unifié ?

 Le Processus Unifié ou UP (Unified Process) est une méthode


générique de développement logiciel développée par les
concepteurs d’UML
 Générique signifie qu'il est nécessaire d'adapter UP au
contexte du projet, de l'équipe, du domaine et/ou de
l'organisation.
 Il existe donc un certain nombre de méthodes issues
de UP comme par exemple RUP (Rational Unified
Process), 2TUP (Two Track Unified Process)
 Ce processus utilise le langage UML
 Il existe d’autres approches (qui ne sont en général
pas complètement antinomique), comme par ex. les
méthodes « agile », beaucoup moins orientées
modèle, comme XP (eXtreme Programming)

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 22

L'essentiel du Processus Unifié


• Qu’est ce que le Processus Unifié ?

 Le processus unifié permet d’affecter des tâches et des


responsabilités au sein d’une organisation de développement
logiciel.
 Approche disciplinée pour des gros projets (chef de projet,
analystes, intégrateur, intervenants, etc.)
 Approche à adapter pour des petits projets
 Pas particulièrement conçu pour le développement de
systèmes embarqués
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 23

L'essentiel du Processus Unifié


• Caractéristiques d’un PU

Piloté par
les cas
d'utilisation

Itératif et Processus Centré sur


incrémental Unifié l'architecture

Basé sur
UML

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 24

L'essentiel du Processus Unifié


• Caractéristiques d’un PU: Piloté par les cas d'utilisation

 Le processus de développement est centré sur l'utilisateur


M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 25

L'essentiel du Processus Unifié


• Caractéristiques d’un PU: Piloté par les cas d'utilisation

 Les cas d'utilisation décrivent les interactions entre les acteurs et


le système
~ Scénarios d’utilisation compréhensibles par tous
 Permettent de capturer les vrais besoins des utilisateurs
~ Réfléchir en termes d’acteurs et de buts plus que de
fonctionnalités
 Guident tout le processus de développement
~ Garantissent la cohérence du processus
 Favorisent un développement itératif
~ Chaque itération est centrée sur un sous-ensemble de cas

http://www.entreprise-agile.com/HistoAgile.pdf

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 26

L'essentiel du Processus Unifié


• Caractéristiques d’un PU: Itératif et incrémental
 Itération = mini projet donnant lieu à un incrément

http://www.entreprise-agile.com/HistoAgile.pdf
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 27

L'essentiel du Processus Unifié


• Caractéristiques d’un PU: Itératif et incrémental
 Itération = mini projet donnant lieu à un incrément

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 28

L'essentiel du Processus Unifié


• Caractéristiques d’un PU: Itératif et incrémental
 Ordonnancement des itérations basé sur les priorités entre cas
d'utilisation et sur l'étude du risque
 Une itération est une séquence d’activités
 Une itération se décompose en:

 Une planification de l’itération

 Analyse des besoins (raffinement)

 Analyse et conception

 Implémentation et tests

 Évaluation

 Livraison
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 29

L'essentiel du Processus Unifié


• Caractéristiques d’un PU: Itératif et incrémental
Avantages d’un processus itératif et incrémental

 Gestion des risques importants lors des premières itérations


 Construire et stabiliser le noyau architectural rapidement
Feed-back régulier des utilisateurs
 Adaptation permanente du système aux besoins réels
 Feed-back régulier des développeurs et des tests
 Affiner la conception et les modèles Complexité mieux
gérée
 Etapes plus courtes et moins complexes
 Exploitation des erreurs des itérations précédentes
 Amélioration du processus d’une itération sur l’autre

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 30

L'essentiel du Processus Unifié


• Caractéristiques d’un PU: Centré sur l’architecture

 Au sens de RUP (Rational Unified Process), une architecture :


 Sert à comprendre le système lorsqu’il est complexe
 Pilote le projet en découpant les tâches
 Favorise la réutilisation

Software architecture is not only concerned with structure and behavior,


but also with usage, functionality, performance, resilience, reuse,
comprehensibility, economic and technological constraints and tradeoffs,
and esthetics. (RUP, 98)-

A Technical Architecture is the minimal set of rules governing the


arrangement, interaction, and interdependence of the parts or elements that
together may be used to form an information system. (U.S. Army 1996)
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 31

L'essentiel du Processus Unifié


• Caractéristiques d’un PU: Centré sur l’architecture
Quelques axes pour considérer l’architecture
 Architectures client/serveurs en niveaux
 aussi appelés tiers
 Architectures en couches
 Présentation, Application, Domaine/métier, Infrastructure
métier (services métiers de bas-niveau), Services
techniques (ex. sécurité),
 Fondation (ex. accès et stockage des données)
 Architectures en zones de déploiement
 déploiement des fonctions sur les postes de travail des
utilisateurs (entreprise : central/départemental/local)
 Architectures à base de composants
 réutilisation de composants

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 32

L'essentiel du Processus Unifié


• Vue globale de la vie d’un logiciel avec UP
 La vie d’un logiciel est composée de cycles;
 1 cycle ⇒ 1 nouvelle version du logiciel;
 Chaque cycle est composé de 4 phases :
 Etude préliminaire (Initialisation ou Inception)
 Elaboration
 Construction
 Transition
 Chaque phase d’un cycle est composée d’itérations
 1 itération ⇒ 1 incrément
 Chaque itération est une mini cascade d’activités
 Capture (spécification) des besoins
 Analyse
 Conception
 Réalisation
 Test et intégration
...en proportions variables en fonction du temps
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 33

L'essentiel du Processus Unifié


• Vue graphique d’un cycle avec UP

[Figure extraite du livre de C. Larman]

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 34

La structure logique du Processus Unifié


M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 35

La structure logique du Processus Unifié


• Les quatre phases

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 36

La structure logique du Processus Unifié


• Phase 1: Etude préliminaire (Inception)

 Phase très courte (souvent une seule itération)


 Etape préliminaire à l’élaboration
 Permet de déterminer la faisabilité, les risques et le périmètre du
projet

 Que doit faire le système ?

 A quoi pourrait ressembler l’architecture ?

 Quels sont les risques ?

 Estimation approximative des coûts et des délais

~ Accepter le projet ?
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 37

La structure logique du Processus Unifié


• Phase 2: Elaboration
 Quelques itérations courtes et de durée fixe, pilotées par les
risques
 Identification et stabilisation de la plupart des besoins
 Spécification de la plupart des cas d’utilisation
 Conception de l’architecture de base
 Squelette du système à réaliser
 Programmation et test des éléments d’architecture les +
importants
 Réalisation des cas d’utilisation critiques (<10% des
besoins)
 Tester au plus tôt, souvent et de manière réaliste
 Estimation fiable du calendrier et des coûts

Besoins et architecture stables ? Risques contrôlés ?

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 38

La structure logique du Processus Unifié


• Phase 3: Construction

 Phase la plus coûteuse (>50% du cycle)


 Développement par incréments
 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é ?


M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 39

La structure logique du Processus Unifié


• Phase 4: Transition

 Produit délivré (version béta)


 Correction du reliquat d’erreurs
 Essai et amélioration du produit, formation des utilisateurs,
installation de l’assistance en ligne...

~ Tests suffisants ? Produit satisfaisant ? Manuels prêts ?

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 40

La structure logique du Processus Unifié

 Les jalons correspondent a des étapes d’évaluation de la phase terminée,


et de lancement de la phase suivante
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 41

La structure logique du Processus Unifié


• Les activités d’une itération: Vue globale

 Les activités d’une itération présentées dans ce schéma peuvent


varier en fonction du projet. Par exemple, les deux premières
peuvent être fusionnées en une seule.
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 42

La structure logique du Processus Unifié


• Activité 1: Modélisation métier

 Comprendre les problèmes posés dans le contexte de


l’organisation
 Compréhension de la structure et la dynamique de l’organisation
 Buts:

 Comprendre le contexte du système.


 Artéfacts/ Livrables:

 Modèle du domaine

 Modèle du métier

 Glossaire
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 43

La structure logique du Processus Unifié


• Activité 1: Modélisation métier
Modèle du domaine
Qu’est-ce qu’un modèle du domaine ?
Diagramme de classes conceptuelles (objets du monde réel)
~ Peu d’attributs, pas d’opération, pas de classes logicielles

Comment construire un modèle du domaine ?


Réutiliser (et modifier) des modèles existants ! Utiliser une
liste de catégories :
Classes : Transactions métier, Lignes de transactions, Produits/services liés
aux transactions, Acteurs, Lieux, ...
Associations : est-une-description-de, est-membre-de, ...
Identifier les noms et groupes nominaux des descriptions textuelles

Modélisation itérative et agile


Objectifs : Comprendre les concepts clés et leurs relations... et communiquer !
Il n’existe pas de modèle du domaine exhaustif et correct Le
modèle du domaine évolue sur plusieurs itérations Travailler en
mode “esquisse"

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 44

La structure logique du Processus Unifié


• Activité 1: Modélisation métier
Modèle du domaine: exemple

Modèle du domaine de PlaCo


Une scierie, équipée d’une machine de découpe de planches au laser, veut un système
pour dessiner les plans à transmettre à la machine.
Chaque plan a une hauteur et une largeur.
Les formes à positionner sur le plan sont des rectangles et des cercles :

un rectangle est défini par les coordonnées de son coin supérieur gauche, sa
largeur et sa hauteur ;
un cercle est défini par son rayon et les coordonnées de son centre.
Les coordonnées et les longueurs sont des valeurs entières exprimées dans une
unité donnée. Les formes ne doivent pas se superposer.
L’application doit permettre d’ajouter, supprimer et déplacer des formes sur un plan, de
sauvegarder et charger des plans, et de transmettre un plan au système de découpe.
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 45

La structure logique du Processus Unifié


• Activité 1: Modélisation métier
Modèle du domaine de PlaCo

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 46

La structure logique du Processus Unifié


• Activité 1: Modélisation métier

Modèle d’objets métier (Business Object Model)


Modèle plus général que le modèle du domaine
Abstraction de la façon dont les travailleurs et les entités métier doivent être mis en
relation, et de la façon dont ils doivent collaborer afin d’accomplir une activité
~ Diagrammes de classe, d’activité, de collaboration et de séquence

Glossaire
Définit les termes les plus importants
~ Evite les ambigüités
Dérivé des cas d’utilisation et modèles du domaine et du métier
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 47

La structure logique du Processus Unifié


• Activité 2: Recueil et expression des besoins

 Buts:

 Appréhender les besoins fonctionnels, non fonctionnels et


architecturaux.
 Artéfacts/ Livrables:

 Modèle des cas d’utilisation (diagramme de cas


d’utilisation + description textuelle et diagramme de
séquence des cas d’utilisation les plus significatifs)

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 48

La structure logique du Processus Unifié


• Activité 2: Recueil et expression des besoins
Cette activité est basée sur un concept clé: le cas d’utilisation
Qu’est-ce qu’un cas d’utilisation ?
Usage qu’un acteur (entité extérieure) fait du système
~ Séquence d’interactions entre le système et les acteurs
Généralement composé de plusieurs scénarios
~ Scénario de base et ses variantes (cas particuliers)
Attention : Système = boite noire

~ Décrire ce que fait le système, et non comment il le fait

Pourquoi des cas d’utilisation ?

Procédé simple permettant au client de décrire ses besoins Parvenir à un accord


(contrat) entre clients et développeurs
Point d’entrée pour les étapes suivantes du développement Conception et
implémentation ~ Réalisation de cas d’utilisation Tests fonctionnels ~ Scénarios de cas
d’utilisation
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 49

La structure logique du Processus Unifié


• Activité 2: Recueil et expression des besoins
Modèle de cas d’utilisation: 1. Diagramme de cas d’utilisation

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 50

La structure logique du Processus Unifié


• Activité 2: Recueil et expression des besoins
Modèle de cas d’utilisation: 2. Description textuelle d’un cas
d’utilisation
Chaque cas est décrit par un ensemble de scénarios
Un scénario de base (main success scenario)
Des extensions (une pour chaque cas particulier possible)
Qu’est-ce qu’un scénario ?
Séquence d’interactions entre les acteurs et le système
Description d’un scénario
Description abrégée : scénario de base décrit en un paragraphe
~ Histoire d’un acteur qui utilise le système pour atteindre un but
Description structurée (selon Martin Fowler) :
Titre : But que l’acteur principal souhaite atteindre avec ce cas
~ Verbe à l’infinitif suivi d’un complément d’objet Préconditions : Conditions
d’activation du cas (optionnel)
Scénario de base : Liste d’interactions entre acteurs et système
Extensions : Une liste d’interactions pour chaque cas particulier
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 51

La structure logique du Processus Unifié


• Activité 2: Recueil et expression des besoins
Modèle de cas d’utilisation: 2. Description textuelle de “Ajouter
un rectangle” (1/2)
Description abrégée :
Le technicien saisit les coordonnées des deux angles opposés du rectangle. Le rectangle
est ajouté dans le plan.
Description structurée :
Précondition : un plan est chargé
Scénario principal :

- Le système demande de saisir les coordonnées d’un angle du rectangle


- Le technicien saisit les coordonnées d’un point p1
- Le système demande de saisir les coordonnées de l’angle opposé
- Le technicien saisit les coordonnées d’un point p2
- Le système ajoute le rectangle correspondant dans le plan et affiche le plan

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 52

La structure logique du Processus Unifié


• Activité 2: Recueil et expression des besoins
Modèle de cas d’utilisation: 2. Description textuelle de
“Ajouter un rectangle” (2/2)
Description structurée (suite) :
Alternatives :
2a: Le point p1 n’appartient pas au plan
Le système indique que p1 n’est pas valide et retourne à l’étape 1
2b: Le point p1 appartient à une forme du plan
Le système indique que p1 n’est pas valide et retourne à l’étape 1
4a: Le point p2 n’appartient pas au plan
Le système indique que p2 n’est pas valide et retourne à l’étape 3
4b: Le rectangle défini par (p1, p2) a une intersection non vide avec une forme du plan
Le système indique que p2 n’est pas valide et retourne à l’étape 3
1-4a: Le technicien indique au système qu’il souhaite annuler la saisie
Le système annule la saisie
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 53

La structure logique du Processus Unifié


• Activité 2: Recueil et expression des besoins
Modèle de cas d’utilisation: 3. Diagramme de séquence
système d’un cas d’utilisation
~ Représentation graphique d’un scénario d’un cas d’utilisation

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 54

La structure logique du Processus Unifié


• Activité 2: Recueil et expression des besoins
Modélisation itérative d’un cas d’utilisation
Le modèle des cas d’utilisation évolue au fil des phases et des itérations :
Itération 1 / Phase d’inception (initialisation) :
- La plupart des cas sont identifiés
- Environ 10% des cas sont analysés
~ Cas les plus significatifs / risqués / importants
Itération 2 / Phase d’élaboration :
- Environ 30% des cas sont analysés
- Conception des cas les plus significatifs / risqués / importants Implémentation de ces
cas
~ Premier feed-back et première estimation des coûts du projet Itérations suivantes de la
phase d’élaboration :
- Analyse détaillée de quelques nouveaux cas Conception et implémentation de
nouveaux cas
Dernière itération de la phase d’élaboration :
- Quasiment tous les cas sont identifiés de 40 à 80% des cas sont analysés
- Les cas les plus significatifs / risqués / importants sont implémentés
~ Architecture stabilisée et projet planifié
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 55

La structure logique du Processus Unifié


• Activité 2: Recueil et expression des besoins
Appréhender les besoins non fonctionnels

Exigences supplémentaires :
- Certains besoins non fonctionnels sont déjà dans les cas d’utilisation
~ Les regrouper pour éviter les doublons
- Lister également ceux qui ne sont pas dans les cas d’utilisation

Exemples de besoins non fonctionnels


Usability : Facteurs humains, aide, documentation
Reliability : Fréquence des pannes, possibilité de récupération
Performance : Temps de réponse, débit, exactitude, ressources
Supportability : Adaptabilité, maintenance, configurabilité

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 56

La structure logique du Processus Unifié


• Activité 3: Conception

Objectif premier de la modélisation pendant la conception :


 Appréhender les besoins fonctionnels, non fonctionnels et
architecturaux.
 Comprendre et communiquer :
 Quelles sont les responsabilités des objets ?
 Quelles sont les collaborations entre objets ?
 Quels patterns de conception peut-on utiliser ?
~ La doc. peut être générée à partir du code (reverse engineering)
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 57

La structure logique du Processus Unifié


• Activité 3: Conception

 Cette activité a pour buts:


 Appréhender la logique comportementale (interactions
entre objets) Diagrammes de séquence comme
artéfacts/ livrables.
 Appréhender la logique structurelle Diagrammes de
classes, de packages et de déploiement comme
artéfacts/ livrables de cette activité.

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 58

La structure logique du Processus Unifié


• Activité 3: Conception
Diagrammes de séquence
~ Point de vue temporel sur les interactions
Pendant la capture des besoins : Système = boite noire
~ Séquences d’interactions entre acteurs et système
Décrire les scénarios des cas d’utilisation

Pendant la conception : On ouvre la boite noire


~ Interactions entre objets du système
Réfléchir à l’affectation de responsabilités aux objets
Qui crée les objets ?
Qui permet d’accéder à un objet ?
Quel objet reçoit un message provenant de l’IHM ?
...
De façon à avoir un faible couplage et une forte cohésion
Elaboration en parallèle avec les diagrammes de classes
~ Contrôler la cohérence des diagrammes !
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 59

La structure logique du Processus Unifié


• Activité 3: Conception
Diagrammes de classes
Pendant la capture des besoins : Modèle du domaine
Classes = objets du mondes réels
Peu d’attributs, pas de méthodes, pas de visibilité
Pendant la conception : Modèle de conception
Classes = objets logiciels
Ajout de la visibilité, d’interfaces, de méthodes, d’attributs

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 60

La structure logique du Processus Unifié


• Activité 3: Conception
Liens entre diagrammes de séquences et de classes

[Figure extraite du livre de C. Larman]


M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 61

La structure logique du Processus Unifié


• Activité 3: Conception
Diagrammes de packages

Qu’est-ce qu’un diagramme de packages ?


Regroupement des classes logicielles en packages
~ Point de départ pour un découpage en sous-systèmes
Relations d’imbrication entre classes et packages ou entre packages
Relations de dépendances entre packages

Objectifs d’un découpage en packages


Encapsuler et décomposer la complexité
Faciliter le travail en équipe
Favoriser la réutilisation et l’évolutivité

Forte cohésion, Faible couplage et Protection des variations

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 62

La structure logique du Processus Unifié


• Activité 3: Conception
Ex. de diagramme de packages / archi. en couches
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 63

La structure logique du Processus Unifié


• Activité 3: Conception
Architecture de déploiement
Objectif
Décrire :
la distribution des éléments logiciels sur les composants physiques la communication entre les
composants physiques (réseau)
Utilisation de diagrammes de déploiement
Nœuds physiques
~ dispositifs physiques (ordinateur, téléphone, ...)
Nœuds d’environnement d’exécution
~ Ressource logicielle :
s’exécutant au sein d’un nœud physique
offrant un service pour héberger/exécuter d’autres logiciels (par ex. : O.S., Machine
virtuelle, Navigateur Web, SGBD, ...)
Liens
~ Moyens de communication entre les nœuds

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 64

La structure logique du Processus Unifié


• Activité 3: Conception
Exemple de diagramme de déploiement
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 65

La structure logique du Processus Unifié


• Activité 4: Réalisation et tests
Objectifs :
Ecrire le code implémentant les cas d’utilisation ciblés
Vérifier que ce code répond bien aux besoins

Ordre d’implémentation des packages et classes :


~ Du moins couplé au plus couplé

Génération automatique d’un squelette de code


Diagrammes de classes
Définition des classes, attributs, signatures de méthodes, ... Codage des associations 1-n
par des collections
...
Diagrammes d’interaction :
Corps (partiel) des méthodes Signature des constructeurs

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 66

La structure logique du Processus Unifié


• Activité 4: Réalisation et tests
Exemple d’automatisation des tests unitaires : Junit
Principe de JUnit :
Création d’une classe TestXXpour tester la classe XX

Annotation des méthodes de TestXX:


@Test: méthode de test
@Before: méthode exécutée avant chaque méthode de test
@After : méthode exécutée après chaque méthode de test
@BeforeClass : méthode exécutée avant tous les tests
@AfterClass: méthode exécutée après tous les tests
Vérification d’assertions dans les méthodes de test : assertEquals(x,y) : vérifie que
x et y ont la même valeur assertSame(x,y): vérifie que xet ypointent sur le
même objet
assert(not)Null(o): vérifie que o == Null(o!= Null)
...
M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 67

La structure logique du Processus Unifié


• Activité 5: Gestion de projet
Gestion des versions
Structurer les artéfacts par discipline ~ un répertoire / discipline (sauf implémentation
qui est parfois sur plusieurs répertoires)
Utiliser un outil de gestion de versions / travail collaboratif (Git, SVN, ...)
~ Créer un point de contrôle à la fin de chaque itération

Planification à deux niveaux différents :


Plan de phase
~ Macro plan visible de l’extérieur sur lequel l’équipe s’engage
Jalons et objectifs généraux
~ Peu de jalons : fins de phases, tests “pilotes" à mi-phase
1ère estimation peu fiable des jalons à la fin de l’inception
Estimation fiable et contractuelle à la fin de l’élaboration
~ Engagement de l’équipe sur la livraison du projet
Plan d’itération
~ Micro organisation interne d’une itération
Le plan de l’itération n est fait à la fin de l’itération n − 1
Adapter les plans d’itérations en fonction des évolutions

M1 MIAGE/ ISI1 - Modèles de l'ingénierie des SI 68