Chapitre 9 : LES ENVIRONNEMENTS
DE PROGRAMMATION D'APPLICATIONS
SUR BD
Tout commence et tout fini par l'utilisateur.
Trois fois dans les chapitres précédents le point de vue de l'utilisateur
a été explicitement au départ des progrès demandés
au SGBD:
- comme concepteur et développeur:
ses exigences conduisent à des modèles et langages de richesse
sémantique de plus en plus grande et indépendants de l'implémentation
physique;
- comme usager non informaticien:
la prise en compte de sa vision propre des données - liée
à ses droits et responsabilités - conduit à la définition
des vues externes, logiquement indépendantes du schéma du
concepteur;
- comme opérateur sur
terminal: son temps propre - de lecture, de réflexion, de frappe
et/ou "cliqué" - définit le "temps réel" que devra
respecter au mieux le système et lui fixe ainsi ses performances.
Dans ce chapitre nous rappellerons d'abord
quelques règles de l'ergonomie des interfaces graphiques entre homme et
machine pour réfléchir sur leur spécification, puis nous
regarderons quels sont les bons outils pour programmer de telles interfaces, enfin
nous indiquerons dans quels environnements ces outils peuvent être intégrés.
IX.1. Les interfaces graphiques
Les interfaces homme-machine (IHM) ont,
depuis l'essor du fameux Macintosh, pris l'aspect graphique et interactif qui
permet aujourd'hui de retrouver des éléments graphiques communs
à toutes les "graphical user interfaces" (GUI). Il ne faut pas croire pour
autant qu'avant les terminaux, PC ou stations graphiques il n'y avait que les
"bêtes" terminaux en mode asynchrone caractère par caractère
du type ANSI vt100 ou émulateur "telnet".
Dès les premières grandes
applications transactionnelles, on avait conçu un terminal dit mode synchrone
par pages transmises en un seul bloc. La séparation du temps de réflexion
de l'utilisateur, sur une pleine page devant ses yeux, du temps d'attente de
la réponse du système était alors totale. De nombreuses
- et bonnes! - habitudes de présentation des écrans ont été
prises depuis cette époque par les utilisateurs. Les applications modernes
sur interfaces graphiques doivent en tenir compte.
IX.1.1. Vocabulaire descriptif
L'usage en a établi un lexique
presque commun à toutes les bonnes spécifications et manuels utilisateurs.
Mais certains néophytes ou éditeurs, trop liés à un
seul type de générateur d'interfaces, font encore souvent des confusions:
ainsi entre les termes de "formulaire" - ou "forme" (d'affichage) - et celui de
"fenêtre" on ne comprend pas toujours que le premier désigne l'objet
à visualiser - qui peut être plus grand que l'écran! - et
le deuxième le moyen de visualisation.
IX.1.2. L'ergonomie "navigationnelle"
Dans une situation normale de travail,
la recherche et la manipulation des données obéissent à des
enchainements logiques d'opérations: choix du contexte, choix d'une entité
de référence ("maître"), liste d'entités liées
("détail"), calcul d'un agrégat ou choix de l'une d'elles qui devient
"maître", liste d'entités liées, etc... On appelle cela une
navigation à travers les données. Les applications sur ce modèle
comportemental sont les plus simples d'apprentissage et donc les plus répandues.
IX.1.3. L'approche orientée
objet
IX.1.3.1 Les objets graphiques standards
("widgets")
Les "WIndow gadGETS" - un bouton
de sonnette par exemple - sont de véritables objets: accessibles seulement
par leurs méthodes - enfoncer ou relâcher - leurs caractéristiques
externes permanentes - position X,Y, graphisme - sont fixées à
la conception, mais la variation de leur état interne, si elle est visible
pour l'utilisateur par un écho de son action, peut envoyer à d'autres
objets des messages préprogrammés - affichage de cet objet, par
exemple.
On peut classer ces objets en inactifs
et actifs, les premiers sont des informations ou des décorations invariantes
à la fin de la conception, les seconds sont en quelque sorte les actionneurs
ou/et capteurs offerts à l'utilisateur pour l'exploitation de l'application.
IX.1.3.2 objets de la base de
données et objets affichables
Quelle correspondance peut-on et
doit-on faire entre les objets tels qu'ils sont inscrits dans le schéma
"externe" de l'utilisateur dans la métabase et les objets tels qu'il
peut et veut les visualiser?
Les options par défaut sont
presque toujours:
FORME (ou FORMULAIRE) <-> résultat
d'une requête sur une ou plusieurs vues du schéma externe;
BLOC (ou CHAMP COMPOSITE ) <->
affichage d'un tuple ou d'une liste de tuples d'une vue de ce schéma;
CHAMP [ELEMENTAIRE] <-> affichage
d'un attribut réel ou virtuel de cette vue, ou d'un résultat de
calcul d'agrégat.
IX.1.3.3 objets de métiers
standards et réutilisables
Outre les objets "naturellement"
composites (un bon de commande et ses lignes, un équipement et ses sous-ensembles,
un ménage et ses membres, etc...), chaque métier a l'habitude
de classer, associer, hiérarchiser, relier des objets selon des schémas
qui deviennent des standards de fait dans leurs domaines respectifs. Il est
par conséquent normal que les interfaces des applications développées
pour l'un d'eux finissent par ne différer que sur des styles, mais conservent
les mêmes topologies et les mêmes enchaînements de formulaires.
Les usagers des applications informatiques sont d'autant plus rapides au travail
que la conception des interfaces applicatives dans un même métier
renforce les habitudes de pensée de ce métier. Pour le meilleur
comme pour le pire ...
(insérer figure)
IX.1.4. Les styles
Le plus simple est le plus beau: ne
pas encombrer l'écran de plus de fenêtres qu'il n'est à chaque
instant nécessaire, ne visualiser qu'un contexte à la fois, coordonner
le défilement des objets dont les instances sont liées, etc...
IX.2. Les générateurs
d'applications sur BD
On appelle ainsi les outils qui interprètent
un langage de définition et de manipulation des données à
travers écran-clavier-souris selon une interface standard, ou plus généralement
elle-même définissable et paramétrable.
Le soucis de la productivité
des développements a conduit au choix de méthodes de prototypage
par une sorte de dessin des formes d'affichage avec les mêmes outils du
terminal, c'est ce que l'on appelle la "programmation visuelle".
Mais il reste toujours du code à
écrire dans des "scripts" associés aux objets graphiques. Les
langages plus ou moins proches de l'embedded-SQL conçus dans ce but sont
depuis l'origine appelés "langages de 4ème génération"
(L4G, ou 4GL en anglais).
L'ensemble de ces dessins de formes
et de scripts est finalement compilé, pour des raisons évidentes
de performance, et stocké, soit dans un fichier, soit dans la BD elle-même
pour permettre sa sauvegarde et son export éventuel simultanément
avec les données de la base.
IX.2.1. La "programmation
visuelle"
IX.2.1.1 Les interprêteurs
de SQL ou de QBE
Quand l'administrateur d'un SGBD,
ou le développeur d'application, veut interroger directement la BD, il
utilise un interprêteur de SQL. Celui-ci admet généralement
l' entrée de texte de requête en mode ligne ou en mode plein écran
et peut formater les sorties en tableau; des instructions supplémentaires
au SQL standard permettent le contrôle du texte entré et de l'affichage
du résultat. Mais on ne peut pas mettre une telle interface entre les
mains d'un non-informaticien. Aussi les éditeurs de SGBD proposent-ils
des interprêteurs de requêtes qui guident l'utilisateur par une
succession de choix à faire sur un schéma graphique des relations
(rectangles) et de leurs possibles jointures (arcs joignant les rectangles).
Des menus permettent de compléter logiquement les prédicats WHERE
de restriction du SELECT. L'utilisateur peut, avant ou après exécution
de sa requête, visualiser le texte SQL automatiquement généré
en tâche de fond.
Le langage QBE avait, au contraire
du SQL, été conçu pour être graphique dès
l'origine, mais malgré sa puissance d'expression et les enrichissement
picturaux qui sont proposés encore à ce jour par des chercheurs,
il représente encore une voie peu suivie par les éditeurs de SGBD.
IX.2.1.2 Les outils QBF et dérivés
OO
Presque tous les SGBD offrent des
générateurs de formulaires d'affichage de type "Query By Form"
faits de champs interactifs qui acceptent des valeurs ou des prédicats
restrictifs mono-table et des jointures entre tables, mais implicitement prédéfinies
par le choix des tables affichées. C'est, bien sûr, sémantiquement
inférieur au QBE, mais acceptable pour des applications simples et stables.
Enrichis avec la panoplie des objets
graphiques et avec les mêmes principes de guidage que pour les aides à
la formulation de requêtes SQL, on trouve, aujourd'hui, des dérivés
"orientés objet" du QBF très ergonomiques.
IX.2.1.3 Les "langages visuels"
On appelle ainsi un ensemble de langages
dont les éléments terminaux sont des objets graphiques dans le
plan de l'écran et les expressions des assemblages construits par déplacements
et "cliqués" de la souris, les identifiants d'objets ou d'attributs et
leurs valeurs restant des éléments textuels ajoutés. Si
certaines de leurs règles de construction sont reprises dans les outils
QBF et dérivés, leur utilisation exclusive pour les GUI reste
du domaine de la recherche: leur conception autant que la vérification
de leur richesse sémantique prend toujours comme référence
un des langages relationnels SQL ou QBE ou un modèle sémantique
général comme l'Entité-Association.
IX.2.2. Les "langages de
4ème génération"
Ces langages, mi-visuels mi-textuels,
le plus souvent interprétés, sont nés en même temps
que les SGBD Relationnels. Ils ont pour principal objectif de permettre le développement
d'applications sur terminaux semi-graphiques par maquettage-prototypage beaucoup
plus rapidement que par programmation et compilation avec les langages
classiques - COBOL, PL/1, Pascal, etc... - relégués au rang de "langages
de 3ème génération" par les promoteurs de ces nouveaux outils.
Leur simplicité apparente d'utilisation avait pour revers leur grande diversité
de syntaxe et de capacité sémantique. Aujourd'hui l'existence et
l'utilisation par ces outils de bibliothèques semi-graphiques ou graphiques
standards et le renforcement de la norme SQL ont créé une convergence
notable.
IX.2.2.1 Le prototypage des formes
d'écran
Tous les L4G le proposent, dans
le mode "dessinez-le vous même", à partir d'une collection de types
d'objets graphiques visuellement manipulables. Ainsi une application
apparaît d'abord comme un ensemble de formulaires d'affichages
- ou "formes" ou "grilles" - chacune composée d'un fond - ou "décor"
ou "papier peint" - éventuellement d'une barre de menus et de
blocs - ou "zones" ou "entités" ou "champ composite" - positionnés
sur ce fond. Un bloc est lui-même de type grille , s'il ne permet
que l'affichage individu par individu, ou de type liste , s'il permet
une vision tabulaire de plusieurs individus à la fois avec déroulement
vertical pour voir le reste de la liste. Le bloc est composé de champs
élémentaires actifs ou non, c'est-à-dire d'état
modifiable ou non à partir du clavier ou de la souris.
Tous ces objets sont nommés.
Leurs variables publiques et leurs méthodes sont regroupés dans
des structures référencées par les mêmes noms.
S'agissant d'objets, la hiérarchie des types entraîne celle des
héritages de variables et méthodes.
Le couplage entre la valeur des
variables et celle des attributs de données dans la base d'une part,
entre les méthodes et les actions sur les données de la base
ou sur d'autres objets de l'application d'autre part, est en général
spécifié par un "script" attaché à chacun de ces
objets.
IX.2.2.2 La spécification
des enchainements dans l'application
Avec les L4G les plus récents
les enchaînements sont le plus souvent spécifiés et programmés
selon une logique "événementielle" décrite par des règles
de déclenchement d'action - ou "triggers" applicatifs sur le modèle:
SI détection_changement_état_objet
ALORS lancer_action
l'action lancée, pouvant être
une modification de données dans la base ou l'appel à une méthode
d'un objet graphique ou une séquence d'actions de l'un ou l'autre type.
Elle peut en conséquence changer l'état d'un autre objet qui,
ayant lui aussi un trigger attaché, relancera une nouvelle action et
ainsi de suite... Comme il n'est pas exclu que la base de données elle-même
soit pourvue de triggers détectant eux des changements d'état
sur les données, on a, dans le cas le plus général un modèle
d'enchaînements à deux boucles:
(insérer figure)
Figure 9.1: enchaînement "événementiel"
des actions d'une application.
Une contrainte d'intégrité
sémantique nouvelle apparaît: l'utilisateur doit voir les objets
graphiques dans un état cohérent avec celui des données
de la base relevant de sa vue ou de ses vues propres et le décalage
temporel entre les changements d'état de part et d'autre doit être
le plus réduit possible.
Un script attaché à
un objet graphique - par exemple un bouton - a typiquement l'allure suivante:
ON CLICK formeA.boutonB DO
BEGIN
INSERT INTO tableT(colonneC)
VALUES (:saisieS); /* action
sur la BD */
formeA.popupP(messagetext = 'Valeur entrée dans la BD'); /* action
sur l'écran*/
END
IX.2.2.3 Les procédures SQL+while
Le programme de l'action déclenchée
par un trigger applicatif doit nécessairement pouvoir inclure des instructions
de manipulation de la base de données. Celles-ci s'exprimeraient aisément
en C-Embedded SQL si le programme était codé en C. Les grands
éditeurs de SGBD ont tous choisi de s'écarter le moins possible
de ce stantard pour incorporer du SQL dans leur L4G, et même, si possible,
de préfigurer le futur standard SQL3 qui ajoutera le WHILE au SQL. Ainsi
le PL/SQL d'Oracle distingue soigneusement la manipulation des données
de la base de la manipulation de l'interface. L'exemple ci-après en donne
une illustration :
DECLARE
Returns the five highest paid
CURSOR c1 IS
employees from the emp table,
SELECT ename, sal FROM emp
and stores the result in tmp,
ORDER BY sal DESC;
a table created for transfer.
name emp.ename%TYPE;
salary emp.sal%TYPE;
Output: SELECT * FROM tmp
BEGIN
ORDER BY earns DESC;
OPEN c1;
FOR i IN 1..5 LOOP
EMPLOYEE EARNS
FETCH c1 INTO name, salary;
--------------------------
EXIT WHEN c1%NOTFOUND;
KING 5000
INSERT INTO tmp VALUES(name, salary);
SCOTT 3000
COMMIT;
FORD 3000
END LOOP;
JONES 2975
CLOSE c1;
BLAKE 2850
END;
IX.2.3. Les interfaces au
standard SQL et la portabilité
IX.2.3.1 Une portabilité encore
bien relative
Un développeur d'application
ne peut pas ne pas avoir le soucis de la portabilité, par rapport à
la variété des terminaux et stations semi-graphiques et graphiques,
d'une part, et par rapport à la variété des SGBD, d'autre
part. Il y a deux façons de le faire: soit il programme, par exemple
en C, en utilisant une bibliothèque de procédures standards pour
les entrées-sorties graphiques et l'Embedded SQL pour les entrées-sorties
de données de la base, soit il programme en L4G et récupère,
après mise au point complète et traduction, un programme intermédiaire
en C incluant des appels de procédures de X11 Motif et des blocs codés
en Embedded SQL. Mais deux limitations de portabilité subsistent:
- les spécifications des
procédures de la bibliothèque semi-graphique curses(3v) ou de
la bibliothèque graphique X11 Motif assurent la portabilité,
et même, dans le monde Unix standard, l'indépendance physique
par rapport à l'écran. Elles ne valent néanmoins pas
pour le monde PC sous MS Windows, ni pour le monde Macintosh.
- la précompilation, qui
traduit les blocs de code Embedded SQL en appels de procédures de
définition ou de manipulation des données de la base, ne peut
se faire qu'en présence d'un SGBD et le code C obtenu reste ensuite
lié par ces appels de procédures à ce SGBD particulier.
IX.2.3.2 Vers une ouverture plus
grande
Selon que l'application regarde
vers l'interface graphique ou vers la BD l'effort pour une plus grande ouverture
n'est pas de même nature:
- le code de l'application s'exécute
sur le PC ou la station donc avec l'unique window manager de ce système,
le problème pour le développeur est donc seulement un problème
classique de compilation multi-cibles à partir d'un code source commun.
La spécification d'une bibliothèque source graphique commune
relève donc du choix de l'éditeur de L4G et de son client pour
le temps du développement seulement.
- par contre une compilation
d'Embedded SQL ne pouvant se faire qu'avec un SGBD donné, ce PC ou
cette station ne peut plus, pendant l'exploitation, qu'accéder à
ce SGBD. Il faudrait simultanément lancer l'exécution d'un
autre code compilé - du même source, mais avec un autre SGBD
- pour accéder à un autre SGBD depuis le même PC ou
la même station. Ce besoin d'interconnectivité a été
très tôt exprimé par les clients, aussi les éditeurs
de L4G se sont-ils concertés dès après l'adoption du
SQL1 pour spécifier un niveau commun d'appels de procédures
pour manipuler les BD. Il a été adopté en 1991 par
le consortium X/Open sous le nom de Call Level Interface (ou CLI) et est
candidat à la normalisation par l'ISO.
On voit ainsi se préfigurer
symétriquement deux bibliothèques programmatiques standards -
ou Application Programmatic Interfaces (API) - une pour les entrées-sorties
côté terminal, l'autre pour les entrées-sorties côté
SGBD, qui, ensemble, donneront le maximum de portabilité et d'interconnectivité
aux applications sur BD.
IX.3. les ateliers de génie
logiciel (AGL / CASE)
Les cibles pour le développement
d'applications multi-utilisateurs sur BD apparaissent maintenant complètement:
- la métabase - Information
Schema - du SGBD: c'est le réceptacle des définitions logiques
et physiques des tables, vues, contraintes d'intégrité, droits,
index, procédures et d'une façon générale de tout
ce qui peut constituer le dictionnaire de définition et de manipulation
cataloguée des données;
- les PC ou stations et leurs
bibliothèques graphiques: ils recevront les codes exécutables
des programmes applicatifs, de préférence par téléchargement
et configuration automatique;
- la base elle-même: avec
nécessairement son "peuplement" initial de données, mais aussi,
dans des "annexes" spécialement prévues à cet effet,
les "images" des applications qui seront sauvegardées ou exportées
en même temps que les données, ce qui, somme toute, peut rendre
de grands services pour la sécurisation du système applicatif
tout entier.
Quels outils rassembler pour une telle
production logicielle et dans quel atelier les trouver ou les intégrer?
IX.3.1. Outils détachés
Quel est la panoplie minimale d'outils?
En général, on souhaite au moins y trouver, dans l'ordre des productions
citées ci-dessus:
- un outil d'aide à
la conception du schéma logique des données, doté
de plus ou moins d'expertise, éventuellement étendu pour l'aide
à la conception du schéma physique;
- des générateurs
d'applications pour interfaces graphiques mais aussi des générateurs
de rapports imprimés;
- des chargeurs de données
pour le peuplement initial de la BD à partir de fichier externes
de formats variés;
auquels il faut ajouter les outils d'exploitation
pour les administrateurs du SGBD et des BD:
- un moniteur des ressources
statiquement ou dynamiquement allouées;
- des outils d'export et d'import
.
IX.3.2. Ateliers intégrés
Que l'on suive ou non des méthodes
générales de gestion des projets de développement logiciel
- MERISE ou l'une des nouvelles méthodes Orientée Objet - on peut
vouloir se doter d'un environnement intégré pour rassembler de façon
cohérente, avec une gestion minimale des versions des configurations -
SCCS, SRCS ou mieux - toutes les pièces de la production d'une application
sur BD, sans oublier l'aide en ligne, la documentation papier et les jeux et procédures
de validation.
Trois stratégies sont alors
possibles:
- l'achat de l'atelier d'un
éditeur de SGBD qui fait de l'intégration verticale, avec
le confort d'une validation garantie par celui-ci pour toutes les étapes
du cycle de production d'applications sur ce SGBD, et, également, avec
les garanties de portabilité et d'ouverture offertes par cet éditeur,
mais avec le danger d'une dépendance grandissante par rapport à
cet éditeur (ses limites seront vos limites);
- l'achat d'un atelier indépendant
par rapport aux différents SGBD comme par rapport aux différentes
interfaces graphiques, mais aussi par rapport à l'intégration
des autres outils détachés de production, comme les outils
de "middleware" pour les architectures clients-serveurs;
- la constitution de son propre
atelier sur un standard ouvert comme par exemple le "Portable Common
Tool Environment" (PCTE) sous Unix, permettant l'intégration de tous
les outils souhaités dont aucun n'imposera son environnement aux
autres.
IX.4. Conclusions
Pouvoir développer les interfaces
utilisateurs, et les programmes dont elles permettent le contrôle, en parallèle
à la conception des schémas - conceptuels, externes et internes
- d'une Base de Données est l'intérêt premier de ces logiciels
généraux que l'on appelle Systèmes de Gestion de Bases de
Données.
Si la séparation des programmes
et des données a permis de fonder théoriquement les modèles,
langages et architectures logicielles de ces SGBD, et même si cette séparation
est encore un des fils directeurs des principales méthodes de développement
d'application - y compris celles qui se disent orientées objet - il n'en
reste pas moins que du point de vue de l'utilisateur terminal, les interfaces
qui donnent une visualisation graphique des objets manipulés, les programmes
qui, "derrière", manipulent ces objets en mémoire vive et le système
qui gère le stockage persistant de ces objets en mémoire secondaire,
doivent apparaître, en fonctionnement opérationnel, comme un seul
et même système, avec le moins possible de "coutures" visibles.
Cette exigence conduit le double
mouvement d'intégration verticale AGL/L4G/"moteur"BD et de définition
de standards pour les interfaces entre les éléments de cette intégration.
Ce qui libère les acheteurs en ouvrant la concurrence à des offres
de technologies et d'architectures variées mais interopérables.
IX.5. Références
[AFNOR 86] AFNOR, "Memorandum Ergonomie
du Logiciel", 1986
[Batra 92] Dinesh BATRA and Ananth
SRINIVASAN, "A review and analysis of the usability of data management environments",
International Journal of Man-Machines Studies (1992) 36, 395-417
[Cartarci et al. 95] Tizinia CATARCI
and M-F COSTABILE, "Special Issue on Visual Query Systems", Journal of
Visual Languages and Computing, (1995) 6-1, March 1995