Flussdiagramme und Methodenaufrufe

Ich mache einige Flussdiagramme und frage mich, ob ich mich dem richtig nähere. Im Wesentlichen habe ich mehrere Methodenaufrufe und ich führe jeweils ein Flussdiagramm separat durch. Einige dieser Methoden rufen jedoch einige Informationen auf und fahren dann fort. Siehe dieses Beispiel:

Geben Sie hier die Bildbeschreibung ein

Ich habe 3 andere Methoden, die ebenfalls GetQueue () aufrufen, und ich frage mich, ob ich dies richtig darstelle. Der AddQueue () -Fluss sieht visuell so aus, als wäre er unterbrochen.

HINWEIS: In meinem Flussdiagramm vorgenommene Änderungen:

Geben Sie hier die Bildbeschreibung ein

flowchart

— Keith Barrows
quelle

Ist diese Detailgenauigkeit wirklich notwendig? Ich weiß, dass Flussdiagramme wie dieses früher beliebt waren, aber sie scheinen heutzutage aus vielen Gründen in Ungnade gefallen zu sein ... Im Wesentlichen handelt es sich um eine redundante Form der Dokumentation. Sie müssen sie auf dem neuesten Stand halten, und der Code sollte ohnehin schon angemessen darstellen, was im Flussdiagramm angezeigt wird (was bedeutet, dass die Zeit besser für die Erstellung von mehr Code aufgewendet wird).

— Robert Harvey

Es wurde von mir angefordert, bevor ich zu einem anderen Kunden übergehe.

— Keith Barrows

@ Robert Harvey: Flussdiagramme waren früher nützlich, als Leute Maschinen- oder Assembler-Code direkt schrieben. Sie könnten für frühe FORTRAN- und BASIC-Programmierer nützlich gewesen sein, die keine guten Kontrollstrukturen hatten. Heutzutage ist der einzige Grund, warum ich sie machen würde, wenn ein Kunde sie als Ergebnis haben wollte und bereit war, mich angemessen zu bezahlen.

— David Thornley

Bei der Entwicklung dieser von Grund auf neu fand ich es sehr hilfreich, gelbe Stickies zu verwenden und die 90 Grad für Entscheidungen zu drehen. Auf diese Weise können Sie sie verschieben und Prozesse dazwischen einfügen. Wenn Sie alle Don sind, geben Sie sie in Ihre Software ein.

— Michael Riley - AKA Gunny

Ich verwende immer noch gelegentlich Flussdiagramme, obwohl ich finde, dass Unit-Tests oft besser für den gleichen Zweck sind. Sie sind jedoch keine Ergebnisse; Ich benutze sie, um einen Kontrollfluss direkt in meinen Kopf zu bekommen.

— Michael K

Antworten:

Verwenden Sie ein Unterprogramm-Symbol für den Methodenaufruf (vordefinierter Prozess).

Geben Sie hier die Bildbeschreibung ein

— Robert Harvey
quelle

Ich habe kürzlich einige Flussdiagramme erstellt und hatte mit dem gleichen Problem zu kämpfen, wie Subroutinenaufrufe oder vielleicht Methoden- und Funktionsaufrufe, wie Sie sie heutzutage nennen könnten, dargestellt werden.

Ich habe mich für eine Konvention entschieden, bei der ich das Unterprogramm CALLS von dem Unterprogramm REFERENCES trenne. Für das erstere verwende ich ein gewöhnliches Rechteck, das den Aufruf mit Argumenten zeigt, wobei alle Variablen verwendet werden, die zu diesem Zeitpunkt in der Programmausführung wirksam sind.

Ich verwende das doppelseitige Rechteck "vordefinierter Prozess" einfach als Referenz auf ein anderes Flussdiagramm, das die Definition dieser Funktion oder Unterroutine enthält. Das Unterroutinenrechteck muss nicht die Argumente der Unterroutine anzeigen, da dies Teil des definierenden Flussdiagramms der betreffenden Unterroutine ist. Es kann jedoch hilfreich sein, sie bereits in die Referenz aufzunehmen, damit jeder, der sie liest, sie lesen kann Sehen Sie sich die Bedeutung der tatsächlichen Argumente an, die in einem Aufruf verwendet werden.

Dies erhöht die Anzahl der Rechtecke, macht jedoch klarer, dass diese anderen Flussdiagramme vorhanden sind, um die Definition einiger der aufgerufenen Funktionen nachzuschlagen. Wenn eine Funktion einfach ist, erstelle ich oft kein separates Diagramm dafür, sondern dokumentiere es nur mündlich.

Ich benutze auch das "Dokument" -Symbol, um zu sagen, dass Details aus der Codeliste nachgeschlagen werden sollten.

Der Sinn eines Flussdiagramms besteht für mich nicht darin, ein Programm zu erstellen, sondern anderen das Verständnis eines Programms zu erleichtern. Ich denke, die Hilfe aus der Vogelperspektive und deren Zweck sollte im Auge behalten werden. Sie dienen nicht zur visuellen Beschreibung JEDES Details Ihres Programms. Details sind bei Bedarf im Code sichtbar. Das Flussdiagramm ist nur ein Bild Ihres Programms aus der Sicht der übergeordneten Ebene.

Wenn Flussdiagramme auf einem hohen Niveau gehalten werden, müssen sie auch weniger auf dem neuesten Stand gehalten werden, wenn der Code geändert wird.

Sie sind Bilder. Wie bei jeder guten Story-Software sollte auch die Dokumentation Bilder enthalten, die einen alternativen Blickwinkel auf den Code bieten.

— Panu Logic
quelle