連載 次世代開発基盤技術“Software Factories”詳解 第5回 ビューポイントによる関心の分離と開発プロセスの実現 マイクロソフト株式会社　萩原 正義 2005/08/03
Page1 Page2 Page3

◆ビューポイント

　表2は、IEEE std 1471-2000のアーキテクチャ記述よりも分かりやすく簡略化した、ビューポイント、ビュー、モデル間の関係を示している。

		EA（エンタープライズ・アーキテクチャ）
		ビジネス	情報	アプリケーション	インフラストラクチャ
開発ライフサイクル	概念レベル	・ユースケース ・シナリオ ・ビジネス ・ゴールと目的	・ビジネス・エンティティとその関係（＝静的モデル）	・サービス分割（＝静的モデル） ・ビジネス・プロセス（＝動的モデル）	・サービス配布 ・QoS（Quality of Service）戦略
	論理レベル	・ワークフロー・モデル ・役割主義	・メッセージ・スキーマ ・文書仕様	・サービス相互作用（＝動的モデル） ・サービス定義 ・オブジェクト・モデル	・論理サーバ・タイプ ・サービス・マッピング
	物理レベル		・データベース・スキーマ ・データアクセス戦略	・詳細設計 ・インフラ技術依存設計	・物理マシン ・導入済みソフトウェア ・ネットワーク・レイアウト
表2 ビューポイント、ビュー、モデル間の関係
ステークホルダーの持つ関心の表現に適切なモデルを選択するための枠組みをビューポイントが与える。この例では、開発ライフサイクルの概念／論理／物理レベルと、EAのビジネス／情報／アプリケーション／インフラストラクチャの組み合わせ（＝「ビューポイント」の枠組み）で関心の分類を行い、この枠組みの各セル（＝「ビューポイント」）の中にステークホルダーの持つ関心の表現に利用可能な「モデル」を当てはめている。アーキテクチャ記述は、ステークホルダーの関心に応じて、ビューポイントの枠組みからこれらのモデルを選択して表現する。アーキテクチャのさまざまな角度からの表現（ビュー）はビューポイントの枠組みの規定に従う。アーキテクチャ記述の表現が適切になるように、ビューポイントは有効な関心の分離の枠組みを提供しなければならない。ビューポイント定義を決定するのはソフトウェア・プロダクトラインを提供するアーキテクトの責務である。

　ここでは、開発ライフサイクルの概念／論理／物理レベルと、EAのビジネス／情報／アプリケーション／インフラストラクチャの組み合わせ（＝「ビューポイント」の枠組み）として関心を分類している。

　アーキテクチャ記述に関する各ステークホルダーの関心を表現する「モデル」*2は、この分類に基づいて選択すると考えると分かりやすい。例えば、ビジネス分析者の関心は、概念レベル−ビジネスと論理レベル−ビジネスによる分類を利用して表現可能である。別の例（表2では直接的には表現されない）としては、論理的3階層アプリケーション・アーキテクチャでは、UI階層、ビジネス・ロジック階層、データ階層から構成され、それらに関連するビューポイント定義を選択してモデルを決定する。

*2 コードや構成定義など開発成果物も含まれる。

　表の各セルがビューポイント定義である。また、各セルに入った項目がモデルである。セルには一般に複数個のモデルが存在する。この表からは、アーキテクチャ記述のために用意すべきビューポイント定義は、関心の分類法に依存しているといえる。

●ビューポイントの多次元化とその問題点、アスペクトの抽出

　ビューポイント数は、表2の場合は3×4＝12であるが、別の分類法として、例えば、静的／動的、あるいは、共通性（不変性）／可変性などの分類を用いれば、セル数は多次元の組み合わせになり、より多くのビューポイントが定義されることとなる。

　しかし、関心の分類法の組み合わせを増やすことで、ビューポイントが多次元化、あるいは、詳細化し、その数が増大することは必ずしも好ましいことではない。分類法が多次元化すると、1つの分類法が別の分類法に対して横断的になったりするためである。

　例えば、表2で「概念レベル−アプリケーション」のビューポイントは、静的モデルの「サービス分割」と動的モデルの「ビジネス・プロセス」から成っている。

　このビューポイントでの静的／動的の分類法での次元では、静的モデル「サービス分割」は、「概念レベル−情報」のビューポイントでの静的モデル「ビジネス・エンティティとその関係」と、また動的モデルは、「論理レベル−アプリケーション」のビューポイントでの動的モデル「サービス相互作用」と、それぞれセルをまたがったくくりでグループを形成して横断的となる。

　このように、ソフトウェア開発では、横断的な関心はどのドメイン、どの抽象レベルにも存在する。これが、「横断的な関心を扱うアスペクト指向パラダイムが、AOP（Aspect-Oriented Programming）というプログラミング・パラダイムにとどまらず、潜在的に有力な技術である」と見なされる理由である。ビューポイント定義はソフトウェアのアスペクトを抽出する基盤ともいえる。

●部品表として活用するビューポイント定義

　さらに、表2のビューポイント定義は、複数のプロダクト生産に利用される一種の部品表と見なせる。すなわち、ソフトウェア・プロダクトラインの観点から、各セルはモデルに加えて、その視点で必要となる開発成果物すべてを含めたセルと見なし、全体が複数のプロダクト生産のための部品表と見なせる。

　例えば、DSL、パターン、フレームワーク、ツール、その視点での微視的な開発プロセス などの開発成果物の部品を各セル（ビューポイント）は管理できる。IEEE std 1471-2000のビューポイントは抽象的なモデルしか規定していないが、これをSoftware Factoriesは実現レベルで拡張したといえる。

　ビューポイントを定義し提供するのは、ソフトウェア・プロダクトラインを開発するアーキテクトの責務であり、ステークホルダーが適切なモデルを選択しプロダクト生産プロセスに関与できるようにする。いい換えれば、ビューポイントを定義し、そのセルに含まれるモデルとそのほかの開発成果物を用意することで、ソフトウェア・プロダクトライン開発基盤をプロダクト生産プロセスに提供することがアーキテクトの責務ともいえる。

　例えば、「論理レベル−情報」のビューポイントでの「メッセージ・スキーマ」モデルでは、プロダクト生産のシステム設計者向けにXMLスキーマ言語を用いた設計モデル構築用のDSLの提供がアーキテクトの責務の1つとして挙げられる。

●ドメインとビューポイントの観点から見た既存のフレームワーク

　次に、既存のフレームワークやコンポーネントを、ドメイン（※主に解決領域のドメイン）およびビューポイントの観点で再確認してみよう。

　図3は、ドメイン、ビューポイント、DSL、フレームワークの関係の例を示している。

図3 ドメイン、ビューポイント、DSL、フレームワークの関係の例

既存のフレームワークは必ずしもドメイン依存に作られていないので、フレームワークとドメインの関係は多対多である。システムのアーキテクチャを構成する各ドメインには、そのドメインの関心を表現する複数のDSLが提供される。DSLモデルは、そのドメインのフレームワークだけでなく、ほかの依存関係があるドメインのフレームワークに対してもカスタマイズする機能を持つ。ステークホルダーの関心は、関心が分離されたビューポイントに従って表現されるが、関心の分離は分類法によっては必ずしもドメインを単位としていないので、図のビューポイント1のように複数のドメインにまたがるビューポイントに従ってDSLモデルが選択される場合がある。

　フレームワークとドメインの関係には、1フレームワークが1ドメインをカバーする場合（図3のドメイン1）だけでなく、1フレームワークが複数ドメインをカバーする場合（図3のフレームワーク1）、あるいは、複数フレームワークが1ドメインをカバーする場合（図3のドメイン2、3）が存在する。

　例えば、ドメイン1をビジネス・サービス層、ドメイン2をビジネス・エンティティ層、ドメイン3をデータ層と想定してみよう。

　この場合、ビジネス・サービス層のドメイン1とビジネス・エンティティ層のドメイン2にまたがるフレームワーク1はビジネス・サービスとビジネス・ルールの双方を処理する。このとき、DSL1はビジネス・サービスのオペレーションを定義する。

　また、ビジネス・エンティティ層のドメイン2では、ビジネス・ルールを定義するDSL2とビジネス・エンティティを定義するDSL3を使ってモデル化する。ビジネス・ルールは、ビジネス・サービスへの制約を与えてフレームワーク1をカスタマイズする機能と、ビジネス・エンティティに制約を与えてフレームワーク2をカスタマイズする機能を持つ。これらのドメイン1とドメイン2ではビューポイント1の定義が関連するすべての開発成果物の管理を行う。

　ドメイン3はデータ層であり、（DB）定義をするビューポイント2が開発成果物を管理する。データベース・アクセスのDAO（Data Access Object）フレームワーク3とデータベース・サービス・フレームワーク4から成り、DSL4はデータベース・スキーマ定義をするモデルである。フレームワーク3は、ビジネス・エンティティDSL3とデータベース・スキーマ定義DSL4の双方からカスタマイズされて、オブジェクトとデータベース・スキーマ定義との対応関係を行う。

　以上のことから、このシステムのアーキテクチャ全体は、ビジネス・ロジック処理を管理するビューポイント1とビジネス処理に必要なデータベース・リソースを管理するビューポイント2で記述されることが分かる。

　既存のフレームワークやコンポーネントなどの開発成果物は、DSLに対するカスタマイズのためのホットスポットを、既存のAPIやオブジェクト・モデルなどのプログラミング・モデルで提供する。これにより、既存のフレームワークやコンポーネントは、ビューポイントによる関心の分離がなされたシステム表現と開発成果物の管理を組み合わせることにより、アーキテクチャ記述に関するステークホルダーの多次元の関心をサポートできる開発基盤となる。（次のページへ続く）

INDEX
	次世代開発基盤技術“Software Factories”詳解
	第5回 ビューポイントによる関心の分離と開発プロセスの実現
	1．アーキテクチャ記述の推奨プラクティス
	2．ビューポイントとは？
	3．ビューポイントを用いたプロダクト生産プロセス

「次世代開発基盤技術“Software Factories”詳解」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）