Développement, visions objet vs procédurale

La manière de percevoir l’intégration de données est relativement différente qu’on ait une vision de développement objet ou une vision de développement procédural.

Il y a quelques années pour le module CNAM de préparation à l’oral Probatoire, je rédigeais une étude sur « L’évolution du développement logiciel ». Dans celle-ci, je mettais en évidence la notion de langage dédié.

Un développeur logiciel est ainsi amené à utiliser régulièrement de nombreux langages : le HTML pour l’agencement graphique, le sql pour le traitement de données relationnelles, le C# pour coordonnées toutes les interactions, le XML pour l’échange de données entre systèmes d’information, le XSLT pour la transformation d’un flux XML…

Pour ma part, je m’investis principalement dans le développement en C# et sa plateforme .Net, j’évolue également autour des autres langages indiqués plus tôt, mais à plus faible dose. Tout est affaire de dosage en fonction de ses préférences !

Au final, je m’efforce d’avoir une vision de Programmation Orientée Objet (POO).

◊ La Programmation Orientée Objet

Elle permet d’organiser nos idées sous la forme d’objets qui architecturés permettent de former des composants, des éléments complexes dont les sous éléments sont hiérarchisés. Malheureusement, elle n’a pas pour vocation le traitement de données en lot. Au contraire, le chargement d’un élément complexe avec sa hiérarchie peut-être coûteux.

Ce problème se résout à l’aide du principe de chargement paresseux (Lazy loading) qui indique qu’on charge qu’une partie de l’élément complexe. Lorsqu’on a besoin d’une autre part de cet élément, on charge cette part à la demande. De cette manière, on permet de préserver la mémoire vive du serveur.

◊ La Programmation Procédurale

Je côtoie des collègues de travail qui s’investissent dans le développement en langage Oracle pl/sql (procedural language/sql).

Le langage pl/sql possède très peu d’instructions. C’est un langage procédural permettant principalement de regrouper une suite de requêtes SQL. Il est dédié au traitement de données en lot.

Le SQL représente un langage spécifique : léger, facilement maintenable, portable. Il possède une syntaxe limitée et il est optimisé pour son domaine d’application : le traitement de données en lot.

Comme l’ensemble des traitements s’effectue en base de données, la logique de programmation en pl/sql est :

 de recourir à des tables temporaires et des tables de travail pour stocker les données et,  de réaliser des traitements en lot en bannissant au possible l’utilisation de curseur qui, à

l’inverse du traitement en lot, amène au traitement unitaire.

Sur les projets auxquels j’ai participés, j’ai rencontré 3 catégories de pensée :

 des personnes travaillant, développant nos applicatifs uniquement en mode procédural,

 d’autres personnes possédant plutôt une philosophie de développement purement en

mode objet et,

 une troisième catégorie alliant les 2 modes.

Je pense faire partie de cette dernière catégorie avec un grand souhait de me rapprocher du mode purement objet en y joignant des principes et astuces résolvant les erreurs classiques à ce mode.

Pour moi, durant plusieurs années, la frustration fut grande, dès lors que je me retrouvais au sein d’une équipe pensant en mode procédural, ne comprenant pas et n’étant pas intéressé par le mode objet.

Pourquoi ne comprennent-ils pas ma logique, devrais je changer selon la leur, la situation est- elle normale ?

Le livre « Patterns of enterprise application architecture » (« Patrons d’architecture applicative pour entreprise ») écrit par Martin Fowler m’apporta un soulagement en mettant en valeur les 3 catégories et en indiquant qu’il était réellement difficile de passer du mode procédural à une compréhension du mode objet.

Maintenant, il est important de choisir la philosophie de l’équipe qu’on souhaite rejoindre. Néanmoins, connaitre ces 2 modes et y cerner les avantages et défauts, est un grand atout qui permet de résoudre des problèmes assez courants lors de l’intégration de données.

2.

Le recours à l’intégration de données

Au cours de mes années d’expérience et toujours récemment, je suis intervenu sur de nombreux modules logiciels d’intégration de données.

L’intégration de données a pour rôle : l’échange d’une quantité importante de données entre applicatifs logiciels différents. L’échange est réalisé à l’aide de fichiers au format CSV ou plus récemment au format XML.

Revenons sur l’environnement Optima :

Figure P3.I.2._a Environnement Optima, le tiers de présentation « UI », intégration « Batch » ; et le tiers applicatif « Application »

Au sein de l’environnement Optima, les applicatifs Intranet Oscare, Supervision center et Icap’s possèdent des modules de téléchargement et d’intégration de fichiers d’échange.

L’environnement Optima, possède également le service de traitement en lot « Batch Service » réalisant l’intégration automatique des données de fichiers déposés dans un répertoire précis.

◊ Ces échanges peuvent-être manuels

Lorsqu’ils sont peu fréquents, en recourant à un module de téléchargement et d’intégration de fichier.

Les utilisateurs, pour obtenir plus de flexibilité, utilisent énormément ces modules :

Prenons l’exemple de l’élément « Production nouvelle » sous ICAP’S : il englobe un certain nombre de facilités, chacune étant définie à l’aide d’un formulaire composé de 40 champs à remplir. La saisie à travers l’intranet d’ICAP’S peut-être assez longue et laborieuse.

Les utilisateurs préfèrent ainsi :

 exporter les données d’une « Production nouvelle » existante,  modifier celles-ci à l’aide d’un tableur,

 générer des rapports et des graphiques toujours dans leur tableur et,

 enfin réimporter les données modifiées dans ICAP’S pour créer une nouvelle « Production

nouvelle ».

◊ _{Ces échanges peuvent-être automatisés}

Lorsqu’ils sont fréquents, à l’aide d’un service Windows scrutant le dépôt des fichiers d’échange dans un répertoire précis.

Ce mode est souvent utilisé lors d’échange de données entre entités ou filiales d’une entreprise.