Quand utiliserais-je un pseudocode au lieu d'un organigramme?


9

Je suis un étudiant travaillant avec diverses techniques de programmation et j'ai rencontré un pseudocode et un organigramme. Je sais que ceux-ci sont tous deux utilisés afin de réfléchir au problème avant de réellement programmer, mais j'ai quelques questions à ce sujet.

  1. Quand utiliserais-je un pseudocode pour planifier et quand utiliserais-je des organigrammes? Ou est-il préférable de faire les deux avant de réellement programmer. Particulièrement pour une petite sorte de jeu d'arcade en JAVA puisque c'est mon prochain projet.
  2. J'ai remarqué que le pseudocode est très similaire au code réel plutôt qu'aux organigrammes. Est-ce que cela améliorerait le pseudocodage parce que vous copiez / collez essentiellement le pseudocode dans votre programme (bien sûr, vous devez le changer pour l'adapter à la langue. Je comprends cette partie).
  3. Est-il pratique d'utiliser les deux lors de la programmation? Particulièrement le même jeu mentionné précédemment. Merci.

Évidemment, vous n'utiliseriez pas de diagrammes où vous n'avez aucun flux - c'est-à-dire pour presque toutes les entités déclaratives.
SK-logic

1
Je ne me souviens pas de la dernière fois que j'ai vu un organigramme de codage. Diagrammes de classes et de flux de données, diagrammes de cas d'utilisation, oui. Mais pas les organigrammes. Peut-être qu'ils sont plus répandus dans le développement de jeux.
Robert Harvey

@RobertHarvey, les diagrammes FSM (qui sont essentiellement des organigrammes) sont utilisés assez souvent dans la conception matérielle
SK-logic

Réponses:


7

Les organigrammes et les pseudocodes ont souvent le même niveau d'expressivité, mais diffèrent par leur linéarisation. Le pseudocode est linéaire (c'est-à-dire une séquence de lignes avec des instructions), un organigramme ne l'est pas. Par conséquent, les organigrammes sont un niveau d'abstraction plus élevé, utilisé avant d'écrire un pseudocode ou pour la documentation.

Les organigrammes ont, à mon avis, deux avantages importants par rapport au pseudocode: premièrement, ils sont graphiques. Beaucoup de personnes non techniques ont une forte crainte du texte structuré, mais pas des descriptions graphiques, donc les organigrammes seront plus agréables avec eux. Deuxièmement, les organigrammes sont bien meilleurs pour exprimer des méta-considérations telles que montrer la ligne principale d'exécution par opposition aux branches.

Vos questions en détail:

  1. Pour un problème vraiment compliqué, vous utiliseriez d'abord les organigrammes, puis le pseudocode. Les deux sont facultatifs lorsque vous vous sentez suffisamment en sécurité.
  2. Oui, le pseudocode a l'avantage d'être fusionnable avec du vrai code. Steve McConnell, par exemple, recommande fortement d'écrire les méthodes en pseudocode d'abord, puis de laisser le pseudocode dans le code en tant que commentaires.
  3. J'ai toujours pensé que la nécessité de dessiner un organigramme lors de la conception montre une partition insuffisante de votre problème. Les organigrammes non triviaux indiquent une logique alambiquée, qui devrait être évitée à grands frais.

1
Les organigrammes sont également un excellent moyen de s'assurer que chaque point de décision définit les actions pour le (s) chemin (s) moins courant (s) ainsi que le plus commun. Cela vous permet de savoir quoi faire lorsque l'approbation est refusée ou que la commande est annulée! Il y a souvent plus de bogues dans les cas marginaux parce que les gens oublient de les faire ou les font à la hâte pendant l'AQ lorsque les tests les trouvent.
HLGEM

2

Sur le pseudo code

Pour être honnête, je n'utilise pas beaucoup le pseudocode. En règle générale, il est plus rapide d'écrire simplement le code, de sorte que lorsque j'en ai fini avec mon code, c'est du code réel. Il y a des cas où le pseudo-code peut être utile, mais vous travaillez généralement sur quelque chose de très complexe et essayez simplement de briser la structure d'une méthode ou quelque chose. Dans ces cas, j'utilise des commentaires dans mon IDE pour définir la structure jusqu'à ce que les choses se passent bien. Ensuite, j'entre et j'écris le code réel dans les commentaires. Cela m'aide à faire quelques choses:

  • Je peux voir les domaines que j'ai ou non mis en œuvre en lisant les commentaires et en y voyant des lacunes évidentes.
  • Lorsque je remplis le vrai code, j'ai des commentaires expliquant en anglais ce que je fais. (Ils en auront probablement besoin si c'est si compliqué que je dois d'abord écrire un pseudo code).

Sur les organigrammes

Le code change généralement tellement que les organigrammes ne sont pas utiles, sauf pour une conception ou une documentation d'architecture plus large et à l'échelle du système. Dans ces cas, je vais simplement mettre un tableau blanc sur un diagramme pour obtenir l'essentiel ou montrer à quelqu'un d'autre dans l'équipe. Sauf si vous avez vraiment besoin d'un organigramme pour vous aider à comprendre, alors vous n'avez pas vraiment besoin d'eux pour «faire» correctement le logiciel. De nos jours, il existe de nombreux plugins pour les IDE qui généreront des organigrammes à partir du code lui-même, ainsi que des diagrammes de classes et autres (et vice versa `). Le seul temps réel dont vous auriez besoin pour faire un organigramme vraiment précis est si vous ne pouvez pas garder l'architecture entière et comment les choses fonctionnent dans votre tête à la fois et devez parler de quelque chose de visuel pour attraper les défauts.


0

En général, je n'écris pas de diagrammes pendant que je travaille sur des projets personnels (car les projets ne sont pas très gros) et la plupart des entrées, sorties et processus sont clairs.

mais comme vous commencerez à travailler sur de grands projets complexes avec différentes sources d'entrée, les fichiers plats, les bases de données, les interfaces manuelles, etc., les organigrammes sont pratiques.

Je vous recommanderais d'écrire du pseudo-code et des digrammes UML car ces outils vous aideront à trouver de meilleures classes, méthodes, etc. Parfois, lors de l'écriture d'un pseudo-code, vous trouverez des moyens différents et plus efficaces de résoudre un programme.


0

Le pseudo-code est pour représenter rapidement une idée à ceux qui comprennent au moins les bases du code. Les organigrammes dessinent de jolies images pour que tout le monde comprenne la même chose.

Les organigrammes sont souvent utilisés à des fins de documentation car de nombreuses personnes différentes utilisent cette documentation et les organigrammes sont plus faciles à suivre que le pseudo-code pour les non-programmeurs. Dans un projet sur lequel vous travaillez vous-même, coller avec un pseudo-code est très bien car il est beaucoup plus utile et beaucoup plus facile à créer car un éditeur de texte est tout ce dont vous avez besoin.


0

Les organigrammes sont un niveau d'abstraction élevé, ils vous permettent de planifier la façon dont les choses devraient se dérouler, par exemple

si x meurt y gagne

Ils n'ont pas besoin de dépendre de la façon dont vous concevez le programme en termes de classes et de méthodes, le pseudo-code d'autre part fournit un niveau d'abstraction inférieur (bien que cela dépende vraiment)

if (isdead (s)) y.win ()

ainsi le pseudo code peut maintenant être traduit en programme réel basé sur la langue que vous utilisez.

Pour un jeu, je recommanderais d'abord d'utiliser un organigramme, puis de concevoir les classes et les méthodes, d'écrire un pseudo-code et enfin de le convertir en programme


0

Je considérerais la nature du code que vous écrivez. Si c'est:

  1. Très itératif / récursif
  2. Les succursales de manière compliquée
  3. Implémenté dans plusieurs systèmes que vous souhaitez représenter

Dans les deux premiers cas, le pseudocode devient progressivement plus difficile à lire qu'un diagramme à grande image. D'un autre côté, un code principalement linéaire rend les diagrammes incroyablement ennuyeux qui rendent le processus plus difficile à comprendre en raison de son ampleur.

Pour le troisième cas, les organigrammes sont mieux à même de représenter les processus qui traversent les frontières du système et représentent l'ensemble du processus.


0
  1. Vous devez utiliser tout ce qui vous convient. Cela dit, j'ai l'impression que les organigrammes ne sont pas largement utilisés pour esquisser le contrôle des programmes de nos jours; d'une part, ils sont généralement non structurés, par rapport au pseudocode. Il est plus courant d'utiliser des diagrammes de dépendance de classe comme UML pour décrire votre architecture à un niveau beaucoup plus élevé. De plus, si votre application dispose d'une machine à états, il est essentiel de dessiner un diagramme de machine à états (semblable à un organigramme).
  2. Je pense que vous avez raison ici. Une façon de travailler consiste à écrire votre pseudocode sous forme de commentaires dans votre fichier source pour commencer et à insérer les lignes d'implémentation réelles entre elles.
  3. Encore une fois, utilisez tout ce qui vous convient. Si vous n'êtes pas sûr, essayez-les tous les deux; J'espère que votre pratique convergera rapidement vers ce qui vous sera le plus utile. Personnellement, je ne trouve pas les organigrammes utiles à moins que j'essaie de démêler un ordre d'exécution particulièrement compliqué.

0

Pourquoi écrire du pseudo-code quand on peut écrire Java? J'ai trouvé Java, un bon IDE et Javadoc sont le moyen le plus simple de saisir un problème de programmation - au moins un problème orienté objet . (Et un jeu d'arcade devrait être OO.) Le langage a été conçu à partir de zéro pour cela. C'est simple et direct. (Trop simple à de nombreuses fins, peut-être, mais la meilleure chose que j'ai vue à ce sujet.) L'hypertexte dans le Javadoc et, via un IDE, dans le code lui-même font un "diagramme" plus compréhensible que vous ne pourriez en tirer même une grande feuille de papier. Le code Java est aussi simple que n'importe quel pseudo-code et beaucoup plus rigoureux. Et une fois que vous l'avez "schématisé" et "pseudo" codé, le programme s'exécutera!


1
java et d'autres peuvent être de longue haleine. "public static void main .." ou "system.out.println" ou de longs identificateurs avec notation camelback, de longue haleine.n alors les exceptions qui ont 2b interceptées ... Je me souviens qu'il y a 10 ans, j'ai ouvert un dossier. quelque chose comme le nouveau BufferedReader (nouveau InputStreamReader (System.in)); apparemment plus facile maintenant mkyong.com/java/… Mais vraiment n'importe quelle bibliothèque que vous appelez pourrait être longue, pas comme un pseudocode qui peut être aussi concis que vous pouvez l'imaginer
barlop

également en java ou dans n'importe quelle langue, vous rencontrez des erreurs lors de la compilation. rien de tout cela avec un pseudocode. vous pouvez vous concentrer sur le design sans aucune distraction. Les commentaires sur le pseudocode peuvent être beaucoup plus brefs car le pseudocode est plus clair pour l'esprit car il vient de l'esprit. Vous n'êtes pas limité en pensant dans une seule langue, et vous pourriez voir que je vais utiliser cette autre langue. Il est plus rapide et moins douloureux à écrire (aucune compilation nécessaire - même les erreurs de compilation très fluides) et donc moins de temps à écrire facilite la refonte.
barlop

@barlop: Cela fonctionne pour moi, mais cela peut ne pas fonctionner pour tout le monde. Je laisse beaucoup de code ("BufferedReader", par exemple) hors de mes classes jusqu'à ce que j'en ai besoin ou que je sache si je peux le faire fonctionner. Même quand je l'ai, il est bien caché dans les classes que je n'ai pas besoin de regarder lors de la conception globale. Les erreurs du compilateur sont facilement corrigées et peuvent empêcher des défauts de conception majeurs, tels que l'utilisation de la mauvaise classe à un point où vous ne pouvez même pas obtenir une instance de la bonne classe. Je l' avoue, je l' ai « conçu » logiciel de cette façon qui pourrait ne être écrit en Java, mais l'OP est en Java.
RalphChapin

alors dites que vous voulez ouvrir un fichier, voyez-vous comment le pseudocode de openfile ("c: \ blah \ file") est plus court que le java pour le faire? ou que l'impression "dfdfd" est plus courte que la java pour le faire? Je n'ai jamais (encore) fait de pages de pseudocode et de classes multiples. en partie «parce que je n'ai pas écrit de gros programmes depuis longtemps b) en partie» parce que je ne pense pas que je le ferais, je pense que j'écrirais un pseudocode puis le ferais implémenter. Tout autre pseudocode, s'il y en a, serait de niveau supérieur. Je pourrais avoir une liste de toutes les classes et méthodes, y compris les constructeurs. Je sais donc quelles classes sont quoi et que je peux en obtenir une instance ..
barlop

donc je ne serais pas dans une situation d'utilisation de la mauvaise classe mais de toute façon, si c'est mon programme, j'aurais écrit dans mes notes quelle classe est quoi ... les classes sont de très haut niveau. j'aurais une note là-dessus si je ne m'en souviens pas. Et le pseudocode est tout ce que l'on veut dire, donc si vous vouliez faire une instance de classe blah et que vous avez écrit bleh, alors c'est juste une faute de frappe d'écriture mais cela n'entrave pas votre conception. (si vous écrivez pour vous-même parce que vous savez ce que vous voulez dire, et vous l'avez utilisé comme un bla).
barlop

0

Vous pouvez utiliser un organigramme si vous êtes vraiment dérouté par les instructions if et que vous essayez de comprendre cela. Ou si vous essayez de comprendre une boucle, voyez l'effet des compteurs. Si vous apprenez, cela peut beaucoup aider.

Cela peut sembler un peu restrictif, car vous devez mettre de brèves déclarations dans des boîtes. Et si votre programme est très linéaire et vos boucles et ifs sont triviaux, alors je ne vois aucune utilité.

Le pseudocode est utile pour concevoir un programme. Sans la distraction d'avoir à obtenir la bonne syntaxe, et sans la lourdeur que certains langages peuvent impliquer. Le fait qu'il soit plus rapide à écrire facilite également la refonte du code. Et vous pouvez être aussi concis que votre esprit le souhaite, il est agréable à écrire, nécessite moins d'effort mental pour le faire fonctionner (comme pas ou beaucoup moins de débogage), et plus de capacité à se concentrer sur la grande image et le design.

Donc, utile pour vous.

Ils peuvent également être utilisés pour communiquer avec les autres.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.