ソフトウェアプロダクトラインにアスペクト指向は有効か？

ソフトウェアプロダクトラインの開発ではアーキテクチャに適切な拡張性を持たせ、要求に応じてアーキテクチャを再利用しつつ、その拡張性を使い個別の可変性に対応していくことが求められます。

コアのアーキテクチャの開発は、オブジェクト指向を使ったフレームワーク開発に代表されるように、アーキテクチャスタイルを考慮して進められます。拡張性の実現法は、用いるパラダイムに応じて多様な選択肢がありますが、典型的にはコンポーネントの接続を用いた設計がとられます。ここでいうコンポーネントは.NETアセンブリなどの特定プラットフォームの物理レベルのコンポーネントを指すのではなく、UMLのコンポーネントで表現される論理レベルでインターフェイス定義を持つモデルをいいます。このモデルをオブジェクト指向を用いて実現するならば、Open-Closed Principleに従う、複数のクラスで構成される物理的配布単位とみなすことができます。しかし、ソフトウェアプロダクトラインの可変性の観点では、こうした静的タイプだけによる実現法では限界があります。より一般的にはUMLパッケージを用いる方法があります。UMLパッケージは物理的配布単位で得られる変更の一貫性の単位を論理レベルで表現しているとみなせます。トランザクションスコープといってもいいでしょう。これにはクラスのような静的な構造だけでなく、シーケンス図や状態遷移図のような動的な振る舞いを含むことができます。こうして複数のモデルをまとめて1つの一貫性のある変更単位を定義するのがUMLパッケージです。内部にあるモデルが論理レベルの表現であるのなら、UMLパッケージ全体として実装に依存しない定義が可能となります。UMLパッケージはパラメータを取ることができます。たとえば、クラスのフィールド定義、シーケンス図の操作の一部をパラメータ化することができます。こうして、UMLパッケージを定義しておき、その実現法を変更の一貫性を含めて、モデル変換やモデル言語のコード生成に任せることで、可変性への対応をモデルベースで行うことができます。
たとえば、UMLパッケージとして最近注目を浴びているのが、Jacobson氏のユースケーススライスです。ユースケーススライスとは、その名前のとおり、ユースケースに関する追跡性のあるモデルです。ユースケースの実現をオブジェクト指向で行うと、クラスに横断的な構造となるので、アスペクト指向を使い横断的な関心としてユースケースを表現します。ただし、AOPとは異なりプログラミング言語の物理レベルではなく、概念、論理レベルを主に対象としたアスペクト指向の表現です。

さて、ソフトウェアプロダクトラインの可変的な特性をユースケースとして表現し、それをユースケーススライスを使ってモデル駆動型で実現しようとする試みは、一見すると非常に有望な手段と一頃は思われていました。しかし、研究が進むにつれて多くの技術制約や問題が明らかになり、現在はあまり有力な手段とは思われていません。私も1年ほど前、こうした検討をかなり進めましたが、実現可能性という点で採用しませんでした。

現在のこの分野の動向は、AOSD Conference 2007の動向などから、2つの方向性を持つと考えています。

• 1つは、ソフトウェアプロダクトラインの特性と親和性のある形に実現法を変えてアスペクト指向の技術を適用していくこと。たとえば、アスペクトはベースクラス（OO）に対して横断的にコードの挿入やインターセプトを行うために、アスペクトとベースを関係づけるポイントカット言語が1対nの関係を持つ特徴があります。一方、ソフトウェアプロダクトラインでは、1つの可変点に対して要求に応じて複数のバージョンのコンポーネントやパッケージが対応づけられるので、パッケージとベース（可変点）はn対１の関係を持ちます。これは、関係づけにおいて本質的な違いで、アスペクト指向をソフトウェアプロダクトラインへ適用するうえで大きな制約となります。このためアスペクト指向はフィーチャ指向に置き換える必要があります。
• もう1つは、モデル駆動型開発に用いるDSL自体にアスペクト指向を入れるというアプローチです。これをDomain Specific Aspect Language（DSAL）といいます。たとえば、トランザクションモデル、例外処理などに特化したDSLの開発での適用が考えられます。こうして汎用DSLに対して、そのDSLを補完するDSALを用意して可変性に対応します。