ObjectSquare

[レポート]


オブジェクト指向シンポジウム 2003 [ アスペクト指向 ]

オブジェクトテクノロジ・ソリューション部
坂坂屋の赤坂英彦
Akasaka_Hidehiko@ogis-ri.co.jp

[概要]

オブジェクト指向シンポジウムは、情報処理学会主催の産学共同のシンポジウムで、毎年開催されています。今年は 8 月 20 日(水)から 8 月 22 日(金)の 3 日間、早稲田大学の西早稲田キャンパス 14 号館で行われました。

[受講動機]

最近、全然セミナーに参加してないなぁ。ふと思うのはそんなことばかり。今回のオブジェクト指向シンポジウムの日程は、ちょうどイテレーションが終わって一段落するあたり。こんなチャンスはめったにありません。早速申し込んでしまいました。 受講動機はこんな感じです。

でも、実は、イテレーションは若干遅れてしまい、私の参加した 8/21 (木)は、イテレーションの終結日と重なってしまいました。メンバーのみんなには大変申し訳なく思いつつも、久しぶりのセミナーを楽しんできてしまいました f(^^;;。

[アスペクト指向とは]

アスペクト指向とは、システムで横断する関心事を分離するためのメカニズムです。従来より「関心の分離」を一歩進めるための技術です。
以下に、アスペクト指向でよく用いられる用語について整理しておきます。

[受講したセッション]

今回、私が受講したセッションは以下の通り、すべてアスペクト指向関係です。
[1] チュートリアル:「アスペクト指向ソフトウェア開発」
[2] 一般講演:「ポストオブジェクト指向技術」
  [2A] オンデマンドのアスペクト・ウィービングに基づく Web アプリケーション開発のすすめ
  [2B] プログラムスライスを用いたアスペクト指向プログラムのデバッグ支援環境
  [2C] ソフトウェア進化のための Mixin 型を使ったプログラミング手法
[3] パネル討論:「ポスト・オブジェクト指向プログラミング (POP) 」

[セッション詳細]

それぞれのセッションについて紹介していきます。大変申し訳ありませんが、紙面の都合上(というより、私の時間の都合により)、内容はメモ形式、つまり箇条書きで失礼させていただきます。
なお、一般講演([2A]、[2B]、[2C])のところでは、講演者は複数名いらっしゃいます。壇上で発表された方が判るように、お名前の前に [Sp] を付けました。

[1] チュートリアル:「アスペクト指向ソフトウェア開発」

[講演者]

野田夏子氏、岸知二氏(NEC)

[内容]

前半は野田氏が AOP (アスペクト指向プログラミング)の概要説明と、AOP をサポートするいくつかの実装の比較を行い、後半は岸氏がアスペクト指向のポイントについて解説して下さいました。資料も良くまとまっており、現時点で私にとって最良のハンドブックです。

アスペクト指向(横断的な関心事の分離をサポートするもの)の実装の比較

AspectJ
  AOPの共通概念(用語確立)、普及に貢献。

Hyper/J(サブジェクト指向プログラミング)
  多元的な関心事の分離の考え方から発展。

DemeterJ (adaptive programming)
  横断的な関心事をグラフ構造のトラバースに限定したツール。

AspectJ と Hyper/J - アプローチの違い

AspectJ

「支配的」なクラス構造。

Hyper/J

[感想]

このセッション、朝の 9:00 は辛かったけど、最初にこのセッションを受講できて良かったです。後続のセッションを聞くための良い予習になりました。

[2] 一般講演:「ポストオブジェクト指向技術」

[2A] オンデマンドのアスペクト・ウィービングに基づくWebアプリケーション開発

[講演者]

[Sp] 佐藤芳樹氏(東工大,JST) 、立堀道昭氏(日本 IBM) 、千葉滋氏(東工大,JST)

[内容]

状況によって最適なアルゴリズムが異なるケース(キャッシュ機能の実現)において、実行時に動的に合成して、効率的にカスタマイズ可能な Web アプリを作成したという話でした。

Wool (動的結合可能なツール、自作)

動的な合成は、クラスローダ単位 (DebugAPI を用いて、リクエストのフックで実現)。

課題

[感想]

セッションとは関係ありませんが、エラー処理をエラーレベル(状態)に合わせて処理を切り替えたい場合、advice (join point のフック処理)を状態マシンにして実現できるかな?と、使えそうにないアイディアを、ぼんやりと考えていました。

[2B] プログラムスライスを用いたアスペクト指向プログラムのデバッグ支援環境

[講演者]

[Sp]石尾隆氏、楠本真二氏、井上克郎氏(阪大)


[内容]

AspectJ のコンパイラの機能(コールグラフ)を使った解析手法についての話でした。

コールグラフを使った解析手法
  関心のある部分だけ抽出

結論

・バグの原因特定には使える(◎)
・バグの修正支援としては難しい(△)

[感想]

デバッグについては気になることがありました。join point でのトレースでは、いきなり知らないところへジャンプしてしまい混乱するのではないかと心配だったのです。セッションの後、講師の方に聞いてみたところ、「AspectJ ではステップトレースの際、有効な join point にはマークが付くのです。ほらね」と、デバッガで見せてくれました。なるほど、納得。マジックの様にサプライズの連続ではなさそうです(^^;;。とりあえず、デバッグも大きな問題はないようです。

[2C] ソフトウェア進化のためのMixin型を使ったプログラミング手法

[講演者]

[Sp]紙名哲生氏、玉井哲雄氏(東大)

[内容]

Mixin を用いて、横断的な関心事の分離を図るものです。例題では、デザインパターンを用いた方法と、Mixin を用いた方法の比較で、その優位性を示していました。

McJava(自作、現在コア部分のみ)

特徴

影響を受けたアイディア

[感想]

自分でも意外だったのは、私は AspectJ よりも Mixin(MxJava) の方が良いと感じたことです。
でも Mixin だけなぜか質疑応答で意地悪な質問攻めばかりでした。それだけ親近感がわくのか、それともデザインパターンを例にしたことが聴衆の意見(反感)を呼んだのでしょうか。

[3] パネル討論:「ポスト・オブジェクト指向プログラミング(POP)」

[講演者]

司会:立堀道昭氏(日本 IBM)
パネリスト:岸知二氏(NEC)、千葉滋氏(東工大)、一杉裕志氏(産総研)、小野康一氏(日本IBM)

[内容]

パネル討論は以下のお題についてパネリストの方が適宜、賛成派( 2 名)、反対派( 2 名)に分かれて議論を展開しました。それぞれのパネリストの主張が終わると聴衆の方にも意見を聞き、活発な討論になりました。パネル討論の通例に従い? やや議論は発散気味でした (^^;;。

お題(1):AspectJは使い物になるか

・AspectJ はアスペクト指向の基本概念の確立に寄与(○)
・言語仕様が汚い、標準ライブラリにアスペクトを追加できない(×)
⇒ Sun のライセンス形態が微妙に影響するらしい。
・オーディエンス ⇒ Yes
  ・ワイルドカードがなぜ悪い(よい名前付けの推進力になる)。
  ・実用で使えるかどうかがポイント。

お題(2):Separation of concerns の有益さは真理か
・差分プログラミング、多重継承と同様の問題があるのか。
・制限されたルール上で使う分には問題がない(○)
・プログラマに関心の分離を求めるのは無理なのではないか(×)
・これは討論用にかなり無理した発言に思えた(^^;;
・オーディエンス ⇒ Yes
・関心の分離を否定するのは、AOP を否定することにならないか(私)。
・元々Aspect 指向推進派の人たちなのだから有りえない(^^;

お題(3):AOP で可読性、安全性、信頼性、保守性が上がるか
・モジュール化。
・オーディエンス ⇒ No
  ・全体構造を理解するのが難しくなるのではないか。
  ・分離するのだから、部分的にはとてもシンプルになるのだけど... (私)

お題(4):AOP が浸透する日などくるのか

・キラーアプリケーションがなければ浸透しない(×)
・外圧によって使わなければならない状況にきっとなる(○)
・J2EE に変わるような AOP フレームワークが出来る(?)
・オーディエンス ⇒ Yes(?)
  ・アスペクトの切り出し方はきっとパターン化される(私)。


[感想]

パネル討論は、とても積極的に意見が出てきて内容も面白かったです。しかし、アスペクト指向先駆者の方々がパネリストをしている関係上、反対意見の主張(役割の演技)には無理があるような気がしました。聴衆側に「アスペクト指向なんて使えない!!」という強烈な意見を持った方がいたら、もっと議論が白熱したかもしれません。なんとなく、オブジェクト指向が出始めてきた頃の議論を、アスペクト指向に対象を変えて、繰り返していたような感じがしないでもありませんが。

[所感]

今回セッションを受講して感じた点についてまとめておきます。なにぶんにも、私自身、アスペクト指向に興味を持っているだけで、内容の理解が浅いため、問題を履き違えている可能性があります。こんな意見もあるのかなぁ程度に読んで下さい。

横断する関心事の分離について

横断する関心事の分離は難しいが、これはプログラマ全員に求められるものではない


ナイーブなオブジェクト指向の復権

アスペクト指向の普及により、煩わしい横断する関心事がなくなるため、今まで以上に、ピュアなオブジェクト指向に没頭できるはず(求められるはず)。

アスペクト指向の普及方法について

アスペクト指向の普及方法としては2種類が必要なのではないだろうか

AspectJ は前者のタイプとして、アスペクト指向の普及にとても貢献しています。ただし、それだけでは不足していると思います。何でもかんでもアスペクトで解決しようとしてしまうような間違った方向に普及してしまったら危険です。

アスペクト指向はオブジェクト指向より簡単?

受講者の質問の中に「オブジェクト指向は難しいけど、AspectJ なら出来るかも知れない」というものがありました。 これは 「分別のつかない子供に、切れ味鋭いナイフを与えるようなもの」だと思います。とても危険な感じがしました。
もっともこれは、オブジェクト指向が普及し始めた頃にも感じた「自由度があり 過ぎて、良くも悪くも作れてしまう」という問題と同じ事なのですが。
この問題については、日経 BYTE(2003.10) で萩原さんが指摘しているとおりです。

いったい何がアスペクトなのか?

AspectJ (プログラミング言語)の普及によって、アスペクト指向のメリットの追求が、下流工程側の視点から行われてしまい、一歩間違えると何でも「アスペクト」としてコーディングされてしまう危険性が(可能性は高くないかもしれませんが)あると思います。
C# や .NET における差分プログラミングでは、予め用意されたアトリビュート(アスペクトに相当)をドメイン側のコードから指定します。また、アトリビュートはユーザ側で定義することも可能だそうです(カスタム・アトリビュート)。AspectJ と異なるアプローチですが、この方法も妥当な現実解のひとつだと思います。

[教訓]

重複コードのルーチン分割のように、何でもアスペクトに分割してはならない

異なる抽象度のモノのマッピング(結合)はできないだろうか?

最初のチュートリアルでの質疑応答にて
「分析と設計(メカニズム)をアスペクトとすることが可能なのでは」
という質問がありました。
オブジェクト指向では同じダイアグラムを利用して分析、設計と開発を行うため、このような期待はある意味自然なものなのかもしれません。
ただ、分析と設計ではモデル化の視点が違いますし、抽象度も異なります。アスペクト指向が解決する「横断的な関心事」だけではこれらは解決できないのではないかと思いました。

アスペクト指向三昧を終えて(セッションを受講して)

セッションを終えての感想です。

ただし、個人的には、いまひとつカッコ良く感じない

今後、当面の間、私の技術テーマは「アスペクト指向」で決まり!!です。

謝辞

今回のシンポジウムでは、講演者の方々に日本語のコミュニティはないのか質問して回りました。そのときは「英語しか知らないですね」とのことだったのですが、パネル討論のパネリストでもある一杉裕志さん(産総研)が、速攻でメーリングリストを立ち上げて下さいました。
アスペクト指向関係のセッションを行って頂いた講演者の皆様、情報処理学会の皆様に感謝いたします。また、無知な私に有用な情報、指摘を与えてくれた同僚、そして快くセミナーに送り出してくれたプロジェクトメンバーのみんなにも感謝します。
ありがとうございましたm(_._)m。

参考文献




© 2003 OGIS-RI Co., Ltd.
HOME HOME TOP オブジェクトの広場 TOP