ひがさんのBlogのまとめサイト (2)

(続き)AOP

インターセプタは、自分自身の単体テストを行う。

アスペクトが組み込まれるクラスは、アスペクトを組み込まない状態で単体テストを行う。

結合テストでは、アスペクトがきちんと組み込まれていることを検証する。

インターセプタの細かいテストは単体で行われているはずなので、結合テストでのアスペクトの検証は正常ケース(そつうレベル)のみ。

で良いんじゃないかと思ってます。
横断的な関心がコアから分離されたので、テストも同じように分離し、結合テストでアスペクトの設定があってるかの検証は行うという考えです。
ぼくはDIContainerをダイコンと呼ぶね - ひがやすを blog

まとめサイトにないけど、Tapestry系を追っかけてたら見つけたので。

これは本当にアスペクトで実装すべきなのでしょうか？データアクセスはcross-cutting concernなのでしょうか？
間違ってる！といいきるだけの根拠は全然ないのですが，直感としては違うんじゃないかという気がしてしょうがないです．
koichikのひとりごと

S2Daoがcrosscutting concernかっていうと違うと思います。
AOPは、crosscutting concernを実現するものかっていうとそれもまた違うと思ってます。
〜(省略)〜
だったらダイコン時代のAOPは、crosscutting concernなんて難しいものを捨ててしまって、単なるInterceptorで良いのではないでしょうか。
ただし、なんでもインターセプトすれば良いというものではなく、複数のクラスに汎用的に適用できる場合に使うということで良いと思います。
2004-07-01 - ひがやすを blog

明快な見解ですね。
注意しないと簡単にヤバいシステムがつくれてしまいそうなので、AOPの適用のしどころには十分なレビューが必要だなぁ。

AOPに関しても同じで、無理にアスペクトを抽出しようとせず、何度かプロジェクトを経験して、これってやっぱりアスペクトだよなぁと思ったときに初めて使うか、あるいは、AOPの使い方としてパターン化された部分を使うとかそんな感じで良いと思います。
そうしないと、悲劇を生み出す最終兵器になりかねません。
このメソッド呼んだときいったい何が起こってるんだよ
2004-07-14 - ひがやすを blog

ですよねー。
で、そのパターン化されたパターンってのが随時公開されるわけですね。
MockInterceptorとかDelegateInterceptorとか。
これって十分「パターン」ですよね。

AOP フレームワークは

コンパイル時にクラスに対してアスペクトを適用する

実行時にクラスに対してアスペクトを適用する

実行時にインスタンス(コンポーネント)に対してアスペクトを適用する

の3タイプに分かれるんじゃないかと思ってます。
1はコンパイラもしくはポストプロセッサで処理するタイプが多く、AspectJが代表選手でしょう。
2はClassLoaderで処理するタイプが多く、JBossAOPが(たぶん)代表選手。
3はダイコンで処理するタイプが多く、S2もここに含まれます。
〜(省略)〜

1はコンパイル時がちょっとめんどくさいが、実行時に特別な環境を必要としない。

2は実行時に特別な環境が必要だが、普通にnewしたオブジェクトにもアスペクトを適用できる。

3は実行時に特別な環境を必要とし、インスタンスもダイコンから取得する必要がある。

2004-07-14 - ひがやすを blog

まとまっていてわかりやすい。
トレースログの埋め込みの場合なんかは1がいいなと思うんだけど勘違い？
S2のTraceInterceptorはコンポーネントごとに書かないといけないから、この目的には向いてないような。ピンポイントでトレースするなら便利だけど。

S2DaoとかDelegateInterceptorとかはinterfaceに対してaspectを仕掛けてるみたい。
けど、普通は実装クラスのコンポーネント定義に対してaspectを仕掛ける。
つまりコンポーネントごとに個別にaspectを仕掛ける必要があるわけだ。
大変。

	<component class="java.lang.Object">
		<aspect>commonInterceptor</aspect>
	</component>
	<component class="hoge.HogeImpl">
		<aspect>hogeInterceptor</aspect>
	</component>
	<component class="hoge.FooImpl">
	</component>

とか書いたら、HogeImplにはcommonInterceptor,hogeInterceptorの2つのaspectが、FooImpleにはcommonInterceptorだけが適用される。
みたいな、スーパクラスやインタフェースを指定したaspect指定が併用できるといい気がするんだけどどうかなぁ。
まあ、AspectJみたく正規表現パターンで適用できればそれに越したことはないんだけど。S2のver.2.4で実現されたんだっけかな？

クラス図

〜(省略)〜
2004-06-20 - akon0.98aのよっぱらいの戯言
〜(省略)〜
2004-06-24 - ひがやすを blog

難しい…。SOA、Lyee、T型、ほとんど知らん。
クラス図による分析はその後のINPUTに結びつきづらい、ER図でデータモデル分析した方が良いっていう主張だってことはわかった。
この点はもっと経験をつまないとなんともいえませんね。精進します。

やっぱりユースケースはくさってる
2004-06-25 - ひがやすを blog

今度はユースケース図もぶった斬る。

というか、こういう話題には、経験なさすぎて ( ´_ゝ`)ふーんそんなもんかーとしか思えない。
ソフトウェア開発の会社に勤めながらこの辺りの分析〜設計をシステマチックにやったことがないことを、心より恥じる。

全然関係ないけど、↓これ面白すぎ。
里見へ 2004-04-05 - 日記

実業務適用例

あと設定ファイルの柔軟性が高いので「設定ファイルをうまく書くパターン」もありそうです。
2004-06-30 - アガテナ [S2]S2を使ったプロジェクト納品

全部参考になるけど、1点だけ抜粋。
設定ファイルの分割や記述方法のガイドラインなんかほしいなぁ。
次期バージョンでは基本的にdiconファイルは書かなくていい無設定S2Containerになるようだけど、サンプルレベルではない業務システムなら完全無設定でOKとはならないはず。プロパティの設定が必要なコンポーネントが結構でてくると思うし。
だからこそ誰かガイドライン書いてくれないかなー(人任せ)。

S2Dao

〜(省略)〜
2004-07-08 - ひがやすを blog

S2Daoのいいところは、デフォルトでSQLを自動生成してくれるけど、SQLファイルを作成すれば自作のSQLを適用するのも自由自在。本体クラスに手を入れなくても良い、と。φ(。_。)メモメモ

設計

ダイコン時代のOOの特徴は、ロバストネス分析の結果から自動的にクラスが抽出できる点だと思います。
2004-07-10 - ひがやすを blog

( ´_ゝ`)ふーん
すごいんだろうけど、経験がないからいまいち感動に乏しい。
で、結局今現在goyaでは「ロバストネス分析は不要」って方向になっているんだっけ？
方向転換の原因はなんでしょ？
goyaまでたどり着いたときに忘れずにチェックしなきゃ。

これが、ダイコン時代のコンポーネントの設計にはぴったりなんですよ。
Responsibilityがinterfaceのメソッド、CollaboratorがDIされるコンポーネントを表すので。
2004-07-15 - ひがやすを blog

ということで、CRC分析。
名前は聞いたことがある。カードを使うってことも聞いたことがある。でも、UMLがあれば不要じゃん？とか思ってた。
まだ、現役なのかー。

コメントにあったakonさんのCRC分析に関するword文書がすばらしい。
大体基本は抑えたけど、これは経験者と実践していかないと身につかなそうだなぁ。

やはり、ある手以後グルーピングしてインターフェースにまとめた方が、わかりやすいんだろうなと思ってます。
〜(省略)〜
そこで、私が考えたのが、バウンダリに関連するコントロールを1つのコントロールにまとめる、エンティティに関連するコントロールを1つにまとめる、それ以外を共通のコントロールにまとめる方法です。
2004-07-27 - ひがやすを blog

バウンダリとエンティティに関するコントロール(ロジック)の集約の仕方については御意。

テスト

ホワイトボックステストが書きたくなったらクラスの設計を見直せ。間違いない。
2004-07-21 - ひがやすを blog

な、なんだってー！！
ホワイトボックステストを書かないだってー！！？

ダイコン

インターフェースと実装を分離することで、

モックを使って簡単にテストできるようになったり

実装が出来上がってなくても平行して開発が進められるようになったり

するというメリットが生まれます。
〜(省略)〜
このような開発スタイルをとった場合、誰かが業務ロジック同士の依存関係を解決する必要があります。
このようなニーズは汎用的であるため、フレームワーク化されていた方が
いいでしょう。
設定ファイルに書いてある内容をもとに依存関係を解決する仕組みが
Dependency Injection Container -> DIContainer -> ダイコン
になるわけです。
ダイコンで管理されている業務ロジックがステートレスでシングルトンなのもこのような理由があるのです。
2004-07-26 - ひがやすを blog

きれいにまとまりました。

ハマチ

なんかコメント欄でやたらとハマチって言葉が出るんで検索してみた。
google:ハマチダイコン Java

おお、S2と連動するワークフローエンジンですか。
なんかすごい。
でも、2005年の情報があまりないのはなぜ？もうお蔵入り？

と思ったら、有料製品に格上げ？「GFlow」？

富野由悠季の新作を待ち続けるブログ（仮）

ハマチベースの製品のようですね。コードネームが「ぶり」なのかな？

と思ってたら次は「ぶり2」らしい。

[buri2] - まこたん(makotan)の日記

さすが出世魚。どんどん出世しますな。しかも「2」。
でも、どっちかっていうと「GFlow2」ってことで有料製品？

とりあえず知らなかった用語を調べてみる。

XPDL: 何かワークフローを表現するデータの標準形式らしい。情報があまりなくない？XPDL Support and Resources | XPDL
JaWE: Java Workflow Editorのこと。XPDLをGUIで編集できるエディタのようだ。Enhydra.org

で、結局、ハマチは今現在どうなってるのかさっぱりわかりませんね。
ダウンロードしてみたけど、Readmeファイルないし。
実業務で使っていいのか悪いのか。使えないんだったら試す意味ないしなぁ。
構造だけ勉強させてもらうとか？でも、それってパクリか？
いや、インスパイアされただけだから無問題かな。

- - -

以上、「ダイコン時代の設計手法 - クラス抽出」まで。
続きはまた。