(Édition originale – IBM Systems Magazine)
TROIS LOIS de la softwaristique
S’appuyer sur les fondamentaux signifie une évolution plus facile
En 1942, Isaac Asimov a fait découvrir au monde de la littérature de science-fiction les Trois Lois de la Robotique :
- Un robot ne peut porter atteinte à un être humain ni, restant passif, laisser cet être humain exposé au danger.
- Un robot doit obéir aux ordres donnés par les êtres humains, sauf si de tels ordres entrent en contradiction avec la première loi.
- Un robot doit protéger son existence dans la mesure où cette protection n’entre pas en contradiction avec la première ou la deuxième loi.
En réfléchissant au développement, au déboggage, à la maintenance, au déploiement et à l’évolution globale des applications logicielles, je propose que la même structure de lois soit appliquée aux logiciels:
- Un logiciel ne peut utiliser que des standards ouverts ou, s’ils n’existent pas, des formats interopérables.
- Le logiciel doit utiliser une architecture à plusieurs niveaux, sauf lorsqu’une telle architecture entrerait en conflit avec la première loi.
- Un logiciel doit centraliser sa logique, tant qu’une telle centralisation n’entre pas en conflit avec la première ou la deuxième loi.
Loi 1 : Standards ouverts
Cette loi s’applique aux langages logiciels ainsi qu’aux formats de données. Si la spécification technique du language ou du format est publique, alors elle est ouverte.
Ruby et PHP sont des langages de programmation à standard ouvert, XML et HTML sont des formats à standard ouvert et HTTP est un protocole à standard ouvert. Et bien qu’ils ne soient pas véritablement ouverts, aussi Java et RPG suivent également des standards, ce qui est mieux que d’introduire des coûts et des risques en réinventant la roue. Car être non standard introduit un risque pour la durabilité du logiciel, étant donné que celui qui l’utilisera après vous risque de ne pas être en mesure de le maintenir. Cependant, lorsque des standards sont respectées, vous n’avez plus besoin d’y penser, car le “standard” garantit la pérennité du logiciel à mesure que la technologie évolue. L’évolution technologique va soit changer le standard et offrir un moyen de conversion de l’ancienne version vers une nouvelle, soit proposer de nouveaux produits qui intégreront le standard existant. Un bon exemple est Open Office. Pour le rendre largement utilisé par la communauté, les développeurs ont créé un convertisseur à partir de Microsoft* Word. Le nouveau standard RPG IV est similaire, avec la commande CVTRPGSRC pour convertir le RPG III en RPG IV.
En l’absence de standards ouverts, vous pouvez utiliser des formats interopérables, non pas tant pour les langages de programmation que pour le stockage et l’échange de données. Les langages de programmation peuvent être spécifiques à une plate-forme ou à un device, ou multiplateformes, et cela ne signifie pas que vous devez choisir entre la capacité d’intégration et de déploiement. Ce qui est déterminant, c’est principalement la finalité de votre application. S’il est destiné au cloud, vous pouvez rechercher un système back-end multitenant et des options permettant également d’activer la synchronisation hors ligne à partir de votre device front-end. Dans tous les cas, même si vous choisissez des langages spécifiques à la plate-forme et au device, vous pouvez utiliser un format de fichier approprié pour la préservation et le partage des données. Par conséquent, le déploiement ne sera pas un problème ni maintenant ni plus tard.
Loi 2 : Multiniveau
Les niveaux peuvent différer dans leur dénomination, mais le modèle multiniveau standard comprend trois niveaux principaux répartis en trois blocs respectifs : le niveau données, qui stocke les données ; le niveau application, qui traite les données ; et le niveau de présentation, qui présente les données et permet la saisie.
Par exemple, les feuilles de calcul Excel incluent les trois niveaux dans un seul bloc, ce qui est mauvais du point de vue applicatif. C’est pourquoi le format .csv a été inventé. Il représente un bloc de niveau données séparé du bloc de niveau présentation. La messagerie texte utilise deux niveaux en un seul bloc: présentation et données. Les logiciels plus sophistiqués, comme ERP ou CRM, auront les trois niveaux dans différents blocs pour les bases de données, les processus métier et les différents canaux de présentation.
Avoir une application divisée en blocs à plusieurs niveaux permet à chaque niveau d’être développé, testé, exécuté, réutilisé ou remplacé séparément.
Un niveau peut être logique ou physique. Les niveaux physiques sont constitués de blocs entiers (par exemple, un fichier de base de données ou une feuille de style en cascade CSS), et il est facile de remplacer un niveau physique par un autre.
Les niveaux logiques peuvent être considérés comme une configuration au sein de leur environnement. Par exemple, DDS et RPG comprennent ensemble deux niveaux, mais ils ont une présentation commune: la définition du buffer. Au sein de la DDS, cette disposition est mélangée à la disposition de présentation de l’interface utilisateur (une autre disposition). Bien que cela puisse paraître avantageux, puisque vous obtenez une description du buffer centralisée à la fois pour le RPG (niveau application) et pour le périphérique de fichiers (niveau présentation), il serait préférable d’avoir deux blocs distincts, un pour la description du buffer et un autre pour la mise en page de la présentation, même s’ils se trouvent dans le même conteneur. De cette façon, il deviendrait équivalent à un véritable bloc distinct qui pourrait être facilement remplacé. (Souhaiteriez-vous que les DDS soient XML? Lisez «Life After DDS» ibmsystemsmag.com/ibmi/developer/rpg/oamos-intro.)
Une application bien conçue utilisera différents niveaux physiques, mais également des niveaux logiques.
Par exemple, au niveau application, un niveau logique peut avoir une fonction distincte pour un processus de validation et, en outre, cette fonction distincte peut également être placée dans un module physique séparé. Le même principe peut être utilisé pour les données de la base de données, un fichier ou un agrégat distinct pour NoSQL pourrait être créé.
Enfin, une architecture multiniveau augmentera l’agilité et la durabilité des changements de votre application avec les évolutions de la technologie du marché ou des devices.
Loi 3 : Logique centrale
Cette loi concerne les règles logiques (alias règles métier). Vous pouvez avoir des règles absolues ou relatives.
Une règle absolue peut envisager le type d’un champ de données, sa validation ou sa corrélation avec un autre champ. Par exemple, un champ peut être configuré pour toujours afficher une date ou un nombre, ou pour être toujours validé de manière unique. Il peut également être défini pour ne pas exister s’il n’est pas défini dans un fichier d’en-tête.
Une règle relative peut dépendre du login de l’utilisateur, des données contextuelles ou de l’environnement. Par exemple, si je dois afficher une grille composée de cinq colonnes sur une interface graphique, je peux afficher la grille entière sur le desktop d’un navigateur PC mais une seule colonne sur un smartphone.
Ce qui compte dans nos prémisses de standards ouverts et multiniveaux, c’est que des règles absolues soient définies au niveau des données ou, si cela n’est pas possible, au niveau de l’application. Les règles relatives sont définies au niveau application et, si elles ne sont pas applicables, au niveau présentation.
L’objectif est d’écrire n’importe quelle règle métier une fois et en un seul endroit. Mais si, pour des raisons d’application telles que la rapidité des transactions, vous devez répliquer la règle métier à différents endroits, vous pouvez toujours intégrer une procédure qui hérite (ou référence) la règle à partir d’un emplacement central.
Trouver du sens aux fondamentaux
Lorsque vous utilisez des fondamentaux, vous obtenez un résultat cohérent, mais plus encore, vous gagnez en durabilité. Parce que votre modèle ne sera pas la conséquence d’un « contexte » occasionnel, il est en harmonie avec l’écosystème global; il persiste donc à travers les évolutions. En fait, on peut dire que les fondamentaux sont l’écosystème. L’informatique n’est pas une science naturelle; son écosystème peut donc changer, mais en son sein, nous pouvons toujours rechercher les fondamentaux.
Obtenez plus d’informations et de solutions sur les transformations numériques sur notre site Web polverinipartners.com
