 |
Mercredi 11 juin 2025 - 11:17 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Fed-CASE 1.0 est un nouvel "éditeur de logigrammes" de Joosen Software Development distribué en France par Someware, à qui nous devons déjà l'importation de l'excellent compilateur DICE.
L'aide à la conception d'un programme
Lorsque l'on développe une grosse application, il est souvent utile de s'éloigner un peu du langage de programmation pour avoir une vue plus précise des buts à atteindre. Quel que soit le niveau du programmeur, un petit "croquis" sur une feuille de papier était souvent la meilleure solution pour mettre au point un algorithme complexe, mais tout ceci est du passé car... (roulement de tambours, le suspense est à son comble...) voici venu sur notre machine préférée non pas un, mais deux programmes d'aide à la conception : j'ai nommé Fed-CASE et Strux.
Attention, nous n'allons pas parler de constructeurs de GUI comme Designer ou GadToolsBox qui permettent aussi de générer un source mais dont le but est de créer une interface graphique. Fed-CASE et Strux sont aussi des constructeurs, mais de programmes.
Deux méthodes sont couramment utilisées :
1. Un pseudo-langage, quelque fois nommé "langage d'analyse", qui se présente sous la forme d'une sorte de PASCAL libre où tous les côtés "bassement machine" ont été supprimés. Par exemple, un programme de factorielle par multiplications successives et appels récursifs se présenterait comme suit :
Programme Factoriel
Fonction fact(nombre) de type réel;
paramètre d'entrée
nombre de type réel;
début
si(nombre > 1) alors
retourne(nombre*fact(nombre-1) );
sinon
retourne( 1 );
finsi
fin
Variables
x de type réel;
début
affiche('Entrez un nombre :');
lire(x);
affiche('resultat =',fact(x));
fin
|
Cette méthode que l'on m'a enseignée à l'IUT ne m'a jamais satisfait car je ne l'a trouvais pas très claire. En plus, les professeurs avaient instauré une syntaxe tellement stricte que j'en étais réduit à coder mon programme d'abord en C avant de le traduire en analyse : bonjour l'intérêt ! Bon, c'est un cas extrême et ce type de langage, dans des versions beaucoup plus puissantes (et plus illisible pour le profane) est souvent utilisé avec des générateurs de code du genre de Yacc ou Lex.
2. La deuxième méthode dite des "logigrammes" ou des "organigrammes" présente le programme sous une forme graphique où chaque action a son propre symbole. Pour ceux qui travaillent sur automates programmables dans l'industrie, cette méthode ressemble au Grafcet mais en beaucoup plus puissant. Ici, le cheminement du programme saute aux yeux... ou l'esprit tordu du programmeur ! C'est l'origine du code spaghetti. Nommé "flowcharting" dans la langue de Shakespeare, le déroulement du programme est représenté comme l'écoulement (flow) de l'eau dans des pipelines mais avec tous les artifices de la programmation : les boucles, les sauts, les fonctions, les tests...
L'installation
Il est livré sur deux disquettes (le programme et une disquette de données) et avec une documentation de 151 pages malheureusement qu'en anglais. Il fonctionne "sur n'importe quel Amiga équipé d'au moins 1 Mo" (dixit la doc).
Le programme peut démarrer directement de la disquette fournie. N'oubliez pas la règle habituelle de sécurité : on ne travaille jamais sur la disquette originale, mais uniquement sur une copie ! Un script Installer permet l'installation sur disque dur mais j'aurais aimé qu'il soit indiqué la taille nécessaire, c'est-à-dire 781 ko avec tous les exemples.
Ce programme est complètement localisable, même sous 1.3, car il utilise des fichiers de configuration (comme DICE avec son DCC:config/dice.errors). Malheureusement, seuls les fichiers anglais sont disponibles (allez Someware, un petit effort !). Autre point positif : il ne joue pas au petit Poucet, tout est centralisé dans son propre répertoire (ceux du système sont déjà assez encombrés sans que l'on rajoute les fichiers spécifiques à une application). Par contre, il doit créer une assignation et modifier le "path". Fin (provisoire) de l'installation.
Un exemple
Je clique sur l'icône "Fdc", qui ouvre une fenêtre sur le Workbench (que l'on peut heureusement fermer) avec son droit d'auteur, puis un écran qu'il referme immédiatement : "Error 15: Could not open Status Window".
Après une (longue) recherche, je me suis aperçu que le problème provenait de mes préférences : l'écran de mon Workbench a un suraffichage qui est plus grand que la taille du ScreenMode, 668x262 contre 662x262 (car le codeur PAL de mon A1000 a la fâcheuse habitude de décaler légèrement l'affichage vers la droite : avec ces réglages, je peux le centrer en faisant simplement glisser l'écran). Après un petit voyage dans Prefs/ScreenMode, je reclique sur l'icône, le disque dur crépite... Ça marche, maintenant devant moi l'écran de l'éditeur.
La première fenêtre contiendra nos graphiques, la seconde les symboles à notre disposition, et la troisième en bas est la fameuse "Status Window" où seront affiché divers messages provenant du programme.
Figure 1
Fed-CASE produit lui-même les déclarations, les types et les domaines de visibilité des variables ou des fonctions étant définis dans les noms. Ainsi V_main() est équivalent à void_main(). LI_i indique que la variable "i" est locale à la fraction et de type entière (int i). Si le nom commence par un "F", il s'agit d'un paramètre de la fonction. Même si cette syntaxe est assez inhabituelle, on s'y fait très rapidement. J'émettrai quand même une petite réserve en ce qui concerne les structures car, si utiliser celles prédéfinies (New-Window, Gadget...) est trivial, en créer une relève de l'exploit tellement la syntaxe est impénétrable.
Pour le reste, je vous renvoie à la documentation qui est complète et très compréhensible même pour ceux qui ne lisent pas couramment l'anglais. Les différentes structures de tests, de boucles, etc., sont décrites et accompagnées d'exemples parlants. Il y a même une introduction au C mais...
La documentation et les exemples
Eh oui, il y a un mais : elle comporte quelques erreurs importantes. Je passe sur certains sources C ne correspondant absolument pas aux logigrammes auxquels ils sont associés, mais le chapitre 20 concernant les pointeurs (page 94) laisse planer quelques doutes sur les connaissances en C de la personne qui l'a écrit.
Ainsi, &LPI_ptr=LPI_ptr+3 (le "&" indique qUe l'on travaille sur le pointeur et non sur la valeur pointée) avec LPl_ptr=0x2000 ne donnera jamais 0x2003 mais 0x200c. Petit rappel : on ne rajoute pas 3 à la valeur du pointeur mais on demande à ce qu'il pointe sur trois éléments plus loin. Comme ptr est un pointeur sur des entiers, qui sont codés sur quatre octets sur 68000, ptr augmentera de 3x4=12 octets.
Pis encore, tout le long de la documentation, les entiers sont lus par des scanf("%d",LI_nbre). Ce qui provoquera une fois de plus le réveil du méditateur fou (vous savez, le fameux cadre rouge...). Eh oui, comme tout programmeur C le sait, on ne passe pas à scanf() la variable qui doit contenir l'entier mais son adresse. La bonne version est donc : scanf("%d",&LI_nbre).
Dans le même genre, ce n'est pas la peine de tester fac.flow, qui n'affichera aucun factoriel car il calculera, par exemple, fac(4) de la manière suivante : fac(4)=4x3x2x1 ... x0 (à bon !). Résultat : quel que soit le factoriel demandé, le résultat sera toujours nul.
Pis encore : une boucle est utilisée dans main(), dont l'indice n'est jamais incrémenté ou décrémenté (ben voyons !). Ce sont vraiment des erreurs de débutants !
Génération du code
Les mauvaises surprises continuent : Installer n'a pas fait tout le travail. Il avait demandé où se trouvent les includcs du compilateur C. Peines perdues, car le générateur recherche quand même le volume Include:. Pire, il doit créer deux fichiers "include:data/const_nom_du_programme.h" et "include:proto/proto_nom_du_programme.h".
Je tiens à dire que je trouve totalement déplorable d'écrire au milieu des includes (surtout que include:proto est déjà utilisé) alors que ces fichiers auraient pu être créés dans le même répertoire que le source et utilisés par un #include "nom_de_l'include". Si vous utilisez DICE, une simple assignation n'est pas suffisante car ce compilateur stocke les fichiers Commodore dans un sous-répertoire nommé "amigaxx", mais on n'en voudra pas à Fed-CASE qui n'est pas obligé de prendre en compte toutes les fantaisies de nos compilateurs. Ma solution a été de faire une multi-assignation :
Assign include: sources: Dinclude: Dinclude:amiga20 ADD |
Pour être complet, il faudrait rajouter Dinclude:pd où l'utilisateur peut mettre les fichiers relatifs aux bibliothèques extérieures (reqtools, ARP...).
"Sources:" est le répertoire où est créé le code C, et où j'ai ajouté deux sous-répertoires ("data" et "proto" évidemment), ainsi mes includes restent intactes.
Pour l'exemple arg.flow. voici le code généré :
Il se compile sans problèmes avec DICE, tout comme le reste des exemples que j'ai testés (je n'ai pas dit qu'ils faisaient ce pourquoi ils étaient prévus, voir fac.flow), mais quelques défauts sont apparus. D'abord attention de ne jamais lancer l'éditeur par l'icône d'un projet car la pile donné (4 ko) est beaucoup trop petite d'après ce que dit la documentation (20 ko). Ensuite, ce n'est pas Fdc qui génère le code mais un programme annexe nommé "code" et qui affiche ses messages sur la fenêtre qui a été ouverte sur le Workbench. Dans l'éditeur, rien n'indique que le code est en train d'être créé. Aucun signal pour dire que la génération est terminée, que ce soit dans Fde ou dans la fenêtre de sortie.
Il aurait pourtant été si simple de bloquer la fenêtre d'édition (pointeur "busy"), de faire passer le Workbench en avant-plan et de faire apparaître une requête quand la traduction est finie. Si beaucoup de structures sont utilisées, la génération du code laisse le temps d'aller prendre un café avec des copains, de regarder un film à la télé, voire de relire entièrement son dernier Amiga News. WindowExamp.flow qui ne fait qu'ouvrir une fenêtre a été converti en... 5 minutes 30, montre en main. Ce n'était pas mon 68010 qui ramait, car ce n'était guère plus rapide sur A1200, mais simplement "Code" qui a lu, relu (et rerelu) les fichiers include. La LED du disque n'a pas arrêté de clignoter. J'ai un peu peur pour ceux qui n'ont pas de disque dur...
Créer son propre logigramme...
Le logigramme que vous pouvez voir en figure 2 vaut de l'or : non pas qu'il provienne d'un nouveau Einstein de l'informatique, car ce n'est que mon oeuvre mais il est exceptionnel de par les embuches que j'ai dû surmonter. Après quelques manipulations, la seule chose que j'obtenais était un... Guru.
Figure 2
Le graph est classique et très lisible. Remarquez simplement que je suis obligé de placer le résultat de facto dans une variable temporaire nommée "LI_ret" car le code refuse deux points de sosie pour une même fonction. Le code généré est correct et se compile sans problème avec DICE... Heureusement, vu la simplicité de cet exercice !
Tentative d'impression : je ne vais pas parler que de l'A1200 car sur mon A1000, la seule chose que ma Star LC10 Couleur ai sortie a été un superbe carré noir, malgré mes tentatives pour changer mes préférences (image positive ou négative, etc.).
Bon bref, l'A1200 a réussi à imprimer le graph... mais en quel état. D'abord, Fdc imprime un en-tête. C'est bien, mais pourquoi insérer un Form Feed ensuite ? Bonjour la consommation de papier. Ensuite, l'impression est très grossière. Pas très concluant tout ça !
Conclusion
Je dois dire que j'ai été particulièrement déçu : le concept était vraiment intéressant mais la réalisation gâche tout. Il y a des petits moins plus ou moins grave partout : l'installation incomplète, le Guru de l'Auto-Save ou l'impossibilité d'ouvrir un écran virtuel plus grand que l'écran physique...
Utiliser ce logiciel dans de telles conditions relève de la haute voltige ou du masochisme, mais heureusement, le temps pris à chaque génération où des structures système sont utilisées laisse largement le temps de se remettre de nos émotions. :-/
Bref, cette version usurpe le numéro 1.0 tant on a l'impression d'être devant une bêta pas très finie, impression confirmée par de nombreuses options inopérantes (impossible de placer l'éditeur sur un écran public par exemple). Elle ne peut servir que de démo (et encore). La documentation, même si elle explique bien le produit et la façon de l'utiliser, contient trop d'erreurs, dont certaines impardonnables pour être prise au sérieux.
C'est vraiment du gâchis et la seule chose qui empêcherait ce produit de rejoindre AmigaBasic dans ma "trashcan" serait une nouvelle version beaucoup plus stable, plus propre (pourquoi écrite dans les includes ?) et qui génère un code utilisable même pour un programme complexe. Il deviendrait à coup sûr une aide à la programmation incontournable... Bref, il est urgent d'attendre.
Someware, qui importe ce produit en France, m'a parlé d'une version supérieure plus stable en cours de test qui sera aussi portée sur d'autres systèmes (Windows NT, Unix).
Annexe : le commentaire d'Éric Gontier
Éric Gontier de Someware a fourni, à notre requête, le commentaire suivant à propos de ce test :
L'aspect novateur, les perspectives d'évolution, et l'intérêt évident dans le cadre d'études ou d'apprentissage au langage C, nous ont encouragé à diffuser Fed-CASE. Si, actuellement, quelques fonctions sont absentes ou ne fonctionnent pas correctement, l'édition d'organigrammes et la génération de code C sont parfaitement possibles. Nous sommes bien sûr conscients des problèmes actuels du logiciel, et nous travaillons activement avec l'auteur, Christian Joosen, afin de les résoudre et d'améliorer le produit. Une nouvelle version, issue de cette collaboration, sera donc disponible prochainement.
|
Nom : Fed-CASE. Développeur : Joosen Software Developement. Genre : aide à la programmation. Date : 1993. Configuration minimale : Amiga OCS, 68000, 1 Mo de mémoire. Licence : commercial. Prix : NC. |
|
