Une conception objet également pour l’utilisateur

Pour l’utilisateur, le portage à l’identique de l’application ne présente pas d’intérêt. Comme les deux années d’expérimentation l’ont démontré, certaines fonctionnalités, indispensables un jour s’avèrent inutiles le lendemain. C’est pourquoi je pense qu’il est intéressant d’imaginer la version suivante de l’application comme étant une collection d’objets aisément paramètrables. Placé dans environnement Windows NT, cette structure logicielle revient à créer des objets OCX (OLE Controls Extension).

Les OCX sont des contrôles (éléments de l’interface utilisateur) utilisateur au même titre que les boutons, les listes et autres attributs graphiques sont des contrôles du système. Ainsi, il est possible de créer des contrôles dont le rôle est spécifique mais dont les moyens de communication sont clairement définis: on récupère l’actif et l’on ne se concentre que sur les spécificités de l’objet conçu.

La conséquence d’un tel mécanisme est la possibilité d’intégrer les futurs outils de contrôle de par exemple la DAS-1601 dans des applications telles que Excel, IDL... Autre avantage : la prochaine version de Visual Basic – langage de programmation extrêmement simple et qui est destiné non pas aux programmeurs mais aux utilisateurs – permettra de gérer ses objets OCX. Par conséquent, il sera très simple pour l’utilisateur d’assembler les objets en un ensemble logiciel associé à un script de pilotage: l’utilisateur construit lui-même son application en décrivant dans un langage clair les étapes de celle-ci, sans se soucier des notions et problèmes purement informatiques.

Afin d’illustrer, la simplicité sous-jacente au système, je donnerai ici un exemple de ce qui sera réalisable. Il suppose l’utilisation d’au moins un langage de macro-programmation visuelle telle que Visual Basic 4, Delphi, Excel 6, Word 7, Access 2... Le but de cet exemple est de lire la valeur analogique présente à l’entrée du troisième convertisseur de la DAS-1601, et de la stocker dans la variable Channel3.

Le fait même de taper ces quelques lignes de code pourront sembler encore trop compliquées, mais il n’en est rien. En effet, la plupart des applications précédemment citées proposent ou proposeront une construction visuelle du code, ainsi ‘programmer’ ce qui précède reviendra à cliquer sur l’objet DAS disponible dans la palette d’outils OCX, le lâcher dans le plan de travail et à assigner la variable Channel3 à son attribut ADChannel(3) par accès à sa fenêtre de propriété. Il est difficile de faire plus simple, vu la complexité de ce qui se cache réellement.

Tout ceci est bien beau d’un point de vue informatique, mais la véritable question qu’il reste à poser est la suivante: l’utilisateur a-t-il vraiment besoin de ce kit d’outils ? Je le pense. Parce qu’avec une telle structure logicielle, la collaboration chercheur/informaticien sera plus immédiate. Dans le pire des cas, l’informaticien aura la possibilité de répondre aux attentes du scientifique dans des délais extrêmement courts (correspondant au temps nécessaire pour décrire l’opération demandée), dans le meilleur, le scientifique, que je qualifie d’utilisateur vis à vis du produit, pourra modifier lui-même le code pour le personnalisé. C’est en effet le terme de « personnalisation » qui, selon moi, exprime le mieux le concept des OCX.