フローチャートとメソッド呼び出し
私はいくつかのフローチャートを実行しており、これに正しく取り組んでいるかどうか疑問に思っています。本質的に、いくつかのメソッド呼び出しがあり、それぞれを別々にフローチャート化しています。ただし、これらのメソッドのいくつかは、いくつかの情報のメソッド呼び出しを行ってから続行します。この例を見てください：
GetQueue（）を呼び出す他の3つのメソッドがあり、これを正しく表現しているかどうか疑問に思っています。 AddQueue（）フローは、視覚的には壊れているように見えます。
注：フローチャートで行われた変更：
サブルーチンシンボル をメソッド呼び出しに使用します（定義済みプロセス）
最近、いくつかのフローチャートを作成し、同じ問題、サブルーチン呼び出し、またはおそらくメソッド呼び出しと関数呼び出しをどのように表示するかについて、最近のようにそれらに取り組んでいます。
私は、サブルーチンCALLSをサブルーチンREFERENCESから分離するという慣習に決めました。前者については、プログラム実行のその時点で有効な変数を使用して、引数が作成された呼び出しを示す通常の長方形を使用します。
両面の「定義済みプロセス」の長方形を、その関数またはサブルーチンの定義を含む別のフローチャートへの参照として使用しています。サブルーチンの四角形は、問題のサブルーチンの定義フローチャートの一部であるため、サブルーチンの引数を表示する必要はありませんが、参照できるように参照に追加しておくと役立つ場合があります。呼び出しで使用される実際の引数の意味を参照してください。
これにより、長方形の数が増えますが、呼び出された関数のいくつかの定義を検索するために、これらの他のフローチャートが存在することが明確になります。多くの場合、関数が単純な場合は、そのための個別の図を作成せず、口頭で文書化します。
また、「ドキュメント」記号を使用して、コードリストから詳細を調べる必要があることを示しています。
フローチャートのポイントは、プログラムを作成することではなく、他の人がプログラムを理解しやすくすることです。鳥瞰図としての助けとそれらの目的は心に留めておくべきだと思います。これらはプログラムのすべての詳細を視覚的に説明するためのものではなく、詳細は必要に応じてコードから表示できます。フローチャートは、高レベルの視点から見たプログラムの1つの画像にすぎません。
フローチャートを高レベルに保つことは、コードが変更されたときにフローチャートを最新に保つ必要性が少なくなることも意味します。
写真です。他の良い物語のように、ソフトウェアのドキュメントにも、コードに別の視点を与える写真が必要です。