AOPのベクトル分析モデル案めも



AOPの改良案としての基本的考えてについて、ブログにコメントした内容をここに保存しておきます。

わたしも最新の状況を見れてるわけじゃないんで、ちがっているかもしれませんが。たとえば1000とか2000もの画面があるような業務アプリに、DIしてその設定をメンテするっていう手間を考えると、改良の余地があると思うんですよ。用は横断的な関心ごとをどこに入れるのかというののメンテが馬鹿にならないという解釈です。seasarはそこらへんをデフォルト表現で簡素化できているので、実務的アプローチとしてはいい線いっているのではないかと思っているわけです。前回のソフトウェア工学研究会で、アスペクト自体をオブジェクト指向分析で抽象表現するアプローチについて提案があったんですが、その進め方の方向がいいと私は思っています。 そこでも業務の種類あるいはクラスの業務的役割の抽象的カテゴリに対してアスペクトを一括して注入できるようにすることはできない点が課題として上がっていたと記憶しています。というか、それができないと実用に耐えないのではないかと思うんですよ。』
...
# essence 『そうゆうことです。直行する関心ごとっていうふうに、よくいわれるけど、結果としてきれいに直行できるはずないんですよ、結局注入しないきゃならないんで。だから、モデルとして完全な直行はあきらめて、関心ごとのベクトルモデルでそれぞれのベクトルの方向を、オブジェクト分析して、実装も分析に近いモデルでのせていくというベクトルモデルみたいな考え方を考察中です。非機能要求はオブジェクト指向でできないという一般的な考え方は間違っていると思っていて、特に業務のドメインモデルがいわゆるリッチドメイン実装モデルでやることが現実的でない文化になっている現在の状況では、とくに非機能領域自体をドメインとした分析モデルはその領域の実装モデルとの連続性は非常に高いと思っているんです。なぜなら、いままでフレームワークの設計方法自体がこういったアプローチで設計してきた実績からそう思うんですよ。この場合「非機能要求」っていう大きいくくりでまとめてしまっているので、フレームワーク自体も大きく複雑になるわけですが、ベクトルモデルで個別の非機能的関心ごとの部品で分析設計したあとに、ベクトルどうしを連結することで非機能的部分をあわせたフレームワークを簡易な表現でこうちくできるんではないかというのが、私が考えるベクトルモデルの思想なんです。』
# essence 『もちろんアプリ部分もベクトルの一つということとして考えてます。』

Posted: 水 - 11月 23, 2005 at 12:33 AM      
    |


©