5 Bonnes raisons du MDA pour le développement mobile

 
Article co-écrit par Florent Dupont et Lamia Gaouar, qui prépare actuellement un doctorat SIC autour des développements Android et MDA à l'université de Tlemcen.

La démocratisation des plateformes nomades (mobiles et tablettes) poussent les entreprises à proposer toujours plus de services aux utilisateurs. Elles ont, en effet, bien compris tous les enjeux qui se trament derrière les applications mobile : communication améliorée, nouveaux services aux utilisateurs, régie publicitaire, avantage concurrentiel, etc.

Cet engouement pour les plateformes nomades offre de nouvelles perspectives de marché, notamment pour les entreprises éditrices (que ce soient des Mobile Agencies, des Web Agencies ou encore des SSII) qui peuvent proposer leur expertise de développement. Depuis 2011, le marché des ventes de mobile dépasse les ventes de PC et offre donc des perspectives de marché de développement d’applications mobile très importantes.

Ces éditeurs doivent cependant s’adapter aux plateformes de développement mobile qui sont foncièrement différentes de celle des applications Desktop. En effet, ces plateformes imposent des contraintes fortes, les ressources étant limitées : taille d’écran réduite, processeur faible, stockage limité, connexion lente et intermittente, RAM limitée. Toutes ces limitations impliquent une discipline de développement particulière pour que l’expérience utilisateur soit toujours efficace.

Au niveau logiciel, de multiples OS (Android, iOS, BlackBerry, Windows Phone) se disputent le marché de la mobilité. A chaque OS correspond une plateforme de téléchargement d’applications, des outils de développement et un langage de programmation permettant le développement et la distribution des applications :

 

Cette hétérogénéité des outils de développement et des langages, rend difficile le développement d’applications mobile multiplateformes. Elle pousse les développeurs à faire un choix sur la plateforme, tout en assurant la plus grande distribution possible.

Des outils pour aider les développeurs ?

Google a récemment apporté un élément de réponse avec le projet J2ObjC qui permet de convertir du code Java (Android) en code Objective-C (iOS). L’intérêt d’une telle démarche est de pouvoir récupérer le code fonctionnel d’une application Android afin de faciliter la conversion vers la plateforme iOS.
Mais cette approche pose encore de nombreuses questions :

• Qu’en est-il de la conversion Objective-C vers Java ? Et vers d’autres OS  ?
• Et plus généralement, comment capitaliser sur le fonctionnel d’une application indépendamment des préoccupations techniques afin d’en faciliter la migration ?  

Une réponse avec le MDA

L’approche MDA a su faire ses preuves pour le développement d’applications d’entreprise et peut également apporter beaucoup pour les applications mobile. Au travers de 5 points, nous allons voir pourquoi et comment l’approche MDA peut nous aider à assurer la pérennité des savoir-faire, le gain de productivité tout en répondant aux problématiques de fragmentation des plateformes mobile.

1. Réduire les problématiques de fragmentation

Chaque OS mobile détient une part du marché, et donc chacun possède sa communauté d’utilisateurs et de développeurs. Cette fragmentation pose un souci pour les entreprises désireuses de toucher un large public car le développement des applications multiplateformes est très coûteux en temps et en argent. Les entreprises se trouvent face à un dilemme :

• Développer une application de qualité en un temps efficace et limiter sa distribution à une plateforme spécifique. 
• Développer une application aux fonctionnalités réduites, mais proposée sur plusieurs plateformes et à un large panel d'utilisateurs.

Des solutions hybrides existent comme Cordova (application native construite à partir de vue Web et Html5) ou Flex 4.6 (exécution sous plateforme Flash) et permettent d’assurer du multiplateformes, mais leur prise en charge reste techniquement partielle. En réalité, une application native restera plus adaptée pour plusieurs raisons :

• L’utilisateur dispose d’un environnement adapté à sa plateforme et à ses spécificités : l’expérience utilisateur reste optimale.
• Le développeur tire profit de l’architecture spécifique et optimise l’application en fonction de la plateforme.
• L’application peut évoluer et éventuellement tirer parti des fonctionnalités spécifiques à une plateforme ou OS.

L’approche MDA peut répondre à ces problématiques : décrire les besoins fonctionnels d’une application indépendamment de la plateforme d’exécution, et respecter les spécificités techniques de chaque plateforme. MDA permet de générer le code sans valeur ajoutée (boilerplate code) spécifique à chaque plateforme. On assure ainsi un gain de productivité, même sur des applications natives.

2. Capitaliser sur les concepts proches

Chaque OS mobile utilise son propre langage de programmation et arbore ses propres APIs mais les concepts généraux restent standards et communs. On peut se permettre de capitaliser des concepts communs entre différentes plateformes permettant de modéliser une application de manière générique, citons par exemple :

• Activité : correspond à une page de l’application, elle est une notion commune à tous les OS. Une application est composée d’une ou de plusieurs activités.
• Gestion des données de l’application : en séparant le code de l’interface graphique et le code fonctionnel.
• Vues et actions associées : une vue est un objet graphique par lequel l’utilisateur interagit avec l’application ce qui provoque une action liée à la vue. Nous retrouvons la plupart des vues sur tous les OS mobile : bouton, saisie de texte, label, barre de navigation, bouton radio, case à cocher, etc.
• Type d’évènements : une application doit prendre en charge certains évènements susceptibles d’apparaitre durant son exécution tels que les appels téléphoniques, les SMS, etc.
• Applications natives : les applications natives telles que le calendrier, les contacts, les alarmes, le lecteur média sont communs à tous les OS.

L’approche MDA divise la conception de l’application en deux points de vue :

• Un point de vue "fonctionnel" indépendant des détails liés à la plateforme d’exécution. On définit ce que l’on veut générer (le quoi). Dans cette partie, on modélise des notions abstraites telles que des écrans, boutons, objets métier, DAO, mais en restant indépendant de leur implémentation technique. Modéliser le fonctionnel de l’application assure la pérennité des savoir-faire.
• Un point de vue "technique" dans lequel sera décrit l’architecture de la plateforme d’exécution. On définit comment on veut le générer (le comment). Dans cette partie, on spécifie comment la notion fonctionnelle doit être générée : quel langage (Objective C, Java), quelle version (Android 4.1 par exemple), quelle implémentation de BDD. Modéliser l’architecture technique assure la prise en compte de la plateforme d’exécution.

L’étape qui suit la description fonctionnelle et technique d’une application est la génération du code source, c’est le rôle du générateur (ex. MIA Studio, Acceleo). Il s’appuie sur le modèle fonctionnel et technique de l’application pour générer du code source que le développeur pourra enrichir manuellement (le traitement algorithmique et les ressources qui ne peuvent pas être déduits du modèle). La modélisation nous assure une pérennisation du savoir fonctionnel. La génération de code assure un gain de temps considérable entrainant un gain de productivité.

3. Elargir l’écosystème mobile

L’écosystème - tout ce qui vit autour d’une plateforme pour en faciliter le développement - existant sous JavaEE/.NET est large, mais sur plateforme mobile, cet écosystème est encore réduit. L’utilisation de librairies tierces dans les applications mobile est limitée par les différents OS pour plusieurs raisons :

• Une taille d’application importante : l’utilisation massive de librairies est au contraire des bonnes pratiques pour le développement mobile (problématique d’espace mémoire).
• Corrolaire du point précédent : une taille d’application trop importante peut être un frein à son téléchargement (debit limité et frais des réseaux 3G).
• Le manque de visibilité des développements des librairies. Alors que les librairies pour applications JEE/.Net sont portées par de grands éditeurs (JBoss, Spring, Microsoft, etc.), les librairies mobile existantes sont quasi-exclusivement développées par des développeurs tiers. Le suivi et la maintenance ne sont donc pas toujours assurés.
• Les éditeurs Google, Apple, Microsoft gardent la main sur les évolutions des SDK et ne garantissent donc pas la compatibilité des librairies tierces avec les nouvelles versions des plateformes.

Pour assurer la pérennité du code et élargir son périmètre de compatibilité à plusieurs versions, il est donc préférable d’être indépendant au maximum des librairies tierces et d’avoir un code standard au SDK. L'approche MDA réduit le temps de développement en générant du code standard au SDK, en respectant les bonnes pratiques d’architecture et de qualité.

4. Industrialiser le développement

La mise en place d’une approche MDA, conjointement avec les différents composants d’une usine logicielle (construction, Intégration continue, analyse qualimétrique), industrialise le développement et assure une bonne qualité au code.
L’industrialisation avec le MDA nécessite plusieurs éléments clés :

• La mise en place d’un POC par une équipe d’architectes logiciels. Ce POC servira de base de code attendu pour faciliter la réalisation du générateur.
• Un code généré ne doit pas être source d’erreurs et doit rester compatible avec les niveaux de qualimétrie logicielle (qualité, architecture).
• Une formation des développeurs à l’utilisation du DSL et du générateur.
• Un support technique permettant d’accompagner les développeurs sur les outils afin d’assurer un bon démarrage du projet.
• Une communauté autour du générateur qui remonte les bugs. L’amélioration en continue du générateur profite aux développements en cours et aux prochains projets.
• Une capitalisation sur les bonnes pratiques de développement afin de développer des futures applications encore plus rapidement.

Sur le marché, il y a encore peu de développeurs avec des compétences “mobile”. L’industrialisation des développements mobile par l’approche MDA, a encore plus de sens dans ce contexte, car il permet d’avoir un meilleur accompagnement et un meilleur suivi.

5. Réduire le coût de possession

Avec des budgets toujours plus serrés, les entreprises veulent réduire le coût de possession de leurs applications. L’approche MDA, et plus spécifiquement le DSL et le générateur de code ont une grande valeur de capitalisation et de réutilisabilité. Elles permettent ainsi de réduire les coûts de possession, notamment sur l’investissement initial et le coût de maintenance  :

• Une conception facilitée par un DSL adapté, cadrant les besoins spécifiques aux plateformes mobile. 
• Un générateur de code disponible “sur étagère” et utilisable rapidement permet de booster le démarrage d’un projet. 
• Réduction du support technique : le code ou les patterns complexes et qui sont enclins aux erreurs (typiquement liés à la persistance, mapping ORM) sont générés.
• Un code de qualité suivant les bonnes pratiques assure une meilleure maîtrise et une réduction des coûts de maintenance. 
• Un processus itératif : l’outillage MDA par amélioration continue va réduire les coûts des projets progressivement au fur et à mesure de son amélioration.

Un OS peut aujourd'hui être leader du marché et demain perdre certains marchés. Un exemple, avec les annonces de Samsung, premier fabricant mondial de smartphones, qui compte  sortir de nouveaux smartphones en 2013 en abandonnant Android pour Tizen. Ou encore à l’image du géant chinois Huawei qui propose son propre OS mobile ou encore plus récemment Firefox avec FirefoxOS.



En conclusion, au lieu d'investir sur la technologie qui abrite une application, mieux vaut investir dans une technique de développement qui permet de capitaliser la fonctionnalité d'une application indépendamment de sa technologie. Une méthode qui intègre l'évolutivité et la pérénité dans son processus de développement comme l'approche MDA.

Les limites du MDA en entreprise

Je souhaitais faire un retour d'expérience concret sur les cas "typiques" de limites de l'approche MDA en entreprise d'un point de vue "développeur". Ces limites peuvent pousser, dans certains cas, à abandonner l'approche MDA.
Ce retour d'expérience personnel est issu de plusieurs points de vue : de mon œil neuf que j'avais lorsque j'ai débuté et que j'étais "utilisateur du générateur", puis d'un œil plus expérimenté en tant que "concepteur de générateur" et en condensant les retours d'expériences des développeurs au sein de différents projets utilisant l'approche MDA.

Une idée du contexte : les DSL ne sont pas forcément Turing-complet mais, dans tous les cas, le générateur mixe code manuel et code généré (approche par balises comme défini dans l'article précédent). Les DSL sont dans tous les cas des modèles (je n'ai pas de retour d'expérience sur des DSL texuels). Ils sont indépendants ou basés sur une extension d'UML avec des profils.

Les cas limites du MDA

L'inexpérience du développeur
Le développeur débutant ne connait pas les enjeux liés à l'approche MDA.
Il développe en dehors des balises prévues à cet effet et remet en cause l'outillage MDA de lui avoir fait perdre tout son travail.
Il considère que le code généré est trop compliqué à lire et à modifier et préfère considérer sa propre approche.
La phase de conception peut également être problématique pour les développeurs qui veulent tout de suite "coder du technique". Le cas le plus typique étant les développeurs avec une vision bottom-up et qui souhaite modéliser la base de données sans vision fonctionnelle ( "Comment ça je ne peux pas modéliser une colonne de table du type CHAR(3) pour Oracle ?" ).
Finalement, il laisse tomber l'approche MDA.

Le temps  (ou la paresse du développeur...)
Le développeur connait les intérêts de l'approche MDA, mais considère le round-trip trop consommateur en temps et préfère modifier le code sans passer par le modèle.  En fin de projet, les délais sont serrés et le modèle devient moins prioritaire : seule la livraison compte !

La raison est simple : ajouter du code depuis l'IDE lui prend très peu de temps comparé au temps de round-trip : modélisation, export XMI, validation du modèle, génération, vérification de la validité du code. Sans compter le temps d'ouverture des outils, le temps de chargement (du modeleur et du générateur) qui s’avèrent non négligeable. La fréquence de round-trip s'avère donc incompatible avec des délais courts.
De plus, la plupart du temps, le modèle ne fait pas partie de la livraison. Refaire une étape de modélisation n'est donc pas jugée prioritaire.

En solution, le développeur ajoute un maximum de code manuel alors que ce code pourrait être intégré au modèle. Finalement, il se rend compte que le modèle n'est plus vraiment à jour, et que la resynchronisation modèle / code sera coûteux et ne sera donc fait qu'"après la livraison, quand on aura plus de temps". Traduisez par "Jamais".

La perte de code
Le développeur effectue des roundtrips réguliers, mais il s'aperçoit que certaines portions de code ne sont pas correctement regénérées et lui font perdre son code manuel.
Ce cas peut arriver pour plusieurs raisons :

• Les balises de code manuel peuvent être supprimées lors d'une réorganisation automatique du code par l'IDE.
  Par exemple, les balises autour des zones d'import de fichier Java sont souvent effacées lors d'une "réorganisation des imports" sous Eclipse. Sous FlashBuilder 4, les zones d'imports des AS3 sont systématiquement supprimées.
• Les balises peuvent être modifiées lors d'un reformatage.
  Par exemple, Eclipse formate les commentaires : les balises (qui sont des commentaires) sont modifiées et ne sont donc plus valides. 
• Une maladresse du développeur, une balise est modifiée et le code manuel n'est pas ré-intégré.
• Un refactoring qui n'est pas pris en compte par l'outillage : Comment gérer les refactoring de méthodes, de classes ?
  Par exemple, les balises de code manuel pour les méthodes sont constituées de la signature de la méthode. En cas de changement de celle-ci, la balise est changée et le code perdu.
  Autre exemple, pour les renommages de classes : Un classe Toto devient un fichier Toto.java. Lors d'un renommage de Toto en Titi, le code de la classe existante Toto.java n'est pas ré-intégré dans Titi.java. Titi.java est vierge de tout code manuel. Toto.java est toujours présent mais orphelin.
• Certains fichiers entièrement générés ont besoin d'être customisés par le développeur. Le développeur modifie donc le code généré consciemment. Lors d'une regénération, le code sera perdu, mais le développeur récupérera les modifications dans le SCM et les ré-intégrera manuellement.  

Le temps passé sur le SCM à réintégrer le code perdu devient donc problématique. D'autant plus, lorsque nous préconisons une approche incrémentale, le développeur fera nécessairement plusieurs round-trip au cours du développement de son logiciel. Chaque round-trip nécessitant de la part du développeur qu'il vérifie que du code n'as pas été perdu. La fréquence de round-trip s'avère donc incompatible avec des délais courts (point précédent).
A ajouter également, le non déterminisme du générateur :  Lors de génération successive, pour un même modèle, le code généré n'est pas dans le même ordre. Ce principe s'explique car la spécification du méta-modèle (UML en l’occurrence) n'ordonne pas certaines relations entre objets.

Là encore, il pourra remettre en cause l'approche MDA (notamment sur la fin des projets) comme étant problématique.

La conformité du code
Le développeur perd du temps à corriger des erreurs dans le code généré : erreur de compilation, erreur à l’exécution ou encore pertes de performances.
Suite à un audit de code, ou une validation de qualité, il est démontré que le code généré est la cause de perte de qualité du projet. Le code généré entraine donc une dette technique qu'il faudra prendre en compte.
Plusieurs cas peuvent être remontés :

• Le code généré ne compile pas ou contient des portions de code au comportement douteux provoquant des bugs;

• Le code généré fait baisser la note qualitative du code source de l'application. Il n'est pas formaté correctement, n'est pas commenté, il est difficilement lisible et donc difficilement maintenable.

Le développeur perd du temps à remettre le code en conformité.

Ces points à eux seuls ne sont en général pas des causes d'abandon du MDA, mais peuvent faire baisser l'image de cette approche et peuvent avoir un effet cumulatifs avec d'autres points remontés précédemment.


Comment résoudre ces cas ?
Suite à ces différents cas d'abandon, j'ai défini 9 bonnes pratiques à suivre pour résoudre ces cas.

1. Former les développeurs et les chefs de projets pour leur faire comprendre les intérêts qu'ils vont trouver à l'approche MDA : démarrage du projet plus rapide, suivi des préconisations d'architecture logicielle concernant la stack logicielle de l'entreprise, qualité de code, fiabilité du code technique qui a été éprouvée par les architectes logiciels et dont le développeur n'a plus à se préoccuper.
2. Limiter le modeleur au DSL. Dans le cas où le DSL est une extension d'un langage existant (UML par exemple), il est nécessaire de customiser le modeleur pour limiter les possibilités de modélisation aux cas restreint par le DSL. Dans la mesure où on peut "ajouter" des concepts à UML, mais pas en "enlever", le modeleur ne pourra pas limiter toutes les possibilités offertes par le langage existant, ce qui nous amène au point suivant...  
3. Le modèle doit être validé, au moins en partie, pendant la phase de modélisation. Au même titre qu'un code qui ne compile pas, apparait en erreur dans l'IDE, il faut qu'un modèle qui ne soit pas valide apparaisse en erreur dans le modeleur. Ceci implique que la validation de la cohérence d'un modèle doit être faite au plus tôt dans la chaine de génération.
4. La qualité du modèle doit être remontée au plus tôt. Au même titre que le code peut avoir une note de qualité (par exemple dans Sonar), il doit être envisager d'avoir une note de qualité du modèle. L'approche MDA permet une meilleure qualité de code, mais n'empêche pas de modéliser n'importe quoi (tout en respectant les règles du DSL déjà validées par le point 4). Noter la qualité du modèle permet donc d'assurer une qualité de code accrue. Ce point nécessite également de mettre en place un document de convention de modélisation.
5. La chaîne de génération doit être transparente : la plus rapide et la moins intrusive possible pour le développeur. Idéalement le développeur devrait modéliser et développer de manière fluide en passant de son modeleur à son IDE de manière instantanée : L'étape de génération devrait lui être cachée !
6. Le code généré doit être correct (il ne comporte pas d'erreur de syntaxe), efficace (le code généré n'implique pas de pertes de performances et n'ajoute pas de bug supplémentaires à l'application), fonctionnel (Il a été validé par des architectes logiciels par un POC) et maintenable (il répond aux standards de qualité définis dans les conventions de codage).
7. Le générateur doit être déterministe : il doit toujours générer le même code (et surtout dans le même ordre) pour un même modèle en entrée.
8. Le générateur, par son action (lors d'une regénération) ou son inaction (modification du code par l'IDE ou erreur du développeur), ne doit pas faire perdre de code manuel.
9. Lors de la création du générateur, une étude importante doit être faite pour bien définir les zones de codes manuelles et les zones de code entièrement générées. Il faut pouvoir laisser des portes de sorties au développeur pour customiser le code et qu'il ne se sente pas restreint et  considère l'approche MDA comme étant limitative au développement.

Aller plus loin
Ces bonnes pratiques sont bien évidemment spécifiques à ma propre expérience d'un point de vue développeur sur le cas concrets des générateurs mixtes généré/manuel. Dans la suite des articles, j'expliquerai comment on peut faire en sorte de respecter ces bonnes pratiques.


Le point de vue concepteur de générateur apporte également tout un lot de bonnes pratiques à mettre ne œuvre pour que l'approche MDA soit un succès.
L'utilisation d'autres types de générateurs ou de DSL (DSL textuels par exemple) apportent également leurs lot de bonnes pratiques.

Internationaliser son DSL sous MagicDraw

Sous Magic Draw, avec un méta-modèle basé sur un profil UML, il est possible de customiser l'interface pour changer le libellé des éléments du DSL.

Cette possibilité offre l'intérêt de pouvoir internationaliser un DSL. On peut donc, pour des raisons techniques (ou de conventions par exemple) définir son DSL ( les stéréotypes et les propriétés de stéréotypes) en anglais et en avoir une représentation en français dans le modeleur (MagicDraw dans le cas présent).

Libellés sur les stéréotypes
Lorsqu'on crée un stéréotype et qu'on l'applique sur une classe, par défaut, cette classe va être représentée comme étant une Class <<stereotype>>.
Par exemple, si je crée un stéréotype <<DomainObject>> et que je l'applique sur ma classe "Product". Et si je crée un stéréotype <<IdDomainAttribute>> que j'applique sur l'attribut de ma classe "Product",  je vais obtenir ceci :  

Dans les spécifications, on voit qu'il s'agit d'une classe.

 

Il est possible de personnaliser le DSL pour que les éléments ne soit plus affichées comme des classes mais comme des éléments propre du DSL.
Voici les étapes à suivre :

• Créer une nouvelle Classe DomainObjectCustomization (ici le nom a peu d'importance, mais par convention, il est préférable de la suffixer par Customization)
• Appliquer un stéréotype <<Customization>> sur cette classe
• Editer les propriétés de la classe DomainObjectCustomization, puis renseigner "Hide Metatype" à true.
• Renseigner Customization Target à DomainObject
• Renseigner le Representation Text à "Domain".
• Renseigner le keyword à "Domain"

Faire la même chose pour personnaliser l'attribut :  

• Créer une nouvelle Classe IdDomainAttributeCustomization
• Appliquer un stéréotype <<Customization>> sur cette classe
• Editer les propriétés de la classe IdDomainAttributeCustomization, puis renseigner Hide Metatype à true.
• Renseigner Customization Target à "IdDomainAttribute"
• Renseigner le Representation Text à "ID".
• Renseigner le "keyword" à "ID"

En redémarrant (ou en rechargeant le modèle), on obtiendra les changement suivants :

Dans les spécifications, on voit maintenant apparaître Product comme étant un Domain et non plus comme une classe.

Pour info,
Hide Metatype permet de ne plus considérer Product comme une Class <<Domain>> mais comme un Domain.
Representation Text, comme son nom l'indique, permet de changer le texte de représentation du stéréotype. Une sorte d'alias qui sera utilisé dans la fenêtre des spécifications par exemple. Sauf que cette valeur n'est pas prise en compte dans le diagramme.
Keyword, comme son nom ne l'indique pas (du tout), permet de changer le texte de représentation du stéréotype dans le diagramme.




Libellés des propriétés de stéréotype


Dans l'exemple ci dessous, je définie une propriété du stéréotype "ServiceInterface" appelé "secured". Sans customisation, quand j'édite les propriétés sur une classe stéréotypée "ServiceInterface", le libellé a le même nom que celui indiqué dans le profil.
Mais il est possible de customiser le libellé, pour, par exemple, l'afficher en français.

 Les étapes à suivre pour mettre en place cette customisation :

• Ouvrir la customisation du profile pour l'élément concerné. Ici j'édite la customisation de "ServiceInterface" que j'ai nommé "ServiceInterfaceCustomization" :

•  clic droit dessus, puis "Nouvel Élément" -> "Propriété"

•   Le nom de la propriété doit avoir le même nom que la propriété du stéréotype. Dans mon exemple, la propriété s'appelle "secured".

• Éditer les valeurs de customisation de la propriété nouvellement créée, puis appliquer un stéréotype <<metaProperty>>

• Indiquer dans la valeur "New name" le nom qui sera dorénavant affiché pour cette propriété.

 Pour info, on peut également jeter un œil sur la présentation d'Andrius Strazdauskas, qui exposait, au MD-Day 2011, les avantages de créer son DSL en se basant sur UML et ses profils (et donc d'utiliser Magic Draw pour la customisation graphique du DSL).

Pour aller plus loin, la documentation officielle de Magic Draw sur le profiling et les DSL