連載 次世代開発基盤技術“Software Factories”詳解 第7回 Software Factoriesによる可変性を管理したモデル駆動型開発の例 マイクロソフト株式会社　萩原 正義 2005/10/12
Page1 Page2 Page3 Page4

◆ビューポイントの設計

　本連載の「第5回 ビューポイントによる関心の分離と開発プロセスの実現」で紹介したビューポイントはSoftware Factoriesの基盤技術の中で非常に重要であるにもかかわらず、理解が難しいという認識を筆者は持っている。

　アーキテクチャは関心の分離に従って構築されることが多いが、Software Factoriesではこれをビューポイントに分離して構築する。同様に、要求と開発プロセス全体もビューポイントに分割されるので、ビューポイントの理解は不可欠である。

　ユースケースがアクターから見たシナリオ・ベースの要求モデルであるのと同様に、ビューポイントはシステムのステークホルダーから見た要求モデルの一種である。

　ビューポイントは、ステークホルダーの視点の違いから生まれる要求間の一貫性のなさ、矛盾、冗長性、仕様の断片化などの問題に対応する。ドメインとシステムの断片的な知識、知識の適切な表現方法、そのビューポイントでの開発のための開発サブプロセスの知識を持ち、独立に管理可能である。従って、複数の独立したビューポイント間で一貫性を管理する大きなフレームワークが別に必要となるが、それがSoftware Factoriesの「Factoryスキーマ定義」に対応した開発ツールである。

●ビューポイントを構成するもの

　ビューポイントは、一般的には、

• 関心のドメイン（群）
• 表現のための記法（Software FactoriesではDSLモデル）
• この記法で記述される仕様
• 開発活動と戦略や開発プロセスの定義（Software Factoriesでは「微視的な開発プロセス」と呼ぶ）
• 開発履歴

から構成される。

　これを理解するために、ドメインとして図書館における図書の貸し出し業務を考えてみよう。

　この場合、ビューポイントの記法は、クラス定義と関係の属性名、属性型、属性値により定義される記法（構文）である。この記法で記述される仕様は、図書館の貸し出し業務における、図書館、職員、借り手、カタログのクラス構造である。

　また、開発プロセス定義は、クラス構造の構築のための各クラスの追加と削除、クラス間の関係の接続と切断などの操作と、クラス構造のすべての接続、クラス間の親子関係、属性名の重複などの一貫性をチェックする。

　これら一般的定義に加えて、Software Factoriesのビューポイントは以下の表1の可変点の定義を持つ。

可変点	場所	定義	バインディング・タイム	バインディング所有者	バインディング機構
ビルディング・ブロックAの変更	フィーチャBの構成コンポーネント	フィーチャBの提供機能のアルゴリズムの変更	設計時	アーキテクトD	オーバーローディング
サービス1の追加	フィーチャCのサブフィーチャ	フィーチャCのサブフィーチャの追加	コンパイル時	アプリケーション設計者E	パーシャル・クラス
表1 Software Factoriesにおけるビューポイントの可変点定義の例
この表で、「可変点」はフィーチャの実現におけるアルゴリズムの変更、状態値の追加などの内容、「場所」は可変点が定義されるモデルの識別やその部位、「定義」は可変点の説明や理由、「バインディング・タイム」は可変点の実現法が決定される開発ライフサイクルのフェイズ（設計時、コンパイル時、リンク時、実行時など）、「バインディング所有者」はこの可変点を提供する担当者やその役割、「バインディング機構」は可変点を実現する機構（C++など特定開発言語に依存する機構、デザインパターンなど実装に非依存な機構など）を定義する。この例では、図1の説明にある、縦のビルディング・ブロックと横のサービスの変更に対する可変点の定義をしている。可変点の定義はプロダクトライン分析の解決領域モデリングで行われる。

　可変点の定義はC++のマルチパラダイム設計の形式に類似する*3。可変点の定義はプロダクトライン分析の解決領域モデリングで行われる。

*3 「オージス総研 −マルチパラダイムデザイン」を参照のこと。

●ビューポイントの実際の設計例

　ビューポイントの実際の設計例として、本連載の「第5回 ビューポイントによる関心の分離と開発プロセスの実現」では、EA（Enterprise Architecture）のアーキテクチャと開発ライフサイクルの各フェイズで分類したビューポイント定義である、ビジネスのプロセスとエンティティ、UI（ユーザー・インターフェイス）プロセス、サービス／メッセージ／アプリケーション・エンドポイント、論理サーバ／ホスト・アプリケーションなどを取り上げて説明した。

　またそのほかに、開発ライフサイクルの各フェイズに、ドメインに特化したアプリケーション・アーキテクチャのモデル群を組み合わせた例も存在する（図2）。

図2 医療における標準仕様HL7に基づくアプリケーション構築用のビューポイント定義例（参考文献「A Software Factory Approach To HL7 Version 3 Solutions」からの引用）

Application Architecture Viewpointでは以下の成果物が提供される。HL7が定義する、 ・ 協調モデル（HL7 Collaboration Model） ・ メッセージタイプ仕様（HL7 Message Type Specification） ・ WSDLアプリケーション・ロール（WSDL by HL7 Application Role） ・ 協調ポート・モデル（HL7 Collaboration Port Model） ・ 協調ポート・デザイナ（HL7 Collaboration Port Designer）とコード・ジェネレータ（HL7 Collaboration Port Code Generator） ・ コード・テンプレート（Code Templates） ・ 設計ガイドライン（Design Guidelines） また、Implementation ViewpointにはHL7協調ポート・メッセージ・フレームワーク（HL7 Collaboration Port Messaging Framework）が提供される。このアプリケーション・アーキテクチャとWebサービスを基盤としたアプリケーション開発では、汎用の問題領域デザイナと解決領域デザイナで分析し、Orchestration ViewpointでWebサービス間のビジネス・プロセスを設計し、実装した成果物はDeployment Viewpointで配置する。

　この2つの例は、開発ライフサイクルのフェイズによる分割をビューポイント定義の基本としている。しかし別の定義としては、特定の関心のドメイン（群）を専任に開発するため、その開発ライフサイクル全体を1つのビューポイントで定義する、いわゆる、ソフトウェア・セル生産方式*4の考え方をSoftware Factoriesと組み合わせることも可能である。

　ソフトウェア・セル生産方式は、Software Factoriesが目指す工業化において、大量生産型のプロダクトラインに加えて、少量多品種の生産を可能とするための補完技術となるだろう。

*4 アジャイルプロセス協議会でWG（ワークグループ）を発足し、方式検証を進めている（詳しくは「IT Pro：日本のソフト開発力向上狙い、『ソフトウエア・セル生産』の研究会が始動」を参照のこと）。

　

INDEX
	次世代開発基盤技術“Software Factories”詳解
	第7回 Software Factoriesによる可変性を管理したモデル駆動型開発の例
	1．フィーチャ・モデルによる可変性管理
	2．ビューポイントの設計
	3．パターン指向のアーキテクチャ構築
	4．付録：Software Factoriesの開発手順

　

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

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