Au Pied Levé - À Main Levée
I-2.2.3. Méthodologie de programmation LCP
par , 01/04/2020 à 10h55 (715 Affichages)
APL-AML est une monographie fragmentée en plusieurs billets pour des raisons de volume.
Un billet SYNOPSIS et un billet SOMMAIRE agrègent tous les billets du blog via des liens hypertextes.
■ ■ ■ SOMMAIRE DU BILLET ■ ■ ■
- Indépendance du langage
- Indépendance de la typologie du développement
- LCP, c’est trois niveaux de conceptualisation
- Sujets d'algorithmique inspirés de développements réels
- Imprimer des numéros de table en piles
- Traduction textuelle d’un montant numérique
- Algorigrammes LCP dans les forums
- Quelques liens utiles
Pratiquer LCP suppose de penser par traitements et non par conditions. Formaté « programmation sauvage », rééduquer ses neurones pour « raisonner sur la base des actions et non sur celle des conditions » nécessite un effort mental important car il faut résister au déviationnisme satisfaisant ses vieux réflexes. Cette règle fondamentale impacte l’organisation des traitements (MCT), le système de menus et la programmation (LCP) mais s’applique dans bien d’autres domaines.
■ § 1. Indépendance du langage
Un contributeur sur Wikipédia a prétendu le contraire (Discussion : programmation structurée) « La programmation en Warnier se fait par branchement (GO TO) ». L’auteur de ce propos n’a vraiment rien compris à LCP. Cela dit, pratiquer LCP avec un langage que l’on découvre nécessite une autre forme d’effort mental pour « fixer » ses repères et les adapter à son nouvel environnement de développement.
Maitriser un langage est une chose, maitriser la démarche algorithmique LCP en est une autre. Associer les deux en est encore une autre. Il s’agit d’adapter le concret (le langage) à l’abstrait (l’algorithme).
On parle parfaitement notre langue maternelle, on connait les règles d’écriture d’un poème, il reste à écrire le poème, à formuler sa pensée en respectant la forme.
On parle parfaitement notre langue maternelle, on connait les règles d’écriture d’un poème, il reste à écrire le poème, à formuler sa pensée en respectant la forme d'écriture poétique.
■ § 2. Indépendance de la typologie du développement
On peut penser que LCP n’est adapté qu’aux problématiques de gestion. Sans doute parce que selon ses principes, la structure hiérarchique d'un programme se déduit logiquement de la structure des données utilisées (FLS/FLE), la construction du programme commençant par la structuration des données qu'il doit produire en sortie.
- FLS = Fichier Logique de Sortie
- FLE = Fichier Logique d’Entrée
Cette perception n’est pas fausse si l’on n’a pas dépassé le premier niveau de conceptualisation. Passé l’apprentissage de la méthode, LCP peut se résumer par ce seul principe fort :
Dès lors, LCP peut s’appliquer quel que soit le langage, quel que soit le domaine. Le degré de décomposition algorithmique dépend de la capacité d’abstraction du programmeur. Mais ce n’est pas la même chose d’écrire une séquence de programme et de la lire ou de la relire soi-même plus tard.
« penser hiérarchiquement par traitements, autrement dit : raisonner du plus global vers le plus détaillé, par décompositions hiérarchiques successives sur la base des actions et non sur celle des conditions ».
■ § 3. LCP, c’est trois niveaux de conceptualisation
- Accolades, FLS/FLE ► Algorigramme ► Programmation :
Pédagogie (formateur) : durée = 1 semaine
Initiation (stagiaire) : durée = 2 à 3 semaines
- Algorigramme ► Programmation :
Apprentissage : 1 à 2 mois par type de programme (Contrôle/Mise-à-jour/Édition/Interactif)
- Penser par traitements ► Développer à main levée :
Expérience : toute sa carrière
Ces trois niveaux de conceptualisation peuvent être assimilés aux trois niveaux de lecture :
- Lecture syllabique
- Lecture mot-à-mot
- Lecture rapide
Passer du premier au deuxième, puis au troisième niveau, donc s’affranchir des accolades, de l’étude des FLS/FLE et de l’algorigramme nécessite un effort mental, la volonté de s’approprier la démarche, de l’adapter au langage de développement.
Passer du mode de pensée par conditionnements au mode de pensée par traitements se vit comme l’aboutissement d’une psychothérapie. C’est une prise de conscience, un choc psychologique irréversible. Il s’agit rien de moins que de refouler les automatismes de sa réflexion par conditionnements et d’imprimer durablement dans sa mémoire procédurale de nouveaux automatismes de réflexion par traitements.
La formation ou l’autoformation doit être considérée comme un investissement. On doit admettre que c’est un départ et qu’il faut ensuite concéder une période d’assimilation des principes appris. Ceux-ci enfin, doivent faire l’objet d’une recherche objective et de recommandations convenues. Il n’y a pas de « méthode de programmation », il y a un ensemble de principes fondamentaux plus ou moins bien exprimés et utilisés. La programmation ne se présente pas uniquement sous la forme de prescriptions mythiques.
Un langage dit « structuré » comme « ace », compilateur à base de SQL de l’EDI Informix, permet de déclarer des clauses « FORMAT », « BEFORE GROUP OF », « ON EVERY ROW », « AFTER GROUP OF » et « ON LAST ROW » (+ des clauses « PAGE HEADER » - « PAGE TRAILER ») qui ne sont rien d’autres que les « DÉBUT PROGRAMME », « DÉBUT TRAITEMENT », « TRAITEMENT », « FIN TRAITEMENT » et « FIN PROGRAMME » de LCP ; la décomposition hiérarchique des traitements (du général au particulier) se réalisant par une simple clause « ORDER BY ».
DÉBUT PROGRAMME FORMAT DÉBUT TRAITEMENT BEFORE GROUP OF TRAITEMENT ON EVERY ROW FIN TRAITEMENT AFTER GROUP OF FIN PROGRAMME ON LAST ROW
La prétendue programmation structurée avec son arbre programmatique et ses feuilles, certes à base de structures itératives/alternatives (comme LCP) n’a fait que relooker la programmation sauvage et permis de déculpabiliser des générations de développeurs dont le raisonnement a été formaté « par conditions ».
Arbre Programmatique (Définit par Roland Trique) : arbre comportant des nœuds et des feuilles, le tout disposé selon un arbre inversé et selon une structure hiérarchique, permettant de représenter le raisonnement dans le cadre d'une programmation structurée (d'après Jean Wojtalik).
Yves LEROY :
Anecdote :
À la suite de la formation LCP qui terminait mon cycle de formation chez le constructeur (Assembleur, Fortran, COBOL et LCP), je me suis installé par hasard dans un bureau où 7 collègues développaient l’application de gestion du personnel du Ministère de l’Agriculture.
Les développements étaient sur le point de se terminer mais il manquait encore le programme le plus important, la mise-à-jour. Deux tentatives de développement n’avaient pas abouti et la troisième venait d’être interrompue. Le chef de projet a alors manifesté son impatience et exhorté l’équipe à prendre ses responsabilités. Ne faisant pas partie de l’équipe et n’étant pas sollicité sans doute à cause de mon âge (23 ans), de mon modeste niveau d’études (BEPC), de mes deux années passées à l’exploitation comme opérateur-pupitreur et de mon inexpérience supposée en programmation, j’ai quand même relevé le défi en proposant : « Si vous vous voulez, je veux bien le faire votre programme ! »
Une analyste qui avait fait le stage LCP avec moi, m’avait vu à l’œuvre au cours de ce stage et s’est immédiatement proposée pour faire l’analyse. « Pourquoi pas, on n’a plus rien à perdre » a-t-il été dit. Deux mois plus tard, le programme était développé. Ce fut mon premier algorigramme LCP et mon premier programme en tant que professionnel. Il a géré le personnel pendant 14 ans.
L’application terminée, l’équipe a été dissoute pour constituer de nouvelles équipes de développement. Oublié, j’ai dû laisser mon poste de travail et retrouver une place ailleurs. J’ai pu m’installer trois bureaux plus loin où une équipe développait une application pour le compte de l’Office des Vins.
L’ambiance dans ce bureau était plutôt tendue, chacun travaillant en silence, concentré sur son listing. Tout à son travail, le chef de projet laisse échapper : « On ne sera jamais dans les temps, on va avoir des pénalités de retard ». À leur grande surprise, je leur dit : « Si vous voulez, je peux vous aider ? ».
J’ai d’abord été testé avec un programme d’édition d’erreurs que j’ai écrit en une semaine avec quasiment une seule instruction, un « MOVE CORRESPONDING », le seul que j’ai utilisé dans toute ma carrière de coboliste. Encouragés, ils m’ont confié LE programme d’édition de l’application, un programme qu’ils considéraient comme particulièrement complexe. Deux mois plus tard, le programme imprimait les premières fiches d’encépagement et l’application était opérationnelle dans les temps. Le programme sera vendu quelques années plus tard au CIVC (Comité Interprofessionnel des Vins de Champagne).
Avec ce programme, ce fut donc mon deuxième algorigramme LCP. Après ça, je n’ai plus eu besoin de réaliser d’algorigramme, je développais à main levée.
Pour la petite histoire… Je n’ai jamais fait partie officiellement d’une équipe de développement. Programmeur "dernier recours", mes challenges « Programmation » se sont succédés au gré des hasards et des sollicitations puis se sont transformés, toujours par hasard, en challenges « Application ». On dit que le hasard vaut mieux que mille rendez-vous.
Les principes présentés dans le document « LA PROGRAMMATION RATIONNELLE (1971) » sont inspirés de l’œuvre de Jean-Dominique WARNIER. Les principes étudiés ne proviennent pas de subtiles sophistications. Présentés avec plus de rigueur, ils pourraient avoir force de loi. Nous pensons qu’ils peuvent être le point de départ d’une amélioration des programmes et de la gestion automatisée qui ait les objectifs suivants :
- Construire le programme sur des bases logiques plutôt que créer une œuvre artisanale.
- Faciliter la maintenance des programmes en les dépersonnalisant.
- Créer un langage logique de programmation, indépendant de l’outil utilisé, commun aux informaticiens.
- Faire du développement un ensemble cohérent.
NB : Propos cités dans l’Avertissement du document « LA PROGRAMMATION RATIONNELLE » d’Yves LEROY.
Pour cela, il faut :
- s’approprier la méthode en adaptant ses principes aux spécificités du langage utilisé.
- Dépersonnaliser la programmation en optant pour des noms de tables et des noms de données pertinents, issus d’une réflexion et non de l’imagination.
- Personnaliser le programme dans sa mise en page en adoptant des règles.
- Développer de façon homogène et rigoureuse les programmes, shells, requêtes SQL.
Afin d’illustrer ce beau discours, je propose deux sujets inspirés de développements réels :
- L’impression des numéros de table pour l’organisation des examens-concours
- La traduction textuelle d’un montant numérique
Il ne s’agit pas seulement ici de citer des exemples de structures itératives, répétitives, simples ou complexes, mais de montrer concrètement comment peuvent se traduire ces quatre objectifs. Les problématique choisies sont simples, compréhensibles, originales, intéressantes du point de vue de l’analyse, de l’algorithmique, de la programmation et de la pédagogie.
Les programmes choisis constituent des exemples de développement illustrant :
- la cohérence des choix de développement,
- les règles de nommage des tables et des données,
- la préoccupation de la structure du programme,
- la préoccupation de la mise en page,
- l’exploitation des MAJUSCULES/minuscules pour distinguer INSTRUCTIONS/données,
- l’adaptation de la méthode LCP au contexte spécifique du compilateur « ace » du SGBD/R Informix,
- l’utilisation des clauses du langage comme commentaires,
- l’ajout en fin de programme du shell d’exécution et d’éventuelles requêtes SQL.
On « lit » un programme, on « lit » toute l’application. Il ne s’agit pas cependant de comprendre la programmation des programmes proposés mais de comprendre le message « LCP » qu’ils transmettent.
Ce sont néanmoins d’excellents exercices algorithmiques pour d’éventuels formateurs.
■ § 4. Sujets d'algorithmique inspirés de développements réels
- Imprimer des numéros de table en piles
- Sujet d’algorithmique original : imprimer des numéros de table en piles
- Simulation
- Algorigramme LCP
- Programme " post_itBDD.ace "
- Les tables de la BDD sollicitées par le programme post_itBDD
- Programme source " post_itBDD.ace "
- La pédagogie LCP
- Méthodologie « logique de Construction de programme » (LCP)
- LCP et le programme post_itBDD.ace
- Structuration des données de Sortie (FLS)
- Structuration des données d’entrée (FLE)
- Structuration du programme (PRG)
- Algorigramme
- Structuration in extenso du programme
- Édition des numéros de table
- post_itALL.ace
- Algorigramme
- Méthodologie de programmation LCP
- Traduction textuelle d’un montant numérique
- Compréhension de la problématique
- Simulation
- Règles orthographiques des nombres en lettres
- Million et milliard
- Mille ou Milles ?
- Cent ou Cents ?
- Vingt ou Vingts ?
- Les nombres de 20 à 99
- L'Algorigramme
- L'algorithme
- Exercice pratique de refactoring
■ § 5. Algorigrammes LCP dans les forums
Discussion : Algorithme pour établir un ordre de passage§ 5.1. : Forum Algorithmes et structures de données
Discussion : Écrire une base de programme
Discussion : Sujet d’algorithmie original : imprimer des numéros de table en piles
Discussion : Logigramme et représentation
Discussion : Exercice sur l'exponentiation rapide
Discussion : 'Tit PB d'algo intéressant : Calendrier d'un championnat de football africain
- Deux objectifs : créer table MATCHS puis ecploiter la BDD
- Synthèse (1ère partie)
- Synthèse (2ème partie)
Discussion : Compréhension de l'algorithme de calcul de la factorielle
Discussion : Exercices d'algo
Discussion : exercice bts algo
Discussion : Une mise à jour 0,1 pour 0,n§ 5.2. : Forum COBOL
■ § 6. Quelques liens utiles
La logique informatique (Blog de Serge Meneut)
Les bonnes pratiques de programmation
▲ I-2.2.2. Règles de développement
► I-2.2.3. Méthodologie de programmation LCP
▼ I-2.2.4. La programmation mentale
Consulter le profil
Marquer ce blog comme lu
