Il existe diverses approches du développement d’applications. Toutes ont pour but de rationaliser le procédé de mise au point des applications afin de satisfaire au mieux les besoins. Parmi les approches couramment utilisées, on distingue le développement spécifique, les L4G, les suites BPM et le MDA. Par Jean-Loup Comeliau de W4.

1 Le développement spécifique permet aux développeurs de concevoir avec exactitude les applications voulues, avec les technologies de leur choix. L’informatique choisit un langage de programmation et des API afin d’utiliser des composants plus abstraits, par exemple pour coder l’interface utilisateur. Il faut alors pouvoir se connecter au système d’information, alimenter les écrans avec les données physiques existantes via SQL ou équivalent. Si des processus métier entrent en jeu, il faut alors également synchroniser par programmation les valeurs des variables en fonction des rôles et de la planification des tâches et orchestrer le système. Il est vrai que les ateliers de conception graphique peuvent accélérer l’obtention d’écrans et d’une IHM, mais le « câblage » des vues spécifiques avec les données demeure alors à faire, en lecture ou en mise à jour. Le développement spécifique demande donc à l’informatique d’avoir à sa disposition des experts techniques dans différents domaines et la maintenance devient souvent coûteuse.

2 Les L4G (Langage de 4ème Génération) sont une solution courante car ils permettent à l’informatique d’adresser simultanément et sans complexité les différentes couches logicielles nécessaires aux applications, Modèle-Vue-Contrôle. Conçue pour réduire l’effort de codage et le temps de développement, cette approche permet aux non-experts de la technologie de développer des applications. Cependant, les L4G résultent souvent en des solutions propriétaires, limitées fonctionnellement et peu flexibles. C’est une option satisfaisante pour des besoins relativement simples dans des environnements bien définis et confinés, mais le manque d’ouverture, les limitations fonctionnelles, l’impossibilité de concevoir des écrans sophistiqués sont souvent un obstacle.

3 Les suites BPM (Business Process Management) sont souvent envisagées pour le déploiement à grande échelle d’applications principalement axées sur la formalisation des processus métier et leur exécution. Avec des fonctionnalités avancées pour la gestion sur-mesure des processus métier, des rôles, des priorités de la traçabilité et des politiques d’orchestration, les suites BPM permettent aux services informatiques de créer et déployer des applications en s’appuyant sur un environnement centré sur la définition des processus. Cependant, de tels outils sont souvent très chers, surdimensionnés et sous-exploités, et ils ne permettent pas de modéliser les données applicatives, ni de créer des IHM sophistiquées.

4La démarche MDA (Model Driven Architecture) (de l’OMG) permet à l’informatique de mieux équilibrer ses efforts en se concentrant plus sur les aspects métier que sur les aspects technologiques. C’est ce qu’on appelle « the separation of concerns », où les développeurs se focalisent sur le modèle métier alors que les outils automatisent la partie technique en automatisant la concrétisation du modèle pour la plateforme cible, pour laquelle on génère du code correspondant au modèle. Ce code doit ensuite être compilé, déployé vers la cible et aligné avec les librairies natives de l’environnement. Cette phase de génération de code ralentit souvent le déploiement et requiert un outillage lourd pour s’assurer que modèle et code généré restent en phase. De plus, les outils MDA n’intègrent généralement pas la dimension processus métier.

Une approche plus appropriée : Modéliser-Exécuter

Dans une approche du développement basée sur les modèles, la définition du modèle est un préliminaire pour toute application, comme c’est le cas pour la démarche MDA. En élargissant le périmètre du modèle pour y intégrer, en plus des données et de l’IHM, la définition des processus métier, la DSI peut pousser l’automatisation du développement plus loin et produire de nouvelles applications beaucoup plus rapidement.

Une telle conception à partir des modèles assure une collaboration efficace dès le début et renforce l’adoption de l’agilité. La DSI peut ainsi visualiser conceptuellement le monde métier, puis mettre au point des applications fonctionnelles en les ajustant aux besoins des utilisateurs. Les composants du modèle sont les briques fonctionnelles qui permettent de traduire directement les besoins des utilisateurs en termes applicatifs. Tous les éléments des processus, des données et des IHM peuvent être modifiés « à la demande ».

Une fois le modèle complété et stabilisé, l’approche traditionnelle pilotée par les modèles requiert que le développeur le transforme en une application en passant par des étapes variées : définition de la plateforme d’exécution (PC, station de travail, smartphone, tablette…), transformation du modèle abstrait en modèle concret, génération du code, compilation, déploiement et, finalement, exécution. Ce procédé lourd ralentit non seulement l’exécution initiale de l’application, mais aussi les phases de maintenance et de mise à jour des versions déployées sur sites.

Afin d’accélérer le développement agile des applications, il est utile de proposer des outils pour créer des applications sociales et collaboratives où l’exécution directe du modèle élimine les étapes intermédiaires de transformations de modèles et de génération de code. Dès qu’un modèle existe, il est exécutable.

Modéliser-Exécuter = des applications déployées et modifiées à la volée sans génération de code

Pour l’entreprise, le modèle devient alors une représentation logique complète de son environnement fonctionnel. Il inclut une description :

• de la structure des objets métier, par utilisation de classes, d’attributs typés et de relations
• des processus métier à suivre, avec leurs étapes, transitions, conditions et rôles

Le modèle inclut une description de l’IHM directement liée aux objets modélisés qui permet l’automatisation de la production des écrans utilisateurs.

Cette description comprend :

• l’arbre de navigation, qui décrit comment accéder aux différents écrans et actions disponibles pour les utilisateurs finaux, avec des redirections possibles vers du code Java « maison » pour l’implémentation d’une logique fonctionnelle particulière
• les types de vues à utiliser pour gérer les données (tables, arborescences, formulaires, cartes….) et leurs dispositions graphiques
• un ensemble de ressources et de composants graphiques tels que des icônes, des images, des polices de caractères, des chartes graphiques et des labels et messages

Contrairement aux autres environnements empiriques de développement, où une phase de conception minimale de l’IHM doit précéder l’exécution, une solution aussi performante rend disponible instantanément des écrans par défaut, propres à permettre la gestion des données et la mise en œuvre des processus, tels que décrits dans le modèle. Pour une personnalisation plus poussée, les développeurs peuvent ensuite affiner l résultat par configuration ou par programmation.

Exemple : Prenez une application de demande d’achats. Définissez simplement les classes logiques (Demande, Fournisseur, Article, Achat, etc.) et leurs attributs typés, ainsi qu’un processus de demande d’achat, avec ses étapes, règles, acteurs et rôles. Ce modèle est suffisant pour produire une application opérationnelle à laquelle les utilisateurs peuvent se connecter, accéder à une corbeille des tâches à traiter propre à leur rôle, afficher une liste de fournisseurs, rechercher, filtrer ou éditer les données, initier une nouvelle demande d’achats. Le modèle se transforme ainsi instantanément en une application fonctionnelle sur-mesure, sociale, collaborative, garantissant la cohérence des données ainsi que l’expérience utilisateur

Grâce à cette approche, le problème récurrent de la synchronisation entre code et modèle disparaît. Ce qui est modélisé est vraiment ce qui est obtenu (WYMIWYG : What You Model Is What You Get). De même, ce qui est changé dans le modèle se reflète tout de suite en changement applicatif. Ajustez l’IHM, les données et processus s’alignent. Rajoutez un nouvel attribut dans une classe, il apparaît instantanément dans les vues associées. Déclarez une nouvelle classe, un accès est proposé dans l’IHM pour en gérer les objets. Améliorez un processus (en ajoutant une étape ou une condition) et l’IHM et les données se synchronisent.

Grâce à l’approche modéliser-exécuter, les efforts de développement portent sur la couverture des besoins métier plutôt que sur la résolution de problèmes ou questions techniques. La DSI peut travailler main dans la main avec les fonctionnels, en mettant au point la structure de données, en personnalisant l’IHM, en définissant les étapes des processus, assurant ainsi une conception rapide qui maximise la couverture des besoins et qui permet une maintenance évolutive bien moins coûteuse ainsi qu’une plus grande adhésion des utilisateurs.

Jean-Loup Comeliau de W4