Organigramme et appels de méthode

Je prépare des organigrammes et je me demande si je m'approche de cela correctement. Essentiellement, j'ai plusieurs appels de méthode et je organigramme chacun séparément. Toutefois, plusieurs de ces méthodes appellent une méthode pour certaines informations, puis continuent. Voir cet exemple:

entrez la description de l'image ici

J'ai 3 autres méthodes qui appellent également GetQueue () et je me demande si je représente cela correctement. Le flux AddQueue () ressemble visuellement à une rupture.

REMARQUE: modifications apportées à mon organigramme:

entrez la description de l'image ici

flowchart

— Keith Barrows
source

Ce niveau de détail pictural est-il vraiment nécessaire? Je sais qu'à une certaine époque, les organigrammes comme celui-ci étaient populaires, mais ils semblent être tombés en disgrâce de nos jours pour de nombreuses raisons ... Ils sont essentiellement une forme redondante de documentation; vous devez les tenir à jour, et le code devrait déjà représenter de manière adéquate ce qui est montré dans l'organigramme de toute façon (ce qui signifie: il vaut mieux passer du temps à produire plus de code).

— Robert Harvey

Il m'a été demandé avant de passer à un autre client.

— Keith Barrows

@Robert Harvey: Les organigrammes étaient utiles dans le passé, lorsque les gens écrivaient directement du code machine ou assembleur. Ils ont peut-être été utiles aux premiers programmeurs FORTRAN et BASIC, qui n'avaient pas un bon éventail de structures de contrôle. De nos jours, eh bien, la seule raison pour laquelle je les ferais, c'est si un client les voulait comme livrable et était prêt à me payer adéquatement.

— David Thornley

Lors de l'élaboration de ceux-ci à partir de zéro, j'ai trouvé très utile d'utiliser des collants jaunes, en tournant à 90 degrés pour les décisions. Cela vous permet de les déplacer et d'insérer des processus entre eux. Lorsque vous êtes tous enfermés, entrez-les dans votre logiciel.

— Michael Riley - AKA Gunny

J'utilise toujours des organigrammes de temps en temps, même si je trouve que les tests unitaires sont souvent meilleurs dans le même but. Ce ne sont pas des livrables, cependant; Je les utilise pour obtenir un flux de contrôle directement dans ma tête.

— Michael K

Réponses:

Utiliser un symbole de sous - programme pour l'appel de méthode (processus prédéfini)

entrez la description de l'image ici

— Robert Harvey
source

J'ai récemment fait un organigramme et j'ai eu du mal avec le même problème, comment présenter des appels de sous-programme, ou peut-être des appels de méthode et de fonction comme vous pourriez les appeler ces jours-ci.

J'ai établi une convention selon laquelle je sépare les APPELS de sous-programme des RÉFÉRENCES de sous-programme. Pour le premier, j'utilise un rectangle ordinaire montrant l'appel avec des arguments en cours, en utilisant toutes les variables qui sont en vigueur à ce stade de l'exécution du programme.

J'utilise le rectangle "processus prédéfini" à double face simplement comme référence à un autre organigramme qui contient la définition de cette fonction ou sous-routine. Le rectangle de sous-routine n'a pas besoin d'afficher les arguments de la sous-routine car cela fait partie de l'organigramme définissant la sous-routine en question, mais il peut être utile de les ajouter dans la référence déjà pour que celui qui la lit puisse voir la signification des arguments réels utilisés dans un appel.

Cela augmente le nombre de rectangles mais il est plus clair que ces autres organigrammes existent pour rechercher la définition de certaines des fonctions appelées. Souvent, si une fonction est simple, je ne créerai pas de diagramme distinct pour elle, mais je la documenterai seulement verbalement.

J'utilise également le symbole "document" pour dire que les détails doivent être recherchés dans la liste de codes.

Le but d'un organigramme pour moi n'est pas de créer un programme, mais de faciliter la compréhension d'un programme par d'autres. Je pense que l'aide en tant que vue à vol d'oiseau et que leur objectif doit être gardé à l'esprit. Ils ne sont pas destinés à décrire visuellement CHAQUE détail de votre programme, les détails sont visibles à partir du code en cas de besoin. L'organigramme n'est qu'une image de votre programme du point de vue de haut niveau.

Garder les organigrammes à un niveau élevé signifie également qu'il est moins nécessaire de les garder à jour lorsque le code est modifié.

Ce sont des images. Comme pour toute bonne histoire, la documentation du logiciel devrait aussi avoir des images qui donnent un point de vue alternatif au code.

— Panu Logic
source