Du bon usage de l'abstraction (4 MDA et conclusion)

Peut on définir le niveau d’abstraction d’un modèle ? Quels sont les écueils à éviter dans la modélisation UML ? Comment susciter l’adhésion d’une entreprise à une démarche basée sur UML ? Comment combler les lacunes d’UML ? L’initiative MDA versus l’approche par DSL. Tels sont quelques-uns des thèmes abordés.

Du bon usage de l'abstraction (4)

Et MDA dans tout ça ?

Avec MDA, l’objectif déclaré de l’OMG est d’élever le niveau d’abstraction des modèles utilisés pour définir et construire des SI. A la lumière des articles précédents, cet objectif peu apparaitre incongru. Jetons donc un œil critique sur cette ambitieuse initiative. Mais avant cela, un petit rappel.

On désigne par le sigle MDA une initiative ambitieuse de l’OMG  qui vise à promouvoir la construction d’applications par modélisation plutôt que par codage. Pour faire face à la pléthore de plateformes de middleware actuelles, l’OMG propose dans son approche MDA d’utiliser deux types de modèles UML. Des modèles UML indépendants de la plateforme, les PIM (Plateform Independant Model), qui définissent de manière très rigoureuse les fonctionnalités métiers et le comportement d’une application sans toutefois comporter aucun aspect technique. Ces modèles PIM seront alors traduits en modèles dépendant de la plateforme, les PSM (Plateform Specific Models) par des outils qui utilisent des mappings standardisés par l’OMG. Avec MDA, le statut d’UML devrait donc progressivement évoluer pour passer d’un langage descriptif à un langage prescriptif. C’est d'ailleurs l’un des enjeux d’UML 2.

L’automatisation dans la production de code, on le voit, est étroitement liée à l’approche MDA. A ma connaissance l’un des outils les plus prometteur dans ce domaine (à condition d’avoir la foi en MDA) est probablement AndroMDA. En deux mots, AndroMDA est un framework de génération de code J2EE avec des « cartridges » préfabriquées qui ciblent les framewords de prédilection des javaistes : Struts, JSF, Spring, Hibernate, etc… Peut-être qu’un ou deux articles dans ce blog sur le sujet serait les bienvenus, c’est un sujet intéressant.

Dans ses objectifs à long terme l’approche MDA va même plus loin et ne se réduit pas à une simple génération de code. La possibilité de pouvoir littéralement « exécuter » des modèles abstraits et incomplets dans une phase précoce est même envisagée. Pour le moment cependant, je pense qu'il est sage de ranger ce type de spéculations dans la même catégorie que les machines à voyager dans le temps et autres systèmes de téléportation quantiques…

Plus sérieusement, je reste extrêmement dubitatif sur ce genre d’initiative généraliste et grandiose. Pour trois raisons :

• L’objectif qui vise à élever le niveau d’abstraction ne me semble pas le bon. Au risque de me répéter : il vaudrait mieux en créer de nouvelles sans relation avec UML, voir ci-dessous.
• Jamais, je n’ai lu la moindre esquisse d’argument qui viendrait conforter l’idée selon laquelle le travail de « décoration technique », nécessaire pour passer du PIM au PSM, serait plus simple, plus naturel ou plus sûr que d’écrire du bon vieux code Java ou C#.
• Le credo MDA de l’OMG reste largement un liste de vœux pieux mâtinés des vieilles litanies du  « faster-better-cheaper », et du « focus on business requirement » … et du concept plus rigolo de « future proof », rien de moins !

Une approche basée sur des DSL (Domain Specific Language) me semblerait bien plus prometteuse. Elle serait en cohérence avec la définition de l’abstraction que je propose plus haut.

Des langages tels que Java, C# ou même PHP sont des langages de programmation généralistes, pour l'essentiel inspiré du C++. Ils permettent de tout faire ! De la conception d'un simulateur de navette spatiale à un système de facturation chez PSA. Mais cette généralité est aussi leur principale faiblesse. Pour tenter de palier à cette inadéquation dans certaines couches de l'architecture logicielle, on construit des API, que l'on emboite sans bien en voir la fin... (les fameuses poupées russes !) Il n'en reste pas moins qu'une servlet ou une librairie de balises JSP ou la classe 'UserTransaction' restent des classes Java (je connais moins bien .NET).

Une notation comme UML se veut elle aussi généraliste (et ce en dépit des lacunes évoquées précédemment). Hélas pour l'instant UML n'est pas encore un langage de programmation mais plutôt encore un langage de description. Et ce n'est pas les quelques outils de génération de code à partir de diagrammes de classes qui feront significativement avancer les choses. Ni même, selon moi, des framework comme AndroMDA. A moyen terme, UML reste donc avant tout  un langage de description généraliste.

A mon sens le progrès résiderait plutôt dans la mise au point et la standardisation du plusieurs langages DSL adaptés à toutes les tâches «intermédiaires» de la conception et du développement. Ce que j’ai à l’esprit est une entreprise de définition et de standardisation d’une dizaine de DSL, disons au moins un par couche d’architecture logicielle :

• Un langage pour exprimer des règles de gestion. Vraisemblablement, le paradigme objet et toute l’expérience accumulée avec les moteurs de règles comme JRules pourrait être utilisée ici avec le plus grand profit.
• Une notation graphique et suggestive pour toutes les problématiques d’accès concurrents, de multithreading et de transactions.
• Un DSL pour les aspects sécurité d'accès et de définition des habilitations.
• Le langage d’accès aux bases de données relationnelles existe déjà. C’est SQL !
• Un langage pour orchestrer des workflow. Peut-être que BPMN pourrait en constituer le squelette.
• Le foisonnement technologique dans la couche de présentation laisse augurer qu'icion ne saurait se satisfaire d’un seul DSL avant longtemps. A minima, un DSL pour la logique de navigation, inspirée peut-être des concepts Struts et un DSL pour décrire tous les mécanismes de validation de surface.
• Tout ce que j’ai oublié…

Cependant, définir une dizaine de DSL ne suffira pas. Il faudra encore standardiser la manière dont ces langages s’articulent deux à deux. Par exemple l’articulation du langage SGBDR et du langage des règles de gestions pourrait bénéficier des années d’expérience dans le développement d’outils O/R.

Reste ensuite à écrire les IDE et les outils qui prendront en charge toute cette panoplie de DSL et qui guideront le développeur dans leur usage. Microsoft Visual Studio, semble-t-il s’insère dans une démarche de ce type. Une bonne âme nous écrira-t-elle un petit article sur le sujet ?

Conclusion

Pas facile de conclure sur un sujet aussi kaléidoscopique. En vrac quelques sujets qui me tiennent à cœur.

Un mot sur le passage du niveau d’abstraction « ‘Quoi’ formalisé en UML » au niveau « ‘Comment’ formalise en UML (cf. article 2). Selon moi ce passage se fera d’autant plus naturellement que l’analyste UML aura un minimum d’expérience comme concepteur. Je vois d’ici certains sourcils se froncer, pourtant, il faut connaitre de l’intérieur, je crois, le travail du concepteur si l’on souhaite faire un modèle d’analyse dont il puisse tirer le meilleur profit. Souvenons-nous que le principal facteur de réussite d’un projet informatique est que chacun fasse un peu le boulot des autres ! (C’est là l’un des sujets de chamaillerie préféré avec mes collègues analystes lors de notre couscous hebdomadaire...)

Revenons aussi brièvement sur ce qui m’apparait comme une mauvaise habitude assez répondue : la valorisation exagérée des exemples comme moyen d’expliquer des concept ou des idées en informatique. C’est une tendance que l’on retrouve aujourd'hui chez beaucoup de jeunes ingénieurs. Certes, construire une bonne définition nécessite plus d'effort qu’énumérer une liste d’exemples. Mais c’est précisément cette difficulté qui en fait sa valeur : celui qui la crée se voit contraint de prendre position et de synthétiser en peu de mots une idée. Passer du mode « liste d’exemples » à un mode « définition » nécessite un peu de maturité. Mais c’est le passage du mode de pensée réactif et primitif à un mode de pensée plus anticipatif qui est en jeu.

A trop ignorer toute conceptualisation, on perd la compréhension de la raison d'être des outils que l’on utilise. On les utilisera donc de manière peu efficace. Il vaut la peine de comprendre, je crois, quels sont les problèmes qu’essaient de résoudre des frameworks comme Spring ou Hibernate ou un serveur d’application, avant de les utiliser ! Revaloriser la conceptualisation me semble par ailleurs aller de pair avec celle de la clarté dans l’expression orale ou écrite trop souvent négligée. Bon, ça fait peut être un peu vieux schnock ce que j’écris, mais j'assume ! Et qu’on ne me fasse pas dire ce que je n’ai pas écrit : je n’ai rien à titre personnel contre les exemples. Mais ils ne suffisent pas !

L’abstraction bien comprise, n’est en définitive qu’une recherche d’économie et d’efficacité de la pensée. Economie dans le nombre de termes utilisés pour définir un concept. Economie encore, car au moyen de l’abstraction, la pensée opère sur les bonnes catégories. Efficacité enfin, car l'abstraction permet de négliger le superflu dans un échange d'informations entre deux cerveaux humains. Comme n’importe quel outil, elle n’a pas de fin en soi et n’est pas un gage de qualité. Mais elle est, sans aucun doute, l’alliée de l’informaticien sous la pression de délais.

Développer l’intuition du bon niveau d’abstraction, chacun dans sa fonction, m'apparait en définitive comme l'un des aspects les plus gratifiants de notre métier.

Enfin, je vous laisse méditer ce petit aphorisme, tiré d’un ouvrage récent consacré aux systèmes complexes adaptatifs [5], qui m’a bien plu et qui n’est pas totalement sans relation avec notre sujet :

Learning about modelling is a lot like learning about sex: despite its importance, most people do not want to discuss it, and no matter how much you read about it, it just doesn't seem the same when you actually get around to doing it!

Bibliographie

[1] Pierre-Alain Muller, Modélisation objet avec UML (Eyrolles, 2003).

[2] Grady Booch, Ivar Jacobson, James Rumbaugh, UML 2 : Guide de référence (CampusPress 2004)

[3] Conallen, Concevoir des applications Web avec UML (Eyrolles 2000)

[4] Jean-Paul Delahaye , Information, complexité et hasard (Hermes science publications Paris, 1999).

[5] Miller John H., Page Scott E, Complex Adaptive Systems (University Presses Of California, Columbia And Princeton 2007).