Le «flowchart» est sans doute la plus connue des méthodes de crétion d'alogritme de programmation.
C'est d'ailleurs peut être la raison pour laquelle tant de programmeurs estiment que la création d'un algorithme ne sert à rien...
En effet, si le flowchart a l'énorme avantage d'être partriculièrement visuel, il a en revanche, l'énorme inconvénient de n'être réellement efficace que lorsque l'on prévoit de coder en langage machine, ou à tout du moins, en assembleur.
En effet, il ne permet pas de représenter des possibilités pourtant très utiles des langages de troisième génération telles que les boucles ou les tests à choix multiple de manière facilement traduisible.
Le premier principe à garder en tête quand on veut utiliser le flowchart, c'est qu'à chaque action possible correspond un pyctogramme précis.
Chaque action étant reliée à celle qui la suit dans l'ordre logique par un trait
Le second principe est que son sens logique de lecture est, au même titre qu'un livre, de gauche à droite et de haut en bas.
Si pour une raison ou une autre, il faut modifier le sens logique de la liaison (aller de droite à gauche ou de bas en haut), et les raisons pour le faire ne manquent pas, il s'agira d'indiquer le changement de sens par un flêche allant dans la bonne direction sur le trait de liaison.
Pour chaque programme, ou pour chaque tronçon de programme, tel que fonction ou procédure, il y a lieu de prévoire, cela semble évident, un point d'entrée dans le programme ou le tronçon de programme et un point de sortie.
Ces points d'entrée et de sortie seron simplement représenté sous la forme de cercles ou d'ovales.
Autant que possible, il faudra tâcher qu'il n'y ait qu'un début et une fin à chaque tronçon de programme, même si on peut envisager d'avoir des points d'entrée ou de sortie vers d'aures fonctions ou procédures...
Une application qui ne serait pas en mesure de recevoir des informations n'aurait aucun intérêt…
En effet, le but de tout programme est toujours de prendre des informations quelques part et de leur appliquer un traitement prédéfini.
Pour représenter une lecture d'information, le flowchart utilise au choix un parallélograme ou une carte biseautée.
La carte biseautée est généralement utilisée quand il s'agit de lire des informations au départ du disque dur.
Le but de toute application est généralement de prendre des informations d'un côté, de les traiter, et d'utiliser le résultat du traitement…
Le traitement s'indique simplement à l'intérieur d'un rectangle
L'une des utilisations possibles des informations traitées est leur affichage à l'écran ou leur impression papier.
Il est aussi souvent utile de prévoir l'affichage d'un petit message indiquant à l'utilisateur ce que l'on attend de lui, ou ce que l'ordinateur est en train de faire.
L'affichage est représenté dans le flowchart sous la forme d'un rectangle dont le côté inférieur a la forme d'une «doucine» (sorte de "S" couché et allongé)
Une autre utilisation possible des informations une fois qu'elles ont été traitées est bien évidemment l'enregistrement sur disque dur (ou sur tout autre support, amovible ou non: disquette, clé usb…) sous la forme de fichier.
L'enregistrement sur disque est alors représenté sous la forme d'un cylindre.
Il est excessivement rare qu'une application travaille de manière strictement rectiligne…
En effet, il est souvent nécessaire, et c'est d'ailleurs une très grande partie du travail du concepteur, de fournir des alternatives au déroulement normal de l'application.
C'est, finalement, grâce à ces alternatives, que l'application disposera de son *semblant* d'intelligence.
Evidemment, pour permettre une alternative, il s'agira toujours d'effectuer un test logique qui permettra à l'application de décider si elle doit effectuer une action (ou un groupe d'actions) ou plutot son alternative.
Le test logique ne pourra avoir que deux réponses possibles: soit, le résultat obtenu est «vrai», soit, il est «faux»
Le test s'inscrira dans un losange sur pointe disposant de deux branches de sortie, l'une dirigeant vers les actions à prendre si le résultat est vrai, l'autre dirigeant vers les actions à prendre si le résultat est faux.
Dans la mesure du possible, on tâchera d'écrire le test de manière à ce que le résultat «vrai» prenne le plus grand groupe d'instruction
Il est enfin parfois utile de mettre des commentaires directement dans l'algoritme, surtout quand on commence à créer des suites d'instructions complexes, de manière à savoir se remémorer la logique que l'on a décidé de suivre.
Pour représenter un commentaire, nous mettrons son texte dans un rectangle ouvert sur le côté droit.
Copyright (©) 2005 (Philippe Dunski)
Ce cours est libre, vous pouvez le redistribuer et/ou le modifier selon les termes de la Licence Publique Générale GNU publiée par la Free Software Foundation (version 2 ou bien toute autre version ultérieure choisie par vous).
Ce cours est distribué car potentiellement utile, mais SANS AUCUNE GARANTIE, ni explicite ni implicite, y compris les garanties de commercialisation ou d'adaptation dans un but spécifique. Reportez-vous à la Licence Publique Générale GNU pour plus de détails.
Cependant, l'auteur apprécierait grandement que vous lui fassiez part de toute modification apportée à son contnu
Vous pouvez le contacter par mail à l'adresse koala01@free.fr
Vous pouvez trouver une adaptation française de la licence GNU/GPL à l'URL http://www.linux-france.org/article/these/gpl.html
