Système d'Information Dynamique

Un Système d'Information Dynamique est un Système d'Information vivant qui évolue constamment en fonction des besoins de ses utilisateurs.

Il est souple, parce que les évolutions demandées sont réalisable facilement et rapidement et parce qu'elles ne cassent pas l'existant. Vision utopique ? Peut-on ajouter facilement des fonctionnalités nouvelles sans casser du code qui fonctionne ?

La première idée qui vient quand on se pose cette question, est la réponse d'une "bonne architecture". Une bonne architecture permettra la définition des différentes briques du Système d'Informations, de façon à permettre leur évolution de façon indépendante. Le SI peut évoluer de façon incrémentale, par ajout successif de différentes briques. Chaque brique est indépendante des autres, elle vit sa vie propre au sein du système. C'est pourtant la cohérence de l'ensemble qui donnera toute la valeur du système et permettra aux fonctionnel d'être implémenté. Pour ce faire, il y a des liens entre les briques, elles se connaissent les unes des autres, elles se parlent, elles échanges des informations. Elles doivent se mettre d'accord sur la façon d'échanger de l'information, et sur la nature de l'information échangée. La bonne architecture répondra à ces questions.

2 remarques cependant:

• la définition d'une bonne architecture et sa mise en oeuvre prennent du temps. Les bonnes pratiques et les outils sont là pour réduire ce temps, mais il est difficilement réduit à zero.
• les liens qui seront mis en oeuvre entre les différentes briques du système, seront des liens qui apparaitront dans le code. Qu'il s'agisse d'un appel à un service, d'une référence à un objet, ces liens se traduisent par des opérations impératives, qui nécessitent d'être intégrées dans le processus de développement. Même en respectant la "bonne architecture", le couplage entre les différentes briques a toutes les chances d'être présent dans le code.

Le couplage faible visera à réduire les liens entre les différentes briques. Moins il y a de liens, mieux c'est.

Imaginez que vous pouvez maintenant développer vos différentes briques, sans vous soucier des autres, ni des liens que vous aurez à créer avec les autres. Vou souhaitez une IHM qui représente une information particulière. Seul vous importe la présentation de cette information. Le lien avec le contenu ne devrait pas être l'objet de votre développement. Vous souhaitez développer un service qui réaliser un traitement particulier. Seul vous importe le traitement que vous souhaitez apporter à votre information. L'endroit où se trouve l'information, la façon dont elle est stockée ne doit pas être l'objet de votre développement.

Vous concentrez votre travail sur le métier, la présentation et le traitement. Vous vous occuperez plus tard des liens à faire entre ces briques. Vous ne ferez pas de code pour implémenter ces liens. Pas de Event Handler sur un bouton, pas de propriétés d'objets à introduire dans un contrôle. Non seulement vous n'écrirez pas ce code, mais personne d'autre ne le fera non plus, ni une autre personne, ni un générateur. En fait, il n'y aura pas de code pour décrire ces liens. Ces liens deviennent descriptifs, ils sont de l'information dynamique, qui peut très bien se décrire sans passer par de l'écriture de code.

Les avantages sont considérables:

• cela prend moins de temps à faire
• cela peut se faire plus tard
• cela est plus facilement maintenable, dans le sens où il y a moins de contrainte sur des éléments descriptifs que sur des élément impératifs (typage, ordre, référence)

Cela permet surtout la totale indépendance entre les briques, qui peuvent vivre leur vie de façon indépendante, puisqu'il n'y a plus de liens à faire avec l'existant. Si vous ajoutez un traitement ou un contrôle, vous n'avez que l'implémentation du traitement à inclure dans votre code, que votre contrôle à ajouter dans votre page. Vous exprimerez plus tard que votre bouton appelle votre nouveau traitement. Vous n'avez plus besoin que votre traitement soit fait avant votre bouton. De fait, votre bouton ne connait même pas votre traitement, et il ne le connaitra jamais.

Imaginez maintenant que l'infrastructure qui vous permette de travailler de cette façon existe. Seriez-vous impatient de la voir et de la tester ?