Le processus unifié & UML

Deux outils, et ils répondent à deux questions différentes qu'on confond tout le temps. Le processus dit dans quel ordre on travaille ; le langage dit comment on écrit ce qu'on a compris. Le premier est un calendrier, le second un alphabet — et aucun des deux ne remplace l'autre.

Pourquoi un processus, et pas juste du code

On te confie un système de réservation de salles pour l'université. Tu sais programmer. Qu'est-ce qui t'empêche d'ouvrir un éditeur et de commencer ?

Rien, techniquement. Et c'est bien le problème : les questions que tu n'as pas posées ne disparaissent pas, elles attendent. Quelle base de données ? Quelles classes ? Qu'est-ce qu'une « réservation », au juste — une intention, un contrat ? Que se passe-t-il si on annule ? Et si le client change d'avis au troisième mois, combien de ce que tu auras écrit faudra-t-il jeter ?

Un processus de développement est une réponse à une question très concrète : dans quel ordre décider. Il dit quand analyser, quand concevoir, quand coder, quand tester — et surtout quand s'arrêter pour vérifier qu'on ne s'est pas trompé de direction. Il rend le travail prévisible, ce qui n'a rien d'un luxe administratif : c'est ce qui permet à cinq personnes de travailler en même temps sans se marcher dessus.

Il faut dire tout de suite ce qu'un processus n'est pas, parce que la confusion est courante et qu'elle rend la matière antipathique. Ce n'est pas de la paperasse : le but n'a jamais été de produire des documents, mais de prendre les bonnes décisions dans le bon ordre. Ce n'est pas non plus une méthode de gestion d'équipe : le processus dit quoi produire et quand, pas qui fait quoi. Et ce n'est surtout pas un choix moral entre le bien et le mal — la section suivante défend la cascade avant de la condamner, et ce n'est pas une politesse.

La cascade, et le défaut qui la condamne

La cascade est le processus le plus intuitif qui soit, et c'est pour ça qu'on le réinvente spontanément. On fait toute l'analyse. Puis toute la conception. Puis tout le code. Puis tous les tests. Chaque étape doit être terminée à cent pour cent avant que la suivante ne commence — d'où le nom : l'eau tombe d'un palier au suivant et ne remonte jamais.

Il faut lui reconnaître ce qu'elle a de bon, sinon on ne comprend pas pourquoi elle a dominé trente ans. Elle est facile à planifier — quatre blocs, quatre dates. Elle est facile à contractualiser — le client signe une spécification, l'équipe livre exactement ça. Et elle vient du génie civil, où elle marche très bien : on ne coule pas les fondations en même temps qu'on pose la toiture, et surtout on ne découvre pas au huitième mois que le client voulait deux étages de plus.

C'est là que le logiciel diffère, et c'est tout le sujet. En construction, changer d'avis coûte cher parce que la matière est déjà coulée. En logiciel, la matière n'est jamais coulée — mais on découvre bien plus tard qu'on s'est trompé, et le coût d'un malentendu croît avec le temps qu'on a passé à construire dessus.

Les défauts de la cascade se listent facilement, mais ils ont tous la même racine, et c'est elle qu'il faut retenir plutôt que la liste : le retour d'information arrive après la décision qu'il aurait dû éclairer. Le client ne voit le produit qu'à la toute fin, donc trop tard pour ajuster. Une exigence mal comprise au début pollue tout ce qui vient après, et personne ne le sait avant la recette. Les risques techniques — l'architecture tient-elle la charge, la passerelle de paiement fait-elle vraiment ce qu'annonce sa documentation ? — ne sont validés qu'au moment où il est le plus cher d'en changer. Et l'équipe n'apprend rien entre les étapes, puisqu'il n'y en a qu'une de chaque.

L'itératif, et ce qu'il achète

L'approche itérative renverse une seule chose, et tout le reste en découle : au lieu de découper le projet par activité, on le découpe par tranche de temps. Chaque itération dure deux à six semaines et contient un peu d'analyse, un peu de conception, un peu de code, un peu de tests. À la fin de chacune, quelque chose fonctionne et se montre.

Ce « quelque chose fonctionne » n'est pas un détail de présentation, c'est le mécanisme entier. Un logiciel qui tourne est la seule chose sur laquelle un client peut réagir honnêtement. Devant une spécification de quarante pages, il approuve ; devant un écran, il dit « ah, non, ce n'est pas ça que je voulais dire ». Les deux réponses sont sincères, et seule la seconde est utile.

Ce que l'itératif achète, précisément : le retour du client arrive tôt et souvent, donc les malentendus se corrigent quand ils ne coûtent encore rien. Les risques s'attaquent en premier plutôt qu'en dernier — on écrit d'abord le morceau dont on n'est pas sûr. L'équipe apprend d'une itération à l'autre, et sa deuxième estimation vaut bien mieux que la première. Et un changement d'exigence cesse d'être une catastrophe pour devenir un simple élément de la prochaine itération.

Ce qu'il coûte, parce que rien n'est gratuit : il faut être capable d'intégrer et de démontrer souvent, ce qui suppose une discipline technique réelle. Et il demande un client disponible, qui accepte de regarder et de dire. Un client absent transforme l'itératif en cascade avec des réunions.

· Le client n'est pas sûr de toutes ses exigences.
· L'équipe emploie une passerelle de paiement qu'elle n'a jamais essayée.
· La date de mise en service est fixée, le périmètre ne l'est pas.

Les quatre mots du processus unifié

Le processus unifié — le PU — est la mise en forme la plus connue de l'approche itérative. Il a été conçu par Jacobson, Booch et Rumbaugh, les trois auteurs qui avaient chacun leur propre notation dans les années quatre-vingt-dix et qui les ont fusionnées : c'est de cette fusion que viennent à la fois UML et le PU, et c'est pourquoi les deux arrivent toujours ensemble.

On le définit par quatre adjectifs, et l'examen les demande. Mais quatre mots récités ne servent à rien : ce qui compte est de savoir à quelle question chacun répond.

Les deux premiers vont ensemble et sont presque une seule idée : itératif décrit le rythme, incrémental décrit le résultat. On peut très bien être itératif sans être incrémental — trois itérations qui produisent trois documents ne construisent rien —, et c'est une façon courante de rater le PU tout en cochant ses cases.

Le troisième mérite qu'on s'y arrête, parce qu'il est le moins évident. Pourquoi piloter par les cas d'utilisation plutôt que par les modules du système ? Parce qu'un module n'a de valeur pour personne. Livrer « la couche d'accès aux données » à la fin d'une itération ne se démontre pas et ne se juge pas ; livrer « le caissier peut encaisser une commande » traverse toutes les couches et se voit. Le pilotage par les cas d'utilisation est donc ce qui rend l'incrémental possible : c'est lui qui garantit qu'à la fin de chaque tour, il y a quelque chose à montrer.

Le quatrième répond à une objection qu'on se fait naturellement en découvrant l'itératif : si l'on ne conçoit qu'un peu à la fois, ne finit-on pas avec un assemblage incohérent ? Si, exactement — et c'est pour ça que le PU exige que l'architecture soit stabilisée très tôt, dans les premières itérations, avant que la production de fonctionnalités ne commence pour de bon. On accepte d'être souple sur le contenu parce qu'on a été rigide sur la charpente.

Les quatre phases, et où part l'effort

Le PU découpe le projet en quatre phases, qui sont des périodes du calendrier. Chacune contient elle-même plusieurs itérations — c'est le point que la liste des quatre noms fait toujours oublier.

Ces quatre phases ne pèsent pas le même poids, et leur déséquilibre est instructif. La figure ci-dessous les met à l'échelle.

Pourquoi payer trente pour cent de l'effort en élaboration, une phase qui ne produit presque rien de visible ? Parce que c'est exactement là qu'on achète l'assurance du projet. L'élaboration existe pour transformer les inconnues en certitudes pendant qu'il est encore bon marché de se tromper : elle construit une architecture exécutable — pas un document d'architecture, un squelette qui tourne — et lui fait traverser les cas d'utilisation les plus risqués. Si la passerelle de paiement ne tient pas la charge, on l'apprend là, à trente pour cent du budget, et pas à quatre-vingts.

Corollaire, et c'est ce que l'examen aime demander : la construction ne tranche plus rien. C'est la seule phase qui n'a pas de question à résoudre, ce qui explique qu'elle soit à la fois la plus longue et la moins risquée. Quand tout va bien, la construction est ennuyeuse — et c'est le signe que l'élaboration a fait son travail.

(A) Écrire les cas d'utilisation principaux pour évaluer la faisabilité.
(B) Implémenter la dernière fonctionnalité restante.
(C) Former les utilisateurs et livrer le système en production.
(D) Vérifier que l'architecture supporte 10 000 utilisateurs simultanés.
(E) Décider de la topologie matérielle : serveurs, base, cache.

Les disciplines ne sont pas les phases

Voici la confusion annoncée au début du module, et elle vaut la peine d'être posée lentement, parce qu'elle est la source de la moitié des mauvaises réponses.

Une phase est une période du calendrier : inception, élaboration, construction, transition. Elles se succèdent, une seule à la fois, et on les traverse dans l'ordre.

Une discipline est un type de travail : exigences, analyse, conception, implémentation, tests, déploiement. Elles ne se succèdent pas : à n'importe quel moment du projet, on peut faire un peu de n'importe laquelle. Ce qui change d'une phase à l'autre, ce n'est pas lesquelles on pratique, c'est en quelle proportion.

Une façon de ne plus jamais s'y tromper : les phases répondent à « quand ? », les disciplines à « quoi ? ». Une question d'examen qui demande « dans quelle phase ? » attend un des quatre noms latins ; une question qui demande « quelle discipline ? » attend un type de travail. Et il est parfaitement normal qu'une même activité appartienne à une discipline donnée tout en ayant lieu dans trois phases différentes.

Prends une seule activité — écrire un cas d'utilisation — et regarde où elle a lieu. En inception, on en écrit quelques-uns, à gros grain, pour estimer l'ampleur du projet et décider s'il vaut la peine : on cherche un ordre de grandeur, pas de la précision. En élaboration, on reprend les plus risqués et on les détaille scénario par scénario, parce que ce sont eux qui vont éprouver l'architecture. En construction, on affine encore, juste avant d'implémenter chacun.

Trois phases, une seule discipline — celle des exigences — et trois raisons différentes de faire la même chose. C'est ça, la nuance qui rend la distinction utile plutôt que scolaire : la discipline dit ce qu'on fabrique, la phase dit pourquoi on le fabrique maintenant, et donc à quel niveau de détail on s'arrête.

La conséquence pratique se voit dans un plan de projet. On ne peut pas écrire « analyse jusqu'au 15 octobre, puis conception » — ce serait figer une discipline dans le calendrier, ce qui est exactement la définition de la cascade. Ce qu'on écrit, c'est « élaboration jusqu'au 15 octobre », et pendant cette période l'équipe fera de l'analyse, de la conception, du code et des tests, dans les proportions que la phase commande.

(1) « On est en élaboration jusqu'à la mi-octobre. »
(2) « Cette semaine, l'équipe fait surtout de la conception. »

UML : un langage, pas une méthode

On change complètement de sujet ici, et c'est volontaire. Tout ce qui précède parlait d'ordre de travail. UML ne parle que de notation. Les deux sont nés ensemble et s'emploient ensemble, mais confondre les deux est la première erreur à ne pas faire.

UML — Unified Modeling Language — est un langage graphique normalisé pour modéliser, visualiser et documenter un système orienté objet. Le mot important de cette définition est langage : UML ne te dit pas quoi faire, ni dans quel ordre, ni quand tu as fini. Il te donne des symboles dont le sens est fixé, et rien de plus. Il est indépendant de tout langage de programmation et — c'est moins connu — de tout processus : on peut faire de l'UML en cascade.

UML sert trois usages, et ils ne demandent pas le même niveau de détail. Visualiser — saisir d'un coup d'œil une structure ou un comportement ; un croquis suffit. Spécifier — décrire sans ambiguïté ce qui doit être construit ; là, la rigueur compte. Documenter — laisser une trace lisible pour celui qui reprendra le système dans deux ans. Savoir lequel des trois on vise évite le débat le plus stérile de la modélisation, celui du niveau de détail.

Que la notation soit normalisée a deux conséquences très concrètes, et elles valent mieux que le mot « standard ». La première : un diagramme survit à celui qui l'a dessiné. Six mois après le départ d'un collègue, son diagramme se lit encore, sans légende et sans lui — ce qui n'est vrai d'aucun croquis personnel. La seconde : un outil peut le lire. C'est parce que la notation est fixée que Visual Paradigm sait ouvrir le fichier d'un autre, qu'un diagramme de classes peut engendrer un squelette de code, et que l'inverse est possible aussi.

Symétriquement, il faut savoir ce qu'UML n'achète pas, parce que c'est là qu'on se raconte des histoires. Il ne dit pas si ton modèle est bon — il vérifie ta grammaire, jamais ton propos, exactement comme l'orthographe ne juge pas un roman. Il ne dit pas non plus quand dessiner, ni combien : c'est le processus qui en décide, et un projet honnête n'emploie que trois ou quatre des treize diagrammes. Et il ne remplace pas le code : la plupart des diagrammes ne s'exécutent pas.

Le corollaire est celui par lequel ce module a commencé, et il se vérifie dans les deux sens. On peut produire de très beaux diagrammes et n'avoir rien décidé — c'est ce qui arrive quand on modélise pour remplir un livrable. Et on peut mener un projet parfaitement itératif avec trois croquis au tableau. Le langage ne fait pas le processus, et le processus n'impose pas le langage.

(A) UML impose de travailler par itérations.
(B) UML est indépendant du langage de programmation employé.
(C) Un projet devrait produire les treize types de diagrammes.
(D) Un diagramme UML valide peut décrire une conception mauvaise.

1. LA FRONTIÈRE  — qu'est-ce qui est DANS le système, et qu'est-ce qui est dehors ?
2. LES ÉLÉMENTS  — que représentent les boîtes ? des concepts ? des objets ? des acteurs ?
3. LES RELATIONS — que veulent dire les traits, et surtout DANS QUEL SENS se lisent-ils ?

Les treize diagrammes, et les neuf du cours

UML 2 définit treize types de diagrammes. Les apprendre par cœur comme une liste ne sert à rien et ne tient pas ; ce qui tient, c'est la coupure en deux familles, parce qu'elle correspond à une vraie différence de nature.

Les diagrammes de structure montrent ce qui est : ils décrivent le système figé, comme une photographie. Les diagrammes de comportement montrent ce qui se passe : ils décrivent le système en mouvement, comme un film. Toute question du type « quel diagramme choisir ? » se tranche d'abord là — cherche-t-on à décrire un état de choses ou un déroulement ?

Deux remarques qui font gagner du temps. D'abord, séquence et communication portent exactement la même information — les mêmes messages, entre les mêmes objets ; seule la mise en page change, l'un privilégiant l'ordre chronologique, l'autre la topologie des liens. On choisit selon ce qu'on veut faire ressortir, jamais selon ce qu'on veut dire.

Ensuite, tous ces diagrammes ne servent pas. Un vrai projet en emploie trois ou quatre. Le cours en retient neuf, et c'est déjà généreux : ce sont ceux qu'on rencontre effectivement en analyse et en conception.

Choisir le bon diagramme

C'est la compétence que ce module doit vraiment laisser, et elle se réduit à deux questions posées dans l'ordre. Première question : structure ou comportement ? Décris-tu un état de choses, ou un déroulement ? Cette seule question élimine la moitié du catalogue. Seconde question : à quel niveau ? Le métier, le système vu de l'extérieur, ou l'intérieur du logiciel ?

Le niveau est ce qui distingue des diagrammes qui se ressemblent beaucoup. Le modèle du domaine et le diagramme de classes de conception ont la même notation — des boîtes et des traits — mais pas le même propos : le premier décrit le monde tel qu'il est avant qu'on écrive quoi que ce soit, le second décrit le logiciel qu'on va écrire. De même, le diagramme de séquence système traite le système comme une boîte noire, alors que le diagramme de séquence ordinaire regarde à l'intérieur.

(A) Montrer toutes les fonctionnalités demandées par les utilisateurs.
(B) Décrire le cycle de vie d'une commande : créée, validée, expédiée, livrée.
(C) Spécifier l'ordre des messages entre un contrôleur et trois objets
    métier pendant un paiement.
(D) Représenter le serveur web, la base de données et le cache.
(E) Fixer le vocabulaire de la facturation avant toute conception.

« Un étudiant s'inscrit à un cours. L'inscription est refusée si le cours
  est plein. Une inscription passe de « demandée » à « confirmée » quand
  le paiement est reçu, ou à « annulée » si l'étudiant se désiste. »