D.OM GI

Dans le cadre de l'utilisation de D.OM en génération de code sur des projets en architecture multi-tiers, Objet Direct a bâti une infrastructure complète de génération pour une cible applicative J2EE. Cet environnement est regroupé au sein de la plate-forme D.OM GI. Les concepts utilisés sont conformes au MDA et s'appuient sur une forte agilité, induite par des cycles de développement très courts.

Au contraire des techniques habituelles, le code n'est pas généré pour un framework cible donné, mais le framework est lui-même généré. Cela permet une évolution du fonctionnel complètement indépendante de celle du framework technique et un véritable développement en parallèle des aspects techniques et fonctionnels. La complexité d'un framework générique disparaît, tout le code technique étant en fait spécifique mais entièrement généré automatiquement. On simplifie grandement l'architecture cible : dans le cadre d'un framework, on retrouve facilement jusqu'à 10 instances d'objets techniques pour un objet métier ou applicatif. On peut, ici, regrouper toutes ces fonctions dans un nombre restreints d'instances de classes générées spécifiquement pour prendre en charge les aspects techniques liés à un objet métier.

La version actuelle de D.OM GI permet la génération sur une architecture J2EE : JSP + Objet Métier + persistance Oracle ou MySQL comme le montre le schéma ci-dessous :

Le cycle de développement

On dissocie deux cycles en développement : le cycle d'analyse et le cycle de production du logiciel, comme le montre le schéma ci-dessous :

Le cycle d'analyse (orange) :

Il représente l'activité d'analyse des besoins utilisateur, par prototypage : l'analyste concepteur exprime le besoin en UML. Il génère ensuite un prototype qui est une vue exécutable du modèle UML. Il peut à cet instant échanger avec la maîtrise d'ouvrage pour valider sa compréhension du besoin fonctionnel, en déroulant les cas d'utilisation du logiciel directement sur le prototype. La maîtrise d'ouvrage émet alors ses observations qui sont prises en compte dans un nouveau cycle de modélisation/validation.

Ces cycles peuvent être très courts (inférieurs à la journée) ; cependant ils nécessitent - coté maîtrise d'ouvrage, un type d'interlocuteur qui a une vue fonctionnelle de ses besoins, et non ergonomique, comme c'est souvent le cas avec un utilisateur final de l'application.

Le cycle de génération (mauve) :

Il représente l'activité de production de l'application. Les phases essentielles sont :

• La génération de code ; réalisée à partir du modèle d'analyse précédent
• L'intégration ; qui consiste à développer les parties de code non couvertes par le générateur ; ce sont nécessairement des parties non fonctionnelles, et très souvent liées à des APIs externes. Ce code a une importance variable d'une part selon les projets, et d'autre part selon le domaine de couverture du générateur de code : dès que des services non fonctionnels sont présents au sein de nombreux composants de l'application, on a avantage à les coder dans le générateur.
• La validation utilisateur : l'application générée possède une ergonomie proche sinon identique à l'ergonomie finale. Les codes fonctionnel et technique ont été générés ou complétés par codage manuel. L'application peut donc être testée en vraie grandeur par les utilisateurs. Les retours utilisateur sont pris en compte dans le modèle d'analyse, et réintroduits dans l'application pour une nouvelle itération.

Caractéristiques de l'application générée

Maintenabilité

Le code généré est conforme au standard J2EE (Java, Beans, MVC notamment). Il est donc maintenable sans dépendance vis à vis des outils de génération MDA, D.OM GI en l'occurrence.

Pour traiter les évolutions ou corrections de l'application, deux possibilités sont couramment pratiquées :

• L'enrichissement des modèles puis la re-génération sur le code existant (le code manuel est préservé). Cette solution présente les avantages d'une cohérence entre modèle et code maintenue et d'une productivité optimale par la génération de code.
• L'enrichissement et/ou la modification directe du code existant, sans utiliser d'outil MDA. Cette solution convient lorsqu'on ne souhaite pas maintenir de compétence particulière sur le générateur de code.

Qualité de code

• Tests unitaires
  Notre expérience sur de nombreux projets MDA a montré que la génération de code réduit pratiquement à néant les anomalies révélées habituellement par les tests unitaires. Ceci est dû au fait que le code contenu dans le générateur est testé par les très nombreux scénarios d'utilisation de l'application elle-même (les use-cases de l'application) ; on observe une relation 1-n entre une partie de code du générateur donnée, et les zones de code générées correspondantes ; et une relation 1-m entre chaque zone de code générée et les scénarios de test qui utilisent ce code. Donc contrairement à une écriture manuelle du code, ici, une très petite quantité de code est testée par de très nombreux scénarios de test.
• Tests d'intégration
  Les anomalies d'intégration sont elles, maîtrisées par l'intégration en continu, qui n'est pas spécifique au MDA - le processus unifié ou l'extreme-programming l'ont également adopté. Cependant la spécificité de l'intégration en MDA réside dans la fréquence des itérations qui conduisent à une intégration : au lieu d'une intégration de l'ordre de 3 à 5 fois par semaine en processus unifié, on intègre ici, de façon automatique, à chaque génération de code, c'est à dire à la fréquence des compilations, pour une application de taille moyenne, ou chaque jour pour les très grandes applications (plusieurs centaines d'écrans, et de tables en BD).
• Tests fonctionnels et recette
  Le MDA n'apporte pas non plus de particularité à la phase de tests fonctionnels. Cependant, de même que pour les tests d'intégration, la fréquence de déploiement permet une mise à disposition en continu de l'application aux utilisateurs. Une fréquence de prise en compte des anomalies ou observations des utilisateurs finaux de 1 semaine (réunion de prise en compte et consignation hebdomadaire des anomalies avec les représentants des utilisateurs), a démontré son efficacité sur de nombreux projets.
  En conséquence la phase formelle de recette n'induit pas de retours utilisateurs conséquents et impactants sur un planning de production logiciel. Cette phase nécessite toujours d'écrire un cahier de recette - dont une partie est automatisable en utilisant un framework de tests d'IHM (HttpUnit par exemple) - , mais ne présente pas de risque de remise en cause importante de l'existant, lorsque les utilisateurs qui ont testé et consigné leurs anomalies tout au long du projet sont des représentants fiables des utilisateurs finaux.