L’application web riche est une solution au besoin d’interaction entre les systèmes complexes d’information et les utilisateurs. Ce genre d’applications est de plus en plus réclamée par les utilisateurs de l’entreprise, exemple les agents d’un centre d’appels. Cette solution comporte de très nombreux avantages :

1. Une belle vivacité de l’application qui enrichie le cadre de travail de l’utilisateur.
2. La facilité de manutention, associée à l’architecture web, évitant les déploiements sur chaque poste de travail.
3. La disponibilité des ressources techniques pour réaliser ce type d’application.

Cette solution comporte aussi quelques défis de taille. Parmi ces défis, la complexité technique associée à l’implantation de règles fonctionnelles est celui qui peut causer le plus de problèmes dans le cycle de développement d’une application.

Par exemple, pour la règle fonctionnelle suivante : “Afficher un voyant rouge si la quantité de pomme dans l’inventaire est plus petite que 10.” Cette règle se conceptualiserait simplement comme suit:

1. Obtenir l’inventaire.
2. Récupérer la quantité courante de pommes.
3. Comparer cette quantité avec la valeur 10.
4. Si la quantité est plus grande ou égale à 10 alors neutraliser le voyant rouge.
5. Si la quantité est plus petite que 10 alors afficher un voyant rouge.

Par contre, l’implantation de ce pseudo code liera fortement les concepts énoncés avec des mécaniques techniques complexes. Pour le concept de “Obtenir l’inventaire” : Celui-ci sera lié avec une demande, probablement asynchrone, du fureteur au serveur. Le serveur, une fois l’information obtenue du système de gestion de données, retournera une réponse au fureteur où devra être codé une technique pour assigner la réponse du serveur à la demande précédente de “Obtenir l’inventaire“.

Pour le concept “Si la quantité est plus grande ou égale à 10 alors neutraliser le voyant rouge” : Celui-ci sera lié avec une comparaison entre un paramètre externe (la valeur 10) et une série de lignes de code pour faire l’évaluation, une décision (le code à exécuter si la comparaison est vraie ou fausse) et une demande à un composant graphique pour changer d’apparence (un autre module qui possède aussi toute une complexité technique).

Cette règle fonctionnelle pourtant simple a le potentiel de voir sa signification dissoute parmi des centaines de ligne de code sur plus d’une plateformes et en plus d’un langage de programmation. Une application complète réalisée de cette manière implanterait plusieurs centaines de fonction réparties dans plusieurs milliers, ou même des millions de lignes de code. Le cycle de vie de cette application devient alors un cauchemar pour le développeur qui devra la modifier et pour le gestionnaire qui sera incapable d’obtenir une évaluation fiable de l’effort pour accomplir cette tâche.

Abstraire le fonctionnel du technique dans une interface web riche devient ici un enjeux qu’il convient d’inscrire formellement dans la planification d’un projet informatique. Cette tâche doit être accomplie dans la phase de design de l’application. Le design doit permettre au développeur de transposer les informations contenues dans le dossier fonctionnel en élément technique qui en respecte la sémantique.

Pour illustrer la dissociation du fonctionnel et du technique, reprenons l’exemple précédant:

Dans le cas du concept : “Obtenir l’inventaire”

1. Celui ci traduit la volonté fonctionnelle de récupérer une liste d’items de catégorie “inventaire”.
2. Le moyen technique d’y arriver est d’utiliser un mécanisme de communication entre le fureteur et le serveur en format “question-réponse”.

Le design doit alors fournir une mécanique répondant au besoin de “question-réponse“. Cette mécanique sera disponible pour implanter toutes les règles associées à ce besoin. Le développeur utilisera celle-ci comme une abstraction à plus haut niveau. Il n’aura plus à se soucier de ses spécificités techniques. La complexité technique se sépare alors de la règle fonctionnelle.

Dans le cas du concept de “Si la quantité est plus grande ou égale à 10 alors neutraliser le voyant rouge” :

1. Celui ci traduit la volonté fonctionnelle de signaler qu’une limite à été franchie.
2. Le moyen technique d’y arriver est :
   1. Évaluer une règle.
   2. Générer un événement correspondant au résultat de l’évaluation.
   3. Faire en sorte qu’un composant de présentation capte cet événement.
   4. Faire en sorte que ce composant opère une transition de son état actuel vers un nouvel état.
   5. Faire en sorte que le composant applique le nouveau comportement visuel associé à sont nouvel état courant.

Le design doit alors fournir plusieurs mécaniques répondant au besoin suivant :

1. La matérialisation de la définition d’une règle fonctionnelle.
2. La définition d’évènements.
3. Le moyen d’émettre des évènements.
4. Le moyen de retransmettre des évènements.
5. Le moyen de recevoir des évènements.

La définition de composants visuels comme :

1. Leurs évènements déclencheurs.
2. Leurs comportements (apparence) en fonction de leurs états possibles.
3. Les évènements qu’ils peuvent émettre suite à des actions.

Le développeur peut alors transposer les concepts exprimés en langage naturel dans le dossier fonctionnel en éléments prédéfinis du design. Le design s’articule autour de concepts clefs qui sont facilement reconnaissables dans la langue française ou anglaise. Une documentation ayant pour sujet «comment utiliser le design » explique aisément au développeur comment faire le pont entre les besoins exprimés dans le dossier fonctionnel et la manière de réalisation de l’application. De plus, ces éléments de design se réfèrent également à la notion de « design patterns ». Ces « design patterns » sont des concepts généralement reconnus dans l’industrie. Ceci permet d’avoir un vocabulaire commun qui exprime des concepts de design très sophistiqués avec une appellation simple. La communication de ces connaissances en est grandement améliorée.

Ce paradigme permet de :

1. Dissocier le fonctionnel du technique.
2. Simplifier la complexité du code.
3. Rendre l’ensemble des composants lisibles selon leurs perspectives fonctionnelles.
4. Permettre l’évolution fonctionnelle d’une application dans une proportion de un pour un avec l’évolution de sa contre partie codifiée.
5. Faire en sorte que la mécanique technique, une fois abstraite des processus fonctionnels, devienne une boîte noire. Celle-ci peut alors évoluer autant du point de vue de son optimisation que de sa manière même de fonctionner à l’interne.

En résumé, cet effort de design offre autant une relation de coût et bénéfice avantageuse qu’un positionnement stratégique concurrentiel des outils de productivité de l’entreprise. L’environnement en constante évolution dans lequel évolue l’entreprise met une pression sur le cycle de développement de ses applications informatiques. Les changements dans les systèmes informatiques sont grandement simplifiés si un design adéquat à servi à leurs construction.