最近、いくつかのフローチャートを作成し、同じ問題、サブルーチン呼び出し、またはメソッド呼び出しと関数呼び出しの提示方法に苦労しました。
サブルーチンCALLSをサブルーチンREFERENCESから分離するという慣習に決めました。前者の場合、プログラム実行のその時点で有効な変数を使用して、引数が作成された状態で呼び出しを示す通常の長方形を使用します。
二重の「事前定義されたプロセス」長方形を、その関数またはサブルーチンの定義を含む別のフローチャートへの参照として単に使用します。サブルーチンの四角形は、サブルーチンの引数を示す必要はありません。これは、問題のサブルーチンの定義フローチャートの一部であるためです。呼び出しで使用される実際の引数の意味を参照してください。
これにより、長方形の数が増えますが、呼び出された関数の定義を調べるために他のフローチャートが存在することが明確になります。多くの場合、関数が単純な場合、別のダイアグラムを作成せず、口頭で文書化します。
また、「ドキュメント」記号を使用して、コードリストから詳細を調べる必要があることを示します。
フローチャートのポイントは、プログラムを作成することではなく、他の人がプログラムを理解しやすくすることです。私は鳥瞰図としての助けとその目的を心に留めておくべきだと思います。プログラムのすべての詳細を視覚的に記述するためではなく、必要なときにコードから詳細を見ることができます。フローチャートは、高レベルの観点から見たプログラムの1つの画像にすぎません。
フローチャートを高レベルに保つことは、コードが変更されたときに最新の状態に保つ必要性が少なくなることも意味します。
写真です。優れたストーリーのように、ソフトウェアのドキュメントには、コードの別の視点を示す写真も必要です。