システム設計の概要
システム設計へのアプローチ※画像クリックで拡大表示
POA、DOA、OOAの比較
システム設計へのアプローチは、歴史的な変遷として『POA』→『DOA』→『OOA』の順に進展していますが、現在の主流データベースが「RDBMS」であり、『DOA』と『OOA』の両方を活用した開発が多い。
POA（Process Oriented Approach）『プロセス中心アプローチ』は、
現行プロセスの把握としてデータの流れ（データフロー図）と処理に注目し、時間的推移の記述が特徴です。
DOA（Data Oriented Approach）『データ中心アプローチ』は、
データ構造とデータ間の関連（ER図）を中心にデータを処理から分離、独立させ、システム全体で共有することが特徴です。
OOA（Object Oriented Approach）『オブジェクト指向アプローチ』は、
人、もの、機能などのオブジェクトをモデル化して、実態に即したシステム表現（UML）が可能で、データと関連するプロセス（メソッド）を一体化(カプセル化)したオブジェクト指向プログラミングに対応することが特徴です。
システム開発のプロセス
ウォーターフォール型開発、スパイラル型開発、プロトタイプ型開発の比較
『ウォーターフォールモデル』は、
古くから導入されている古典的な開発プロセスで、川や滝を流れる水が必ず上流から下流へ向かうように､前の工程(上流工程)が完全に終了してからその成果物を元に次の工程(下流工程)へ進んで開発する方式です｡
『スパイラルモデル』は、
開発工程の早い段階にユーザーの承認を得るという必要性がシステム開発プロセスに指摘されるようになり、外部設計が終了した段階でシステムの機能を縮小したプロトタイプ（試作品）を作成、ユーザーに対してプレゼンテーション、試作、評価をしてもらい、インターフェースや操作性の満足度確認してから本格的な開発工程へ進む方法のプロトタイプモデルを応用発展させた手法です。
『反復型モデル』は、
インクリメンタル型開発とイテレーティブ型開発を合わせたソフトウェア開発手法のことで、システム全体をいくつかの部分に分割して反復しながら機能や品質を洗練し、それを段階的に全体に統合していく開発プロセスをいう。広義にはアジャイル開発も含まれる。
「インクリメンタル・モデル」は、全体のシステムを独立性の高いモジュール（機能）に分割し、そのモジュール毎に設計、コーディング、テストを行い、徐々に機能を追加して全体を完成させるモデルである。
「イテレーティブ・モデル」は、インクリメンタル・モデルのように機能毎に完成させていくのではなく、システム全体の開発を繰り返して徐々に完成度を上げていく繰り返し型の開発モデルである。
『システム開発の工程』
システム設計プロセスのV字モデルとは、
プログラムマネージメントとして、要件定義から開発・実装の流れを「品質の作りこみ」とし、単体テストからシステムテスト、受入れテストの流れを「品質の検証」としてV字モデルに相対する工程が開発と検証を同レベルの実施者の対応となる。
「要件定義」と「システムテスト、受入れテスト」は利用者による妥当性の検証、「基本設計」と「結合テスト」は設計者による妥当性の検証、「詳細設計」と「単体テスト」は開発者による妥当性の検証の３段階に対応付けられる。
W字モデルは、
最近、V字モデルを進化させたW字モデル（ダブルV字）が利用されていて、要件定義、基本設計、詳細設計の各開発工程に対応する受入れ・システムテスト、結合テスト、単体テストがあるが、各開発工程段階で同時並行してテスト計画書を作成し、その開発工程のレビューをすることで、ソフトウェアの欠陥を検出することができる。同様に、各テスト工程でテストの実施、テスト結果検証、欠陥修正、再テストの実施が行われるため、W字モデルという。
| 開発作業プロセス | 作業内容 | 主な成果物 |
|---|---|---|
| 要件定義 | これから開発するシステムに要求される｢機能｣(何ができるのか)や｢性能｣(どれくらいの能力が必要なのか)を明確にします。 | 要件定義書 |
| 基本設計 （外部設計） | ユーザ-の立場からみたシステムの外見(インタフェース)を設計します。 入出力画面やその操作性､印刷物の設計などユ-ザ一に直接関連する部分を設計したり､ファイルやデータベ一スに記録するデータ項目を明確にしたりします。 |
基本設計書 外部設計レビュー報告書 |
| 詳細設計 （内部設計） | 基本設計で取り決められたイメージとしてのシステムを実現するためのプログラムやファイル・データベースの物理的な構造を設計します｡また､完成したシステムをテストするパターンなどもこの段階で取り決めます。 | 詳細設計書 内部設計レビュー報告書 |
| 実装・製造 （プログラミング） | プログラム単体の｢仕様書｣を定義し､それに基づいたプログラミング作業をおこないます。また､完成したプログラム単体での動作確認テストはこの段階でおこないます。 | プログラム仕様書 |
| テスト | 完成したプログラムをシステムとして連動させ､要求される機能や性能を満たしているかをテストします｡開発者によるテストとして、単体テスト／結合テスト／システムテストがあり、利用者主体のテストとして、受入れテスト（運用テスト）があります。 | 結合テスト（IT）確認書 システムテスト（ST）確認書 |
| 運用・保守 | システムテストが完了したシステムをユ-ザ-の業務環境へ導入し､旧システムからのデ-タ移行､ユーザー教育などをおこないます。また､運用中に発見されたバグの修正や仕様変更・追加に対応します。 | 運用設計書 操作マニュアル |
設計内容の表記法
データフロー図（DFD）、ER図の設計ツールと作図例
データフロー図（DFD）の作図は、
POAの表記法である「DFD（Data Flow Diagram）」では、データの発生源を四角形、処理を円（バブルと呼ぶ）、ファイルを二重線で表す。データの流れは矢印で表し、矢印の上に流れるデータの内容を示す。
Excelで記述表現する方法もありますが、フローチャートとデータフロー図に対応するフリーのツールの「Dynamic Draw」が便利です。
ER図の作図は、
データベースの設計を行う際、情報を整理し、分析するときに「ER図」を用います。
エンティティは、ある目的を持って同じようなデータを集め､その目的を明確に表す名前を付けたもの（人、物、金、時間、やり取り・行為など）。エンティティの特性を表す構成要素（データ項目）を「属性」と呼び、エンティティ間の関連付けを「リレーション」で表現する。
リレーショナル・データベース（RDB）では、エンティティがテーブル（表）、属性がカラム（列）、検索等の索引がテーブルの主キーとなる。良く使われているフリーのツールは、「A5:SQL Mk-2」です。
UMLモデル図と作図例
UML2モデル図の一覧
| UMLモデル図 | 用途 |
|---|---|
| ユースケース図 * | システム化対象の機能と、その機能に関係する外部要素を可視化する。 |
| クラス図 * | システムの静的な構造を表現し、システムを構成する重要な概念をクラスとして表現する。 |
| シーケンス図 * | 処理の内容をライフライン（クラスやオブジェクト、コンポーネント）間の相互作用として動的の表現し、ライフライン間でやり取りされるメッセージの順番や方向、ライフラインの生成や消滅のタイミングなどを時系列で表現する。 |
| コミュニケーション図 * | シーケンス図と同様にライフライン間の相互作用を表現し、ライフラインとライフラインの接続関係を中心に表現する。 |
| ステートマシン図 * | オブジェクトの状態変化を表現し、ある状態から別の状態への遷移、遷移を起こすきっかけ、遷移を行うかどうかの判断条件を表記できる。 |
| アクティビティ図 * | システムの流れをアクションなどを用いて「意味ある一連の流れ」としてまとめる。業務フロー、イベントフロー、クラス操作における処理詳細などをフローとして表現できる。 |
| パッケージ図 | 複数のモデル要素をパッケージでグルーピングして大きな視点によりシステムを分割します。パッケージ間の利用関係を表現し、システム全体の構造を俯瞰することができます。 |
| オブジェクト図 * | 個々のオブジェクトが保持する属性値やオブジェクト間のつながりを表現し、ある瞬間のオブジェクトの状態（スナップショット）を明確に表現できる。（オブジェクトは、クラスの具体例） |
| コンポーネット図 | コンポーネント自体の入れ子構造やコンポーネント間のつながりを表現できる。（コンポーネントは、ソフトウェアの部品で複数のクラスをまとめて外部に公開するインターフェースを持たせたもの） |
| 配置図 * | システムの物理的な側面を表現し、ノードの配置、ノード間の接続関係を表現することができる。 |
| 合成構造図 * | クラスやコンポーネットなどの内部構造を詳細に表現でき、インターフェースを付加して、外部から内部の仕組みにアクセスするかを具体的に表現できる。 |
| タイミング図 | ライフラインの状態遷移や相互作用のメッセージ送信のタイミングを時系列で表現する。 |
| 相互作用概要図 | 複数の相互作用で構成されるシステム全体の流れを俯瞰することができる。 |
| 開発工程 | 主な成果物 | UMLモデル図 | |
|---|---|---|---|
| 構成図（静的） | 振る舞い図（動的） | ||
| 要件定義 | ユースケースモデル | ユースケース図 | |
| イベントフロー | アクティビティ図 | ||
| 画面遷移図 | なし | ||
| 基本設計の分析 | 概念モデル | クラス図、オブジェクト図 | |
| 分析モデル | クラス図、オブジェクト図 | コミュニケーション図 | |
| アーキテクチャ設計 | アーキテクチャ設計書 | パッケージ図、クラス図 | シーケンス図 |
| 詳細設計 | 設計モデル | クラス図 | シーケンス図 |
| 実装 | ソースコード | なし | |
| テスト | テスト仕様書、テストコード | なし | |
クラス図は、
クラス図は、データの項目を表す「属性」と処理の内容を表す「振る舞い」から成り、クラス間の関係を線（多を「0..*」で示す）で表す。
ユースケース図は、
システム化する領域を四角形で囲み、ユーザーから見た処理およびデータのまとまりを楕円形（ユースケースと呼ぶ）で表し、ユーザー（アクターと呼ぶ）とユースケースの関係は線で表す。
シーケンス図（コラボレーション図）は、
シーケンス図は時間の流れ（コラボレーション図はオブジェクト間の関係）を明確にするために使う。オブジェクトを長方形（：および下線を付ける）で示し、処理の流れを矢印で表す。
良く知られているフリーのツールは、「astah-community」（以前は、JUDE）です。Excelのアドインソフト「ExcelDeUML」もあります。
