構造化分析

構造化分析では、通常、単一の抽象化メカニズムを使用して階層構造を作成します。構造化分析手法は、 IDEF（図を参照）を使用することができ、プロセス主導型であり、目的と視点から始まります。この手法では、全体的な機能を特定し、プロセスを最適化するために必要な入力、出力、制御、およびメカニズムを維持しながら、機能を反復的に小さな機能に分割します。機能分解アプローチとしても知られており、機能内の凝集度と機能間の結合度に焦点を当て、構造化データを作成します。^{[ 11 ]}

構造化手法の機能分解は、システム動作を明示することなくプロセスを記述し、必要な機能の形でシステム構造を規定します。この手法は、アクティビティに関連する入力と出力を識別します。構造化分析が普及している理由の1つは、単一システムレベルでもエンタープライズレベルでも、高レベルのプロセスと概念を直感的に伝達できることです。オブジェクトが商用的に普及しているオブジェクト指向開発の機能をどのようにサポートできるかは不明です。IDEFとは対照的に、UMLはインターフェース駆動型であり、サービス指向アーキテクチャ（SOA）の記述に役立つ複数の抽象化メカニズムを備えています。 ^{[ 11 ]}

構造化分析は、システムを流れるデータの観点から捉えます。システムの機能は、データの流れを変換するプロセスによって記述されます。構造化分析は、逐次分解（またはトップダウン）分析による情報隠蔽を利用します。これにより、関連する詳細に注意を集中させることができ、無関係な詳細を見ることによる混乱を回避できます。詳細レベルが高くなるにつれて、情報の範囲は狭まります。構造化分析の結果は、関連するグラフィカル図、プロセス記述、およびデータ定義のセットです。これらは、システムの機能要件を満たすために必要な変換と必要なデータを記述します。^{[ 12 ]}

デ・マルコのアプローチ^{[ 13 ]}は、以下のオブジェクトから構成されています（図を参照）：^{[ 12 ]}

• コンテキスト図
• データフロー図
• プロセス仕様
• データ辞書

ここで、データフロー図(DFD) は有向グラフです。アークはデータを表し、ノード (円またはバブル) はデータを変換するプロセスを表します。プロセスは、その中のサブプロセスとデータフローを示すより詳細な DFD にさらに分解できます。サブプロセスは、その機能が容易に理解できるまで、別の DFD セットでさらに分解できます。機能プリミティブは、それ以上分解する必要のないプロセスです。機能プリミティブは、プロセス仕様 (またはミニ仕様) によって記述されます。プロセス仕様は、擬似コード、フローチャート、または構造化された英語で構成されます。DFD は、機能プリミティブで構成される相互接続されたプロセスのネットワークとしてシステムの構造をモデル化します。データディクショナリは、データフロー、データ要素、ファイル、およびデータベースのエントリ (定義) のセットです。データディクショナリのエントリは、トップダウン方式で分割されます。これらは、他のデータディクショナリのエントリおよびデータフロー図で参照できます。^{[ 12 ]}

コンテキスト図は、システムと相互作用する可能性のあるシステム外部のアクターを表す図です。^{[ 15 ]}この図は、ブロック図と同様に、システム全体の（おそらくソフトウェアベースの）表示であり、外部要因からの/への入力と出力を示します。

Kossiakoff (2003) によると、このタイプの図は通常「システムを中央に配置し、内部構造の詳細を示さず、その周囲を相互作用するすべてのシステム、環境、アクティビティで囲む」ものです。システムコンテキスト図の目的は、システム要件と制約の完全なセットを開発する際に考慮すべき外部要因とイベントに注意を集中させることです。^{[ 15 ]}システムコンテキスト図はデータフロー図に関連しており、システムが直面するように設計されているシステムと他のアクターとの間の相互作用を示します。システムコンテキスト図は、システムがソフトウェアエンジニアリングの一部となるコンテキストを理解するのに役立ちます。

データディクショナリまたはデータベースディクショナリは、データベースの基本的な構成を定義するファイルです。^{[ 16 ]} データベースディクショナリには、データベース内のすべてのファイル、各ファイルのレコード数、および各データフィールドの名前と型のリストが含まれています。ほとんどのデータベース管理システムは、ユーザーが誤ってその内容を破壊することを防ぐために、データディクショナリをユーザーから隠しています。データディクショナリには、データベースからの実際のデータは含まれておらず、データベースを管理するための帳簿情報のみが含まれています。ただし、データディクショナリがないと、データベース管理システムはデータベースからデータにアクセスできません。^{[ 16 ]}

データベースの利用者やアプリケーション開発者は、1 つ以上のデータベースの構成、内容、および規則をカタログ化した信頼できるデータ辞書ドキュメントから恩恵を受けることができます。^{[ 17 ]}通常、これには各データベースのさまざまなテーブルとフィールドの名前と説明、さらに各データ要素のタイプと長さなどの詳細情報が含まれます。このようなドキュメントの詳細レベルに関する普遍的な標準はありませんが、これは主にデータベース構造に関するメタデータの要約であり、データ自体ではありません。データ辞書ドキュメントには、データ要素がどのようにエンコードされるかを説明する追加情報も含まれる場合があります。適切に設計されたデータ辞書ドキュメントの利点の 1 つは、複雑なデータベース全体、または大規模な統合データベースのコレクション全体で一貫性を確立するのに役立つことです。^{[ 18 ]}

データフロー図（DFD）は、情報システムにおけるデータの「流れ」をグラフィカルに表現したものです。システムフローチャートとは異なり、コンピュータハードウェアではなくプロセスを通してデータの流れを示します。データフロー図は、構造化設計の開発者であるラリー・コンスタンティンが、マーティンとエストリンの「データフローグラフ」計算モデルに基づいて考案しました。^{[ 20 ]}

一般的には、まずシステムと外部エンティティ間の相互作用を示すシステムコンテキスト図を作成します。データフロー図（DFD）は、システムがどのように小さな部分に分割されているか、そしてそれらの部分間のデータの流れを明確に示すように設計されています。このコンテキストレベルのデータフロー図は、モデル化対象システムの詳細を示すために「展開」されます。

データフロー図（DFD）は、構造化シ​​ステム分析設計手法（SSADM）の3つの重要な視点の1つです。プロジェクトのスポンサーとエンドユーザーは、システム開発の全段階を通して説明を受け、意見を求められる必要があります。データフロー図を用いることで、ユーザーはシステムの動作方法、システムの達成目標、システムの実装方法を視覚的に把握できます。旧システムのデータフロー図を作成し、新システムのデータフロー図と比較することで、より効率的なシステムを実装するための比較検討を行うことができます。データフロー図は、エンドユーザーが入力したデータが、注文から出荷、再調理に至るまで、システム全体の構造に最終的にどのような影響を与えるかを、物理的なイメージとして示すために使用できます。あらゆるシステムの開発方法は、データフロー図によって把握できます。

構造図（SC）は、構成システムを最も管理しやすいレベルまで分解した図です。 ^{[ 21 ]}この図は、構造化プログラミングにおいて、プログラムモジュールをツリー構造に配置するために使用されます。各モジュールは、モジュール名を含むボックスで表されます。ツリー構造は、モジュール間の関係を視覚化します。^{[ 22 ]}

構造図は、構造化分析において、コンピュータ プログラムの高レベル設計、つまりアーキテクチャを指定するために使用されます。設計ツールとして、プログラマが大規模なソフトウェア問題を分割して解決するのを支援します。つまり、問題を人​​間の脳が理解できるほど小さな部分に再帰的に分解します。このプロセスは、トップダウン設計、または機能分解と呼ばれます。プログラマは、建築家が設計図を使って家を建てるのと同様の方法で、構造図を使用してプログラムを構築します。設計段階では、チャートはクライアントとさまざまなソフトウェア設計者がコミュニケーションをとるための手段として作成され、使用されます。実際のプログラムの構築（実装）中は、チャートはマスター プランとして継続的に参照されます。^{[ 23 ]}

構造化設計（SD）は、モジュールの開発と、いわゆる「モジュール階層」におけるこれらのモジュールの合成に関係しています。^{[ 24 ]}最適なモジュール構造とインターフェースを設計するためには、2つの原則が重要です。

• 凝集性とは、「機能的に関連するプロセスを特定のモジュールにグループ化すること」に関わるものであり、 ^{[ 12 ]}
• 結合とは、「モジュール間で渡される情報やパラメータの流れ」のことである。最適な結合は、モジュールのインターフェースとそれに伴うソフトウェアの複雑さを軽減する。 ^{[ 12 ]}

構造化設計は、1960年代後半にラリー・コンスタンティンによって開発され、その後1970年代に共同研究者とともに改良・発表されました。 ^{[ 5 ] [ 6 ]}詳細はラリー・コンスタンティン：構造化設計を参照してください。ページ＝ジョーンズ（1980）は、3つの主要なオブジェクトからなる独自のアプローチを提案しています 。

• 構造図
• モジュール仕様
• データ辞書。

構造図は、モジュールの階層構造や呼び出し順序の関係を示すことを目的としています。構造図に示されている各モジュールには、モジュール仕様があります。モジュール仕様は、擬似コードまたはプログラム設計言語で構成できます。データ辞書は、構造化分析のようなものです。ソフトウェア開発ライフサイクルのこの段階では、分析と設計が実行された後、データ型宣言^{[ 25 ]}やプロシージャまたはサブルーチンのテンプレート^{[ 12 ]}を自動的に生成することが可能です。