アスペクトが横断的なモジュール化を実現
ここまで述べてきたように，1対1の原則を考慮することは非常に重要である。しかし実際にはほとんど実現できていない。これを解消するために，複数のドメインクラスに横断的なモジュール化を施す技術を用いてエンドユーザーの要求を表現することが求められる。
本来，ドメインクラスは世の中の現象（インスタンス）を体系化した概念の構造で，それをオブジェクト指向のパラダイムに基づいてシステム上管理するための表現である。例えば，航空券の予約，金融商品の取引，売り上げ動向の分析，支払いに対する承認，開発計画に関する協調作業などをドメインクラスとし，管理可能な構造として表現する。ドメインクラスの構造は，ビジネスの経営的情報資産となるマスターデータとしての「もの」とビジネス活動の出来事の記録としての「こと」の概念の，「もの」クラスと「こと」クラスの関係で決まる。
管理可能性というドメインクラスの利点を損なわず，横断的なモジュール化を可能にするには，オブジェクト指向パラダイムを補う別のパラダイムに基づくモジュール化技術が必要である。それが，アスペクト指向パラダイムである。
オブジェクト指向パラダイムとアスペクト指向パラダイムは相補的関係にある。最初の分割モデルを主モデルとして「クラス」とし，主モデルに横断的なモデルを「アスペクト」とする。対象システムをどのように分割しても，両パラダイムによるモデルは相補的となる（図4[拡大表示]）。アスペクト指向パラダイムを導入することで，ユースケースから分析，設計，実装モデルがシームレスにモデル化できる。従来は，ユースケースが設計/実装モデルの段階でコンポーネントやクラスによって分断され追跡が困難になっていたが，そうした問題は起こりにくくなる。
モデル不完全性こそが現実的解
以上，モデル化におけるさまざまな問題点を取り上げてきた。これらを踏まえて気づくことは，ソフトウェア開発ではモデルに完全さを求めるべきではないということだ。
これまでのOOA/Dにおけるモデル化では，演繹的または完全なモデルの定義を目指していた。しかし完全なモデル化は大変な作業だし，現状をあまりに完全にモデル化すると，変化に対応しにくくなる。
その点，ユースケースは帰納的かつ不完全なモデルとして対象を定義する。すなわち，アクターにとって関心のあるシステムの要求だけを記述し，完全であることを求めない。同様にDOAにおけるエンティティ定義では，操作としてCRUD（Create，Read，Update，Delete）だけを考える（図5[拡大表示]）。すなわち，すべての業務シナリオにおけるデータ操作の基本操作だけを考えた一種の不完全なモデルである。
工学や科学は一般にモデルの完全さを要求するが，その思想をソフトウェア開発にそのまま適用した場合は，現実的にうまくいかない。ある意味，このモデル不完全性こそがソフトウェア開発に現実的な解を与えていると言える。
おわりに
現在広く使われているオブジェクト指向は，許容力が大きい。プログラミング・パラダイムからアーキテクチャ構築，設計手法など多くの分野に適用されている。半面，許容力の大きさが客観的な基準の不足の原因となっている。客観的な基準を確立するために，パターンや開発方法論などのプラクティスの導入，フレームワークのプログラミング・モデルやコンポーネント指向開発などの開発方法の強制を取り入れてきたが，依然として十分とは言えない。今後は，OOPの新機能，アスペクトなどの抽象的なコンセプトの導入などの進化を伴いながら，客観的な基準の確立を模索していくと思われる。
ただ新技術の導入は，既存の技術に一層の複雑さを加え，進化の方向性をかえって不明確にしてしまう危険をはらんでいる。そこで，ソフトウェア技術者はもう一度原点に戻り，ソフトウェア開発の本質的な原則を再評価する時期に来ている。本質的な原則は，関心の分離，責務の分担，概念の単純化などである。また，システムを利用する人の要求の価値を再認識することも必要だ。この原則から，要求分析と定義，アーキテクチャ構築，品質管理，運用管理，ソフトウェア資産管理の発展の方向性を俯瞰することが重要である。
萩原 正義 Masayoshi Hagiwara／マイクロソフト Software Architect1993年マイクロソフト入社。北海道大学，早稲田大学非常勤講師。.NET開発，アーキテクチャの調査研究と技術啓蒙に従事。アスペクト指向，フレームワーク実装技術，開発方法論，データ中心アプローチとオブジェクト指向分析／設計との融合，モデル駆動型アーキテクチャ，サービス指向アーキテクチャなどが現在の興味対象。趣味は，IT業界の著名人との雑談とウィンター・スポーツ。ソフトウェア技術の発展に貢献することが夢。 |
