netail.net

_ [読書][AspectJ] ユースケースがアスペクトになる ▲

Aspect-Oriented Software Development with Use Cases という本が ACM の Online Books プログラムの無料で読める範囲に入ってたので読んでみたら，そういう記述があった．

ユースケースのシナリオを書いていくと，シナリオのうち特別なケースでのみ実行される alternate flow や，定義済みのシナリオを拡張する extends 関係が登場してくるが，これらは複数のクラスに影響を与えるので，クラスを拡張するアスペクトとして表現するほうが良い，と解説していた．（アスペクトが使えることを強く意識したシナリオの書き方になっているような気もする．）

ユースケースは，それに対応する「ユースケーススライス」というモジュールとして実現できる．ユースケース固有のクラスはそのままクラスとしておけるが，他のクラスを拡張する部分はアスペクトとしてインタータイプ宣言ないしポイントカット＋アドバイス表現を用いて記述する．これによって，特定のユースケースに関するコードを他のユースケース用のコードから独立したままに保つ．

異なるユースケースに所属するコードを分離したままで管理するために，ユースケース固有のコードを，それぞれ独立した（ユースケース名を付けた）ディレクトリに配置してしまおう，とも言及されていた．Eclipse では，コンパイル対象のソースコードが入ったディレクトリを指定することができるが，そこで各ユースケースのディレクトリを列挙すれば良いらしい．

非機能的要求も，できるだけ infrastructure use case としてシステム側の振る舞いを記述し，普通のユースケース（application use case）との関係を整理しておくらしい．そうすることで，システムのサービスを担うアスペクトなんかも設計時にきちんと扱うことができる．

別々に記述したものはそのまま混ぜずに置いておくという一貫した方針になっているので，けっこう読みやすい本だと思う．そのかわり，ユースケースとコードの中間（分析モデルとか）については扱いが小さい気がした．

(追記) この本，日本語訳が出てますね．まったく気づいてませんでした．