Les Étapes du cycle d'un Projet Java réussi : la génération de code à partir de la modélisation

Aujourd'hui il est difficilement envisageable de modéliser une application objet en dehors de UML (Unified Modeling Language).
Cependant, faut-il croire aux promesses de plus en plus grandissantes des éditeurs concernant les outils de génération de code ? Autrement dit, UML peut-il faire disparaître la phase de développement ?
Après tout UML est un langage, alors pourquoi pas celui-ci plutôt que Java - .Net - PHP - et consort ? En effet, UML présente sur le papier l'intérêt d'être indépendant de l'architecture et de la plate-forme technique.

L'objectif de cet article est d'essayer de mettre en avant les efforts a consentir pour passer du rêve à la réalité.

Tout d'abord, précisons de suite que les éditeurs proposant le discours précédant mettent en avant le fait de réaliser la modélisation suivant les principes du MDA (Model Driven Architecture). En faisant une traduction rapide, on s'aperçoit que l'indépendance vis à vis de l'architecture est toute relative.
Allons plus loin dans le monde du MDA. Ce principe est lui-même décomposé en deux processus :
  • Le PIM, autrement dit, Platform Independent Model : Il s'agit ici de décrire une application indépendamment de la Plate forme à travers un modèle défini par exemple dans UML. Indépendance vis à vis de la plate-forme ne voulant pas forcément dire indépendant de l'architecture logicielle (Respect des conceptions MVC & DAO ou plus prosélitiquement Architecture N-Tiers).
  • Le PSM, ou encore, Platform Specific Model : Il s'agit ici de transposer le PIM en un modèle maintenant dépendant de la plate-forme. Pour faire simple , il s'agit d'appliquer des codes «modèles» (Code Template) pour chaque élément du modèle PIM.
Cela, peut paraître décevant, mais c'est ce qui se fait de mieux en la matière.
Pour résumer, pour escompter réussir une génération de code efficace (de 30% à 80% du code, le reste constituant les règles de gestion que l'on ne peut traduire en modèle sauf à inventer un Pseudo langage), il s'agit de construire :
  • Une méthodologie de modélisation (à travers UML) orientée PIM dont le résultat est un « Profil d'Analyse » traduisant une architecture logicielle (Association des objets UML et de leur stéréotype à un élément ou ensemble d'éléments de l'architecture logicielle Exemple : Classe de stéréotype «BusinessObject» correspond à un élément de la couche métier d'une architecture N-Tiers).
  • Un ensemble de codes «modèles» (PSM) qui implémente sur une technologie (EJB - .Net - PHP ou autre) chaque élément du PIM (ou Profil d'analyse).
Quelles sont les solutions que propose le marché pour industrialiser cette démarche ?
Deux voies s'offrent à vous :
  • Les outils de modélisation eux-même :
    • La grande majorité propose des Profils d'Analyse (Profil Model dans leur terminologie) «Clé en main» mais déjà associés à une technologie
      Il faut choisir d'abord la technologie d'implémentation pour obtenir le «Profil d'Analyse» adéquat (en fait, je choisis de modéliser mon application en Java, j'aurai des stéréotypes prédéfinis comme «EJBSession», «EJBEntity», etc.).
      Dans ce cas, immédiatement, les squelettes de code apparaissent dans un onglet «Preview».
      Cela à la couleur du MDA, mais ça n'en est pas.
      Cette gamme d'outils permet de générer environ 20% du code à partir d'une modélisation UML relativement légère.
    • Rares sont ceux qui permettent «facilement» (ici tout est relatif) de modifier ou de construire un profil d'analyse afin de lui associer des «codes template» plus riches (on choisit toujours une technologie). Cela a la couleur & l'apparence du MDA, mais ça n'en est toujours pas.
      On peut parler ici d'un niveau de génération pouvant atteindre 40% du code à partir d'une modélisation UML restant légère, mais sur laquelle il faut faire un effort de «Code templating» non négligeable (40 à 60 j/h) sur une technologie donnée.
    • Sont considérés comme des exceptions ceux qui permettent de construire un profil d'analyse réellement indépendant de la plate-forme technique, d'y associer des codes template «technologiques» et de choisir lors de la génération la cible d'architecture. Cela à la couleur, l'apparence & l'odeur du MDA.
      Ces outils permettent de générer jusqu'à 60% du code à partir d'une modélisation UML très fine (d'ailleurs à ce niveau, elle l'est tellement qu'elle est difficilement «désolidarisable» de la plate-forme technique et c'est là tout le paradoxe !!!), pour laquelle l'effort de «Code templating» est important (> 60 j/h) pour chaque technologie. MAIS, le patrimoine applicatif est alors principalement dans la conception et est donc indépendant de la technologie.
  • Les générateurs de code : Ils sont rares à ce jour.
    Leur principe est de :
    • Prendre en entrée :
      • un profil d'analyse,
      • la modélisation faite par un outil UML, sous la forme d'un fichier export XMI (standard d'échange des modélisations UML)
    • D'appliquer le «Code template» de la plate-forme technique cible (paramétrage) pour générer le code désiré.
      En cela, ils remplissent les mêmes fonctions que les outils UML faisant partie des exceptions, sauf qu'ils vous permettent de vous en rendre indépendant et de retenir un outil UML proposant uniquement la construction d'un Profil d'Analyse (à savoir, une nouvelle fois, la plupart).
    On peut définir à ce niveau 3 catégories d'outil :
    • Les « 1-1 » dans le sens où à un élément du profil d'analyse ils ne peuvent associer qu'un & un seul code template (tout comme d'ailleurs les meilleurs outils UML). Dans la plupart des cas cela suffit. Cependant, les EJB, les WebService sont composés de plusieurs éléments (Pour les EJB plusieurs classes, pour les WebService des classes & de fichiers de description XML). Dans ces cas de figure, il faudra modéliser autant de classes que nécessaire, si tant est que l'outil permette de « templater » deux technologies différentes (XML & Java par exemple). En tout état de cause, la modélisation est de moins en moins PIM (indépendante de la plate-forme)
      Cela à la couleur, l'apparence & l'odeur du MDA, mais est-ce du MDA. ?
      On reste dans la gamme des outils permettant de générer jusqu'à 60% dans les mêmes conditions que les outils UML «exceptionnels».
    • Les « 1-n » : Ils sont capables d'associer plusieurs «Code templates» de technologies différentes pour un même élément du profil d'analyse. La modélisation peut rester au niveau de l'architecture logicielle sans se dénaturer «technologiquement». C'est réellement du MDA.
      On reste dans la gamme des outils permettant de générer jusqu'à 60% du code mais avec une modélisation « légère » et réellement indépendante de la technologie.
    • Les « n-n » : En plus de ce qui précède, ils sont capables de composer suivant des règles des groupes éléments du profil pour créer un ou plusieurs «Code Template» de technologies différentes. C'est ainsi qu'à partir d'un diagramme d'activité (Elément 'Activité' de stéréotype «IHM», avec Elément 'Activité' de stéréotype «Action», avec Elément 'Transition', etc.) ou de séquence (Elément 'Objet' de stéréotype «IHM», avec Elément 'Objet' de stéréotype «Action», avec Elément 'Message', etc.), il est possible de générer l'ensemble des classes «ActionBean» (Java), «Struts-config» (XML), voir «Tiles-def» (XML) à implémenter sur le FrameWork STRUTS.
      On est dans la gamme des outils permettant de générer jusqu'à 80% avec une modélisation «légère» et réellement indépendante de la technologie, avec cependant un effort de définition des règles d'association « n-n ».
En synthèse, la génération de code à partir d'une modélisation est une réalité. Le niveau de «génération» dépend des paramètres suivants :
  • Niveau de finesse de la modélisation
  • Choix de l'outil de génération (outil de conception UML ou générateur à partir d'UML)
Pour les petits projets, peu complexes en terme :
  • de règles de gestion qui, rappelons le, ne pourront être générées
  • de navigation
on pourra se contenter d'un outil UML «Classique»
Peu de modélisation 30% à 50% codes générés.

A l'inverse, pour les grands projets complexes en terme :
  • de règles de gestion
  • de navigation
la modélisation étant indispensable (voire à inscrire comme référence du patrimoine applicatif), l'investissement nécessaire à l'intégration d'un outil de génération « n-n » est vite rentabilisé.

Enfin, en guise de conclusion, voici un petit graphique positionnant les indicateurs à prendre en compte et le positionnement des différents «types» d'outils de génération de code à partir d'UML.

Olivier HEDIN

Fermer
Imprimer
Contacts / Site