01 – Les logigrammes

Introduction

Quand vous faites un programme, surtout s’il est complexe, il est toujours bon de savoir comment va se dérouler son exécution avant de commencer à programmer. D’ailleurs, dans certains programmes, c’est essentiel, pour plusieurs raisons :

• La détection et le traitement des erreurs ;
• Les structures de contrôle entraînant de longues conséquences sur votre programme ;
• L’organisation des tâches pendant la création d’un programme en équipe ;
• Etc…

C’est pour cela que nous devons trouver des moyens pour modéliser toutes ces actions. Il existe plusieurs moyens, mais celui qui est le plus répandu est l’organigramme de programmation, aussi appelé logigramme ou algorigramme. Il est bien entendu que pour suivre ce tutoriel qui va vous les présenter, il faut avoir des bases en programmation mais dans N’IMPORTE QUEL LANGAGE ! En effet, avec les logigrammes, vous pourrez créer des schémas sans se soucier du langage de programmation que vous allez utiliser. Si ce n’est pas intéressant ! 😉

Utilité des Logigrammes

Les logigrammes sont utiles car ils nous aident à représenter la logique de manière visuelle. Ils nous permettent de décomposer des problèmes complexes en étapes simples et compréhensibles. Prenons un exemple simple : un logigramme peut nous aider à décrire comment prendre une décision en fonction de plusieurs conditions, comme si une lumière doit s’allumer en fonction de la présence de mouvement.

Détection des erreurs

Imaginez que vous codiez un programme permettant d’utiliser des distributeurs automatiques avec des cartes bancaires (logique). Vous avez beaucoup de choix, mais vous souhaitez obtenir quelque chose de simple. Avant de vous lancer dans la création de votre programme, vous allez devoir réfléchir, car imaginez que vous vous trompiez, les conséquences pourraient être désastreuses (surtout dans notre exemple). La création d’un logigramme permet de représenter l’exécution du programme précisément, en cherchant toutes les erreurs qui pourront subvenir.

Structures de contrôles complexes

Maintenant, imaginez un programme beaucoup plus simple, une calculatrice. La calculatrice va faire différents types de calculs selon ce qu’on lui a demandé. On va donc utiliser les structures de contrôles conditionnelles. Jusque là, ça va. Imaginez maintenant d’instaurer un système permettant de faire plusieurs calculs à la suite, comme :

17 + 57 x 58 – 60

Vous n’allez pas pouvoir les faire dans n’importe quel ordre, car nous commençons par effectuer la multiplication, puis l’addition avant d’attaquer à la soustraction. Ce sont les règles de calcul de base. Vous allez devoir utiliser des structures de contrôles conditionnelles complexes, mais aussi utiliser les boucles, pour enchaîner les différents calculs. Vous devriez mieux dans ces cas-là, tout mettre à plat et réfléchir avant de coder.

Organisation

Troisième cas, l’organisation. Par exemple, imaginez que vous faites un jeu vidéo complet, en 3D et tout le bazar. Imaginez maintenant que ce jeu inclut des parties multijoueurs, fonctionnant bien sûr avec le réseau. Vous allez devoir traiter les informations et les envoyer sur le réseau, sans doute sur un serveur, mais je ne vais pas traiter tous les détails. Étant donné que c’est un jeu complexe, vous décidez d’avoir une équipe et tout le monde est présent. Vous êtes trois développeurs et vous vous organisez les tâches :

• L’un fait le réseau
• L’autre fait le système de jeu de base (collisions, mouvement de personnage)
• Le dernier inclut tous les modèles.

Essayez de comprendre comment ça va marcher. L’un inclut tous les modèles, et une fois qu’ils sont présents, l’autre fait son job. Et enfin, une fois que l’autre a inclus toutes les fonctions et méthodes, l’autre peut faire le réseau. Vous ne voyez pas le problème ?

Vous êtes mal organisés ! Il faut que l’un ait fini pour que l’autre puisse finir son job ! Pour mieux se répartir les tâches, tout mettre sur un schéma et regarder comment ils peuvent être indépendants, et à la fin juste rassembler les bouts.

Ce sont les principales raisons pour faire un logigramme. Il en existe d’autres bien sûr. Si j’ai un conseil à vous donner pour l’instant, c’est que dès que vous sentez que votre programme est complexe, ou que vous êtes plusieurs, faites un organigramme de programmation (logigramme, algorigramme) !

Normes de Notation

Maintenant, le cours va respecter la norme ISO 5807, et si vous suivez mes instructions, vos schémas vont la respecter.

Pourquoi existe-t-il une norme ?

Une norme est le meilleur moyen pour un système quelconque d’être normalisé (en même temps, c’est juste un peu la définition). Le réel avantage qu’apporte une norme est la compréhension par tous. Imaginez par exemple un schéma représentant un circuit électrique.

Si vous avez des bases en électricité, vous comprendrez TOUS la même chose, car ce schéma est normalisé. Maintenant, remplacez le générateur par un rectangle, et les dipôles ohmiques par des cercles. Vous, vous comprendrez votre schéma, mais les autres non.

Ce schéma représente encore un aspect du respect d’une norme, les lettres ! Un petit rappel pour ceux qui dorment au fond de la classe :

S’il n’y avait pas de norme, j’aurais pu croire le contraire ! Mais comme la norme dit que c’est comme ça, j’applique et ça me permet de comprendre. Encore une fois, si j’avais fait le contraire, je me serais compris, mais personne d’autre n’aurait pu en faire autant…

Souvenez-vous : Si un schéma respecte une norme, il est compris de la même manière par tous ceux qui la connaissent.

La norme ISO 5807

Parlons-en un peu. Cette norme permet de normaliser les logigrammes. Vous n’êtes pas obligé de la respecter, mais c’est à vos risques et périls.

Quand vous faites un schéma sur un logiciel adapté, vous pouvez respecter la norme en disant que vous faites un schéma Flowchart (c’est la traduction d’organigramme en fait…). C’est sous cette option que vous pourrez faire vos organigrammes respectant la norme.

Il existe d’autres types d’organigrammes du même principe, mais qui ne respectent pas la même norme. Je peux par exemple citer les diagrammes d’activités UML. Ils ressemblent aux algorigrammes, mais ce n’en sont pas. Suivez à la lettre la norme que je vais vous enseigner, pour pouvoir reconnaître les autres (ou plutôt celles qui ne sont pas l’ISO 5807).

Figures à Utiliser

1. Où mettons-nous nos figures ?

Vous l’avez compris, un algorigramme est une suite de figures signifiant quelque chose, et contenant du texte pour préciser.

Nos figures ne se mettent pas n’importe où, n’importe comment, dans n’importe quel ordre. Nous devons avoir un algorithme correct et structuré. Tout d’abord, on le sait déjà, il faut placer toutes nos formes entre le début et la fin, représentés par des rectangles arrondis sur les coins.

Voici deux règles assez importantes :

• Un algorithme est correct s’il commence par un rectangle arrondi "Début" et finit par un rectangle arrondi "Fin".
• Il ne peut pas y avoir deux débuts dans le même algorithme, mais il peut y avoir plusieurs fins (dans le cas d’un bug entraînant la fin du programme par exemple).

Maintenant, essayons de voir quelles sont justement les figures qui peuvent exister dans un organigramme.

2. Les instructions

Comme vous devez le savoir, un programme n’est qu’une suite d’instructions. Ces instructions permettent de réaliser différents traitements, comme des calculs, des comparaisons etc.

Ce que je vais dire par la suite n’est pas valable pour les entrées et sorties (entrée clavier, joystick, affichage à l’écran, impression… Nous verrons comment les gérer plus tard).

Vous savez que vous devrez mettre vos figures entre le début et la fin de l’algorithme seulement. Je vais vous donner une petite astuce pour mieux démarrer. Quand vous créez vos organigrammes, faites comme si vous codiez les programmes que vous êtes en train de modéliser. Donc, ne mettez pas la fin en premier ou en deuxième, mais en dernier (à part s’il y a plusieurs fin).

Une instruction se représente par un rectangle simple.

3. Les liaisons

Non, pas les liaisons amoureuses ! Je parle des liaisons que nous pouvons voir sur les schémas, qui relient nos figures entre elles.

En général, nous plaçons des flèches dans le sens de l’exécution du programme pour permettre en effet de bien voir le déroulement de l’algorithme en question, et ainsi se repérer facilement (par conséquent une compréhension plus simple). Par exemple, prenez le logigramme suivant :

C’est un bout de logigramme, donc vous ne pouvez pas voir le début et la fin de l’algorithme. Imaginez tout un logigramme complexe derrière. Ce qui vous intéresse, ce sont les flèches. En effet, grâce à elles, vous pouvez déterminer le sens de l’exécution du programme. Vous voyez bien que c’est comme la plupart des algorigrammes, nous partons du haut puis nous descendons vers le bas.

Maintenant, imaginez autre chose, que nous remplaçons les flèches par des droites simples, comme il est le cas dans beaucoup de schémas.

Je vais vous donner un conseil pour vous repérer : Mettez toujours des flèches dans le sens de l’exécution de votre programme pour relier vos instructions.

Entraînez-vous un peu, en modélisant des programmes très simples. Et sachez qu’avant tout, un algorigramme se fait sur papier, puis si besoin sur un ordinateur (dans le cas d’un cahier des charges en équipe par exemple). Par contre, vous ne pouvez pas tout de suite gérer les entrées et les sorties (comme un affichage ou une entrée de texte dans une console via un clavier), car vous n’utiliserez pas les mêmes figures. Pour savoir comment les modéliser, lisez la prochaine partie.

4. Les Entrées/Sorties

Qui pourrait faire aujourd’hui un programme complet sans les entrées et les sorties ?

Dans vos logigrammes, il faudra aussi mettre les entrées et sorties, même écrire du simple texte dans la console doit être marqué ! En avant pour une partie bien simple.

En premier lieu, la figure à utiliser pour les entrées et sorties est un parallélogramme classique. Grâce à lui, nous pouvons repérer et modéliser les entrées, les sorties, les lectures et les écritures (dans des fichiers ou des bases de données par exemple).

C’est vraiment très simple, la seule chose qui change avec les instructions classiques est sa forme. Un petit exemple pour la route…

Il est important de mettre si c’est une impression, un affichage ou bien une entrée.

Il arrive parfois qu’il faille être très précis dans ce que nous mettons dans nos algorigrammes, je vais utiliser l’exemple de l’utilisation d’une manette (entrée) et d’une imprimante (sortie). Il faut indiquer les périphériques utilisés dans des figures à part, des ovales. Ensuite, nous indiquons une flèche qui part de l’ovale et qui se dirige vers l’entrée ou la sortie. Je pense que ce serait plus clair pour vous avec un schéma à analyser.

J’ai instauré deux types de flèches pour faciliter votre compréhension, mais vous pouvez aussi les mettre dans vos futurs schémas.

Analysons, quand vous faites subir mille sévices à votre manette, l’information part de la manette puis se dirige vers l’ordinateur (pour simplifier). Du coup, nous mettons de préférence une flèche de la manette vers l’entrée, comme vous pouvez le voir sur le schéma ci-dessus.

Au contraire, quand vous faites une sortie, par exemple pour une impression, l’information part de votre ordinateur vers votre imprimante, donc nous mettons une flèche de la source de la sortie vers l’imprimante, encore une fois comme sur le schéma ci-dessus. En général, les périphériques d’entrées sont placés à gauche, et les périphériques de sortie à droite.

Voici un schéma pour retenir un peu tout ça (images prises sur iconfinder) :

Récapitulation et Devoirs

C’est la fin de ce premier cours. Nous avons découvert l’importance des logigrammes, les symboles de base et comment les utiliser pour représenter la logique. Pratiquez la création de logigrammes et explorez d’autres exemples.