構造図

ソフトウェア工学と組織理論における構造図（SC）は、システムの最小レベルから管理可能な最低レベルまでを示す図です。 ^[2]構造化プログラミングでは、プログラムモジュールをツリーに配置するために使用されます。各モジュールは、モジュール名を含むボックスで表されます。ツリー構造は、モジュール間の関係を視覚化します。^[3]

構造図はトップダウンのモジュール設計ツールであり、システム内のさまざまなモジュールを表す四角形とそれらを接続する線で構成されています。線は、組織図で使用されるアクティビティとサブアクティビティ間の接続や所有権を表します。^[4]

ウォルバー (2009) によると、構造化分析では、構造チャートは「コンピュータ プログラムの高レベルの設計、つまりアーキテクチャを指定するために使用されます。設計ツールとして、構造チャートはプログラマーが大きなソフトウェアの問題を分割して解決するのに役立ちます。つまり、問題を人​​間の脳で理解できるほど小さな部分に再帰的に分解します。このプロセスは、トップダウン設計、または機能分解と呼ばれます。プログラマーは、建築家が家を建てるときに設計図を使用するのと同じように、構造チャートを使用してプログラムを構築します。設計段階では、チャートが描かれ、クライアントとさまざまなソフトウェア設計者がコミュニケーションするための手段として使用されます。プログラムの実際の構築 (実装) 中、チャートは常に「マスタープラン」と呼ばれます。^[5]

構造図は^[2]

• システムの規模と複雑さ、そして
• 各機能内の容易に識別可能な機能とモジュールの数、
• 識別可能な各機能が管理可能なエンティティであるか、またはより小さなコンポーネントに分割する必要があるかどうか。

構造図は、実行ストリームまたはスレッドを構成する関連要素を図式化するためにも使用されます。階層図として作成されることが多いですが、他の表現も許容されます。表現では、構成システムをサブシステムと管理可能な最低レベルに分解して記述する必要があります。正確で完全な構造図は、構成アイテム (CI) を決定する鍵であり、構成システムとその CI 間の内部インターフェイスを視覚的に表現します^{(CI を明確に定義します)}。構成管理プロセスでは、構造図を使用して、提案された変更が影響を与える可能性のある CI とそれに関連する成果物を特定します。^[2]

ウォルバー (2009) によると、「構造図は、構造図を形成する逆さまのツリーのルートを配置する構造の作成から開発できます。次のステップは、問題を解決するためにプログラムが実行する必要がある主要なサブタスクを概念化することです。次に、プログラマーは各サブタスクに個別に焦点を合わせ、それぞれをさらに小さなタスクに分割する方法を概念化します。最終的に、プログラムは、ツリーの葉がいくつかのプログラムステートメントでコード化できる単純なメソッドを表すポイントまで分割されます。」^[5]

実際には、図に示すように、まず構造図がすでに作成されているかどうかを確認します。作成されている場合は、専門家がそれをレビューして、現在の構造を反映していることを確認する必要があります。そうでない場合は、必要に応じて図を更新します。^[2]

ウィキメディア・コモンズには、構造図に関連するメディアがあります。

• コンピュータ支援ソフトウェアエンジニアリング
• システムコンテキスト図
• 分解図
• 機能モデル
• ヒポ
• 構造化分析と設計手法
• ワーニエ/オール図
• 作業分解構造

• Sarah Brooks (1981)。「構造チャートと基本プログラミング」。MATYC Journal、v15 n2、p. 107-112、1981 年春。
• トム・デマルコ(1979)。構造化分析とシステム仕様。プレンティス・ホール。
• エドワード・ヨードン（1999年）。現代構造分析、ヨードン・プレス・コンピューティング・シリーズ、1999年、

• 構造図の概要。
• 州裁判所構造図、一連の例。
• 構造チャート (.doc)。