開発プロセスとUMLの拡張性 ［後編］：UML BASIC LECTURE（3/3 ページ）

[羽生田栄一（豆蔵 取締役会長）, 岡村敦彦（豆蔵），＠IT]

アスペクト指向ユースケース

　最後に、もう1つ別のプロファイルの紹介をして、今回の連載を終了することにしましょう。それは、本連載第1回目「あなたはテキスト指向、それともダイヤグラム指向？」のユースケースのときに取り上げたトピックですが、おそらく覚えている方は少ないかもしれません。アスペクト指向ユースケースの話です。

　アスペクト指向もオブジェクト指向が昔そうであったように、現時点ではプログラミングの発想からボトムアップ的にソフトウェア開発をファシリテートする考え方といえます。オブジェクト指向ももともとオブジェクト指向言語から始まり、それらの言語をより有効に使うためには考え方そのもののパラダイムを変換する必要があったため、オブジェクト指向設計、そしてオブジェクト指向分析といった上位の手法が発展してきました。

　アスペクト指向もやはりAspectJなどのプログラミング言語はすでにいろいろなところで利用され始めていますが（*）、やはり何をアスペクトにすればよいのか分からない、というようなオブジェクト指向と同様の問題（何をオブジェクトにすればよいか分からない）が、その普及の前に立ちはだかっているようにも思えます。

---

▼［連載］ アスペクト指向のバリエーション解説（2）

▼「AspectJから学ぶアスペクト指向の理解」

---

　そうしたジレンマを背景にアスペクト指向もプログラミングだけではないアプローチとして、適切なアスペクト指向開発（AOSD：Aspect Oriented Software Development）の必要性が大きくなってきています。

　アスペクト指向ユースケースは、そのアスペクト指向開発をユースケースベースでやってしまおう、というのですから、さすがユースケースの父ヤコブソン的な発想といえるでしょう。

　第1回目でも触れたようにヤコブソンは、アスペクト指向はユースケースがやろうとしていたことと同じであるという着眼点を持っていて、よりそれを明確に示したものが「ユースケースによるアスペクト指向開発（「Aspect‐Oriented Software Development with Use Cases」（Ivar Jacobson, Pan-Wei Ng,Addsion-Westley）」ということになります。

　一般的にアスペクトとはいわゆるロギングやセキュリティなどのように複数のクラスを横断する関心事をいい、ビジネスロジックとは異なった観点を別のモジュールとしてとらえることができるため、解決したい問題に集中したプログラミングを可能にします。これは大変うれしいメリットといえます。つまり横断的関心事の変更が、中心的な関心事にその影響を及ばさない仕組みを実現しているのが、アスペクト指向の大きな特徴の1つです。

　ヤコブソンはそうした拡張性に対する独立分離性から、基本ユースケースと拡張ユースケースの関係（extend）をアスペクトとして考えているフシが見られたので、わたしはそこには当初強引さを感じていました。確かに拡張ユースケースに変更を加えても基本ユースケースへは影響を及ぼしませんが、それはあくまでも同様の関心事であり、メインフローのバリエーションとして拡張しているにすぎません。ですので、ついにヤコブソン翁も焼きが回ったかな、などと勝手に思っていたところ、それがそうではないことが分かってきました。

　つまりアスペクト指向をそうしたCore ConcernとCrosscutting concernを分離するものとしてとらえるだけでなく、開発段階でのさまざまな関心事の単位としてアスペクトを扱おう、という発想です。例えば、通常のユースケースは開発における関心事としてとらえられ、同様のアスペクトが必要とされます。

ユースケース：「ホテルを予約する」
aspect ReserveRoom;

　そこにUseCase sliceという概念を導入し、アスペクトやクラスも含んだコラボレーションとして表現しています。

図6 UseCase sliceという概念を導入

　これは、ユースケース「ホテルを予約する」は、このユースケース専用のクラス（ReserveRoomHandler）と複数のユースケースをまたがるクラス（Room）を持つアスペクト（ReserveRoom）で実現されていることを表しています。

　さらに、これまでの考え方ではユースケースは機能的な要求を扱うものとして考えられてきたのに対し、機能外要求も扱うInfrastructure UseCaseやPlatform Specific UseCaseといったものまで登場します。

　そしてそれらを統合するのがUse Case Moduleである、というように、これまでのユースケースと比較すると大幅な拡張が加えられています。また、通常のユースケースも、いわゆる楕円アイコンだけでは分かりにくかったイベントフローについて、表現しやすい拡張が施されています。

図7 通常のユースケースも表現しやすい拡張が施されている

　オブジェクト指向の世界の中では一番オブジェクト指向的ではないユースケースも、それゆえに一般的にも浸透してきつつある手法といえましょう。UMLの記法となってからは、誤解や誤用を受けながらもある程度定着してきたその技法は、いま新たな展開を迎えているようです。

　紙数も尽きたので今回はこれ以上詳細について触れることはできませんが、この続きに関しては、またあらためて別の機会を設けることができればと思います。

---

　さて、これで一応今回の連載は終了です。少しは何かのお役に立てたでしょうか。またどこかで皆さんとお目にかかれる時を楽しみにしています。

「UML BASIC LECTURE」バックナンバー

• 開発プロセスとUMLの拡張性 ［後編］
• 開発プロセスとUMLの拡張性 ［前編］
• オブジェクト制約言語について 応用編
• オブジェクト制約言語（OCL）の基本
• 状態モデリングとステートチャート図のわな（後編）
• 状態モデリングとステートチャート図のわな（前編）
• 関連や関係の落とし穴（後編）
• 「関連」や「関係」の落とし穴（前編）
• クラス図の落とし穴
• あなたはテキスト指向、それともダイヤグラム指向？