構造化分析設計技法
この項目「構造化分析設計技法」は途中まで翻訳されたものです。(原文:en:Structured Analysis and Design Technique(22:54, 17 March 2011 UTC)の翻訳) 翻訳作業に協力して下さる方を求めています。ノートページや履歴、翻訳のガイドラインも参照してください。要約欄への翻訳情報の記入をお忘れなく。(2011年5月) |
構造化分析設計技法 (こうぞうかぶんせきせっけいぎほう、SADT、英: Structured Analysis and Design Technique) は、機能階層としてシステムを記述する一つのソフトウエア工学方法論である。
概要
[編集]SADTは、システムの人的記述と理解を助けることを意図した一つの図的表記法である[1]。それは、エンティティとアクティビティ(ボックス)、及びボックスを関係させる種々の矢印を表すビルディング・ブロックを提供する。これらのボックスと矢印は、関連する非公式な意味論を持つ[2]。SADTは、詳細さの連なるレベルを使って、与えられたプロセスの機能分析ツールとして活用できる。SADT手法は、産業情報システムで多く使われるIT開発のための利用者ニーズを定義することを可能とするが、しかしそれはまた、アクティビティの製造プロセス、手順を説明あるいは表現する。これらの機能は、販売、受注計画、製品設計、部品製造、あるいは人材資源管理のような会社の目的を充たす。SADTは、そこでシンプルな機能的関係を描き出し、そして異なる機能間でのデータ及びコントロール関係を反映できる。
歴史
[編集]SADTは、ダグラス・ロスとSofTech,_Inc.によって1969年から1973年の間に開発され、フィールド・テストされた[3][1] 。この手法論は、MITのAPTプロジェクトで活用された。それは米空軍のICAMプロジェクトによって1973年に全面的に使用が受け容れられた。
Levitt (2000)に沿って、『それは、1960年代から1980年代のソフトウエアの世界が直面する問題へ対応するため開発された、分析、設計、及びプログラミング技術の集合を代表する、一連の構造化手法の一部である』。この時間フレームにおけるほとんどの商用プログラミングは、COBOL、Fortran、それから CやBASICで行われた。そこには少しの『良い』設計やプログラミング技術へのガイドラインはあったが、文書化要求や設計に対する標準的技術は存在しなかった。システムはより大きくまた複雑化し、そして情報システム開発は、それを行うためより難しさを増した。大規模かつ複雑なソフトウエアを管理する助ける方法として、1960年末から複数の構造化手法が出現し始めた[4]。
- 構造化プログラミング - 1967年頃のエドガー・ダイクストラによる
- 構造化設計 - 1975年前後のラリー・コンスタンティンとエドワード・ヨードンによる
- 構造化分析 - 1978年頃の トム・デマルコ、ヨードン、Gane & Sarson、McMenamin & Palmer
- インフォメーション・エンジニアリング - 1990年頃のJames Martinによる
1981年に、IDEF0手法論が、SADTに基づき発行された[5]。
SADT トピックス
[編集]トップダウン・アプローチ
[編集]構造化分析設計技法は、トップダウン・アプローチによる分割を利用する。この分割は、自明の設計視点から物理的領域にのみ実行される。このジグザグなしのプロセスが故に、機能性あるいは生産性の保障は存在しない。そこで、それらの手法は、増大するソフトウエア・システムの要求から遠ざけられ、そしてオブジェクト指向手法が導入された[6]
ダイアグラム(図)
[編集]SADTは、アクティビティ・モデルとデータモデルの2つのダイアグラムのタイプを使う。それはこれらのダイアグラムの構築する矢印を用いる。SADTの表現は以下のようである:
- プロセス、又は行動の名前が特定されるメイン・ボックス
- このボックスの左側に入る矢印:その行動の入力
- 上部に入る矢印:その行動に必要なデータ
- ボックスの下部に入る矢印:その行動に使われる手段
- ボックスの右側から出る矢印:その行動の出力
アクティビティのための矢印の意味:[2]
- 入力は左から入り、そのアクティビティによって必要なデータあるいは称されるものを表す。
- 出力は右から出て、そのアクティビティが生成するデータあるいは製品を表す。
- 制約は上部から入り、アクティビティの実行に影響するが消費されないコマンドを表す。
- 機構はそのアクティビティの達成に使われる手段、構成要素、あるいはツールを識別する。アクティビティの配置を表現する。
データのための矢印の意味:[2]
- 入力はデータを生み出すアクティビティである。
- 出力はデータを消費する。
- 制約はデータの内的状態に影響する。
脚注
[編集]- ^ a b D. Marca, C. McGowan, Structured Analysis and Design Technique, McGraw-Hill, 1987, ISBN 0-07-040235-3
- ^ a b c John Mylopoulos (2004). Conceptual Modelling III. Structured Analysis and Design Technique (SADT). Retrieved 21 Sep 2008.
- ^ D. T. Ross: Structured Analysis (SA): A Language for Communicating Ideas. IEEE Transactions on Software Engineering, SE-3(1), pp. 16-34. Abstract
- ^ Dave Levitt (2000):Introduction to Structured Analysis and Design. Retrieved 21 Sep 2008.
- ^ Gavriel Salvendy (2001). Handbook of Industrial Engineering: Technology and Operations Management.. p.508.
- ^ Nam Pyo Suh (2007). Axiomatic Design - Advances and Applications. New York : Oxford University Press Chapter 5, pp. 239-298.
参考文献
[編集]- William S. Davis (1992). Tools and Techniques for Structured Systems Analysis and Design. Addison-Wesley. ISBN 0201102749
- Marca, D.A., and C.L. McGowan. (1988). SADT: structured analysis and design technique. McGraw-Hill Book Co., Inc.: New York, NY.
- Jerry FitzGerald and Ardra F. FitzGerald (1987). Fundamentals of Systems Analysis: Using Structured Analysis and Design Techniques. Wiley. ISBN 0471885975
- David A. Marca and Clement L. McGowan (1988). SADT: Structured Analysis and Design Technique. McGraw-Hill. ISBN 0070402353
- D. Millington (1981). Systems Analysis and Design for Computer Applications. E. Horwood. ISBN 0853122490
- Robertson & Robertson (1999). Mastering the Requirements Process. Addison Wesley.
- James C. Wetherbe (1984). Systems Analysis and Design: Traditional, Structured, and Advanced Concepts and Techniques. West Pub. Co. ISBN 0314778586