フローチャートはどのような状況でまだ価値があり、有用なツールですか？
私が最初にプログラミングを始めたとき、私はフローチャート（およびプリンター間隔チャート）に大きく依存していました。 COBOLクラスにいる間、フローチャートがインストラクターによってサインオフされるまで、コードを書き始めることができませんでした。当時、私はすべてのためのフローチャートを作らなければなりませんでした。
25年後の今日、私は2種類のことだけをフローチャートにしています。ロジックがトリッキーまたは非常に一般的な概念である非常に特殊なアルゴリズムで、すべての大きなステップを適切な順序で定義します。
私が単に見落としたフローチャートの他の使用例はありますか？
絶対に。
これまでに行ったことのない何かを実装しているとき（そしてアルゴリズムが数ステップ以上かかるとき）はいつでも、それをグラフ化します。ソリューション全体を、グラフ化されていない場合よりも、より原子的なレベルで徹底的に分析する必要があることに気づきました。この方法には3つの大きな利点があることがわかりました。
- 「あらクラップス」は少なくなった
- システムの他の部分全体で発生する可能性のある潜在的なノックオン問題を洗い流します
- アルゴリズムを簡単に他の人に紹介することができます
私が実際にこれらを使用する2つの異なる状況は次のとおりです。
- 低レベルのアルゴリズム。非常に具体的な問題に対する非常に具体的な解決策を意味します。通常、実装前にこれらをピアに渡します。
- ユーザーフロー。これを使用してピアを通過するだけでなく、ユーザビリティの専門家に（非常に非技術的な方法で）フローを説明するためにも使用します。
そうは言っても、毎日フローチャートを作成することはありません（そして、フローチャートが完成したとしても、テクニカルデザインドキュメントを書いていない限り、それは一般的にホワイトボードセッションです）。
決して
フローチャート（特に25年以上前に実施されたもの）は、はるかに表現力豊かなダイアグラム作成手法（アクションダイアグラム、シーケンスチャート、ステートチャートなど）に取って代わられました。
IBM自身の調査によると、フローチャートの使用はシステムの設計または実装の品質に影響を与えないことが示されています（ユーザーや他の開発者とのコミュニケーションにはわずかに役立ちました） アナリストとプログラマーのための図表作成テクニック]。
1976年の最初のプログラミングクラス以来、私は古典的なフローチャートを描きませんでした。また、80年代の初め以来、他の誰もがフローチャートを作成するのを見たことはありません。コードがアセンブリ言語である場合、フローチャートはプログラムロジックを伝達するのに役立ちました。 1960年代後半までに、アセンブリ言語プログラマは疑似コードを使用していました。現代のOO=言語でプログラミングする場合、フローチャートも疑似コードも価値がありません。実装言語で高レベルのコードを書くこともできます。
私は時々、デザインのアイデアを表現するために、大部分が紙に書かれたUML図を描きますが、それらの図は、議論の終わりまでしか存続しません。また、時々状態遷移図を描き、それを実装言語の状態テーブルに変換します。
フローチャートを使用する理由はいくつかあります。
私の意見では、これらはUMLユースケース図よりも優れています。さまざまな使用例とそれらの相互作用を反映でき、ユーザーエクスペリエンスと意思決定をまとめて全体的に優れた仕事をします。
彼らは理解しやすく、より直感的です。最初から最後まで、あなたの心は自然に迷路のように矢をたどります。フローチャートを使用して、別のユーザーストーリーの別のフローチャートを終了して参照できます。通常、それらをページ番号の付いた本に印刷し、ページをすばやくめくって次のフローチャートに移動できます。
彼らは普遍的です。ソフトウェアエンジニアリング以外の人は、フローチャート図がユーザーやビジネスアナリストに認識されやすいUML図を知って理解している人はほとんどいません。私は顧客に複雑なユースケースを伝えようと試み、彼らは時々理解するのに苦労します、私は彼らにフローチャートを描きます、そして彼らは彼らが思ったよりもはるかに複雑にするすべてのニュアンスを最終的に理解する理由を理解します。
フローチャートは、特定の順序で実行する必要がある場合に役立ちます。彼らが私の心の中で本当に輝いているのは、決定が行われる場所を示し、可能な各決定にパスがあることを確認することです。これにより、管理者（98％の時間を承認するマネージャー）が承認しない場合、管理者の承認が必要なプログラムを作成できなくなります。彼らは、最も一般的なパスが唯一のパスではないことを思い出させます。多くの場合、最も一般的なパスしか知らされないため、要件についてユーザーと話すのに役立ちます。
フローチャートは、非常に不適切に構造化されたコードのリバースエンジニアリングに役立ちます。特に、gotosがある場合。ありがたいことに、最近goto-riddされたコードはあまり見かけません。
他の人がエンドユーザーとのコミュニケーションについて指摘したように。フローチャートで文書化されたTVトランスミッターの起動をソートします。ハードウェアとソフトウェアの人々には、共通の仕様がありました。
UMLアクティビティ図とフローチャートは、プロセスまたはアルゴリズムの複雑さを中程度に示すのに役立ちます。
ビジネスルールについてビジネスユーザーと通信するときに非常に優れています。
BPMN 2.0のフォームには、ビジネスプロセスモデリングで非常に役立つバリエーションが存在します。
一部のBPMNツールは、チャートから実行中のWebアプリケーションを生成できます。
したがって、はい、フローチャートにはまだ場所がありますが、それらは賢く使用する必要があります。