構造化分析

ソフトウェア エンジニアリングにおいて、構造化分析(SA) と構造化設計(SD) は、ビジネス要件を分析し、実践をコンピュータ プログラム、ハードウェア構成、および関連する手動手順に変換するための仕様を開発する方法です。

構造化分析と設計技術はシステム分析の基本的なツールであり、1960年代と1970年代の古典的なシステム分析から発展しました。^[2]

構造化分析は 1980 年代に人気が高まり、現在でも使用されています。^[要出典]構造化分析は、システム概念 (または現実世界の状況) を、データ フロー図で表されるデータと制御の用語に解釈することから成ります。バブルからデータ ストア、そしてバブルへと続くデータと制御のフローを追跡するのは困難で、バブルの数が増える可能性があります。

1 つのアプローチは、まずシステムの反応を必要とする外部からのイベントを定義し、次にそのイベントにバブルを割り当てることです。相互作用する必要があるバブルは、システムが定義されるまで接続されます。バブルは通常、複雑さを軽減するために上位レベルのバブルにグループ化されます。データとコマンドのフローを記述するにはデータ辞書が必要であり、トランザクション/変換情報を取得するにはプロセス仕様が必要です。^[3]

SA と SD は、構造図、データフロー図、データモデル図で表示されます。これらには、Tom DeMarco、Ken Orr、Larry Constantine、Vaughn Frick、Ed Yourdon、Steven Ward、Peter Chenなどによって開発されたものを含め、多くのバリエーションがありました。

これらの手法は、構造化シ​​ステム分析および設計法、設計による収益性の高い情報 (PRIDE)、Nastec 構造化分析および設計、SDM/70、Spectrum 構造化システム開発方法論など、公開されているさまざまなシステム開発方法論に統合されています。

構造化分析は、1960年代から1980年代にかけてソフトウェア業界が直面した問題に対応するために開発された分析、設計、プログラミング技術の集合体である一連の構造化手法の一部です。この期間、ほとんどの商用プログラミングはCobolとFortranで行われ、その後CとBASICで行われました。「優れた」設計とプログラミング技術に関するガイダンスはほとんどなく、要件と設計を文書化するための標準的な技術もありませんでした。システムはますます大規模で複雑になり、情報システムの開発はますます困難になっていきました。」^[4]

大規模で複雑なソフトウェアの管理を支援する方法として、1960年代末から次のような構造化された方法が登場しました。^[4]

• 1967 年頃のエドガー・ダイクストラによる構造化プログラミング- 「Go To ステートメントは有害であると考えられる」
• ニクラス・ヴィルトのステップワイズデザイン、1971年
• 1972年のナッシ・シュナイダーマン図
• 1974 年のWarnier/Orr 図- 「プログラムの論理的構成」
• 1974 年のHIPO - IBM 階層 入力-プロセス-出力 (ただし、これは実際には出力-入力-プロセスのはずです)
• 1975年頃のラリー・コンスタンティン、エド・ヨードン、ウェイン・スティーブンスとの構造設計。^{[5] [6]}
• ジャクソン構造化プログラミングは、1975年頃にマイケル・A・ジャクソンによって開発された。
• 1978 年頃のTom DeMarco、Edward Yourdon 、Gane & Sarson、McMenamin & Palmerによる構造化分析。
• ダグラス・T・ロスが開発した構造化分析設計手法（SADT）
• エドワード・ヨードンによって開発されたヨードン構造化メソッド。
• 1978 年にTom DeMarcoによって出版された構造化分析とシステム仕様。
• 構造化システム分析および設計法(SSADM) は、1983 年に英国 商務省によって開発され、初めて発表されました。
• スティーブン・M・マクメナミンとジョン・F・パーマーによって提唱されたエッセンシャル・システム分析^[7]
• IDEF0はSADTに基づいており、1985年にダグラス・T・ロスによって開発された。 ^[8]
• Hatley-Pirbhai モデリングは、1988 年に Derek J. Hatley と Imtiaz A. Pirbhai によって「Strategies for Real-Time System Specific」で定義されました。
• 現代構造分析は、エッセンシャルシステム分析が出版された後にエドワード・ヨードンによって開発され、1989年に出版されました。^[9]
• 情報技術工学は、1990 年頃に Finkelstein によって考案され、James Martinによって普及されました。

Hay (1999) によると、「情報工学は、 1970 年代に開発された構造化技術の論理的発展でした。構造化プログラミングは構造化設計につながり、構造化設計は構造化システム分析につながりました。これらの技術は、図表の使用を特徴としています。構造化設計には構造チャート、構造化分析にはデータ フロー図が使用され、ユーザーと開発者のコ​​ミュニケーションを助け、アナリストと設計者の規律を向上させました。1980 年代には、図表の描画を自動化し、描画したものをデータ ディクショナリに記録するツールが登場し始めました。」^[10]コンピューター支援設計とコンピューター支援製造(CAD/CAM)の例に倣って 、これらのツールの使用はコンピューター支援ソフトウェア エンジニアリング(CASE) と名付けられました。

構造化分析は通常、単一の抽象化メカニズムを使用して階層を作成します。構造化分析法は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]詳細については}ラリー・コンスタンティン：構造化デザインを参照してください。Page-Jones（1980）は、3つの主な目的からなる独自のアプローチを提案しました。

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

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

データフロー図の問題点としては、次のようなものがある。^[3]

1. 適切なバブルの選択
2. 意味のある相互合意の方法でバブルを分割する
3. データフローを理解するために必要なドキュメントのサイズ、
4. データフロー図は本質的に機能的なため、頻繁に変更される可能性があります。
5. 「データ」フローは重視されているが、「データ」モデリングは重視されていないため、システムの主題に対する理解が乏しい。
6. 顧客は、概念がデータフローとバブルにどのようにマッピングされるかを理解するのが困難です。
7. デザイナーはDFDの構成を実装可能な形式に変更する必要がある

• イベントの分割
• フローベースプログラミング
• ヒポ
• ジャクソン構造化プログラミング
• Prosa 構造化分析ツール
• ソフトシステム方法論

• Stevens, WP ; Myers, GJ ; Constantine, LL (1974 年 6 月)。「構造化設計」。IBM Systems Journal。13 ( 2 ): 115–139。doi :10.1147/sj.132.0115。
• エドワード・ユアドン、ラリー・L・コンスタンティン（1979）[1975]。構造化設計：コンピュータプログラムとシステム設計の分野の基礎。ユアドン・プレス。ISBN 0-13-854471-9。
• トム・デマルコ(1978)。構造化分析とシステム仕様。ユアドン。ISBN 0-91-707207-3 
• Page-Jones, M (1980)、構造化シ​​ステム設計の実践ガイド、ニューヨーク：Yourdon Press
• Derek J. Hatley、Imtiaz A. Pirbhai (1988)。リアルタイムシステム仕様の戦略。John Wiley and Sons Ltd. ISBN 0-932633-04-8 
• Stephen J. Mellorおよび Paul T. Ward (1986)。リアルタイム システムの構造化開発: 実装モデリング手法: 003。Prentice Hall。ISBN 0-13-854803 -X 
• エドワード・ヨードン(1989)。現代構造分析、ヨードン・プレス・コンピューティング・シリーズ、1989年、ISBN 0-13-598624-9 
• キース・エドワーズ (1993)。リアルタイム構造化手法、システム分析。Wiley。ISBN 0-471-93415-1 

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

• 構造化分析ウィキ
• 構造化分析の 3 つの視点 CRaG Systems、2004 年。