http://itpro.nikkeibp.co.jp/article/COLUMN/20080515/301810/?ST=slfsys
【予定】
2010年1月25日月曜日
基本設計２－オブジェクト指向の基本設計を理解する
文章：http://itpro.nikkeibp.co.jp/article/lecture/20070702/276411/?ST=slfsys
最近はWebシステム開発を中心に，反復型開発プロセスやオブジェクト指向設計を採用するケースが増えている。
ここでは、オブジェクト指向設計に基づく代表的な反復型開発プロセスであるUP（Unified Process）を例にとって，オブジェクト指向設計における基本設計の勘どころを解説しよう。
UPでは「方向付け」，「推敲」，「作成」，「移行」という4つのフェーズが定義されており，それぞれのフェーズで「要求」，「分析」，「設計」，「実 装」，「テスト」という5つの作業を実施する。推敲フェーズを2回，作成フェーズを2回というように，あるフェーズを何度か繰り返すこともある。このため に，UPは「反復型開発プロセス」と呼ばれる。
●UPにおける基本設計の流れ
例えば，銀行口座の取引履歴照会というユースケースのイベントフローを次のように記述したとしよう。
イベントフローを中心的な成果物として作成したうえで，補足的な成果物として「画面レイアウト」（出力先が画面ではなく帳票の場合は「帳票レイアウト」， ファイルや他のシステムの場合は「インタフェース仕様」）と「データ項目」を添付し，これらの成果物一式を「ユースケース仕様書」として扱うことで，分析 ／設計での手戻りや再調査を最小化できる。
２、APIを用意したプラットフォーム
最近はWebシステム開発を中心に，反復型開発プロセスやオブジェクト指向設計を採用するケースが増えている。
ここでは、オブジェクト指向設計に基づく代表的な反復型開発プロセスであるUP（Unified Process）を例にとって，オブジェクト指向設計における基本設計の勘どころを解説しよう。
UPでは「方向付け」，「推敲」，「作成」，「移行」という4つのフェーズが定義されており，それぞれのフェーズで「要求」，「分析」，「設計」，「実 装」，「テスト」という5つの作業を実施する。推敲フェーズを2回，作成フェーズを2回というように，あるフェーズを何度か繰り返すこともある。このため に，UPは「反復型開発プロセス」と呼ばれる。
●UPにおける基本設計の流れ
１、イベントフローが成果物の中心
UPでは，ユースケースの定義を反復を繰り返しながら徐々に詳細化していく。この作業の前半が，一般的な開発プロセスにおける「要件定義」に当たり，後半が「基本設計」，すなわち「機能要求を仕様化する」作業となる。例えば，銀行口座の取引履歴照会というユースケースのイベントフローを次のように記述したとしよう。
- ユーザーは表示する期間を指定し，ボタンを押す
- システムは，指定された期間の明細と残高の一覧を表示する
このイベントフローを，アクターとシステムとの具体的な相互作用が明確に表現されるよう，次のように詳細化する。
- ユーザーは，ドロップダウンで表示される1日・1週間・1カ月から期間を選択し，［一覧表示］のボタンをクリックする
- システムは，［日付］，［明細］，［残高］について，指定された期間の内容を最大30行まで一覧表示する
イベントフローを中心的な成果物として作成したうえで，補足的な成果物として「画面レイアウト」（出力先が画面ではなく帳票の場合は「帳票レイアウト」， ファイルや他のシステムの場合は「インタフェース仕様」）と「データ項目」を添付し，これらの成果物一式を「ユースケース仕様書」として扱うことで，分析 ／設計での手戻りや再調査を最小化できる。
２、APIを用意したプラットフォーム
基本設計-1:日本IBMの「IBM-DOA」に基づく外部設計フェーズの手順
文章：http://itpro.nikkeibp.co.jp/article/lecture/20070419/268969/?ST=slfsys
DOA（Data Oriented Approach：データ中心型アプローチ）は対象システムの「データの流れ」の把握に重点を置きながら，要件定義や設計を進めていくアプローチである。
★中心的な役割果たすDFD
IBM-DOAで中心的な役割を果たすDFDは，アプリケーションの要求を仕様としてまとめるのに向いており，データを中心に明確であいまいさの残りにくい仕様を作成できる。
●DFD（Data Flow Diagram）の表記法
要件定義では，DFD新論理モデルの中の「データストア」に含まれるデータ項目をリストアップした「データストア記述」，「データフロー」に含まれるデー タ項目をリストアップした「データフロー記述」，「プロセス」の内容をIPO（Input Process Output：入力-処理-出力）形式で記述した「処理機能記述」も作成する。DFD新論理モデルとこれら3つの仕様書を「DFD4点セット」と呼び，外部設計への重要なインプットとなる。
●DFD4点セット
１．複合／構造化設計を知る
複合／構造化設計では，アプリケーションを適切にモジュールに分割する。
(1)モジュール分割の良否を判定する尺度
① 「モジュール強度」
②「モジュール間結合度」
(2)基本的なモジュール分割技法
(1)「STS（源泉／変換／吸収）分割」
STS分割は最も代表的なもので，設計対象のデータフローを詳細に分析して入力処理，変換処理，出力処理のまとまりに分類したうえで，「入力から変換へ」，「変換から出力へ」と大きく変わる個所（これを「最大抽象点」と呼ぶ）でモジュールを分割する
(2)「トランザクション分割」
トランザクション分割は，データフローからトランザクションが分岐する個所を見つけてモジュールを分割する方法である
(3)「共通機能分割」
共通機能分割はプログラムの全体構造から共通機能を括り出して1つのモジュールとして切り出す方法だ。
２、外部設計フェーズの手順
外部設計の目的は，「要件定義書」に基づいて，新システムの「外部仕様」を作成することである。外部仕様とは「システムの外から見える機能やインタフェー ス」のことだ。具体的には，サブシステム構成や各サブシステムの機能仕様，画面や帳票といったユーザー・インタフェース仕様，サブシステム間や他システム とのインタフェース仕様，データベース仕様，移行仕様，運用・障害対策仕様，セキュリティに関する仕様などがある。
（１）サブシステムの定義
個々のサブシステムは異なるチーム，異なるスケジュールで開発されるため，独立して開発できるように分割すべきであり，サブシステム間は限定されたインタフェースでのみアクセスするようにすべきだ。この考え方は，複合／構造化設計と同じである。 これを実現するためには，システマチックな方法が必要となる。IBM-DOAでは，業務の大まかな括りとオンライン処理／バッチ処理などの区分を考慮しながら，高い抽象度のDFD新論理モデルの中でデータフローが最も簡素な（データの流れが最も少ない）境界で切断する。
サブシステムを分割した後は，各サブシステムに名称を付けたうえで，サブシステムごとの「処理機能記述」とサブシステム間のインタフェース仕様（データ項目，発生サイクル，トランザクション量など）を記述する。 サブシステム分割が済んだら，サブシステムごとに「システム機能仕様」を作成する。まず，要件定義で作成したDFD新論理モデルを基に，アーキテクチャな どの物理的な特性を加味した新物理モデルを作成する。具体的には，処理形態（オンライン／バッチ処理など）や処理サイクル（リアルタイム，日次，月次な ど）といった物理的な特性を考慮して，DFD新論理モデルの「データストア」，「データフロー」，「プロセス」を統廃合・分割・追加する。
（３）適用業務フローの作成
システム機能仕様の作成と並行して，「適用業務フロー」を作成する。適用業務フローは，利用部門の処理の流れを業務フローとして記述したものである。この作業は通常，利用部門が主体となって実施する。
（６）システム機能の記述
システム機能仕様の作成，ユーザー・インタフェース設計，データベース設計が終わったら，個々の機能をIPO形式で記述する
以上，日本IBMにおける標準的な外部設計の作業を説明した。要件定義の成果物であるDFDとデータディクショナリをインプットに，標準的かつ定型的な作業で設計を進められることがお分かりいただけただろう。
DOA（Data Oriented Approach：データ中心型アプローチ）は対象システムの「データの流れ」の把握に重点を置きながら，要件定義や設計を進めていくアプローチである。
★中心的な役割果たすDFD
IBM-DOAで中心的な役割を果たすDFDは，アプリケーションの要求を仕様としてまとめるのに向いており，データを中心に明確であいまいさの残りにくい仕様を作成できる。
●DFD（Data Flow Diagram）の表記法
要件定義では，DFD新論理モデルの中の「データストア」に含まれるデータ項目をリストアップした「データストア記述」，「データフロー」に含まれるデー タ項目をリストアップした「データフロー記述」，「プロセス」の内容をIPO（Input Process Output：入力-処理-出力）形式で記述した「処理機能記述」も作成する。DFD新論理モデルとこれら3つの仕様書を「DFD4点セット」と呼び，外部設計への重要なインプットとなる。
●DFD4点セット
１．複合／構造化設計を知る
複合／構造化設計では，アプリケーションを適切にモジュールに分割する。
(1)モジュール分割の良否を判定する尺度
① 「モジュール強度」
②「モジュール間結合度」
(2)基本的なモジュール分割技法
(1)「STS（源泉／変換／吸収）分割」
STS分割は最も代表的なもので，設計対象のデータフローを詳細に分析して入力処理，変換処理，出力処理のまとまりに分類したうえで，「入力から変換へ」，「変換から出力へ」と大きく変わる個所（これを「最大抽象点」と呼ぶ）でモジュールを分割する
(2)「トランザクション分割」
トランザクション分割は，データフローからトランザクションが分岐する個所を見つけてモジュールを分割する方法である
(3)「共通機能分割」
共通機能分割はプログラムの全体構造から共通機能を括り出して1つのモジュールとして切り出す方法だ。
２、外部設計フェーズの手順
外部設計の目的は，「要件定義書」に基づいて，新システムの「外部仕様」を作成することである。外部仕様とは「システムの外から見える機能やインタフェー ス」のことだ。具体的には，サブシステム構成や各サブシステムの機能仕様，画面や帳票といったユーザー・インタフェース仕様，サブシステム間や他システム とのインタフェース仕様，データベース仕様，移行仕様，運用・障害対策仕様，セキュリティに関する仕様などがある。
（１）サブシステムの定義
個々のサブシステムは異なるチーム，異なるスケジュールで開発されるため，独立して開発できるように分割すべきであり，サブシステム間は限定されたインタフェースでのみアクセスするようにすべきだ。この考え方は，複合／構造化設計と同じである。 これを実現するためには，システマチックな方法が必要となる。IBM-DOAでは，業務の大まかな括りとオンライン処理／バッチ処理などの区分を考慮しながら，高い抽象度のDFD新論理モデルの中でデータフローが最も簡素な（データの流れが最も少ない）境界で切断する。
サブシステムを分割した後は，各サブシステムに名称を付けたうえで，サブシステムごとの「処理機能記述」とサブシステム間のインタフェース仕様（データ項目，発生サイクル，トランザクション量など）を記述する。
（２）システム機能仕様の作成
サブシステム分割が済んだら，サブシステムごとに「システム機能仕様」を作成する。まず，要件定義で作成したDFD新論理モデルを基に，アーキテクチャな どの物理的な特性を加味した新物理モデルを作成する。具体的には，処理形態（オンライン／バッチ処理など）や処理サイクル（リアルタイム，日次，月次な ど）といった物理的な特性を考慮して，DFD新論理モデルの「データストア」，「データフロー」，「プロセス」を統廃合・分割・追加する。
（３）適用業務フローの作成
システム機能仕様の作成と並行して，「適用業務フロー」を作成する。適用業務フローは，利用部門の処理の流れを業務フローとして記述したものである。この作業は通常，利用部門が主体となって実施する。
（４）ユーザー・インタフェース設計
（５）データベースの設計（６）システム機能の記述
システム機能仕様の作成，ユーザー・インタフェース設計，データベース設計が終わったら，個々の機能をIPO形式で記述する
以上，日本IBMにおける標準的な外部設計の作業を説明した。要件定義の成果物であるDFDとデータディクショナリをインプットに，標準的かつ定型的な作業で設計を進められることがお分かりいただけただろう。
登録:
投稿 (Atom)
