MD Blog

Un logiciel constitué d’un corpus de plusieurs millions de lignes de code s’apparente à un système complexe (grand nombre de paramètres) : il devient difficile en particulier, de le faire évoluer de manière importante (refactoring massif, évolution de l’architecture) en garantissant sa stabilité. Les méthodes comme l’outillage à mettre en oeuvre pour ce genre de manipulation sont encore à découvrir.

Directement concernés par le sujet, nous travaillons, chez mon nouvel employeur (Kyriba) à l’élaboration d’un “outil de développement du futur” à travers le projet “Tron” (le nom étant déposé, il s’agit juste d’un nom de code interne).
Les travaux s’articulent autour de plusieurs axes :

• représentations du code (mots clés : modélisation, rétro-modélisation, projection, invariants, métriques, code mining) ;
• navigation dans le code (mots clés : interface homme-machine, réalité virtuelle, immersion, expérience utilisateur) ;
• manipulations du code (mots clés : interface homme-machine, refactoring, automatisation, model driven engineering, synchronisation, transformation de code).

Il y a plein de questions extrêmement ouvertes à l’heure actuelle. La première est celle de la représentation “alternative” du code : comment dépasser la vision hiérarchique du code via le couple arborescence de fichiers/code source ?
Comment “voir” le code d’une application complexe ? Quelles sont les projections pertinentes ? Comment extraire l’information du code (i.e. quelles parties du code peuvent être abandonnées, ou mutualisées sans altérer ou en altérant faiblement sa sémantique) ? En d’autres termes comment obtenir une représentation visuelle “compressée sans perte” du code (ou en maîtrisant précisément le niveau de perte) ? Comment peut-on décorer le code avec de l’information calculée (métriques) et utiliser cette information comme support de la représentation ? Peut-on adapter la représentation à l’utilisateur, à son « modèle mental du code » ?
Un exemple intéressant de ce qui se fait dans certains labos ne peut dissimuler le fait que ce sont des sujets relativement balbutiants (pas de grosse bibliographie sur le sujet).

Je vous parlerai des questions liées à la navigation et à la manipulation dans le prochain post.

Pas trop tôt ! L’OMG a enfin proposé un RFP pour une syntaxe concrète pour ASL (Action Semantics Language). Dit comme ça ça ne fait pas trop rêver :-) Pourtant c’est depuis longtemps un de mes dadas et un sujet dont je parle régulièrement dans mes présentations/séminaires MD.

La norme UML2 définit une syntaxe abstraite (un méta-modèle) pour décrire les actions sur un modèle statique : ASL. C’est ce méta-modèle qui est derrière une bonne partie des diagrammes dynamiques d’UML.

Autrement dit, aujourd’hui, pour décrire un comportement en UML (le contenu d’une méthode par exemple) on dispose des diagrammes dynamiques (activités, séquence, vue d’ensemble des interactions) mais pas d’un langage de programmation (une syntaxe concrète). Même si aucune norme n’existe, certains outils (peu finalement) incluent leur version propriétaire d’un tel langage :

• Kennedy Carter,
• Bridgepoint tous les deux autour des travaux de Stephen Mellor (celui de Schlaer et Mellor pour les plus anciens d’entre nous) avec Executable UML.
• et, last but not least, D.OM avec le célèbre D.Script !

Pourquoi suis-je si intéressé par le sujet ? A mon avis l’absence d’un tel langage dans les modeleurs actuels est un des freins majeurs à l’adoption de démarches MD.

Je m’explique : un modèle source d’une approche MD (le PIM en MDA), pour permettre de générer un pourcentage raisonnable du code (>50% sinon on est pas vraiment centré sur le modèle), doit inclure l’aspect comportemental (les règles de gestion du domaine par exemple).

En théorie il y a tout ce qu’il faut dans UML pour modéliser un algorithme avec les diagrammes dynamiques.

Dans la réalité celui qui a déjà essayé sait que l’approche n’est pas pertinente ! Si on veut pouvoir produire le code cible à partir de ces diagrammes ils doivent être équivalents à du code, c’est-à-dire être complets et extrêmement rigoureux.

Or les diagrammes dynamiques d’UML n’ont pas été faits pour être compilés : ils sont très difficile à maintenir et surtout, leur syntaxe, telle qu’implémentée dans les modeleurs, est toujours incomplète et la plupart du temps beaucoup trop laxiste.

Une syntaxe concrète (i.e. un langage de programmation) associée à ASL suffirait donc pour non plus modéliser, mais programmer en UML !

Avantage supplémentaire de l’approche : on peut simuler, et donc tester, ces méthodes avant même de disposer des transformateurs vers la plate-forme cible.

On espère que (pour une fois à l’OMG !) cette RFP donnera lieu rapidement à un standard dont les éditeurs s’empareront.

Même si quand on pense modèle, on voit le plus souvent un diagramme avec des boites et des flèches, il est souvent plus intéressant de produire un modèle sous forme de texte compréhensible par un humain.

C’est en particulier souvent bien plus efficace pour exprimer la composante dynamique du modèle. Ceux qui me connaissent savent que je suis à la recherche d’un Graal : une syntaxe concrète correspondant à la sémantique des actions d’UML (ASL en est la syntaxe abstraite).

Pour parler clairement : un langage permettant d’écrire le corps des méthodes en UML sans être lié à une technologie ou un langage cible.

Il y a peut-être de l’outillage en vue : TMF (Textual Modeling Framework) serait le pendant textuel de GMF pour la partie graphique. GMF est un framework générique pour instancier le (méta-)modèle EMF via des éditeurs graphiques. TMF permettrait la même chose via des éditeurs textuels.

C’est encore à l’état de « proposal » mais ça mérite d’être suivi.