連載 次世代開発基盤技術“Software Factories”詳解 第4回 フィーチャの実現法とサブジェクト指向パラダイム マイクロソフト株式会社　萩原 正義 2005/07/02
Page1 Page2 Page3

　前回説明した書籍購入サイトの例では、「カタログ管理」フィーチャは、必須フィーチャなので従来の実現方法を適用し、カタログ管理ビジネス・プロセス、カタログ・エンティティのモデルで表現され、「カタログ検索」機能や「カタログ保守」機能を持つドメインクラス、データベース・アクセス・オブジェクト、カタログ・データベース・テーブル、DataGridコントロールなどで構成されるカタログUIフォームで実現する。

　「注文管理」フィーチャも同様に、注文管理ビジネス・プロセス、注文エンティティのモデルで表現され、「注文」ドメインクラス、ショッピング・カート、データベース・アクセス・オブジェクト、注文データベース・テーブル、注文UIフォームで実現する。図3は注文ドメインクラスの例である。

図3 注文ドメインクラスの例

問題領域は、一般的にはビジネス・プロセス、ビジネス・エンティティなどのモデルで詳細化し、OOパラダイムを利用する場合はクラスの識別、オブジェクト間のシーケンス図を経由して論理レベルのドメインクラスが定義される。ドメインクラスには、ユースケースで決まる機能要求の操作が、ドメインクラスを動作させるアーキテクチャを前提に割り当てられる。操作の割り当ては、ドメインクラスのインスタンスであるオブジェクト間での連携の単純性、クラスの拡張性、再利用性などを基準にして決定する。

　可変性の要求を満たすために、選択的なフィーチャを利用する。その実現のための複合化技術の例として、例えば、課金ビジネス・プロセスをBPELを使ったWebサービス連携モデルで実現する場合、すなわち、アーキテクトがBPELを実行可能なBPM製品を再利用してアーキテクチャを構築すると意思決定した場合、選択的なフィーチャである「課金処理」フィーチャの認証方式を「認証Webサービスの呼び出し」で実現し、認証方式の変更の可変性に対応しておく。認証Webサービスの呼び出しの例を図4で示す。

図4 BPELを使ってWebサービスを呼び出す可変性実現の例

課金ビジネス・プロセスを、BPELを使ったWebサービス連携モデルで実現する場合、すなわち、アーキテクトがBPELを実行可能なBPM製品を再利用してアーキテクチャを構築すると意思決定した場合、選択的なフィーチャである「課金処理」フィーチャの認証方式を「認証Webサービスの呼び出し」で実現し、認証方式の変更の可変性に対応しておく。

●要求やアーキテクチャを決定するタイミングに関する一般論

　一般に、アーキテクチャはできるだけ開発プロセスの早い段階に構築し、要求の決定はできるだけ開発プロセスの遅い段階に決定すべきである。なぜなら、アーキテクチャの変更はソフトウェア全体の構造に大きな変更を及ぼし、安定したソフトウェア開発が困難になるからである。

　他方、一般に要求の早期確定は困難であり、要求の変更への柔軟な対応が必要となる。アーキテクトは、このようなアーキテクチャと要求定義の決定時期の相反関係を考慮しなければならない。開発プロセスの中で具体的な非機能要求の詳細が決まる前であっても、システム化対象となる解決領域のドメインで、ある程度のボトルネックとなる非機能要求を判断し、選択すべきアーキテクチャの検証を行い、これと並行して、アーキテクチャ定義の確定を待たずにビジネス・プロセスと概念モデル、ユースケースで機能要求を決めていく。

●Software Factoriesにおける要求やアーキテクチャを決定するタイミング

　以上の一般論に対して、Software Factoriesでは、プロダクト開発開始の段階ですでにソフトウェア・プロダクトラインとしてのアーキテクチャが存在するので、開発対象となるプロダクトのビジネス・プロセスと概念モデル、ユースケースを念頭に置いて、アーキテクチャに必要なフィーチャを取捨選択し、可変性に対する選択肢を決定する。

　可変性に対する実現技術の選択では、前述のように、Webサービスのカプセル化機能でフィーチャを提供してそのサービスへの委譲で実現してもよい。あるいは、フレームワークやコンポーネントが用意するクラスのインターフェイス呼び出しや、カスタム属性の選択などの実現技術に対応付けてもよい。これらの対応付けはプロダクト開発プロセスでのカスタマイズで可変性を実現する場合を除き、アーキテクトがプロダクトライン開発プロセスで大半の可変性を実現し提供済みなので、プロダクト開発に従事する開発者は実現技術の開発を意識する必要性は少ない。

　以下に、可変性の要求に対する選択的なフィーチャの実現技術をいくつか見ていこう。

●.NET Frameworkのカスタム属性による可変性の実現

　次のリスト1は、.NET Frameworkが用意したカスタム属性を選択することで可変性を実現している例である。

[PrincipalPermission(SecurityAction.Demand, Authenticated=true)] public class Foo {   public void Bar()   {     // 認証が必要な呼び出し   }   public static void Quux()   {     // 認証が必要な呼び出し   } }

リスト1 .NETのカスタム属性による可変性実現の例

可変性に対する実現技術として、カスタム属性を選択した例である。カスタム属性「PrincipalPermission」を選択することで、.NET Frameworkの認証機能を再利用している。プロダクト開発プロセスにおけるカスタマイズで可変性を実現する場合を除き、アーキテクトがプロダクトライン開発プロセスで可変性を実現し提供済みなので、プロダクト開発に従事する開発者は実現技術の開発を意識する必要性は少ない。

●.NET Framework 2.0のパーシャル・クラスによる可変性の実現

　より先進的な例としては、図5の.NET Framework 2.0が提供するパーシャル・クラスで可変部分を実現し、元のドメインクラスへコンパイル時にマージを行う方法がある。

図5 .NET Framework 2.0が提供するパーシャル・クラスによる可変性実現の例

パーシャル・クラスは別物理ファイルで同一実装クラス名を定義することで、コンパイル時に1つの実装クラス定義としてマージされる複合化技術である。パーシャル・クラスにより、カスタマイズが必要な変化する部分（可変性）と変化しない部分（共通性）を分離可能で、カスタマイズ部分（可変性）に対するコード生成部分（共通性）の上書きが生じない。

●アスペクト指向言語による可変性の実現

　あるいは、図6に示したアスペクト指向言語の機構を使い、アスペクトとして可変部分を実現し、元のドメインクラスへコンパイル時にウィービングを行う方法も存在する。

図6 アスペクト指向言語を利用したアスペクト・ウィービングによる可変性実現の例

アスペクトとは、クラス1とクラス2のような複数クラスに横断的な関心（＝ひとまとめに取り扱うことができる概念・テーマのこと）をクラスから分離して定義するモジュール化技術である。横断的な関心が可変性を持つ場合、それらをコンパイル時に起こるアスペクト・ウィービングまで分離して管理することで、分離した共通性と可変性の複合化技術として利用する。現在、アスペクトはロジック・コード（機能要求）クラスに対する横断的な非機能要求として利用されることが多いが、可変性の観点では非機能要求だけに限定して利用する理由はない。将来は、非機能要求以外の多くの可変性に対する複合化技術として利用されるだろう。

　

INDEX
	次世代開発基盤技術“Software Factories”詳解
	第4回 フィーチャの実現法とサブジェクト指向パラダイム
	1．フィーチャ・モデルによるアーキテクチャの構築
	2．フィーチャ・モデルによる可変性の実現
	3．可変性を実現する先進的な開発手法「サブジェクト指向パラダイム」

　

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

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