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

Page1 Page2 Page3

Back Issue

1 ソフトウェア工業化を目指して 2 開発手法「ソフトウェア・プロダクトライン」とは？ 3 長期的な要求を定義するフィーチャ・モデル 4 フィーチャの実現法とサブジェクト指向パラダイム

　ITシステムに対する要求の多様化、アーキテクチャの大規模化と複雑化に対応するために、現実世界やシステム化対象をさまざまな角度から表現する方法が必要である。今回は、ZachmanフレームワークやUMLの各種ダイアグラムなどにも見られる、システム表現の体系化基盤技術の1つ、「ビューポイント」を扱う。

　ビューポイントは、システム表現モデルの適切な利用コンテキストを定義する視点である。これは、ITシステムのステークホルダー（利害関係者）に応じた適切なコンテキストでシステム表現を行うために必要な、システム表現モデルの体系化の枠組みを定義する。

　アーキテクトが、例えばUMLを利用してシステム構築をする場合、「どのUMLダイアグラムをどの順序で定義していく必要があるか」を決める枠組みが開発方法論である。アーキテクトは経験則や採用する開発方法論で定められた手順に従う。ビューポイントはこのような経験則やプラクティスに従う部分をできるだけ明確に定義する枠組みを用意し、ソフトウェア開発に工学的アプローチを適用していこうとするコンセプトである。

◆アーキテクチャ記述の推奨プラクティス

　ソフトウェア・アーキテクチャにはさまざまな定義が存在する。その理由はアーキテクチャを表現する方法が1つに決まらないからである。アーキテクチャ自体が複数の角度から表現を組み合わせないと厳密な定義ができないことも理由である。

　建築物を設計する場合、通常3方向から見た視点での図面が必要である。また、詳細な構造図、配水管や電気配線図、素材や部品表など多くの付帯的な図面も必要である。視覚的に優れた観点では、立体的な3次元図面もあればなおいいだろう。このように完成すべき物理的な建築物は1つであっても、それを適切に表現するための図面は1つではない。

　それでは、どの図形を使うか、複数の図形をどのように組み合わせるかを明確に規定するにはどうすべきだろうか。それぞれの図形はその図形で表現したい関心事だけに限定し、そのほかの関心事は大胆に無視すればよい。例えば、地下鉄路線図は地下鉄の経路だけを扱い、地上に存在する道路や建物の情報を扱わない。これは、一種の関心の分離である。

　同様に、アーキテクチャの表現でも、構造を扱う表現、振る舞いを扱う表現、配置を扱う表現などが存在する。このような関心の分離をし、それぞれの関心で適切なダイアグラムを適用することが求められる。そのために、UMLでは多くのダイアグラムが用意され、Zachmanフレームワークでは多くの関心を体系化する枠組みが決められている。

　これらの技術背景に沿い、関心の分離の原則とステークホルダーの視点を考慮してアーキテクチャ記述を定義しているのが、IEEE std 1471-2000アーキテクチャ記述の推奨プラクティスである。

●IEEE std 1471-2000アーキテクチャ記述の概念モデル

　それでは、まずこのIEEE std 1471-2000のアーキテクチャ記述を見ていこう。

図1 IEEE std 1471-2000のアーキテクチャ記述の概念モデル

モデル図で記されているキー・コンセプト（StakeholderやConcernなど）の意味については後に掲載する表1を参照してほしい。この概念モデルを簡単に説明すると、次のようになる。 Stakeholder（ステークホルダー）のConcern（関心）の表現は、それを表現するModel（モデル）定義を規定するViewpoint（ビューポイント）を選択して行う。すなわち、 1. Stakeholder（ステークホルダー）は1つ以上のConcern（関心）を持ち、それらのConcernを表現するためのViewpoint（ビューポイント）を選択する。 2. Viewpointの選択は、Concernを表現するModel（モデル）定義の規定を与えるかどうかを判断して決定する。このViewpointはConcernの表現に適切な関心の分離を与えるLibrary Viewpoint（ライブラリ化されたビューポイント）から選択する。複数のMission（目的）を持ち、Environment（制約条件）を持つSystem（システム化対象）に対してArchitecture（アーキテクチャ）を構築する。構築されるArchitectureはArchitecture Description（アーキテクチャ記述）で定義される。アーキテクチャの定義には、定義をしたアーキテクトが説明責任を持つRationale（理由付け）が伴う。ここで、 3. アーキテクチャ（Architecture）は、複数のModelを使ったView（ビュー）として表現される。 4. さらに、複数のViewでアーキテクチャは記述され（Architectural Description）、Model定義の規定を与えるViewpointによってViewは関心の分離の原則に従う。 5. Viewpointによる関心の分離はStakeholderの多次元的な要求に枠組みを与える。 Software Factoriesは、この一連のViewpointの枠組みを開発基盤技術に適用している。

　図1はIEEE std 1471-2000のアーキテクチャ記述の概念モデルを定義している。

　この図では、キー・コンセプトとその関係をメタモデル表現として定義している。このモデル自体は、あるシステムが単一アーキテクチャで構築されることも、1アーキテクチャが単一アーキテクチャ記述で定義されることも仮定していない。すなわち、システムが複数アーキテクチャ、例えば、パイプラインとイベント駆動型アーキテクチャで構築されていてもよく、また、それぞれのアーキテクチャの記述法を統一しなければならない強制力も持たない。

　図1のキー・コンセプトをまとめたのが次の表1である。

キー・コンセプト	意味
Stakeholder： ステークホルダー	システムのアーキテクチャの利害関係者。例えば、アーキテクト、プログラマ、システム運用者、データベース管理者、エンドユーザー、経営者、プロジェクト・マネージャ、ビジネス分析者など。それぞれが別の関心を持ち、互いの要求に矛盾や不整合が存在する
Concern： 関心	機能要求と非機能要求、静的な構造と動的な振る舞い、概念／論理／物理レベルの観点、表示と情報、セキュリティや性能、サービス内容とサービス配置など、開発にかかわる要素、条件を分割して考慮する場合のスコープ
Viewpoint： ビューポイント	ビューを記述、分析するためのモデル（ビューポイント言語）と、モデルに適用するモデリング手法、分析手法などの規定。アーキテクチャ記述では1つ以上のビューポイントを選択する
View： ビュー	（複数の）ステークホルダーの（複数の）関心から見たシステム全体の表現。1つ以上のモデルで表現される
Model： モデル	記法。例えば、UMLダイアグラム、DSLなどの表現。1つ以上のビューに属することもある
表1 IEEE std 1471-2000のキー・コンセプト（抜粋）

　例えば、Webアプリケーションで構築される書籍購入サイトは、アーキテクトの関心として、Webサーバ上のUIプロセス、Webページ・レイアウト定義、ビジネス・ロジックのコンポーネント構造、ビジネス・ロジックのオブジェクトのシーケンス（振る舞い）、コンポーネント配置、データアクセス層、データベースのテーブル定義などから構築される。

　この場合では、UIプロセスなどがモデルで、これらのモデルを集めてアーキテクチャが記述される。モデルは複数のステークホルダーの関心の表現にかかわり、例えば、ここでのコンポーネント配置のモデルは、アーキテクトの関心のモデルとしてだけでなく、システム運用者の関心のモデルとしても利用される。

◆ステークホルダーによる関心の分離

　ここでもう少しステークホルダーの関心の表現を見ていこう。図2はステークホルダーによる関心の分離の例である。この図では、それぞれのステークホルダーの役割に応じて、必要とするアーキテクチャ記述の表現法が異なることを示している。

図2 ステークホルダーによる関心の分離

ステークホルダーの役割に応じて関心は異なり、その関心を表現するモデルも異なる。この例では、ビジネス分析者の関心であるビジネス要求を概念レベルのユースケース・モデルで表現する。同様に、プログラマは実装すべきコードの論理モデルを実装で活用する。データベース管理者は管理対象のデータベースのデータ・モデルからデータ構造を把握する。

　以下に挙げるように、ステークホルダーの関心はさまざまな観点から分類できる。

（1）関心を「静的構造と動的振る舞い」で分類すれば、静的構造には、アーキテクトの関心を表現するビジネス・ロジックのコンポーネント構造や、システム運用者の関心を表現するコンポーネント配置が含まれる。また、動的振る舞いには、アーキテクトの関心を表現するビジネス・ロジックのオブジェクトのシーケンス図や、システム運用者の関心を表現するメッセージ連携が含まれる。

（2）関心を「情報ドメイン」で分類すれば、アーキテクトの関心を表現するデータベース・テーブル定義や、ビジネス分析者の関心を表現する情報エンティティが関心を表現する。

（3）関心を「論理レベルと物理レベル」で分類すれば、論理レベルには、アーキテクトの関心を表現するビジネス・ロジックのコンポーネント構造が含まれ、物理レベルには、データベース管理者の関心を表現するデータベース定義が含まれる。

　これら3種類の関心の分類法は、それぞれ、

（1）UMLダイアグラムの静的／動的モデル（＝静的構造と動的振る舞い）

（2）EA（Enterprise Architecture）のビジネス／情報／アプリケーション／インフラストラクチャ（＝情報ドメイン）

（3）開発ライフサイクルの概念／論理／物理レベル

で関心を分類し、ステークホルダーの関心をモデル選択して表現する例である。

　関心の分類法はこれだけに限定されず、アーキテクチャ記述に適切な関心を、適切な分類法を基準に選択していればよい*1。この分類法はアーキテクチャ記述に必要なモデルの組み合わせを規定するビューポイントが決める。（次のページへ続く）

*1 例えば、Philippe Kruchten氏の“4+1”ビュー・モデル（「The 4+1 View Model of Architecture」、IEEE Software, vol. 12, No. 6、November 1995、pp. 42-50）やISO/IEC 10746-2の「Reference Model for Open Distributed Processing」（RM-ODP）は、別の分類法を定義している。

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

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

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