Principes et positionnement

L'approche MDA repose sur la construction de modèles qui représentent l'application à développer. Les modèles PIM représentent les aspects fonctionnels de l'application. Dans une approche par transformation, où les PSM sont générés automatiquement, la qualité des PIM est primordiale.

En effet, dans ce cadre, les PIM ne sont pas simplement des vues sur le fonctionnel de l'application, ils sont le coeur fonctionnel de l'application.

La publication et la validation des modèles d'analyse fonctionnelle détaillée en particulier, sont donc cruciales.

Notre expérience nous a fait identifier quelques bonnes pratiques :

• Adopter une approche qui s'appuie sur des exemples : il est nécessaire de manipuler les spécifications pour « sentir » les problèmes.
• Associer très fortement les utilisateurs/experts du métier
• Adopter une démarche incrémentale et mettre à jour les modèles suite aux retours des utilisateurs.
• Les itérations se doivent d'être à faible coût en raccourcissant au maximum les délais entre étapes.

Face à ces besoins le réflexe maquettage/prototypage semble la bonne réponse. Néanmoins plusieurs problèmes se posent :

• Le maquettage (dessins d'écrans de l'application cible) permet une validation « en surface » sans lien objectif avec les modèles.
  Sans nier l'utilité de ce type d'approche, il convient d'observer que la qualité de la correspondance entre les modèles fonctionnels produits et les besoins exprimés dans les maquettes d'écran est très difficilement vérifiable : et en pratique, souvent de qualité faible. Par ailleurs, la validation se limite souvent aux problèmes d'ergonomie de l'interface utilisateur.
• Lorsqu'on s'intéresse plus précisément à la validation des concepts identifiés dans les modèles fonctionnels, on construit alors des prototypes fonctionnels permettant de tester en vraie grandeur les concepts exprimés dans les modèles.
  Cependant, les problèmes de coût limitent cette approche à des problèmes très ciblés : on fait du « carottage », donc la validation est très localisée.

La génération automatique de prototypes fonctionnels résout les problèmes précédents. Elle s'affranchit de l'interprétation humaine des modèles UML (donc des erreurs corollaires), et permet de travailler sur l'ensemble du modèle afin de l'appréhender de manière globale.

Elle nécessite l'utilisation d'outils puissants dans les concepts afin de produire des prototypes pertinents vis à vis des modèles, et efficaces dans leur mise en oeuvre, afin de permettre des cycles courts sur un mode fortement itératif.

Le prototypage et D.OM

D.OM est le premier outil permettant de valider des modèles UML par génération de prototype (simulation de modèles).

Les prototypes générés par D.OM sont de véritables applications dotées d'une interface homme machine et permettant de gérer des données et des jeux d'essais. Les utilisateurs peuvent ainsi, durant la phase d'analyse, tester directement les fonctionnalités de leur application.

Les prototypes sont produits de manière entièrement automatisée, ce qui permet de répéter à volonté les expérimentations en limitant les coûts de développement.

Les retours utilisateurs suite à l'expérimentation peuvent ainsi être intégrés dans les spécifications au fur et à mesure.

Les spécifications elles-mêmes peuvent être réalisées à l'aide de D.OM ou d'un autre outil utilisant le formalisme UML (par exemple Rational Rose)

Plusieurs modules de D.OM sont commercialisés, chacun étant dédié à un type de modèles UML

• D.OM Statique s'appuie sur les modèles de classe et s'intéresse plus particulièrement à la validation de modèles métiers et applicatifs.
• D.OM Processus s'appuie sur les modèles dynamiques (diagrammes d'activités et de séquence) ainsi que sur des modèles de flux réalisés à l'aide de diagramme de classes ou d'instances. Il s'intéresse plus particulièrement à la validation de processus (métiers ou techniques).
• D.OM Use Case permet de structurer les prototypes générés par D.OM Statique en fonction de l'expression de besoin (Use Cases). Il permet notamment de présenter des scénarios différents d'utilisation du modèle en fonction de l'interlocuteur (acteur) et améliore la pertinence des présentations et de la validation. Ce module est utilisé dans le cas de modèles très complexes ayant de nombreux cas d'utilisations.

Le cycle de modélisation avec D.OM

La production des PIM et en particulier du modèle d'analyse détaillée se fait donc sur un mode itératif en quatre étapes :

La première étape de modélisation est classique et s'attache donc à définir le PIM avec un niveau de détail élevé (processus, données, règles de gestion).

La deuxième étape consiste en la génération automatique et intégrale d'un prototype fonctionnel : le prototype produit instantanément propose une vision fonctionnelle complète indépendante d'une plate-forme technique ou d'un développeur.

La troisième étape de présentation des prototypes nécessite de s'appuyer sur les cas d'utilisation du modèle à travers les scénarios identifiés dans la phase d'expression de besoins. Cela permet de poser les bonnes questions :

• Est-ce que les affirmations du modèle sont correctes ?
• Qu'est-ce que le modèle ne permet pas de faire ?

Cette phase est très interactive :

• Implication des utilisateurs/experts, qui décrivent les écarts du modèle par rapport à leur besoin réel non plus à partir de diagrammes UML mais sur le prototype généré
• Interprétation de ces réactions en terme de modification des modèles par l'analyste UML.

La quatrième étape consiste à intégrer les remarques faites dans l'étape précédente à mettre à jour les modèles et... à recommencer jusqu'à obtention d'une validation formelle.

L'expérience montre que, sur un sous-ensemble fonctionnel pertinent de taille courante (de vingt à trente classes maximum) trois cycles suffisent à obtenir un modèle complet et valide.

Remarque

Les prototypes peuvent être livrés directement aux « validateurs fonctionnels » moyennant :

• Un effort de pédagogie : il faut expliquer que les IHM présentées ne sont pas celles de l'application finale et qu'ils doivent valider les fonctionnalités de l'application et non son ergonomie
• La fourniture de jeux d'essais représentatifs : l'utilisateur doit pouvoir dérouler des scénarios réalistes (ou réels) d'utilisation de ses données. D.OM permet de saisir, et sauvegarder les jeux de données d'un prototype, et gère la reprise de données existantes lorsqu'un modèle est enrichi suite à un cycle de validation.

Les fonctionnalités associées

Les prototypes générés s'appuient sur une IHM graphique de haut niveau dont les possibilités d'interactions sont déduites de patterns identifiés sur le modèle. En particulier, les cardinalités, droits d'accès, rôles inverses, types de données sont exploités.

Les méthodes sont écrites à l'aide d'un langage de script permettant d'exprimer très naturellement les règles de gestion.

Une gestion des données persistantes complète et la possibilité de sauvegarder les jeux d'essai complètent les possibilités offertes nativement par les prototypes.

Par ailleurs les fonctionnalités suivantes sont également intégrées à D.OM :

• Génération de la documentation (HTML notamment)
• Navigation élaborée entre modèles
• Gestion de versions
• Import/export
• Paramétrage sur le modèle de la génération des IHMs
• Génération des prototypes en Java/Swing
• Paramétrage fin du mapping objet/relationel
• Génération automatique des scripts SQL