Micro Systèmes n°23 mai/jun 1982
Micro Systèmes n°23 mai/jun 1982
  • Prix facial : 18 F

  • Parution : n°23 de mai/jun 1982

  • Périodicité : mensuel

  • Editeur : Société Parisienne d'Edition

  • Format : (213 x 271) mm

  • Nombre de pages : 246

  • Taille du fichier PDF : 185 Mo

  • Dans ce numéro : Synthé... une nouvelle machine qui parle et qui chante.

  • Prix de vente (PDF) : gratuit

Dans ce numéro...
< Pages précédentes
Pages : 118 - 119  |  Aller à la page   OK
Pages suivantes >
118 119
Connaître le Basic n'est pas savoir programmer, de même qu'apprendre par coeur le dictionnaire ne signifie pas savoir rédiger un roman. Informatique technique, il se lance bientôt dans un programme de comptabilité générale. Après trois mois d'effort, quelques « morceaux » de programme ont été écrits  : quelques-uns fonctionnent bien, d'autres mal, certains pas du tout. Six mois supplémentaires ont permis de l'améliorer. Le programme « tourne », mais il n'en est pas pour autant utilisable de manière professionnelle, car il délivre parfois des résultats manifestement aberrants, et il est souvent préférable de vérifier les calculs. Découragé, Jean Durand fait finalement appel à un informaticien professionnel qui reprend tout à zéro et développe en trois mois le logiciel demandé. Depuis, l'entreprise n'a plus aucun problème de gestion ; de plus la conception des programmes est telle que Jean Durand a lui-même réalisé quelques extensions. Programmation et codage Cet exemple ne constitue en aucun cas une attaque contre les autodidactes  : il faut un certain courage pour apprendre l'informatique « sur le tas ». Mais, comme nombre de débutants, Jean Durand a confondu conception et codage, programmation et écriture de lignes d'instructions. Connaître le BASIC n'est pas savoir programmer, de même qu'apprendre par coeur le dictionnaire, si cela était possible, ne signifie pas savoir rédiger un roman. Programmer, c'est définir précisément le problème à résoudre, décrire peu à peu une solution et, après seulement, l'exprimer dans un langage de programmation. Dans cette démarche, l'activité la plus créative n'est pas le codage mais l'analyse du problème  : si l'analyse est bien faite, le codage est linéaire et ne présente aucune difficulté et souvent peu d'intérêt. Les avantages d'une bonne méthode de programmation sont de trois ordres  : conception aisée, uti- lisation appréciée et maintenance facilitée.• Conception S'il est très facile de rédiger un programme de résolution d'équations du second degré, il s'avère beaucoup plus délicat de créer un logiciel de comptabilité, la différence se situant sur le plan de la complexité. Le premier est tellement simple qu'il peut être écrit directement, tandis que le second ne peut être appréhendé dans son entier par quiconque  : il est alors indispensable de le décomposer en petits modules dont la structure est claire. Une bonne méthode de programmation revient ainsi à ne rédiger que des « petits » programmes, par décomposition modulaire. La conception des programmes s'en trouve simplifiée, et le temps de développement réduit. Le programme fonctionne souvent dès les premières exécutions, et la structure modulaire favorise une recherche aisée des erreurs qui subsistent éventuellement. Dans l'exemple précédent, le programme de comptabilité a été écrit en BASIC. Le BASIC n'est pas un langage structuré, mais la conception, elle, peut être structurée. L'analyse d'un problème est indépendante du langage utilisé.• Utilisation Le premier stade d'une application informatique doit être la définition exacte des besoins de l'utilisateur. C'est une phase capitale de toute application informatique et sur laquelle repose toute la suite du développement. Une mauvaise analyse ne pourra qu'engendrer un programme inadéquat. L'utilisateur attend de son logiciel qu'il soit opérationnel rapidement, qu'il fonctionne correctement (quel crédit accorder à un logiciel qui se « plante », comme disent les spécialistes, une fois sur trois pour une cause inconnue), enfin qu'il soit facile à utiliser, c'est-à-dire qu'il lui apporte effectivement une aide et non des tracas supplémentaires. Quelle que soit la qualité de la conception, une mise en oeuvre trop complexe entraînera une réaction de rejet de la part de l'utilisateur. La facilité d'emploi doit donc être considérée dès l'analyse du problème.• Maintenance Dès son fonctionnement, un programme est déjà dépassé ! L'expérience montre qu'il suffit d'un court usage pour s'apercevoir que le programme, si laborieusement conçu, ne donne pas les résultats qui seraient réellement utiles et fournit des informations trop souvent inexploitables. Structurer la programmation permet d'obtenir des programmes lisibles, et donc de favoriser la compréhension de logiciels conçus par d'autres... ou par soi-même  : qui n'a jamais eu de mal à relire un listing rédigé six mois auparavant ? Il ne faut pas songer à modifier un programme que l'on ne comprend pas, car le résultat est généralement catastrophique. La lisibilité d'un programme facilite sa compréhension. Il est en effet plus aisé de modifier le programme BASIC suivant  : 130 GOSUB 300  : REM ENTREE DONNEES 140 GOSUB 360  : REM VERIFICATION 150 GOSUB 470  : REM CALCULS que celui-ci  : 127 A = 3  : GOTO 180 130 INPUT A, B, C 132 INPUT A$  : POKE 13,161 140 IF A > 0 THEN PRINT « IMPOSSIBLE » La conception modulaire, outre son apport dans la compréhension, autorise la modification d'une partie du programme sans devoir réécrire l'ensemble. Cette caractéristique permet de créer des extensions ou d'imaginer des améliorations au logiciel original. Nous verrons à ce sujet qu'il est indispensable de bien spécifier les entrées-sorties d'un module. Chaque module doit être une boîte noire pour les autres modules, ne 118 MICRO-SYSTEMES Mai-Juin 1982
Introduction à la programmation structurée Informatique se définissant que par ses valeurs d'entrée, ses valeurs de sortie et sa fonction de traitement. Les principes d'une programmation structurée La rédaction d'un programme ne se réduit pas à l'écriture du plus grand nombre possible de lignes BASIC ou FORTRAN dans le minimum de temps ; au contraire, la tendance actuelle en informatique est de s'intéresser plus à la qualité des instructions produites qu'à leur nombre. La conception d'un programme est une démarche progressive qui suit un certain ordre. On distingue quatre phases principales  : 1 - La description exacte du problème. 2 - L'analyse structurée du problème et la recherche de sa solution. 3 - Le codage, ou écriture des programmes. 4 - Le test et la mise au point du logiciel. Décrire ce que l'on veut faire La définition exacte des tâches à résoudre est en général une étape tellement « évidente » que bien des programmeurs la négligent ; cela a pour effet de prendre en compte des hypothèses implicites, qui sont celles du programmeur et non celles de l'utilisateur. En fin de parcours, le résultat est parfois catastrophique. En général, l'utilisateur ne connaît pas l'informatique, souvent il s'en moque et le reconnaît  : son seul désir concerne le produit final et non ses détails techniques. Lorsqu'il s'agit de nos propres programmes, il y a lieu d'être encore plus vigilant  : croyant savoir ce que nous voulons obtenir, nous nous lançons tête baissée dans la rédaction, en oubliant certains aspects qui, au début mineurs, apparaissent bientôt comme fondamentaux. Avant de débuter une applica- tion, il est important de préciser les points suivants  : Spécifications de sortie — Quels résultats doivent être imprimés ou affichés ? — Quel est le domaine des valeurs à obtenir (afin d'éliminer les résultats indésirables) ? — Y a-t-il des messages spéciaux à sortir, et lesquels ? — L'impression ou l'affichage doivent-ils utiliser un format bien défini ? Spécifications d'entrée — Quel type de valeurs le programme doit-il attendre ? — Comment sont entrées ces valeurs ? — Quel est le domaine des valeurs à introduire (afin de supprimer les données indésirables) ? — Que doit faire le programme en cas de données invalides ? Spécifications de traitement — Quel traitement doit être effectué ? — Existe-t-il des cas spéciaux à traiter, et comment ? Décomposer le problème Définir exactement le rôle du programme est une étape nécessaire, mais non suffisante. Arrivé à ce stade, le problème posé paraît généralement colossal, et l'informaticien moyen se demande comment le résoudre dans les délais impartis. Afin de simplifier l'analyse, la programmation structurée énonce une série de formules destinées à réglementer le processus de développement de toute application informatique. 1° Le développement du programme doit être effectué indépendamment de tout langage de programmation. L'analyse est effectuée dans un langage naturel, et le programmeur utilise les notations qu'il juge les plus faciles et les plus évidentes, même si elles n'existent dans aucun langage. Ce n'est qu'au codage que le langage utilisé imposera ses exigences. 2° Le programme doit être construit par niveaux, l'analyse est effectuée par niveaux de décomposition successifs, chaque étape détaillant un peu plus l'analyse réalisée à un niveau précédent. Le développement va ainsi du général au particulier, du plus simple au plus compliqué. De ce fait, la programmation structurée est également appelée programmation descendante (« top down design »). 3° Le programme doit être décomposé peu à peu. A chaque étape le programmeur ne décrit que ce qui est strictement nécessaire et renvoie les détails aux niveaux inférieurs. Ainsi, il est inutile de fixer la taille des variables tant que la structure globale n'est pas définie. Chaque phase précise un peu mieux la précédente, et le programmeur s'arrête lorsqu'il a obtenu une décomposition suffisante pour être codée dans un langage de programmation existant. 4° Le programme doit être vérifié à chaque niveau. Après l'écriture d'un niveau, le programmeur vérifie si les décompositions effectuées correspondent bien aux définitions données dans les niveaux antérieurs, c'est-à-dire si les modules fonctionnent individuellement et si l'enchaînement des modules dans le programme est correct. Pour cela, il suffit de choisir un ensemble de données conduisant à un résultat connu et d'exécuter le programme à la main comme le ferait l'ordinateur, en suivant exactement ce qui est écrit. Toutes ces règles peuvent être résumées en une seule  : 5° Un programme doit être simplifié au maximum. Quoique cela puisse paraître paradoxal, il est plus courant de réaliser un programme compliqué que simple. Le but avoué de la programmation structurée consiste ainsi à ramener un problème complexe en une série de petits problèmes. Ecrire le programme Le codage revient à transcrire directement l'analyse en un langage de programmation existant. Le choix est large puisqu'il existe Mai-Juin 1982 MICRO-SYSTEMES — 119



Autres parutions de ce magazine  voir tous les numéros


Liens vers cette page
Couverture seule :


Couverture avec texte parution au-dessus :


Couverture avec texte parution en dessous :


Micro Systèmes numéro 23 mai/jun 1982 Page 1Micro Systèmes numéro 23 mai/jun 1982 Page 2-3Micro Systèmes numéro 23 mai/jun 1982 Page 4-5Micro Systèmes numéro 23 mai/jun 1982 Page 6-7Micro Systèmes numéro 23 mai/jun 1982 Page 8-9Micro Systèmes numéro 23 mai/jun 1982 Page 10-11Micro Systèmes numéro 23 mai/jun 1982 Page 12-13Micro Systèmes numéro 23 mai/jun 1982 Page 14-15Micro Systèmes numéro 23 mai/jun 1982 Page 16-17Micro Systèmes numéro 23 mai/jun 1982 Page 18-19Micro Systèmes numéro 23 mai/jun 1982 Page 20-21Micro Systèmes numéro 23 mai/jun 1982 Page 22-23Micro Systèmes numéro 23 mai/jun 1982 Page 24-25Micro Systèmes numéro 23 mai/jun 1982 Page 26-27Micro Systèmes numéro 23 mai/jun 1982 Page 28-29Micro Systèmes numéro 23 mai/jun 1982 Page 30-31Micro Systèmes numéro 23 mai/jun 1982 Page 32-33Micro Systèmes numéro 23 mai/jun 1982 Page 34-35Micro Systèmes numéro 23 mai/jun 1982 Page 36-37Micro Systèmes numéro 23 mai/jun 1982 Page 38-39Micro Systèmes numéro 23 mai/jun 1982 Page 40-41Micro Systèmes numéro 23 mai/jun 1982 Page 42-43Micro Systèmes numéro 23 mai/jun 1982 Page 44-45Micro Systèmes numéro 23 mai/jun 1982 Page 46-47Micro Systèmes numéro 23 mai/jun 1982 Page 48-49Micro Systèmes numéro 23 mai/jun 1982 Page 50-51Micro Systèmes numéro 23 mai/jun 1982 Page 52-53Micro Systèmes numéro 23 mai/jun 1982 Page 54-55Micro Systèmes numéro 23 mai/jun 1982 Page 56-57Micro Systèmes numéro 23 mai/jun 1982 Page 58-59Micro Systèmes numéro 23 mai/jun 1982 Page 60-61Micro Systèmes numéro 23 mai/jun 1982 Page 62-63Micro Systèmes numéro 23 mai/jun 1982 Page 64-65Micro Systèmes numéro 23 mai/jun 1982 Page 66-67Micro Systèmes numéro 23 mai/jun 1982 Page 68-69Micro Systèmes numéro 23 mai/jun 1982 Page 70-71Micro Systèmes numéro 23 mai/jun 1982 Page 72-73Micro Systèmes numéro 23 mai/jun 1982 Page 74-75Micro Systèmes numéro 23 mai/jun 1982 Page 76-77Micro Systèmes numéro 23 mai/jun 1982 Page 78-79Micro Systèmes numéro 23 mai/jun 1982 Page 80-81Micro Systèmes numéro 23 mai/jun 1982 Page 82-83Micro Systèmes numéro 23 mai/jun 1982 Page 84-85Micro Systèmes numéro 23 mai/jun 1982 Page 86-87Micro Systèmes numéro 23 mai/jun 1982 Page 88-89Micro Systèmes numéro 23 mai/jun 1982 Page 90-91Micro Systèmes numéro 23 mai/jun 1982 Page 92-93Micro Systèmes numéro 23 mai/jun 1982 Page 94-95Micro Systèmes numéro 23 mai/jun 1982 Page 96-97Micro Systèmes numéro 23 mai/jun 1982 Page 98-99Micro Systèmes numéro 23 mai/jun 1982 Page 100-101Micro Systèmes numéro 23 mai/jun 1982 Page 102-103Micro Systèmes numéro 23 mai/jun 1982 Page 104-105Micro Systèmes numéro 23 mai/jun 1982 Page 106-107Micro Systèmes numéro 23 mai/jun 1982 Page 108-109Micro Systèmes numéro 23 mai/jun 1982 Page 110-111Micro Systèmes numéro 23 mai/jun 1982 Page 112-113Micro Systèmes numéro 23 mai/jun 1982 Page 114-115Micro Systèmes numéro 23 mai/jun 1982 Page 116-117Micro Systèmes numéro 23 mai/jun 1982 Page 118-119Micro Systèmes numéro 23 mai/jun 1982 Page 120-121Micro Systèmes numéro 23 mai/jun 1982 Page 122-123Micro Systèmes numéro 23 mai/jun 1982 Page 124-125Micro Systèmes numéro 23 mai/jun 1982 Page 126-127Micro Systèmes numéro 23 mai/jun 1982 Page 128-129Micro Systèmes numéro 23 mai/jun 1982 Page 130-131Micro Systèmes numéro 23 mai/jun 1982 Page 132-133Micro Systèmes numéro 23 mai/jun 1982 Page 134-135Micro Systèmes numéro 23 mai/jun 1982 Page 136-137Micro Systèmes numéro 23 mai/jun 1982 Page 138-139Micro Systèmes numéro 23 mai/jun 1982 Page 140-141Micro Systèmes numéro 23 mai/jun 1982 Page 142-143Micro Systèmes numéro 23 mai/jun 1982 Page 144-145Micro Systèmes numéro 23 mai/jun 1982 Page 146-147Micro Systèmes numéro 23 mai/jun 1982 Page 148-149Micro Systèmes numéro 23 mai/jun 1982 Page 150-151Micro Systèmes numéro 23 mai/jun 1982 Page 152-153Micro Systèmes numéro 23 mai/jun 1982 Page 154-155Micro Systèmes numéro 23 mai/jun 1982 Page 156-157Micro Systèmes numéro 23 mai/jun 1982 Page 158-159Micro Systèmes numéro 23 mai/jun 1982 Page 160-161Micro Systèmes numéro 23 mai/jun 1982 Page 162-163Micro Systèmes numéro 23 mai/jun 1982 Page 164-165Micro Systèmes numéro 23 mai/jun 1982 Page 166-167Micro Systèmes numéro 23 mai/jun 1982 Page 168-169Micro Systèmes numéro 23 mai/jun 1982 Page 170-171Micro Systèmes numéro 23 mai/jun 1982 Page 172-173Micro Systèmes numéro 23 mai/jun 1982 Page 174-175Micro Systèmes numéro 23 mai/jun 1982 Page 176-177Micro Systèmes numéro 23 mai/jun 1982 Page 178-179Micro Systèmes numéro 23 mai/jun 1982 Page 180-181Micro Systèmes numéro 23 mai/jun 1982 Page 182-183Micro Systèmes numéro 23 mai/jun 1982 Page 184-185Micro Systèmes numéro 23 mai/jun 1982 Page 186-187Micro Systèmes numéro 23 mai/jun 1982 Page 188-189Micro Systèmes numéro 23 mai/jun 1982 Page 190-191Micro Systèmes numéro 23 mai/jun 1982 Page 192-193Micro Systèmes numéro 23 mai/jun 1982 Page 194-195Micro Systèmes numéro 23 mai/jun 1982 Page 196-197Micro Systèmes numéro 23 mai/jun 1982 Page 198-199Micro Systèmes numéro 23 mai/jun 1982 Page 200-201Micro Systèmes numéro 23 mai/jun 1982 Page 202-203Micro Systèmes numéro 23 mai/jun 1982 Page 204-205Micro Systèmes numéro 23 mai/jun 1982 Page 206-207Micro Systèmes numéro 23 mai/jun 1982 Page 208-209Micro Systèmes numéro 23 mai/jun 1982 Page 210-211Micro Systèmes numéro 23 mai/jun 1982 Page 212-213Micro Systèmes numéro 23 mai/jun 1982 Page 214-215Micro Systèmes numéro 23 mai/jun 1982 Page 216-217Micro Systèmes numéro 23 mai/jun 1982 Page 218-219Micro Systèmes numéro 23 mai/jun 1982 Page 220-221Micro Systèmes numéro 23 mai/jun 1982 Page 222-223Micro Systèmes numéro 23 mai/jun 1982 Page 224-225Micro Systèmes numéro 23 mai/jun 1982 Page 226-227Micro Systèmes numéro 23 mai/jun 1982 Page 228-229Micro Systèmes numéro 23 mai/jun 1982 Page 230-231Micro Systèmes numéro 23 mai/jun 1982 Page 232-233Micro Systèmes numéro 23 mai/jun 1982 Page 234-235Micro Systèmes numéro 23 mai/jun 1982 Page 236-237Micro Systèmes numéro 23 mai/jun 1982 Page 238-239Micro Systèmes numéro 23 mai/jun 1982 Page 240-241Micro Systèmes numéro 23 mai/jun 1982 Page 242-243Micro Systèmes numéro 23 mai/jun 1982 Page 244-245Micro Systèmes numéro 23 mai/jun 1982 Page 246