Génération automatique de l’interface utilisateur graphique (IU)

Par exemple : Dans le processus de conception, une entité « Personne » est définie et contient différentes caractéristiques telles que le prénom et le nom. Chacune de ces caractéristiques peut également être soumise à des règles de validation : par exemple le prénom et le nom sont des champs obligatoires. Le « Quoi » se rapporte à la perspective externe de l’application, c’est-à-dire à la modélisation des entités et à la définition des règles métier. Les approches déclaratives offrent de nombreux avantages, notamment en réduisant la complexité. Les mécanismes internes sont mis en œuvre plus rapidement et sont immédiatement visibles sans avoir à analyser de grandes quantités de code au préalable.

Généralement, le « Comment » est mis en œuvre manuellement. Cela offre certes de la flexibilité, mais conduit rapidement à une extension verticale sur l’ensemble des couches de l’architecture logicielle. Le principal problème est d’assurer la cohérence. Des problèmes similaires doivent être traités avec des approches similaires pour garantir l’exhaustivité et la cohérence stylistique et fonctionnelle. Si des modifications sont apportées ultérieurement, il existe un risque que des ajustements importants ne soient pas pris en compte, ce qui peut entraîner des bugs et des régressions logicielles.

Une logique plus avancée est automatiquement déduite des entités, caractéristiques, actions et règles métier définies de manière centralisée. D’une part, vers l’arrière dans les couches plus profondes, en générant automatiquement la structure de la base de données et en la migrant si nécessaire. D’autre part, vers l’avant dans les couches supérieures, par exemple en générant des composants d’infrastructure et des interfaces de service Web (API/REST).

Ces déclarations, c’est-à-dire les définitions de mise en page, sont portées jusqu’à l’IU/frontend. Un moteur d’IU spécialement conçu les traite pour générer l’interface utilisateur graphique.

Puisque cette architecture nécessite une forte standardisation, de nombreuses exigences doivent être unifiées afin de déployer tout son potentiel. La robustesse de l’architecture réside toutefois dans le fait qu’elle permet de s’écarter de la norme afin d’implémenter une logique métier spécifique de manière ciblée, sans pour autant créer des incohérences.

Chaque service fournit ses déclarations sous forme de fichiers JSON comme définitions de mise en page pour le Frontend-UI-Engine. Ces définitions de mise en page contiennent toutes les entités, caractéristiques, actions et règles métier sous une forme structurée. Sur cette base, le frontend peut représenter la majorité des cas d’application sans nécessiter de programmation supplémentaire. Cela permet un frontend largement indépendant et autonome couplé de manière mobile au backend.

Différents affichages (Views) peuvent être générées dynamiquement à partir des définitions de mise en page. La structure de base d’un affichage, par ex. d’un formulaire, est implémentée explicitement. Le contenu, c’est-à-dire le type d’action, les champs et les types d’entités, est en revanche déterminé de manière dynamique en fonction du contexte et configuré à partir des définitions de modèle. Par exemple, l’affichage Formulaire reçoit l’instruction « créer une personne » et génère automatiquement les champs nécessaires, y compris les règles de validation et la logique métier, afin de pouvoir envoyer une demande prête à l’emploi au backend.

Les différentes vues et leurs éléments tiennent leurs informations non seulement à partir des définitions de mise en page, mais doivent également tenir compte de l’état actuel des données. Dans un système dynamique, les composants doivent réagir aux événements tels que la modification d’une valeur de champ et représenter ces modifications en temps réel. Cela est réalisé par un mélange d’un motif Model-view-controller (MVC) et d’une base de données virtuelle dans le frontend. Cette base de données virtuelle fait office de modèle au sens du principe MVC et synchronise les modifications et génère les événements correspondants. Le modèle correspond également à un cache pour les requêtes vers le backend.

L’échange standardisé de modifications (Create, Update, Delete) de données s’effectue via ce que l’on appelle des Model Messages. Ceux-ci sont échangées aussi bien entre les unités système (services) qu’avec le frontend. Ces Model Messages indiquent non seulement les modifications apportées aux entités, mais aussi les modifications apportées aux relations entre les entités ou aux données partagées entre elles. Cette connaissance sémantique, associée aux définitions de mise en page, permet de dynamiser le frontend et contribue au découplage du backend.

En raison du caractère dispersé de l’application, dans laquelle différents services gèrent des données différentes, il n’est pas possible pour un seul service d’effectuer une requête complète sur toutes les données. Un Model Service a été développé afin que le frontend puisse tout de même recevoir efficacement des données de plusieurs services en une seule requête. Celui-ci traite les Model Messages et crée une vue agrégée des données de tous les services. Model Service fait donc office d’étape préliminaire à un Data Warehouse et permet de lancer des requêtes complètes, également basées sur des graphiques, sur cette structure de données hiérarchisées.

La localisation, qui comprend la traduction et le formatage du contenu, est un autre élément central du Frontend-Engine.

Apriko étant multilingue, les textes et les données doivent être disponibles sous une forme générique et non traduite, fournis respectivement par le backend. La traduction proprement dite n’a lieu qu’à la dernière étape, lors de la génération de l’interface.

Le découplage du backend et du frontend ainsi que l’approche déclarative dans le développement backend permettent de mieux se concentrer sur la mise en œuvre de la logique métier. Dans le même temps, la création inutile de code boilerplate et son érosion sont minimisées et la cohérence entre les différentes couches de l’architecture logicielle est améliorée.