REALISATION D’UNE APPLICATION INFORMATIQUE DE SUIVI CLINIQUE

Création des éléments graphiques de l’interface
La réalisation de l’interface graphique est l’un des points nécessitant le plus de temps dans l’élaboration d’une application informatique. Afin que l’utilisation soit facile et agréable, nous avons décidé d’utiliser dans SYSTOLE des icônes qui, lorsqu’elles sont cliquées, permettent d’accéder aux différents formulaires. Ces éléments visuels rendent l’interface plus intuitive. De plus, une info-bulle s’affiche lorsque le curseur de la souris reste plus de deux secondes sur l’icône, donnant ainsi une information complémentaire sur sa fonction.
Le texte affiché dans l’info-bulle est paramétrable par l’accès aux options du cadre d’image contenant l’icône.

Pour créer les éléments graphiques de l’application, nous avons choisi d’utiliser un logiciel gratuit disponible sur Internet : GIMP. Ce logiciel permet de réaliser des opérations de retouche d’image et de créer des logos ou des icônes à l’allure professionnelle .
L’utilisation de GIMP a également permis de réaliser un « splash screen » pour SYSTOLE. Il s’agit de l’écran d’accueil de l’application, contenant des informations sur le nom, la version du logiciel ainsi que sur son créateur. C’est un écran d’attente qui s’affiche également pendant ou après que certaines fonctions nécessaires au logiciel soit chargées et mises en place.

Constitution d’un back-end et d’un front-end
Le principe d’une telle application est de séparer les données (les tables) des autres objets (les formulaires, les requêtes, les macros, les modules) [7]. L’application contenant les tables (le back-end encore appelé application d’arrière-plan) est stockée sur un dossier accessible en lecture, écriture et modification par l’ensemble des utilisateurs. L’application contenant les autres objets (le front-end encore appelé application frontale ou d’avant-plan) contient les éléments de l’interface utilisateur et se trouve stockée localement sur chaque poste ou dans le dossier personnel de chaque utilisateur. Les avantages d’une telle solution sont nombreux :

• chaque utilisateur peut disposer de son propre environnement,
• chaque utilisateur n’a accès qu’aux seuls objets de base de données dont il a besoin, ce qui est moins perturbant que de voir une quinzaine de formulaire, une trentaine de requête…,
• les utilisateurs éclairés peuvent réaliser leurs propres outils (formulaires, requêtes,…) et être moins dépendant de l’administrateur de bases de données,
• les utilisateurs moins éclairés pourront laisser faire l’administrateur de base de données (ou un développeur d’applications) qui continuera à produire les éléments de l’interface,
• lors d’utilisation en réseau, les données sont centralisées sur le serveur.
Pour SYSTOLE, nous décidons, en prévision de l’utilisation en réseau, et pour faciliter la sauvegarde des données, de créer un fichier « sysdata.mdb », contenant exclusivement les tables de l’application : il s’agit de notre back-end. Pour l’instant, un seul front-end est créé, qui contient les formulaires, les états et certaines requêtes. Il porte le nom « Systole FE Med 1.3.mdb ». C’est ce fichier qui sera placé sur les postes clients.

Stockage et utilisation dans l’application des données liées au système
Nous venons de créer les tables qui vont contenir les données. Nous les avons placées dans le back-end. Nous avons créé le front-end et pris les décisions techniques pour la réalisation de l’interface graphique.
Mais pour fonctionner correctement, l’application a besoin de stocker dans la base de données un certain nombre d’informations qui n’apparaissent pas dans le MCD. Ces informations, appelées « données systèmes » sont stockées également dans des tables nommées « tables systèmes ». Ces données sont par exemple : le chemin du fichier « sysdata.mdb », celui où la sauvegarde devra être réalisée, les données concernant les utilisateurs…

A titre d’exemple, la figure 10 montre une copie de la table « Valsys relances vacc » qui sauvegarde l’intervenant responsable de l’édition des relances vaccinales ainsi que la période sur laquelle les relances ont été éditées. Au contraire des autres tables, celle-ci ne contient qu’un seul enregistrement. Il n’y a pas de sauvegarde de l’historique de l’envoi des relances, la table sert uniquement à stocker les valeurs de l’action en cours (ou de la dernière action dans le cadre d’une nouvelle édition).