Note: 7 ; Un (excellent) complément au « Writting Effective Use Cases » d’Alistair Cockburn.
Les cas d’utilisation sont un peu passés de mode depuis la grande époque UML, jusqu’au début des années 2000. C’est bien de cette époque que date cet ouvrage dont on peut pourtant dire qu’il serait injuste de le considérer comme passé de mode ! Il s’inscrit dans la lignée du « writting effective Use Cases » d’Alistair Cockburn qui promeut une écriture intentionnelle, courte et efficace par rapport aux Cas d’Utilisation « interactionnels » qui noircissent beaucoup de pages et ont donné une image si déplorable de cette pratique.
L’ouvrage a adopté le forme « Pattern Language ». Elle n’est pas toujours appropriée pour un livre d’environ 200 pages, mais on doit bien constater qu’ici cela ne pose guère de problème. Ceux-ci sont partitionnés sur 7 chapitres (auxquels il faut ajouter le chapitre introductif). Chaque pattern occupant environ 6 à 8 pages, donc assez pour être développé et pas trop pour ne pas devenir indigeste. Le premier chapitre investigue ce qu’est réellement un cas d’utilisation de qualité. C’est du moins la promesse faite par ce chapitre dont le titre est un peu trompeur. Si les auteurs nous montrent effectivement ce qu’est un bon Cas d’utilisation par rapport aux mauvais cas d’utilisation (toute ressemblance avec les bons et les mauvais chasseurs…), le chapitre sert surtout de table de matière et au langage de patterns et d’introduction à la forme pattern. Cela dit, il n’y a rien de mal à cela et c’est même nécessaire.
Le chapitre 2 nous prend un peu par surprise : « The Team » évoque les aspects collaboration et coopération gravitant autour de l’écriture des cas d’utilisation ! Ainsi, ParticipatingAudience met l’accent sur l’implication des utilisateurs et des parties prenantes, tandis que BalancedTeam détaille la pertinence de former des groupes d’écriture diversifiant les points de vue. En réalité, les éléments évoqués sont un peu des nouvelles d’hier, mais les expliciter ne peut pas faire de mal. Le chapitre 3 « The Process » s’inscrit dans la continuité. Le chapitre est assez riche et ne commet pas l’erreur de proposer un workflow de rédaction. BreathBeforeDepth est sans doute l’un des patterns cruciaux de ce chapitre. Les auteurs y référencent de très nombreux autres patterns, sans doute trop. Mais le propos est crucial pour la réussite d’une démarche « cas d’utilisation ». Je suis plus surpris d’y trouver TwoTierReview qui aurait d’avantage eu sa place dans le chapitre précédent, à mon avis. Le QuittingTime est une bonne idée : il rappelle que « pas trop n’en faut » et qu’ajouter du détail peut être contre-productif. C’est une mise en garde dont j’ai eu à faire bon usage, car je dois avouer avoir été coupable de ce travers !
Le chapitre 4 attaque la matière proprement dite, avec les « Use Case Sets ». Également indispensable, ce chapitre dresse en quelques patterns ce qui est nécessaire pour donner un contexte et des limites au modèle de cas d’utilisation. VisibleBoundary qui reprends l’idée du diagramme de contexte, mais surtout procure une vision « boite noire » est l’un de mes préférés avec ClearCastOfCharacters. Ce dernier patterns nous conduit à identifier les acteurs impliqués au travers du system. A contrario, EverUnfoldingStory nous emmène vers la vision Cockburniène des US mâtinées de décomposition fonctionnelles, vision qui n’est pas partagée ailleurs au sein de la communauté des cas d’utilisation. C’est d’ailleurs ma plus importante réticence par rapport à cette approche. Le chapitre 5 est très justement intitulé « The Use Case ». Je dirais qu’il est le plus important du livre, et vraiment il n’y a rien à jeter. Peut-être est-on un peu noyé sous les références vers les autres patterns, mais à part cela les patterns identifiés couvrent bien les différents aspects de la structure d’un cas d’utilisation.
Le chapitre 6 va rentrer dans la structure même des scénarios constituant le cas d’utilisation. Ces patterns sont moins marquants que ceux du chapitre précédent. Ils ressemblent plutôt à de (bonnes) recommandations sur la granularité des étapes de scénarios et pour les concevoir en termes de progression fonctionnelle. Le chapitre 7 aborde la délicate question des relations entre cas d’utilisation, c’est-à-dire en pratique les relations « include » et « extend » que je m’évertue à éviter autant que faire se peut. CommonSubBehavior nous met d’ailleurs en garde contre cela, mais ne nous propose que le très classique (et facile) cas d’utilisation du paiement pour l’illustrer. Le PromotedAlternative est plus intéressant en cela, car il nous amène à penser à quel moment un fragment peut devenir un cas d’utilisation inclus. Enfin l’utilisation de la relation de généralisation dans CapturedAlternative est pour moi d’avantage un jeu de l’esprit qu’une pratique réellement utile, qui sera d’ailleurs trop compliquée à appréhender pour les utilisateurs.
Le chapitre 8 qui conclut cet ouvrage est consacré à ce que j’appellerais des patterns de refactoring d’un modèle de cas d’utilisation. C’est réellement une bonne idée : en relecture il convient de s’interroger si un cas d’utilisation n’a pas pris trop d’embonpoint ou si au contraire un cas d’utilisation inclus n’est pas famélique au point qu’il serait préférable de le rapatrier. Sans doute aurait-il été possible d’en identifier d’autres, c’est un petit point de frustration concernant ce chapitre.
Je ne conseillerai pas ce livre comme premier livre sur les Use Cases. En fait, sa lecture n’en est que plus profitable si l’on a déjà un peu d’expérience avec cette technique, car les patterns qui y figurent permettent surtout de corriger les défauts que nous pouvons être enclins à développer. La coloration spécifique à l’approche d’Alistair Cockburn est nettement moins marquée que ce que j’avais craint, on pourra donc mettre en œuvre ce qui est décrit dans ces pages en sachant qu’à une ou deux exceptions près, cela fait consensus dans la communauté des cas d’utilisation.
Avec une connaissance de base des Use Cases et une bonne assimilation des patterns décrits ici, vous avez toutes les cartes en main pour écrire des use cases de la meilleure qualité qui soit.
Référence complète : Patterns for Effective Use Cases – Steve Adolph & Paul Bramble, with Alistair Cockburn & Andy Pols – Addison Wesley / ASD series 2002 – ISBN: 0-201-72184-8