大規模で複雑なアプリケーションコードの図解
プログラムで使用する関数のフローチャートを作成しようとしましたが、すべてのプロセスの間に多くの条件ステートメントがあり、図がさらに混乱しています。
複雑度の高い大規模なコードベースに使用できるフローチャート以外の言語またはマークアップはありますか？
1つの関数のフローチャートが非常に複雑で理解しにくい場合は、関数が複雑すぎます。 「抽出メソッド」と呼ばれるリファクタリングパターンについて考えてみます。 （OO以外の手続き型関数でも使用できます。）
DFDのネストされたレイヤーを使用する
一般に、ソフトウェアシステムの複雑さに取り組む最善の方法は、それを単純化することです。複雑なソフトウェアのダイアグラム作成を単純化するために私が見つけたより良い方法の1つは、概念の粒度が異なるレイヤーに分割することです。
例
図1は、システムの非常にトップダウンの最高レベルの概要を示しています。これには、最高レベルのシステムがどのように連携するかを概説する以上の実際のロジックはほとんどありません。特定のシステムがどのように機能するかを知りたい場合は、別の図を参照してください。
図Aは、システム1がどのように機能するかについてより詳細に説明していますが、これも高レベルの概要であり、システム1が概念的にどのように機能するかを概説していますが、実際のロジックはさらにサブ図を参照しています。
最も粒度が低い場合、これはシステムの実際のロジックが機能する場所であり、コードでのオブジェクト継承のように（OOP/OODを使用していると仮定）、コードで行うのと同じようにDFDで複数レベルの抽象化があります。実際の実装の詳細は、オブジェクトの最も細かい粒度に委任されます。
認知の複雑さ
ただし、各レイヤーには、認知の複雑さに関するルールが必要です。コードのように、図は5分以内に簡単に理解できるはずです。
適切に設計されたコードは、認知の複雑さに関する上記のルールにも従う必要があります
一般に、これはコードのレイアウト方法でもあります。適切に設計されたコードも5分以内に簡単に理解できるはずです。
異なるインスタンス/コンポーネント間でメッセージフローを明確にするために、シーケンス図（オブジェクト指向設計）の作成を試みることができます。
条件が多すぎるためにコードロジックが複雑な場合、フローチャートは役に立ちません。より良いアプローチは、擬似コードを使用してロジックを記述することです。擬似コードの詳細については、こちらをご覧ください： http://en.wikipedia.org/wiki/Pseudocode また http://149.144.20.200/subjects/PE/PEWeb/other_resources/pseudocode_guide.html
テーブルの関係を表示する場合は、エンティティ関係図を使用し、プロセスの依存関係を表示する場合は、BPMを使用します。各図には目的と制限があります。
Scitools Understand は、いくつかの主要言語のプログラムの依存関係（関数、サブルーチンなど）に関するグラフの作成に優れています。フローチャートはないと思いますが、複雑なコードはいつでも関数に分割でき（それでも、ある程度まで実行する必要があります）、それによって保守が容易になります。
これでどの言語を目指していますか？
