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. Cet article est également disponible sur mon blog perso.
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 ?
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
- 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.
- 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.
2. Capitaliser sur les concepts proches
- 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.
- 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écrite 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.
3. Élargir l’écosystème mobile
- Une taille d’application importante : l’utilisation massive de librairies est contraire aux bonnes pratiques pour le développement mobile (problématique d’espace mémoire).
- Corollaire du point précédent : une taille d’application trop importante peut être un frein à son téléchargement (débit 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 (Red Hat), Spring (Spring Source), 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.
4. Industrialiser le développement
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.
5. Réduire le coût de possession
- 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.
La réduction de la fragmentation du marché des OS de téléphonie mobile pourrait être une vaine quête…
En effet, la production de système d’exploitation de machines est une activité humaine où le gain de part de marché est conditionné
par la puissance de l’innovation technologique. Les coûts sont tels qu’il est vital que la concurrence ne puisse pas « contre attaquer »
rapidement par une innovation équivalente.
La mise au point de nouveaux dispositifs hardware couplés à l’invention de nouvelles facultés de programmation forment la stratégie
d’une avance technologique qui ne peut être rattrapée que par un investissement en R&D analogue.
Cependant, l’approche MDA a sa place sur le champ de bataille. Une fois les apports R&D conçus, l’approche MDA peut prendre tout son sens dans la ré-actualisation du code.
Ainsi, la capacité à re-générer du « boilerplate code » pourrait être une source d’économie importante dans le coût de la contre attaque.
T.L.
Remarque : normalement on devrait faire pouvoir tourner une application Android sous Tizen. Mais est-ce que ce sera toujours vrai à l’avenir ?
Bonjour Florent,
Super article de recherche sur MDA+Mobile!
Certainement, le MDA sur les mobiles est un sujet intéressant, mais il ne verra pas le jour, ni demain, ni avenir.
D’une part, parce qu’il y’a un enjeu politico-économique, d’autre part, il n’est pas imaginable un convertisseur multi-plateformes qui permet de convertir du code Java (Android) en code Objective-C (iOS) ou en Silverlight (Windows phone) et vice-versa.
D’abord, le langage Objective-C lui-même n’est pas portable, et puis faut-il imaginer un SDK commun supportant tous les langages mobiles (Java,…)?
Enfin, Je n’imagine pas un produit mixte, qui est à la fois Samsung, Iphone et WindowsPhone.
Cordialement,
Abdenour
@abou92:disqus La démarche MDA telle décrite dans cet article existe déjà. Il y a un framework du nom de Appcelerator qui permet d’écrire son code en Javascript (vue, logique et modèle). On choisit sa plateforme cible (iOS et/ou Android) et on a deux binaires 100 natifs avec les composants propres pour chaque OS.
Il ne faut pas confondre l’approche MDA avec un outillage de conversion langage vers langage.
Dans l’approche que j’ai décrite, on modélise l’application dans un langage indépendant de la plateforme cible, un PIM (Platform Independant Model) qui reprend des concepts indépendants de tout langage.
Ensuite, le générateur de code va transformer ce PIM en code spécifique (via un Platform Specific Model ou non).
L’idée du MDA, c’est bien d’avoir le modèle comme point d’entrée (le M de Model Driven Architecture). Ce modèle étant générique et réutilisable, indépendamment de la plateforme cible.
Mais cela dit, l’approche migration par le MDA serait tout aussi envisageable. Elle nécessiterait du parsing de code source pour remontée dans un PSM du langage source, une transformation vers un PIM avant une génération vers un langage cible. La démarche existe déjà sur un grand nombre de projet de migration Sodifrance. Elle n’est pas dépendante d’un type d’architecture (Grand système, JEE) et pourrait très bien être adaptée de la même manière à des projets mobilité.
Dans ce cas, on suppose que le code Javascript source soit notre modèle de base (et qu’il soit alors un DSL textuel)…et alors oui en effet, c’est une approche MDA qui correspond à l’approche de l’article : On définit une application avec des concepts standards dans un langage « haut niveau » indépendant de la plateforme cible et qui sert à générer une application vers un langage spécifique à une plateforme.
En effet, l’approche d’Appcelerator est intéressante et se démarque de Cordova (ex Phonegap) sur leur approche car l’applicatif devient un 100% natif et pas seulement une application Hybride.
Merci pour ce partage.
Super article.