afficher >><< masquer ]
SAMPI - Editeur structuré
1. Le Problème et la Proposition
2. Le Langage Primitif de Représentation Textuelle
2.1. Présentation de la Syntaxe Concrète
2.1.1. Les intentions
2.1.11.1. L'objectif
2.1.11.2. La réponse
2.1.11.3. L'éditeur syntaxique
2.1.11.4. L'état de la science dans le domaine
2.1.11.5. L'expression de besoin
2.1.11.6. Le choix de la Représentation Interne
2.1.11.7. La réponse au problème
2.1.11.8. La référence
2.1.2. Eléments du langage
2.2. Notations
2.3. Exemple de structuration des données
2.4. Exemple de structuration des traitements
2.5. Exemple de structurations connexes
3. Le Langage Complété pour la Structuration des Textes
3.1. Présentation de la Syntaxe Complétée
3.2. Etude quantitative de l'évolution des programmes
3.3. L'édition syntaxique
3.4. étude de cas : le langage LTR3 et l'atelier ENTREPRISE
4. L'Enrichissement du Langage par de Nouveaux Concepts
4.1. Présentation de la Syntaxe Abstraite
4.2. Les difficultés
4.3. Compléter la Syntaxe
5. La Formalisation des Solutions Techniques
5.1. L'évaluation fonctionnelle
5.2. La structuration par les objets
5.3. Modèle sémantique comparé de l'évaluateur
5.4. Comparaison critique
5.5. Construction de la Syntaxe Abstraite
6. Les Comparaisons avec d'autres Approches
7. Les Perspectives
8. Les Editeurs
8.0. brisé sur la barrière de la complexité (une fois de plus)
8.1. L'éditeur ligne : Manuel de l'utilisateur
8.2. L'éditeur page : Guide de l'utilisateur
9. Les Aspects d'Implantation
9.1. Contexte d'évaluation
9.2. La Syntaxe Abstraite : Manuel du concepteur
9.3. L'éditeur page : Guide de l'implanteur
Références
Rubrique Perl-Javascript

Les intentions

1. L'objectif

2. La réponse

3. L'éditeur syntaxique

4. L'état de la science dans le domaine

5. L'expression de besoin

6. Le choix de la Représentation Interne

7. La réponse au problème

8. La référence

1. L'objectif

L'élément essentiel qui a guidé les travaux est la constatation suivante : un programme informatique, exprimé à l'aide d'un langage informatique, a le fâcheux trait de comporter un grand nombre de répétitions : répétitions de texte, de traitements, d'identificateurs. La définition même des langages modernes – typés, à structure de bloc – nécessite à l'introduction d'un concept une répétition ; d'un part on déclare l'objet, d'autre part on l'utilise. Le lien sémantique entre la déclaration et l'utilisation d'un même concept est très généralement réalisé par la reconnaissance lexicale d'un identificateur ; c'est le « paradigme DESIGNER », une des « étapes élémentaires » dans l'analyse d'un programme [Gra 86].

Ces répétitions ne s'arrêtent pas aux seuls identificateurs : on peut avoir des répétitions sur les traitements, mais celles-ci sont alors plus difficiles à détecter, et plus encore à expliciter, parce que ces traitements ne travaillent pas nécessairement sur les mêmes structures de données. On introduit alors la notion de généricité qui permet de définir un traitement sur un type d'objet auquel on ne demande qu'un nombre minimal de propriétés. C'est ainsi qu'on procède dans la « méthode Jackson » : on définit le traitement, sans préciser la structure exacte des objets qu'on manipule ; puis on instancie ces traitements par le choix d'une structure de données complètement définie [Cam 86]. C'est aussi un des points essentiels de la Méthode Orientée Objet proposée par G. Booch [Boo 86]. La généricité ne résout cependant pas totalement le problème : on réintroduit en effet des répétitions par la définition des paramètres de généricité, formels et effectifs ; on est en plus relativement limité dans le choix du langage de programmation.

La question est de savoir si l'on peut éviter les répétitions dans un texte source, le but n'étant pas de s'économiser des efforts inutiles mais de conserver son programme sous une forme lisible et maintenable.