Scala IO 2013 => Our journey from UML/MDD to Scala macros

Présentateur

Hayssam Saleh, CTO chez Ebiznext.

• Twitter : @hayssams
• LinkedIn : http://fr.linkedin.com/in/hayssams
• Github : hayssams
• Sa bio sur Scala IO
• La description de sa session ScalaIO

Le Talk !

Ce talk nous présente un retour d’expérience concernant une migration UML vers des macros scala pour modéliser une application.

Les inconvénients d’une modélisation basée sur UML

• Un cycle de vie peu efficace composé d’un enchainement de transformations : UML -> XMI -> Code -> ByteCode. Il fallait près de 4h pour avoir le livrable correspondant à une modification du modèle. L’étape la plus chronophage (78% du temps) était XMI -> Code.

• Pas de solution exploitable dans un vrai projet pour effectuer des merges de modèles UML. Ce qui entrainait la mise en place d’un lock (1 modification à la fois) pour éviter d’avoir à effectuer des merges.

• Le manque de représentation standard de certaines caractéristiques du modèle (Les génériques Java par exemple)

Un DSL comme alternative

Hayssam et son équipe ont proposé alors de s’orienter vers l’utilisation d’un DSL qui doit avoir les caractéristiques suivantes :

• Compréhensible du product owner
• Compilable du développeur

Des macros Slick

Les macros Scala utilisées sont basées sur Slick, un framework de persistance. Hayssam va nous présenter un exemple de modélisation avec une macro Slick et comment se traduisent les définitions des :

• Entités => case classes
• Relations 0..1 => Option
• Relations 1..1 => Composition d’entités
• Relations n..n => List
• Contraintes => via l’utilisation de mots clés du DSL

Un export UML

Les macros Slick vont permettre de générer des diagrammes UML via l’exécution d’une ligne de code.

La magie faite à la compilation, pas d’injection au runtime

Les macros Slick vont impacter le code à la compilation, le bytecode généré contient déjà toutes les transformations. Cela permet de profiter de toute la puissance du compilateur et donc du typage fort de Scala.

Pas de magie au runtime => à l’exécution, seul le code compilé est exécuté.

Slick permet aussi de contruire des requêtes qui vont profiter d’un typage fort facilitant la détection d’erreurs à la compilation.

Les slides de la présentation

Ce que j’en ai pensé

Je suis arrivé un peu par hasard dans cette session. C’était en fin de journée et je m’étais en fait trompé de salle :) Cela dit, je suis content d’y avoir assisté.

Il est intéressant d’avoir des retours d’expérience d’utilisation de DSL dans le monde de l’entreprise. La modélisation qui constitue souvent naturellement la richesse documentaire des applications est ici faite sans induire la double maintenance habituelle (modèle + code). Nous échappons ici à la génération de codes que nous détestons la plupart du temps en tant que développeur.

Ce qui m’a manqué dans cette présentation, ce sont les impacts sur le plan humain et organisationnel de cette migration. J’imagine que des personnes qui étaient habituées à modéliser via des boites ont dû, au moins au début, manifester une certaine hostilité face à ce changement :) J’aurai voulu savoir s’il y avait eu une stratégie particulière pour créer de l’adhésion autour de ce nouveau paradigme.

Pour en savoir plus, le dépôt Github https://github.com/ebiznext/slick-macros contient les exemples du Talk et ce Wiki documente la solution proposée.