La session aborde la modélisation agile et UML, en mettant l'accent sur les bonnes pratiques et les expériences dans un contexte de projet agile. Elle souligne l'importance de l'itération et de l'adaptabilité des exigences tout en utilisant UML de manière pragmatique pour faciliter la communication et la traçabilité. L'intervenante, Agnès Crepet, partage des retours d'expérience de modélisation dans un projet de refonte de système d'information pour le laboratoire pharmaceutique Boiron.

1. Modélisation Agile & UML TogoJUG 3 décembre 2011 Agnès CREPET @agnes_crepet

2. 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éussite UML n’est pas la réponse à tous les problèmes de modélisation!

3. 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

4. Quelques rappels sur l'agilité Modéliser et concevoir Vers une modélisation agile UML pragmatique & Retour d'expériences Sommaire

5. Le manifeste des méthodes agiles

6. 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

7. Les valeurs de l'agilité

8. Quelques rappels sur l'agilité Modéliser et concevoir Vers une modélisation agile UML pragmatique & Retour d'expériences Sommaire

9. 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 @Morendil Responsable de l' institut-agile.fr

10. 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...

11. Itératif, incrémental, adaptatif Modélisation selon Jeff Patton

12. Itératif, incrémental, adaptatif Les besoins se précisent voire évoluent continuellement pendant le projet, même quand on croit toucher au but

13. Quelques rappels sur l'agilité Modéliser et concevoir Vers une modélisation agile UML pragmatique & Retour d'expériences Sommaire

14. 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 ...

15. Vers une modélisation agile 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

16. Vers une modélisation agile 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

17. 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!

18. 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!

19. 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

20. Quelques rappels sur l'agilité Modéliser et concevoir Vers une modélisation agile UML pragmatique & Retour d'expériences Sommaire

21. 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

22. Nous avons utiliser Enterprise Architect (EA) Sparx Systems : http:// www.sparxsystems.com Un outil opensource intéressant : Modelio http://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 UML avec quel outil ?

23. 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)

24. Enrichissement des modèles à chaque itération! Nous allons voir quels modèles utilisés sur ces disciplines Temps Analyse affinage Déploiement Maintenance Exigences initiales Itérations 1.0 1.1 2.0 Analyse Reformulation des besoins 1.2 Démarche d’analyse et de conception (2/3) Recette DSI Recette métier Développement & test unitaires Test dev Conception technique

25. Démarche d’analyse et de conception (3/3) Exigences Diagrammes d’états Diagrammes d’activité (si nécessaire)… Cas d’utilisation Maquette IHM (powerpoint ou Pencil) Modèle du domaine (Diagramme de classe d’analyse) Diagrammes de séquences (si nécessaire)… Analystes Concepteurs Cahier des charges Interviews Outil UML Diag. de classe conception Cas d’utilisation

26. 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

27. 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 besoins Reformulation des besoins

28. Modélisation des exigences : retour d’expériences Saisie des exigences dans EA

29. Exigences dans Modelio

30. 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 Reformulation des besoins Analyse

31. 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...

32. Retour d’expériences : les UC

33. 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

34. 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)

35. 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

36. 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

37. 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

38. Synthèse : les livrables de l’analyse (1/4) Evidemment les UC! Reformulation des besoins Analyse Reformulation des besoins Analyse

39. Synthèse : les livrables de l’analyse (2/4) Diagrammes d’activité si nécessaire mais conseillé! Reformulation des besoins Analyse Reformulation des besoins Analyse

40. 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

41. Synthèse : les livrables de l’analyse (3/4) Eventuellement : diagramme d’état/ transition (facultatif) Pour cerner les traitements métier (transition) Diagramme d’état/transition (facultatif) Eventuellement : diagramme d’état/ transition (facultatif) Pour cerner les traitements métier (transition) Eventuellement : diagramme d’état/ transition (facultatif) Pour cerner les traitements métier (transition) Reformulation des besoins Analyse Reformulation des besoins Analyse Reformulation des besoins

42. Synthèse : les livrables de l’analyse (4/4) Vision statique du système Ex. de diagramme de classe d’analyse : Analyse

43. Diagramme de classe d’analyse Regroupe les concepts (entités) métiers Il 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ésoudre Pour 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

44. 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

45. 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

46. 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 Preparation Lancer ( () Souche … Driver PersistanceMgr mettreAJourPrep() Classe de conception

47. Diagramme de classe de conception et code! Modèle de domaine Un 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 »

48. 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.

49. Synthèse : les livrables de la conception Le diagramme de séquence (facultatif) Vision dynamique du système Développement Conception

50. Diagrammes d'interaction ou dynamiques Rendent compte des messages et des interactions entre objets Support pour concevoir la collaboration entre objets Les 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!) Conception Développement Conception Développement Conception Développement

51. 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!

52. 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

53. Modelio et le support SVN

54. 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?

55. 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

56. 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

57. Conclusion UML 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)

59. 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”

60. Livres : Les agilistes et UML Alistair Cockburn “Writing Effective Use Cases” Le livre et le site de Scott Ambler www.agilemodeling.com