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

前回の補足です。

アスペクト指向がソフトウェアプロダクトラインに本質的に親和性を持たない理由は、ソフトウェアプロダクトラインのアーキテクチャの拡張点には、拡張点に応じて「異なる」拡張コードを導入しなければいけないからです。一方、アスペクトの定義は、この拡張点をjoin pointで定義する場合、「同一」のadviceのコード定義を導入することになります。これでは、ソフトウェアプロダクトラインのプロダクトに応じた拡張点の拡張コード、プロダクトのバージョンに対する拡張コードの進化がうまく表現できません。

Software Factoriesの教科書には、factoryの実装技術としてアスペクト指向コンポーネントが有望ととられるような記述がありますが、厳密には現在のAOPは適切な実現法とは言えません。Microsoft社がAOPに消極的である理由は優先度の問題もありますが、このあたりに理由があります。

歴史的にみれば、AHEADなどソフトウェアプロダクトラインと親和性を持つFOP（Feature Oriented Programming Language）は、mixinを拡張法に持ちます。mixinの方がアスペクトに比べて、base クラスに対する局所的な拡張性、バージョン管理に対して有効な技術と考えられるからです。また、AHEADは直交する関心を代数学的に扱うことで、特性の複合化の組み合わせ数を減らすためのプラットフォームとなっています。正確にいえば、直交する関心の個数（次元）をN、各関心のとりうる実現法の数をkとすると、O(N**k)がO(N*K)になります。

さて、mixinとアスペクトを組み合わせて相補的にソフトウェアプロダクトラインを構築する方法はないでしょうか？

アスペクトが持つpointcut定義を使い、アーキテクチャの拡張点をjoin pointで定義します。次に各join pointではadviceを使わず、間接的にmixinを呼ぶようにします。こうすれば双方の利点を得ることができます。これにより、特性間の依存関係は、特性を含むシナリオをサポートするユースケーススライス、つまり、アスペクト間の依存関係となり、最終的にmixinの依存関係になります。つまり、mixin間の複合化の制約関係になります。

こうしてみると、ソフトウェアプロダクトラインに有効な複数の複合化アーティファクト（設計モデルやパラダイム）を考えていくと、技術が複雑化することがわかります。まして、それらの設計が正しく行われるための分析プロセスなど方法論自体が複雑化します。これをドメインエンジニアリングで行うアーキテクトの技術力いかんにソフトウェアプロダクトラインの成功がかかわるということになります。

私はこうした複雑化した技術は好きではありません。単純化こそ有効な手段と考えています。しかし、企業システムの領域に限っても、ドメインをストレートに表現するドメインモデルは、ビジネス構造をできるだけ忠実に表現しているようでも、そこには多くのビジネスの振る舞い、シナリオが暗黙のうちに仮定されていることは理解しなければなりません。つまり、構造的にみれば、抽象化が可能な比較的単純な表現になっているかもしれませんが、ビジネスルールや要求の検証プロセス、状態遷移などが隠されていて、本質的にはかなり複雑なはずです。ですので、ドメインモデルと使うかどうかによらず、現実世界のシステムはかなり複雑で、それを体系化するソフトウェアプロダクトラインも必然的に複雑さを扱う必要が生じます。その結果、抽象化や単純化のための技術の適切な選択が重要となります。AHEADの代数学的アプローチ、AOPのpointcut言語、mixinの複合化技術、アスペクト指向分析設計など、技術の採用が正しいかどうかの判断を今一度考える必要があります。