Une démarche de modélisation "agile" pour passer des besoins utilisateurs au code
Introduction
Dans cet article, nous allons décrire de façon progressive le processus simplifié que nous préconisons pour la modélisation des applications web.
Nota : la description détaillée de ce processus ainsi que sa mise en œuvre complète sur une étude de cas de librairie en ligne vient de paraître chez Eyrolles, dans la collection intitulée « Les cahiers du Programmeur », sous le titre : « UML 2 - Modéliser une application web». Dans un prochain article, nous reviendrons faire un zoom sur l’activité de conception détaillée prenant pour cible la plate-forme .NET, en nous inspirant du dernier chapitre du même ouvrage.
Le processus que nous vous proposons de suivre pour le développement d’applications Web se situe à mi-chemin entre UP (Unified Process), un cadre général très complet de processus de développement, et XP (eXtreme Programming), une approche minimaliste à la mode centrée sur le code. Il s’inspire également des bonnes pratiques prônées par les tenants de la modélisation agile (Agile Modeling).
La modélisation agile (AM)
La « modélisation agile » prônée par Scott Ambler s’appuie sur des principes simples et de bon sens, parmi lesquels :
- Vous devriez avoir une grande palette de techniques à votre disposition et connaître les forces et les faiblesses de chacune de manière à pouvoir appliquer la meilleure au problème courant.
- N’hésitez pas à changer de diagramme quand vous sentez que vous n’avancez plus avec le modèle en cours. Le changement de perspective va vous permettre de voir le problème sous un autre angle et de mieux comprendre ce qui bloquait précédemment.
- Vous trouverez souvent que vous êtes plus productif si vous créez plusieurs modèles simultanément plutôt qu’en vous focalisant sur un seul type de diagramme.
Un processus « agile » pour la modélisation d’applications web
Le processus pragmatique que nous allons présenter est :
- Conduit par les cas d’utilisation, comme UP, mais beaucoup plus simple,
- Relativement léger et restreint, comme XP, mais sans négliger les activités de modélisation en analyse et conception,
- Fondé sur l’utilisation d’un sous-ensemble nécessaire et suffisant du langage UML, conformément à AM.
Nous allons donc essayer de trouver le meilleur rapport « qualité/prix » possible afin de ne pas multiplier les concepts et les diagrammes qui ne sont pas indispensables au développement d’applications web efficaces. La célèbre règle des 80/20 peut aussi s’appliquer dans notre cas : vous pouvez modéliser 80% de vos problèmes en utilisant 20% d’UML ! Encore faut-il savoir quels sont ces 20% indispensables …
Le problème fondamental auquel cet article va s’efforcer de répondre est finalement assez simple : comment passer des besoins des utilisateurs au code de l’application ? Autrement dit : « j’ai une bonne idée de ce que mon application doit faire, des fonctionnalités attendues par les futurs utilisateurs. Comment obtenir le plus efficacement possible un code informatique opérationnel, complet, testé, et qui réponde parfaitement au besoin ? ».
Il ne s’agit pas de se jeter sur l’écriture du code en omettant de formaliser les besoins des utilisateurs et d’élaborer une architecture robuste et évolutive. D’un autre côté, le but n’est pas de faire de la modélisation pour le plaisir, mais bien de produire le plus rapidement possible une application qui satisfasse au mieux ses utilisateurs !
Nous allons donc vous proposer une démarche de modélisation nécessaire et suffisante afin de construire efficacement une application web. Pour cela nous utiliserons un sous-ensemble du langage de modélisation UML qui sera également nécessaire et suffisant pour la plupart des projets de même nature. Cette approche est le résultat de plusieurs années d’expérience sur de nombreux projets dans des domaines variés. Elle a donc montré son efficacité dans la pratique.
Dans un premier temps, les besoins vont être modélisés au moyen des cas d’utilisation UML. Ils seront également représentés de façon plus concrète par une maquette d’IHM (Interface Homme-Machine) destinée à faire réagir les futurs utilisateurs. La figure suivante montre bien de quoi nous partons et là où nous voulons arriver.
Repartons maintenant du but, c’est à dire du code que nous voulons obtenir, et remontons en arrière, pour mieux expliquer le chemin minimal qui va nous permettre de joindre les deux « bouts ». Dans le cadre de systèmes orientés-objets, la structure du code est définie par les classes logicielles et leurs regroupements en ensembles appelés packages. Nous avons donc besoin de diagrammes représentant les classes logicielles et montrant les données qu’elles contiennent (appelées attributs), les services qu’elles rendent (appelés opérations ou méthodes) ainsi que leurs relations. UML propose les diagrammes de classes pour véhiculer toutes ces informations.
Nous reviendrons dans un prochain article sur les diagrammes de classes de conception dans un environnement technique .NET et C#.
La figure ci-après montre ainsi cette étape préliminaire au codage, mais il reste encore beaucoup de chemin à parcourir …
Les diagrammes de classes de conception représentent bien la structure statique du code, par le biais des attributs et des relations entre classes, mais ils contiennent également les opérations (aussi appelées méthodes) qui décrivent les responsabilités dynamiques des classes logicielles. L’attribution des bonnes responsabilités aux bonnes classes est l’un des problèmes les plus délicats de la conception orientée-objet. Pour chaque service ou fonction, il faut décider quelle est la classe qui va la contenir. Nous devons ainsi répartir tout le comportement du système entre les classes de conception, et décrire les collaborations induites.
Les diagrammes d’interaction UML (séquence ou communication) sont particulièrement utiles au concepteur pour représenter graphiquement ses décisions d’allocation de responsabilités. Chaque diagramme d’interaction va ainsi représenter un ensemble d’objets de classes différentes collaborant dans le cadre d’un scénario d’exécution du système. Dans ce genre de diagramme, les objets communiquent en s’envoyant des messages qui invoquent des opérations sur les objets récepteurs.
Nous reviendrons dans un prochain article sur les diagrammes d’interaction de conception dans un environnement technique .NET et C#.
On peut donc suivre visuellement les interactions dynamiques entre objets, et les traitements réalisés par chacun. Les diagrammes d’interaction aident également à écrire le code à l’intérieur des méthodes, en particulier les appels imbriqués. La figure suivante ajoute une étape du côté du code, mais ne nous dit pas encore comment relier tout cela aux cas d’utilisation.
Comment passer des cas d’utilisation aux diagrammes d’interaction ? Ce n’est pas simple ni direct car les cas d’utilisation sont au niveau d’abstraction des besoins utilisateurs alors que les diagrammes d’interaction se placent au niveau de la conception objet. Il faut donc au moins une étape intermédiaire.
Chaque cas d’utilisation est décrit textuellement de façon détaillée, mais donne également lieu à un diagramme de séquence simple représentant graphiquement la chronologie des interactions entre les acteurs et le système vu comme une boîte noire, dans le cadre du scénario nominal. Nous appellerons ce diagramme : diagramme de séquence système.
Par la suite, en remplaçant le système vu comme une boîte noire par un ensemble choisi d’objets de conception, nous décrirons l’attribution des responsabilités dynamiques, tout en conservant une traçabilité forte avec les cas d’utilisation. La figure ci-après montre ainsi les diagrammes de séquence système en tant que lien important entre les cas d’utilisation et les diagrammes d’interaction de conception.
Mais comment trouver les objets de conception qui interviennent dans les diagrammes d’interaction ?
Le chaînon manquant de notre démarche s’appelle les diagrammes de classes participantes. Il s’agit là de diagrammes de classes UML qui décrivent, cas d’utilisation par cas d’utilisation, les trois principales classes d’analyse et leurs relations.
- Les classes qui permettent les interactions entre le site Web et ses utilisateurs sont qualifiées de « dialogues». Ce sont typiquement les écrans proposés à l’utilisateur : les formulaires de saisie, les résultats de recherche, etc. Elles proviennent directement de l’analyse de la maquette.
- Celles qui contiennent la cinématique de l’application seront appelées « contrôles». Elles font la transition entre les dialogues et les classes métier, en permettant aux écrans de manipuler des informations détenues par un ou plusieurs objets métier.
- Celles qui représentent les règles métier sont qualifiées d’« entités ». Elles proviennent directement du modèle du domaine, mais sont confirmées et complétées cas d’utilisation par cas d’utilisation.
Un avantage important de cette technique pour le chef de projet consiste en la possibilité de découper le travail de son équipe d’analyste suivant les différents cas d’utilisation, plutôt que de vouloir tout traiter d’un bloc. Comme l’illustre la figure ci-après, les diagrammes de classes participantes sont particulièrement importants car ils font la jonction entre le les cas d’utilisation, la maquette et les diagrammes de conception logicielle (diagrammes d’interaction et diagrammes de classes).
Pour que le tableau soit complet, il nous reste à détailler une exploitation supplémentaire de la maquette. Elle va nous permettre de réaliser des diagrammes dynamiques représentant de manière formelle l’ensemble des chemins possibles entre les principaux écrans proposés à l’utilisateur. Ces diagrammes, qui mettent en jeu les classes participantes de type « dialogue » et « contrôle », s’appellent des diagrammes de navigation.
La trame globale de la démarche est ainsi finalisée, comme indiqué sur la figure suivante.
Nous avons ainsi obtenu un schéma complet montrant comment, en partant des besoins utilisateurs formalisés par des cas d’utilisation et une maquette, et avec l’apport d’une analyse orientée-objet, on peut aboutir à des diagrammes de conception qui permettent de dériver du code assez directement.
Notez que nous n’utilisons pas les treize types de diagrammes proposés par UML 2.0, mais seulement un tiers, en insistant particulièrement sur les diagrammes de classes et les diagrammes de séquence. Cette limitation volontaire permet une réduction significative du temps d’apprentissage de la modélisation avec UML, tout en restant largement suffisante pour la plupart des projets. C’est cela aussi la « modélisation agile » !