フローチャートとメソッド呼び出し


11

私はいくつかのフローチャートを実行していますが、これに正しく近づいているかどうか疑問に思っています。基本的に、いくつかのメソッド呼び出しがあり、それぞれ個別にフローチャートを作成しています。ただし、これらのメソッドのいくつかは、何らかの情報のメソッド呼び出しを行ってから続行します。この例を参照してください。

ここに画像の説明を入力してください

GetQueue()を呼び出す他の3つのメソッドがあり、これを正しく表現しているかどうか疑問に思っています。AddQueue()フローは視覚的に壊れているように見えます。

注:フローチャートで行った変更:

ここに画像の説明を入力してください


このレベルの画像詳細は本当に必要ですか?かつて、このようなフローチャートは一般的でしたが、今日では多くの理由で好まれなくなっているように見えます...本質的に、それらはドキュメントの冗長な形式です。それらを最新の状態に保つ必要があり、コードはいずれにせよフローチャートに示されているものをすでに適切に表す必要があります(つまり、より多くのコードを作成するのに時間がかかります)。
ロバートハーヴェイ

別のクライアントに移る前に、それは私に要求されました。
キースバローズ

@Robert Harvey:フローチャートは、機械やアセンブラのコードを直接書いた昔は役に立ちました。それらは、制御構造の良い配列を持っていなかった初期のFORTRANおよびBASICプログラマにとって有用だったかもしれません。最近では、クライアントが成果物としてそれらを望んでいて、十分に私に支払いを喜んでいた場合、私がそれらをする唯一の理由です。
デヴィッド

これらをゼロから開発するとき、黄色の付箋を使用して、決定のために90度回転させることが非常に役立つことがわかりました。これにより、それらを移動したり、間にプロセスを挿入したりできます。全員がドンになったら、それらをソフトウェアに入力します。
マイケルライリー-別名ガニー

私はまだフローチャートを時々使用していますが、同じ目的のためにはユニットテストの方が良い場合が多いと思います。ただし、それらは成果物ではありません。私はそれらを使用して、頭の中で制御フローを取得します。
マイケルK

回答:



2

最近、いくつかのフローチャートを作成し、同じ問題、サブルーチン呼び出し、またはメソッド呼び出しと関数呼び出しの提示方法に苦労しました。

サブルーチンCALLSをサブルーチンREFERENCESから分離するという慣習に決めました。前者の場合、プログラム実行のその時点で有効な変数を使用して、引数が作成された状態で呼び出しを示す通常の長方形を使用します。

二重の「事前定義されたプロセス」長方形を、その​​関数またはサブルーチンの定義を含む別のフローチャートへの参照として単に使用します。サブルーチンの四角形は、サブルーチンの引数を示す必要はありません。これは、問題のサブルーチンの定義フローチャートの一部であるためです。呼び出しで使用される実際の引数の意味を参照してください。

これにより、長方形の数が増えますが、呼び出された関数の定義を調べるために他のフローチャートが存在することが明確になります。多くの場合、関数が単純な場合、別のダイアグラムを作成せず、口頭で文書化します。

また、「ドキュメント」記号を使用して、コードリストから詳細を調べる必要があることを示します。

フローチャートのポイントは、プログラムを作成することではなく、他の人がプログラムを理解しやすくすることです。私は鳥瞰図としての助けとその目的を心に留めておくべきだと思います。プログラムのすべての詳細を視覚的に記述するためではなく、必要なときにコードから詳細を見ることができます。フローチャートは、高レベルの観点から見たプログラムの1つの画像にすぎません。

フローチャートを高レベルに保つことは、コードが変更されたときに最新の状態に保つ必要性が少なくなることも意味します。

写真です。優れたストーリーのように、ソフトウェアのドキュメントには、コードの別の視点を示す写真も必要です。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.