Il y a 15 ans -
Temps de lecture 10 minutes
Soirée MDA et Flex au Paris JUG
Hier soir a eu lieu la 6e édition du Paris JUG. Comme à l’habitude, la soirée fut une franche réussite. Il est étonnant de voir à quelle vitesse l’association se développe. Le bouche-à-oreille faisant effet, hier près de 200 personnes étaient présentes, on est bien loin des 30 personnes du début d’année. Il faut dire qu’Antonio Goncalves et David Dewalle arrivent à faire venir du beau monde : par exemple à la venue de Kirk Pepperdine il y a quelques mois ou plus récemment de la soirée Spring où Julien Dubois, directeur régional France de SpringSource, a effectué une présentation .
Ce mois-ci, la soirée était divisée en deux parties complètement indépendantes (c’est d’ailleurs la première véritable soirée de ce genre depuis la création du Paris JUG). Grégory Weinbach de chez Objet Direct a ouvert le bal avec un sujet volontairement ‘polémique’ : « Pourquoi tout le monde ne fait-il pas du MDA ? », suivi par une présentation Flex animée par James Ward, évangéliste Flex et représentant d’Adobe au JCP (JSR-286 : Portlet Specification 2.0, JSR-299 : WebBeans, JSR-301 : Portlet Bridge Specification for JavaServer Faces).
MDA
L’approche MDA n’est que la vision OMG du Model-Driven engineering, voyons ce qu’elle propose.
Traditionnellement les projets sont centrés sur le code de l’application à livrer. Il s’agit du principal livrable, c’est lui qui va driver les ressources, délais, qualité d’un projet. Or le code intervient assez tard dans la majorité des processus de développement. MDA nous propose un modèle différent : essayer de se rapprocher de l’utilisateur en concentrant notre énergie sur les phases les plus en amont du projet. Là ou les projets traditionnels sont code-centric, MDA propose une approche centrée sur l’analyse fonctionnelle. Si l’idée est louable, voyons comment cela se présente en pratique. On commence par déterminer le CIM (Computation Independent Model), ce modèle se définit suivant les exigences du client et représente l’application dans son environnement. Il ne contient pas d’informations sur la réalisation de l’application ni sur les traitements. Plus simplement, il définit ce que l’on veut automatiser. Ensuite, la deuxième étape consiste à créer un PIM (Platform Independent Model). Celui-ci va définir un modèle abstrait qui permet d’exprimer les exigences fonctionnelles. C’est sur lui qu’est consacrée toute l’énergie. Et enfin vient la création du PSM (Platform Specific Model). Ce modèle permet de résoudre aussi bien les exigences fonctionnelles que non-fonctionnelles. Il dépend nécessairement des technologies utilisées par la plateforme d’exécution.
En pratique, on note quasiment tout le temps une mauvaise conception du PIM. Certains n’y traitent qu’une partie de la problématique réduisant l’approche MDA à une simple génération de code. D’autres, moins nombreux, poussent le modèle à fond : syndrome du PIM obèse; du coup, la compression de fonctions sensée favoriser le gain de temps n’est pas possible, on aura au final passé plus de temps à définir les modèles que l’on aurait mis pour développer l’application. Du coup, certaines questions se posent naturellement : Quelles sont les bonnes pratiques pour modéliser une application ? Comment construire un PIM efficacement ? Comment conserver la motivation de développeurs dont le rôle se résume souvent à inventer des générateurs-de-code-shaddockien puis à ‘merger’ le code re-généré avec les ‘aujustements’ manuels ? Où recruter des analystes qui maitrisent UML 2, des formalismes de modélisation des algorythmes et tout simplement l’algorithmique puisque ce sont eux qui dévcrivent ces algorithme métier ? Questions auxquelles nous restons sans réponses en fin de présentation. D’autres problèmes majeurs interviennent à notre sens dans ce type d’approche. Il est utopique d’imaginer un reverse-engineering efficace. Il n’est déjà pas simple de générer du code à partir d’un modèle, surtout si le code généré est customisé (et c’est en pratique toujours le cas), il ne faut pas espérer de pouvoir retransformer le code en modèle. Certaines méthodes existent : l’utilisation de commentaires signifiants est dangereuse, l’analyse syntaxique sur le code produit est trop difficile à mettre en place. Si dans le meilleur des cas on arrive à remonter une ébauche de PSM, il est quasi impossible de remonter au PIM. Du coup, il ne faut pas espérer maintenir une synchro entre le modèle et le code généré.
Notre fibre agile a également été quelque peu malmenée pendant la présentation, l’utilisation du terme « agilité » pour MDA parait un peu galvaudée:
- les notions de conception émergente, de refactoring, de démonstrations au plus tôt et le fait de ne prendre les décisions les plus engageantes que le plus tard possible ne semblent pas compatibles avec MDA
- comment parler d’une méthode de développement et d’agilité sans mentionner une seule fois le terme « test »? Alors que, puisque le code peut être généré et que les modèles décrivent complètement les comportements, on pourrait imaginer que les tests unitaires et tests d’intégration pourraient également être générés non? Ce qui permettrait de vérifier le comportement de l’application lors de la phase nécessaire d’implémentation manuelle du code manquant après la génération.
Ces quelques questions restent là aussi sans réponse, mais saluons tout de même l’effort de Grégory Weinbach qui n’était pas du tout en terrain conquis!
Adobe Flex
C’est sans conteste que la présentation Flex a marqué l’esprit de cette soirée. L’assemblée ne s’y est pas trompée, peu de personnes présentes à la session MDA ont quitté la salle pour la session Flex. Le moins que l’on puisse dire c’est que James Ward prend son travail d’évangéliste à cœur. La présentation a été fluide, rythmée, ponctuée de whaou effects tout en gardant un côté didactique exceptionnel.
Aussi efficace que soit la technologie, pour qu’elle fonctionne, Adobe doit convaincre et donner envie aux développeurs d’applications serveur (Java ou autre) de l’utiliser. Voila pourquoi ils se déplacent dans ce genre de soirée : ce soir en France, demain dans d’autres JUG européens, il est nécessaire pour Adobe d’évangéliser les différentes techniques d’intégration entre ces deux mondes.
C’est suffisamment rare pour être signalé, et ceci convient parfaitement au public du Paris JUG, la présentation de James contient 90% de démonstration de code, et est très peu orientée marketing. Sans langue de bois, il est suffisamment confiant dans la technologie pour dire à son public: « Essayez Flex, si vous développez de belles applications qui fonctionnent, et que ça vous convient, tant mieux. Si vous arrivez à faire la même chose avec SilverLight ou JavaFX, tant mieux aussi! ».
Les exemples de code commencent par une application « HelloWorld » très simple, composée d’un DataGrid récupérant les données hébergées sur le serveur au format XML grâce à un HTTPService. On obtient à l’écran un tableau de données, triable, avec les tailles de colonnes redimensionnables. C’est simple, ça fonctionne.
James a ensuite listé les différentes techniques disponibles pour le dialogue client/serveur, soit on échange en XML, mais le coût de la sérialisation doit être évité autant que possible (« principe n°327 » de Marc Fleury d’après James), soit on utilise le protocole AMF (disponible lors de l’utilisation de BlazeDS côté serveur), protocole binaire propriétaire, consommé nativement par le client Flash. James héberge sur son site une application qu’il a développée, Census, qui permet de comparer les temps de traitement côté serveur, les temps de transfert, et les temps de traitement côté client. Entre un échange XML avec le flux gzippé et un échange en AMF, les temps de traitement côté serveur sont clairement en faveur de la version AMF; en revanche, la compression AMF est très simple (et peu coûteuse), et les temps de transfert sont en faveur de la version XML/gzip.
Arrivent ensuite LES démos de la soirée.
En premier lieu une application de type « chat ». Un écran simple, avec une zone réservée à l’affichage des messages, et un champ pour leur saisie. Le client Flex dialogue avec une application utilisant BlazeDS côté serveur, et utilise les composants <mx:Consumer/>
et <mx:Producer/>
. Cinq lignes de code. Premier effet.
Ensuite, James réutilise le DataGrid présenté plus tôt et le rend éditable. On obtient une application de type CRUD, et le client est prévenu dès qu’une modification est effectuée côté serveur.
Une simple modification de 2 lignes dans le code source de l’application permet ensuite de générer sa version « bureau », avec Adobe AIR. James exécute le client AIR, on obtient exactement la même interface. Il fait une modification dans une ligne du DataGrid, et on voit la modification apparaître immédiatement sur la version Flash sur Firefox en arrière-plan! Deuxième effet, salve d’applaudissements.
Enfin, nouveauté de la dernière version d’Acrobat Reader, on peut maintenant intégrer dans un PDF une application Flash. James intègre donc dans un PDF le DataGrid éditable, apporte une modification sur une donnée, et boum, on voit la modification apparaître sur les deux autres clients, le client Flash dans Firefox, et le client de bureau AIR. Troisième effet, la foule est en délire!
La présentation s’est terminée par une série de questions, sur des sujets que James n’a pas eu le temps d’aborder (la présentation est assez courte, et il est déjà tard):
- qu’il y a t-il de mauvais dans Flex? James répond très franchement, l’intégration de blocs HTML dans une application Flash reste compliquée, mais des améliorations sont à attendre, l’intégration est par exemple bien meilleure dans les applications AIR. En revanche, les applications/sites Flash/Flex n’étaient pas indexables par les moteurs de recherche, c’était facheux, mais c’est réglé depuis la semaine dernière.
- à quand une solution Flash/Flex sur les mobiles? le projet Open Screen est là pour ça, on verra arriver Flash/Flex sur les mobiles dans les deux années qui viennent
- qu’en est-t-il des tests? le code ActionScript peut être testé avec FlexUnit, et une version Flex de Selenium est en cours de développement
- qu’en est-t-il de l’accessibilité? alors là, la réponse est impressionnante, quand on sait les surcoûts que représentent l’accessibilité dans le développement d’un site/d’une application HTML. Il suffit d’activer un flag à la compilation pour rendre l’application accessible (le Flash généré aura une taille supérieure, c’est pour cette raison qu’il n’est pas activé par défaut). A tester en conditions réelles, mais c’est extrêmement séduisant!!
En résumé, une présentation fraîche et spontanée, franche et pragmatique, donnée par une pointure, James Ward a conquis l’assistance en moins d’une heure.
Les conférences Paris JUG, qui se tiennent une fois par mois, sont gratuites et ne nécessitent qu’une inscription préalable sur le site, si le Paris JUG continue sur des présentations de cette qualité, les salles de 200 places ne seront bientôt plus suffisantes! On en redemande!
Voir aussi:
- un retour sur Touilleur-Express
- Samuel Liard a déjà réagi à l’article de Nicolas Martignole sur son blog
Commentaire
5 réponses pour " Soirée MDA et Flex au Paris JUG "
Published by Samuel , Il y a 15 ans
je comprends mieux vos réactions quand je lis que Grégory à oublié de parler de test ! :)
Comme j’en parle dans mon post (que vous avez gentiment référencé ;) ) l’approche MDA nous à permis d’écrire des tests sur nos services EJB avant de les avoir implémentés. On peut bien sur imaginer en générer une partie.
C’est ce qu’a fait Acceleo dans son module J2EE, ils génèrent les pojo, les dao, les descripteurs ET les JUnit.
Acceleo, outil MDA basé sur Eclipse EMF que je vous conseil ;) http://www.acceleo.com
Published by Gabriel K. , Il y a 15 ans
Pas aussi séduit par la démo Flex.
Le côté je mets une ligne code et on retrouve un tableau avec du tri, des trucs comme ça, on peut le retrouver en jsp (c’est quoi déjà le nom de cette taglib ultra célèbre??), jsf (rich datagrid) , tapestry, wicket, gwt. Et côté client, avec ExtJS, yahooUI et pas mal d’autres. Et en php, et en rails…
Idem pour la démonstration de comet. Il suffit d’aller sur les sites de Tomcat, de jetty ou de dojo ou dwr.
En fait en voyant cette démo je me suis dit « Le fameux Flex… mais c’est que ça?? impressionnant ». Oui, impressionant comme c’est la même chose que tout le monde… Peut-être en plus simple? A vérifier. Franchement instancier un objet avec extJS n’a rien de sorcier. Peut-être en plus « non standard » et lié à un seul éditeur, aussi…
Je ne doute pas qu’on puisse faire plein de trucs marrants, graphiques et tout ça mais faut quand même pas exagérer, c’est pas une révolution.
On va me dire : »au moins on fait pas de javascript ». Marrant, ActionScript est largement inspiré de javascript. Et un des deux a la réputation d’être un langage de ninja, et l’autre d’être un langage surper facile. ya comme qui dirait un truc…
Voilà. Pas bluffé, et j’en suis triste…
Published by Gabriel K. , Il y a 15 ans
PS : si, quand même, la coordination des datagrids par comet était pas mal :-)
A intégrer donc dans les prochains développements en javascript..