5. La structure d'Arbre : la programmation paramétrée
La « programmation paramétrée » est présentée par J.A. Goguen dans [Gog 84], illustrée par le langage OBJ [Gog 84], devenu OBJ2 [FGM 87]. Le langage travaille dans le formalisme des T.A. ; la richesse des concepts introduits le fait placer plutôt sous la rubrique des « environnements monolinguaux » parce qu'il se suffit à lui-même pour un développement intégré de projet – quoiqu'on ne retrouve pas dans OBJ le mécanisme d'évaluation du langage exprimé dans les termes du langage, comme on l'a avec Lisp ou Smalltalk.
L'objectif est de favoriser au mieux la clarté, la validité et la réutilisabilité du logiciel. Pour ce faire, on doit disposer d'une grande facilité de paramétrisation des programmes, qui soit à la fois riche quant aux possibilités offertes et sévères quant aux contrôles de cohérence effectués.
Les traits de la programmation paramétrée :
- la modularité : le langage/outil sera modulaire, avec en corollaire la possibilité de masquage de l'information, une structuration hiérarchique de l'application, le développement de librairies de programmes ;
- le typage fort : ceci aide à la détection des incohérences ; de plus il permet d'introduire la notion de surcharge des identificateurs ;
- la paramétrisation : les modules doivent être faciles à paramétrer ; trois autres points sont requis, qui sont généralement mal supportés par les langages :
- des contraintes sur les paramètres d'instanciation,
- la possibilité de modifier un module lors de son emploi,
- la possibilité de déclarer – sinon de déduire – des propriétés qu'on vérifie dans le module (par exemple, la fonction
"+"est associative) ;
- la simplicité, une sémantique formelle, un développement interactif du programme.
• • •
Au regard des caractéristiques de la « programmation paramétrée », je me reconnais d'une inspiration voisine dans mes propres travaux. Je situerai la différence à plusieurs niveaux :
- Dès qu'il est question de contrôles sur la cohérence, le respect de contraintes, le type des objets, l'outil proposé ne répond plus ; en fait le seul contrôle assuré est celui de la visibilité des identificateurs.
- Je ne propose pas un développement selon une hiérarchie stricte – un graphe a-cyclique. Au contraire, l'outil, par la possibilité d'emploi par référence, offre le moyen de contourner la hiérarchie et le masquage des déclarations. Ceci s'oppose peut-être à une bonne méthodologie de programmation, mais doit s'entendre dans l'esprit des exemples qui ont été présentés auparavant.
- Je ne propose pas non plus un langage mais un outil qui travaille sur les langages, ou plutôt sur les textes sources des langages. Le champ d'application serait donc plus large – un peu plus large si l'on se réfère au langage LIL [Gog 86] : le langage sert à la gestion cohérente des paquetages Ada, dans l'esprit de la « programmation paramétrée » ; ce qu'on propose c'est une gestion plus fine sur des langages moins complexes que le langage Ada.
- La réutilisation n'est pas un processus simple à élaborer : « du logiciel réutilisé c'est plus que du logiciel réutilisable » (cf. [Tra 88] sur les neuf mythes de la réutilisation) ; c'est toute une stratégie de développement tournée vers la réutilisation du logiciel. L'outil proposé veut répondre au problème en offrant à l'utilisateur le moyen de réutiliser du logiciel qui n'était pas réutilisable, c'est-à-dire qui n'a pas été conçu dans cette optique.