[PukiWiki]
第2回J2EE/DI/Aspectパターン勉強会議事録
http://patterns-wg.fuka.info.waseda.ac.jp/st/index.php?%5B%5B%C2%E82%B2%F3J2EE%2FDI%2FAspect%A5%D1%A5%BF%A1%BC%A5%F3%CA%D9%B6%AF%B2%F1%B5%C4%BB%F6%CF%BF%5D%5D

[ リロード ]   [ 新規 | 編集 | 差分 | 添付 ]   [ トップ | 一覧 | 単語検索 | 最終更新 | バックアップ | ヘルプ ]

最新の20件
2008-03-172007-07-072007-07-032007-06-222007-03-132005-10-172005-09-272005-09-262005-06-302005-06-29

[ J2EE/DIコンテナ/AOPパターン・プロジェクト ]

第2回J2EE/DI/Aspectパターン勉強会

  • 日時: 2005年8月18日 19:00-
  • 場所: 豆蔵
  • 参加者: 約30名(すいません。あまりの多さに驚いて名前控えるの忘れました)

第1回のおさらい

JacobsonらのAspect-Oriented Software Development (AOSD)

  • AOPの併用により、ユースケースを実装レベルまで役立たせる考え方
  • この考え方では、分析/設計/実装まで全て対応/一致させるのか?
    • はい。
  • 顧客にはあくまでもユースケースを見せる。
  • テストはどのように行うのか?ウィーブした後に、本当に問題ないのか?各ユースケーススライス単位で干渉しないのか?複数の機能要件は一般に干渉するのでは?
    • 他の責務を見せないという効果がある。AOPというよりも、Multi-Dimensionalな分割/見方。
  • 担当者の割り当て/分担はどのように行うのか?2003年の論文では、ユースケースとサブシステムに分けるが・・・
  • この考え方に、OOの必然性はあるのか?
    • ピアユースケースなどで用いる。
  • 提示スライドにおいて、なぜ、「預け入れ」といったクラスが必要なのか?
    • ユースケース「預け入れる」の調停役として、ユースケースのライフサイクルと同期して生成/用いられる。
  • ユースケース単位で分離して分析/設計するのは分かるが、最後にウィーブ(がっちゃんこ)する必要はあるのか?
    • 複数のユースケース間での整合性や保守性などを考えると、ウィーブしたほうが良い。
  • 最終的に、システム全体のコードがどのように実装されるのかという例示が欲しい。

DIコンテナにおける定義ファイルの効率の良い扱い/管理

  • 課題の説明。
  • 次回の勉強会で取り上げる。

SpringとSeasarの定義ファイルの書き方の違い

  • 用いるコンテナにおける定義ファイルのモデルに依存する部分がある。
  • Spring
    • 例えば、3つの定義ファイルに分けても、最終的には1コンテナに1つの統合された内容。全てのクラスが見える。
    • アプリケーションコンテキスト定義を、親子に分ける例は存在しない。
  • Seasar
    • ツリーモデル。インジェクションの際に、ツリー上の自分と子供しか見えない。

次回開催

  • 次回は
  • 開催日は追ってご連絡差し上げます

リロード   新規 編集 差分   トップ 一覧 検索 最終更新 バックアップ   ヘルプ   最終更新のRSS
Last-modified: Mon, 26 Sep 2005 18:39:29 JST (4465d)
Link: DI(3816d)

Modified by Hironori Washizaki

"PukiWiki" 1.3.4 Copyright © 2001,2002,2003 PukiWiki Developers Team. License is GNU/GPL.
Based on "PukiWiki" 1.3 by sng
Powered by PHP 5.3.3

HTML convert time to 0.010 sec.