Et la méthode, alors ?

On l'a dit et redit : UML n'est pas une méthode mais un langage. Comme si on vous donnait un dictionnaire + un Bescherelle et qu'on vous disait : « écris-nous un roman ». OK, mais quelle méthode utiliser alors ?

On en est où ?

Si vous avez suivi attentivement le début de cette formation, vous savez à présent lire, interpréter et écrire par vous-même un diagramme de cas d’utilisation, un diagramme de classe et quelques autres artefacts intéressants d’UML.

Mais qu’aller vous faire de tout cela ?

The vocabulary and rules of a language such as UML tell you how to create and read well-formed models, but they don’t tell you what models you should build and when you should create them. Grady Booch, James Rumbaugh, Ivar Jacobson (créateurs d’UML)

État de l’art (rapide… très rapide)

MDA DOA

Comme vous vous en doutez, d’autres ont été confrontés avant nous à cette problématique de la démarche à mener pour modéliser de manière efficace et utile, sur la base d’UML.

Il existe (il a existé ?) beaucoup d’initiatives autour d’UML, les plus connues étant les implémentations d’UP (Unified Process) comme RUP (Rational Unified Process), 2TUP (Two Tracks Unified Process), etc.

Ces méthodologies, bien qu’intéressantes et rigoureuses, ont toutes un point commun : leur complexité. Et la complexité, c’est mal (sauf quand on n’a pas le choix…).

C’est probablement cette même complexité qui explique que leur adoption n’ait jamais été massive, et que la démocratisation des méthodes agiles sur le marché IT les ait littéralement… éclipsées.

À côté de cela, le MDA (Model Driven Architecture) et l’ingénierie dirigée par les modèles (IDM) ont essayé de se frayer un chemin, en proposant une approche de réalisation de logiciels à partir de modèles métiers, traduits via des phases successives (CIM : Computational Independant Model, PIM : Platform Independant Model, PSM :Platform Specific Model…) en code source applicatif opérationnel. L’idée est belle : on se concentre sur des problématiques purement fonctionnelles en analysant et en modélisant le besoin de manière rigoureuse, et des systèmes « magiques » transforment tout ceci en un logiciel exploitable. Autant dire que malgré la beauté conceptuelle de la chose, la mayonnaise n’a jamais vraiment pris dans l’industrie IT, comme l’a constaté Forrester Research en qualifiant le MDA de DOA (Dead On Arrival). RIP.

Feature driven development : UML agile ?

Nous sommes donc en quête d’une démarche simple, facile à comprendre et à mettre en œuvre, pour modéliser efficacement nos systèmes.

Plutôt que de réinventer le fil à couper le beurre (ce qui est toujours tentant quand on est informaticien, Bernadette calme toi…), nous allons tâcher d’être pragmatiques et agiles.

Et en parlant d’agilité, voici FDD : Feature driven development de Jeff De Luca, présenté dans le livre Java Modeling in Color. C’est l’heure de faire se rejoindre deux choses que beaucoup opposent, mais qui sont tellement complémentaire : modélisation et agilité.

FDD feature driven development démarche globale

FDD est donc une méthode agile (pour gérer des projet, donc), qui préconise une démarche en 5 étapes s’appuyant fortement sur les modèles :

  1. Créer un modèle d’ensemble du système et de son contexte
  2. Créer la liste des fonctionnalités à implémenter
  3. Assigner chaque fonctionnalité à un développeur (pas traité ici)
  4. Concevoir chaque fonctionnalité
  5. Réaliser chaque fonctionnalité (pas traité ici)

EURÊKA ! Cette méthode est magnifiquement servie par UML (ben oui, quand on parle de modèles…).

Sur cette base, voici les 3 étapes de modélisation de notre démarche de modélisation :

1. Créer un diagramme de classes général

Correspond à l’étape 1 de la méthode FDD.

La première étape de la méthode FDD « Créer un modèle d’ensemble du système et de son contexte » se traduira (s’opérationalisera, s’implémentera, se réifiera : dites-le comme vous voulez) par la réalisation d’un diagramme de classes UML.

Pas n’importe quel diagramme de classes. Pas un truc technique où on identifiera la méthode statique poilue prenant en paramètre un pointeur de pointeur et retournant la référence d’un flottant à double précision : vous l’avez compris, il s’agit d’un diagramme de classes conceptuel.

En d’autres termes, nous allons ici établir une cartographie détaillée des concepts manipulés par notre application. C’est la partie statique de la modélisation, et c’est extrêmement important.

2. Créer un diagramme de cas d’utilisation général

Correspond à l’étape 2 de la méthode FDD.

La deuxième étape de la méthode FDD « Créer la liste des fonctionnalités à implémenter » se traduira par la réalisation d’un diagramme de cas d’utilisation.

Il s’agit ici d’identifier ce que l’utilisateur pourra faire, de manière générale, avec l’application. C’est la vision dynamique (comportementale) de la modélisation, pas un PBS exhaustif (la règle des 100% vous connaissez ? Oubliez là…).

Imaginez MS Project. Que permet de réaliser MS Project ? Créer un WBS, structurer des tâches, créer un diagramme de Gantt, saisir des estimations, saisir des coûts, réaliser des simulation et des rapports… En d’autres termes, il s’agit ici de représenter les fonctionnalités « top level », sans entrer dans de grands détails.

Astuce – Toujours pas clair ? Imaginez le menu général de votre application : il y a de fortes chances pour qu’il présente les éléments que vous aurez fait apparaître dans ce diagramme de cas d’utilisation général.

3. Concevoir chaque fonctionnalité

Correspond à l’étape 4 de la méthode FDD.

Pour chaque cas d’utilisation (i.e. chaque fonctionnalité du logiciel), nous allons ensuite établir une conception plus détaillée.

Concrètement, nous sommes ici dans le vif du sujet de l’interface MOA-MOE : généralement, ces modèles sont co-construits par les deux parties, et doivent être suffisamment précis pour être traduits en code par les développeurs.

Cette conception passe notamment par :

  • La précision des diagrammes de classes
  • La précision des diagrammes de cas d’utilisation
  • La création de diagrammes d’activité, pour faire des « zooms » sur certaines fonctionnalités en en détaillant le processus fonctionnel (workflow)
  • La création éventuelle d’autres types de diagrammes (diagrammes de composants, diagrammes de séquences, etc.)

Maintenant, accrochez-vous bien à votre chaise, ce qui suit va peut-être vous choquer.

Fainéant – Dans la vraie vie, selon le contexte (les manières de faire ne sont pas les mêmes si on conçoit un système embarqué pour une fusée ou un site e-commerce…), je ne vous conseille pas de réaliser cette étape systématiquement. Oui, vous avez bien lu : si vous avez tout compris avec les étapes 1 et 2, que les choses sont claires pour tout le monde (MOA, MOE…), pourquoi se tirer la nouille à créer des diagrammes supplémentaires ? Codez, produisez de la valeur. Soyez agiles.

Démarche UML simple

Mais attention quand même : cette remarque ne vaut que pour cette étape 3 ! Hors de question de faire l’impasse sur le diagramme de classes général, ni sur le diagramme de cas d’utilisation général. Être agile ne veut pas dire être crétin. Pas forcément, en tout cas…

Outillage

OK, nous avons maintenant une trame de travail détaillée. Reste à savoir comment réaliser ce travail, concrètement, avec quel outillage.

Nous avons réalisé un tour d’horizon des logiciels de modélisation UML.

Dans cette formation, nous utiliserons l’outil Astah, qui est un excellent compromis entre simplicité et efficacité, pour un tarif fort abordable.

Vous préférez en utiliser un autre ? Peu importe, faites-vous plaisir, ça n’a aucune importance.

Lectures conseillées

Article

Java Modeling in Color: Enterprise Components and Process

Voir

Article

Adaptive Software Development: A Collaborative Approach to Managing Complex Systems

Voir

Article

Agile Project Management

Voir

Commentaires