Modelisation agile 03122011

Modélisation Agile & UML

TogoJUG3 décembre 2011

Agnès CREPET@agnes_crepet

Objectifs de la session

Pas un cour UML!Pré-requis : connaître les principaux diagrammes UML

Pas d’expertise requise!

Plutôt un retour d’expérience de modélisation dans un contexte de projet « agile »Bonnes pratiques de modélisation. Quand utiliser quel diagramme?

Comprendre comment formulation des exigences, analyse, conception, implémentation et tests s’intègrent dans un processus de développement logiciel itératif

Perspective sur d’autres vecteurs de réussiteUML n’est pas la réponse à tous les problèmes de modélisation!

Qui suis-je?

Agnès CREPET

Java/JEE Architect

hooked on Agile

@duchessfr & @LyonJUG Leader

Curator of @mixIT_lyon conf & @cast_it podcast

Curator of www.avataria.org

Quelques rappels sur l'agilité

Modéliser et concevoir

Vers une modélisation agile

UML pragmatique & Retour d'expériences

Sommaire

Le manifeste des méthodes agiles

Le manifeste des méthodes agiles

En rupture avec les méthodes classiques (cascade, cycle en V, etc.) de gestion de projet logiciel

Août 2001, publication du manifeste des méthodes agiles

Par 17 personnalités éminentes du développement

Ward Cunningham (Wiki), Kent Beck (eXtreme Programming), Ken Schwaber, Jeff Sutherland (SCRUM), Alistair Cockburn, Martin Fowler

Les valeurs de l'agilité





Sommaire

Préambule

Personne n’est parfait = tout le monde est imparfait

L’erreur peut venir du développeur, mais pas uniquement.

Tous les acteurs du projet peuvent se tromper ... à leur manière

"Une erreur de spécification est une forme de bug. Un utilisateur, un décideur et un responsable métier ont aussi le droit de se tromper." (Responsable métier chez Boiron)

"Il n’existe pas de bug qui ne soit issu du cerveau humain. La conception c’est tout ce qui permet de prévenir ou contourner les bugs du cerveau (outil, méthode, design pattern, modélisation, schéma, doc, wiki, commentaire dans le code, …)" (Mix-IT 2011) Laurent Bossavit

@MorendilResponsable de l'institut-agile.fr

http://institut-agile.fr/

Préambule

Les besoins métier évoluent dans le temps, même pendant la vie d'un projet

On doit savoir et pouvoir s’adapter au changement...

Itératif, incrémental, adaptatif

Modélisation selon Jeff Patton

Itératif, incrémental, adaptatif

Les besoins se précisent voire évoluent continuellement

pendant le projet, même quand on croit toucher au but





Sommaire

Quelques fausses idées sur la modélisation

Modèle = Documentation

Processus lourd

Les modèles sont figés

Les Outils sont complexes et onéreux!

Modéliser c’est facile!

Modéliser est une perte de temps ...


Comment documenter / modéliser un besoin ?

2 approches semblent opposées :

l'approche Model-Driven, préconisée par l'OMG, s'appuyant sur une modélisation UML très poussée visant à une génération automatique de code quasi-complète,

certaines méthodes agiles mettent plus l'accent sur la production rapide de code opérationnel que sur la documentation et minimisant donc la modélisation en amont


Trouver le juste milieu entre :

Pas de modélisation du tout

Trop de modélisation

Deux objectifs :

Comprendre le système à faire

Communiquer en interne et externe

Agilité et UML

L'agilité se passe de plus en plus d'UML mais possible de privilégier une modélisation UML pragmatique!

Pas trop de doc… Un peu d’UML!

UML

Unified Modeling Language

Notation standard de l’industrie pour les modèles d’analyse et de conception orientées objet

UML propose de nombreux diagrammes (Diagramme de classes, Diagramme de séquence, …)

C’est un langage et non une méthode ou un processus de développement!

Les digrammes UML

UML 2.3 propose 13 types de diagrammes (9 en UML 1.3)

leur utilisation est laissée à l'appréciation de chacun





Sommaire

Contexte retour d’expérience

Laboratoire pharmaceutique (homéopathie) : Boiron

Contexte de refonte du Système d’Information

Nouvelles technos (stack Java, Spring, Hibernate, etc.)

Application de production (pharmaciens, etc.)

1500 utilisateurs

10000 jours/hommes

2 ans et demi

J’étais architecte logiciel de ce projet

Nous avons utiliser Enterprise Architect (EA)Sparx Systems : http://www.sparxsystems.com

Un outil opensource intéressant : Modeliohttp://www.modeliosoft.com/

Non utilisé dans le projet

Ces deux outils assurent:Gestion des exigences

Modélisation UML 2.x

Nice features (Intégration SCM, reverse-forward engineering, etc.)

L’analyse et la conception UMLavec quel outil ?

Tout n’est pas à modéliser!

Modélisation UML pour l’analyse, très peu pour la conception

Modélisation en mode reverse pour la conception

Génération des modèles à partir du code

Modélisation progressive

Activité d’analyse et donc de modélisation à chaque itération, donc tout au long du projet!

Démarche d’analyse et de conception (1/3)

Temps

Analyse affinage

Déploiement Maintenance

Recette DSI

Recette métier

Développement & test

unitaires

Test dev

Conception technique ExigenceExigence

s initialess initiales

Itérations1.0 1.1 2.0

Analyse Reformulation des besoins

1.2

Enrichissement des modèles à chaque itération!

Nous allons voir quels modèles utilisés sur ces disciplines



ExigencesExigences

Diagrammes d’étatsDiagrammes d’états

Diagrammes d’activitéDiagrammes d’activité

(si nécessaire)…(si nécessaire)…

Cas d’utilisationCas d’utilisation

Maquette IHM (powerpoint ou Pencil)Maquette IHM (powerpoint ou Pencil)

Modèle du domaineModèle du domaine

(Diagramme de classe d’analyse)(Diagramme de classe d’analyse)

Diagrammes Diagrammes

de séquencesde séquences

(si nécessaire)…(si nécessaire)…

AnalystesAnalystes ConcepteursConcepteursCahier des chargesCahier des charges

InterviewsInterviews

Outil UMLOutil UML

Diag. de classe conceptionDiag. de classe conception

Cas d’utilisationCas d’utilisation

Les diagrammes UML que l’on a utilisé

Les diagrammes structurels ou statiques (Structure Diagram) :

Diagramme de classes (2 niveaux) : il représente les classes intervenant dans le système.

Les diagrammes comportementaux (Behavior Diagram) :

Diagramme des cas d'utilisation (use-cases) : toutes les fonctionnalités que doit fournir le système.

Diagramme états-transitions (State Machine Diagram) : permet de décrire sous forme de machine à états finis le comportement du système

Diagramme d'activité (Activity Diagram) : permet de décrire sous forme de flux ou d'enchaînement d'activités le comportement du système ou de ses composants.

Les diagrammes d'interaction ou dynamiques (Interaction Diagram) :

Diagramme de séquence (Sequence Diagram) : représentation séquentielle du déroulement des traitements et des interactions entre les éléments du système

Par où commencer?

Les exigences (pas UML!)

Pas obligatoire mais conseillé!

Les exigences commencent à être rédigées dès l’écriture du cahier de charges

On pourra lier les exigcnes à tous les diagrammes UML

Pour faciliter l’analyse d’impact

Pour faciliter l’écriture des exigences : possibilité de réaliser des diagrammes d’activité

Reformulation des besoinsReformulation des besoins

Modélisation des exigences : retour d’expériences

Saisie des exigences dans EA

Exigences dans Modelio

Diagramme de cas d’utilisation (obligatoire)

UC = Use Cases = Cas d'utilisation

Première phase de projet

Cette phase va conditionner toutes les autres

Les cas d'utilisation sont à la fois le concept le plus simple d'UML, le moins technique, mais aussi souvent le plus mal utilisé

Reformulation des besoins

Analyse


Analyse

UC et User Story

User Story (Scrum) : description textuelle (sans diagramme) haut niveau du besoin

« En tant que ... Je veux ... Pour ..."

UC : très similaire mais un peu plus détaillé

Ajoute les pré et post-contions dans la description

Plusieurs scénarios (nominal, alternatifs)

Un UC référence plusieurs stories

Ex : Le UC « Planifier une itération » référence les stories : créer une itération, définir le but, identifier les tâches, estimer les tâches, démarrer l’ itération...

Retour d’expériences : les UC

Conseils pour les UC

Un cas d’utilisation

Doit être simple: Utiliser le vocabulaire des utilisateurs

Ne pas spécifier comment (quoi!=comment) un système doit être réalisé, mais le service qu'il rend à l'utilisateur

Faire exprimer les besoins, pas des solution (analyse != conception)

Accompagner ce diagramme de texte descriptif

En règle générale un seul acteur principal par cas d’utilisation

Faire valider par le client

Les cas d’utilisation : le point d’entrée!

Fil conducteur du projet : définition des itérations par UC classés par priorité.

Les UC étaient les unités du Backlog (SCRUM)

Les cas d’utilisation : priorisation

Classement (Analyse de la valeur)

Par degré de priorité pour le client

Par activité/domaine fonctionnel

Par les risques encourus durant l’implémentation

Par risques technique, organisationnel, fonctionnel

Traçabilité des exigences (conseillée)

On lie ensuite les exigences aux Use case

Pour obtenir une matrice de couverture des exigences / UC

Intérêt : assurer la traçabilité des exigences par rapport à l’analyse

Enjeu: traçabilité des exigences dans le code

Idéal pour l’analyse d’impact d’une demande changement

Solutions :

Dans les commentaires ? Pas top !

Ecrire ses propres annotations (Java) ? Mieux

En place sur 2 projets chez Boiron depuis début 2011

Une annotation = une exigence, un UC, une règle de gestion

Facilite l’analyse d’impact outillée

Synthèse : les livrables de l’analyse (1/4)

Evidemment les UC!Reformulation des besoins AnalyseReformulation des besoins Analyse


Diagrammes d’activité si nécessaire mais conseillé!

Reformulation des besoins AnalyseReformulation des besoins Analyse

Le comportement d’un système

2 possibilités pour modéliser le comportement d’un système

Description de la succession des activités (ayant une durée)

Utiliser des diagrammes d’activités (diag. comportemental)

Plutôt de haut niveau : appréhension du besoin métier

Description de collections de scénarios d’interaction entre objets

On s’intéresse aux objets qui échangent des messages.

Utiliser des diagrammes de séquence

Plutôt dédiés aux concepteurs/développeurs

On les utilise, à tort, souvent en lieu et place des diag. d’activités


Eventuellement : diagramme d’état/ transition (facultatif)

Pour cerner les traitements métier (transition)

Diagramme d’état/transition (facultatif)Diagramme d’état/transition (facultatif)

Reformulation des besoins Analyse



Reformulation des besoins Analyse





Vision statique du système

Ex. de diagramme de classe d’analyse :

Analyse

Diagramme de classe d’analyse

Regroupe les concepts (entités) métiersIl s’agit du modèle du domaine

Avant de faire des choix de solutions (conception logicielle), il faut bâtir un modèle du problème (analyse)Pour mieux comprendre le problème à résoudrePour obtenir un modèle aussi indépendant que possible des choix

technologiques

Remarque : le mapping 1 à 1 des objets métier et des objets logiciels ne sera pas systématique

Il comporte:les concepts du monde réel (entités métier)leurs attributs leurs associations logiques

Analyse

Du diagramme de classe d’analyse au diagramme de classe de conception (1/2)

Le modèle de conception est déduit du modèle d’analyse (de domaine)

Les classes métier existantes sont détaillées, parfois divisées

De nouvelles classes sont créées à caractère purement informatique (IHM, persistance des données,…)

Ajout de Design Pattern (Facory, Builder, etc.)

L’élaboration du modèle de conception compte deux tâches clés:

Attribuer des responsabilités aux objets

Concevoir des interactions entre les objets

Du diagramme de classe d’analyse au diagramme de classe de conception (2/2)

Le modèle de conception permet de:

Ajouter des méthodes au diagramme

Rendre compte de la visibilité

Définir et faire ressortir les attributs de référence et les attributs simples

Le modèle de conception représente vos classes java réelles de votre projet

Synthèse : les livrables de la conception

Vision statique du système

Diagramme de classe de conception (obligatoire)

Stratgéie d’implémentation

Commencez par la classe la moins connectée pour aller vers la + connectée

Implémentez et testez chaque classe de façon complète avant de passer à la suite

Conception

Développement

PreparationLancer(()

Souche

…

Driver

PersistanceMgrmettreAJourPrep()

Classe de conception

Diagramme de classe de conception et code!

Modèle de domaineUn pour l’analyste, un pour le concepteur

Il est important que le diagramme de classe de conception soit toujours cohérent avec le code.

A cet effet : « forward » ou « reverse » engineering »

Forward et Reverse Engineering

L’opération de « forward engineering »

Consiste à générer du code à partir d’un modèle de classes.

N’a de sens que si les classes sont suffisamment concrètes

On connaît tous les attributs et toutes les méthodes publiques avec leur signature.

L’opération de « reverse engineering »

Consister à analyser du code (un ensemble de classes) et à construire un diagramme de classes.

Produit souvent beaucoup d’informations de bas niveau « inutiles » qu’il faudra masquer dans l’outil UML.

Synthèse : les livrables de la conception

Le diagramme de séquence (facultatif)

Vision dynamique du système Développement

Conception

Diagrammes d'interaction ou dynamiques

Rendent compte des messages et des interactions entre objets

Support pour concevoir la collaboration entre objetsLes messages vont permettre de déduire les méthodes des objets

UML en fournit deux types:Le diagramme de communication reflétant à la fois les échanges de

messages et les relations entre objets

Le diagramme de séquence qui proposent un déroulement chronologique facile à suivre

Nous privilégierons les diag. de séquence, plus intuitifs, mais ils restent facultatifs (coding direct possible!)

ConceptionDéveloppement ConceptionDéveloppement ConceptionDéveloppement

Pas que UML!Possibilité de remplacer les Use Cases par de simples User

Stories

Les spécifications restent importantes:

Format texte

Format Test d’acceptance (Behavior Driven Development): mieux!

Les maquettes autant voire plus importantes que le diagramme en lui-même!

Modélisation en mode itératif

Modéliser par incréments!

Un modèle de domaine (classe) s’enrichit à chaque itération

Ne pas attendre d’avoir fini un diagramme avant de coder

Coder c’est modéliser, modéliser c’est coder!

En mode peer-review : participatif

Comme la gestion du code source, il est important;

que toute l’équipe partage un seul référentiel de modèles

de versionner les modèles

D’utiliser des outils SCM dédiés : SVN, GIT

Modelio et le support SVN

Cas concret : Je suis développeur!

Je travaille en mode itératif

Mon itération commence et j’ai un UC à développer

De quoi je dispose pour commencer mon développement?

Comment je travaille avec les modèles?

Qu’est-ce que je livre?

En entrée je dispose (dans SVN ou Git!) :

Du diagramme de classe d’analyse à jour vis-à-vis de mon UC (analysé dans l’itération précédente)

Du diagramme de classe de conception non à jour vis-à-vis de mon UC

De manière facultative d’autres diagrammes d’analyse :

Diagrammes d’activité, d’état-transition

De mon UC et de la spec de mon UC

De la maquette

Pendant mon développement

Je peux faire quelques diagrammes de séquence

En itératif:

Je peux mettre à jour à la main le diagramme de classe de conception et faire du forward engineering sur ce que j’ai modifié

Je code

Je teste

En mode reverse, je met à jour le diagramme de classe de conception

Je commite dans SVN ou Git mon code ET les diagrammes modifiés

ConclusionUML est :

Un langage intuitif, homogène et cohérent pour visualiser, spécifier, construire et documenter un système informatique.

UML n’est pas :Un processus de développement ni une méthode de gestion de

projet

D’où l’importance de la méthodologie associée : l'agilité!

UML est le standard, mais adoptez juste le sous-ensemble nécessaire et suffisant ! (Règle des 80 / 20)

La valeur ajoutée principale est dans l’activité de modélisation elle-même, non dans le modèle obtenu!

Every model is wrong! and that’s OK (Larman)

Livres : Les agilistes et UML

Martin Fowler “UML Distilled: A Brief Guide to the Standard Object Modeling Language”

Alistair Cockburn “Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process”

Livres : Les agilistes et UML

Alistair Cockburn “Writing Effective Use Cases”

Le livre et le site de Scott Ambler www.agilemodeling.com

Modelisation agile 03122011

Documents

Transcript of Modelisation agile 03122011