
The Rational Edge
オブジェクト指向を超えて
page1|page2|page3
ワーチェスター工芸研究所業務学教授
Gary Pollice
2005/11/25
◆ アスペクト指向方法論は次のキーアイテムか?
われわれの業界では、すべてのものが進歩を続けており、遅かれ早かれソフトウェア開発方法論には新たな劇的転換があると予想される。教職者としては、それにどのように備えればよいのだろうか? OOの方法論を教えることから、次の方法論では絶対に同じ過ちを繰り返さないことをわれわれは十分学んだのだろうか?
まず、次にどの方法論が来るのかについては、経験に基づく推測が必要だ。「クロスカッティング・コンサーン(横断的関心事)」などの名前で呼ばれるアスペクト指向方法論(AOP)が来るかもしれない、というのが筆者の直感だ。AOPはしばらく前からあるもので、複数の研究者がその概念を最初に生み出したと主張している。ここ2年の間に、AOPに関する複数の書籍が出版され、これをサポートするツールも登場している[注9]。
[注9] The Rational Edge 2004年2月号のAOPおよびテスティングに関する筆者のコラム(http://www-128.ibm.com/developerworks/rational/library/2782.html)参照。
- - PR -
われわれは、約50年くらい前からソフトウェアを開発してきたが、発見できた基本原理は悲しいほど少ない。しかしわれわれは、開発方法論の基本的概念をオブジェクト指向の開発からいくつか学ぶことができた。われわれのような大学教授たちは初心者に対し、オブジェクトには状態、動作、そして主体性があると教えている。そして、これらの3つの特性を基にして、オープン・クローズド原則(OCP)やLiskovの置換原則(LSP)などの高度な概念を紹介していく。学生たちがクリーンなインターフェイスや、クリーンなコンポーネントの構築を可能にするアブストラクションをすぐにうまく開発できるようになるのにさほど時間はかからない。
アスペクトのコミュニティが比較的大規模なシステムオブジェクト指向デザインを複雑にする犯人として名指ししたのがクロスカッティング・コンサーンだった。クロスカッティング・コンサーンの一例としては、金融アプリケーションにおけるトランザクションのロギングがある。システムの設計に着手する前に要件がすべてそろっていて、コードの中でトランザクションロギングの実行が必要な場所を特定できれば、クリーンなシステムを構築することができる。しかし、システムが進化すれば、コードの熟成と、クリーンなデザインの多少の破綻から、複雑化はほぼ避けられない。そこで、多くのモジュールに影響する複数のクロスカッティング・コンサーンを用意すれば、これらをインプリメントするオブジェクトに対し、適切なメッセージを適切なタイミングで送信することを覚えておかなくてはならなくなる。
アスペクトは、ほとんど魔法のように適切なタイミングでコールされるモジュールタイプ(つまりアスペクト)にすることにより、システムのこのような問題のコントロールを支援する。現在、アスペクトの概念は、OO方法論を補完する形になっている。もしこれ以上何もないのであれば、教授法に対する新しいアプローチはおそらく必要ないだろう。現在のOOADのコースに単純にアスペクトの講義を追加すればよいだけだ。
しかし、AOPにはOO方法論を補完する以上の役割がある。これは、問題に対する全く新しい考え方を提供してくれる。AOPで使う用語が標準化されていないため、いまのところそのポテンシャルを完全に理解するのは難しい。また、AOPの概念をインプリメントする共通メカニズムもない。しかし、このようなメカニズムは確実に登場するので、われわれは次世代のソフトウェアエンジニアたちに教えるための方法を探さなくてはならない。
喜ばしいことに、Siobhan ClarkeとElisa Baniassadの共著による「Aspect-Oriented Analysis and Design」という新しい書籍が先日出版された[注10]。同書は、アスペクトを応用する際のエンジニアリングに関する問題を幅広く扱っている。このような書籍は方法論の採用加速に役立つし、アスペクト技術に関する書籍は、今後2年ほどの間にほかにも複数出てくる見込みだ。
[注10] The Rational Edgeの本号の書評参照。
しかし、筆者には2010年までにAOPが開発方法論に選ばれるのを拒む要因が2つ考えられる。
1つ目が、今日のAOPコミュニティに標準の用語や技術がないことだ。マーケットシェアの独占を巡り、複数のインプリメンテーションが競合している。AspectJ[注11]がリードしているよう思えるが、JBoss AOP[注12]インプリメンテーションも支持者が多い。HyperJ[注13]は、これら2つよりはるかに強力なように思えるが、同時にはるかに複雑でもある。これらのインプリメンテーションには、クロスカッティング・コンサーンの定義や取り組みでそれぞれ独自のアプローチがあり、1つの標準がないことは、AOP全体の採用にとって障害となる。しかし、UMLがオブジェクト指向システム記述用の異なるアプローチを統一する方法を提供してくれたように、統一されたアプローチができればこの問題は克服できると期待したい。
[注11] http://eclipse.org/aspectj/参照。
[注12] http://www.jboss.org/products/aop参照。
[注13] http://www.alphaworks.ibm.com/tech/hyperj参照。
2つ目が、学習用のAOPツールや、強力なアプリケーションを開発するためのツールが十分にないことだ。しかし、このような状況はすぐにも改善されると感じている。すでに複数のツールが存在しており、AspectJのEclipse用開発ツールは筆者のお気に入りだ。ここ2年の間、これらのツールはコンパイラ、デバッガ、そしてビジュアライゼーションの各機能から、アスペクトの作成とシステムへの影響を調べるのを容易にする統合環境へと進化している。さらに、ソフトウェア開発の全フェーズでアスペクトの利用をサポートする「Concern Manipulation Environment」と呼ばれるEclipse構想も進んでいる[注14]。従って、現状のツールの不在は、長期的にはAOP採用の妨げにはならないかもしれない。
[注14] http://www.eclipse.org/cme/参照。
アスペクト最優先の教育方法は、言語サポート用のツールだけの問題ではない。学生をオブジェクトのようにアスペクトの世界に没頭させなくてはならない。要件から始まり、コンサーンを特定する方法や、クロスカッティングを決める方法を教える。そうしながら、学生にアスペクトの動作を定義させ、これらとオブジェクトを統合してシステムを形成できるようにさせるのだ。
われわれのデザインやアーキテクチャは、今日のクラスやコンポーネントで使うのと同じレベルでアスペクトを説明している。テストケースを書いて、オブジェクトの動作とアスペクトの動作をテストする。アスペクト・ファースト・アプローチはオブジェクト指向アプローチを土台にしており、ソフトウェア開発を一歩進化させることになる。オブジェクトがソフトウェア開発手法に与えたのと同じレベルの影響をアスペクトが与えるかどうか筆者には疑問だが、これらは複雑性と低品質を撲滅するための戦いにおける新しいツールとなるだろう。アスペクトをうまく展開させるには、研究者にはアスペクトを使うために統一されたアプローチの開発、教師にはその原理とテクニックを啓蒙する効率的な解説方法の模索、そして現場の人間には新しいテクニックの十分な学習がそれぞれ必要になってくる。
筆者は、2010年までには新しいソフトウェア開発者がこの市場に参入し、クロスカッティング・コンサーンに関連するソリューションを今日の開発者がオブジェクト指向ソリューションでしているのとほぼ同じように応用していると想像する。このような変化を予想することは、われわれの業界をエキサイティングなものにしている要素の1つであり、将来のソフトウェア専門家を教えることは非常に貴重なことだ。筆者は、学生とかかわる自分の仕事が次の大きな進化に貢献するかもしれないことを大きな誇りに思っている。
|
本記事は「The Rational Edge」に掲載された「Beyond an objects-first approach」をアットマーク・アイティが翻訳したものです。 |
|
3/3 |
|
INDEX |
||
| RationalEdge オブジェクト指向を超えて |
||
| Page1 ◆ 構造化プログラミングの紹介 |
||
| Page2 ◆ 教育と学習に対するオブジェクト・ファーストのアプローチ |
||
| Page3 ◆ アスペクト指向方法論は次のキーアイテムか? |
||
| IT Architect 連載記事一覧 |
The Rational Edge
米ラショナルソフトウェアがWeb上で毎月更新するオブジェクト指向開発のための論文集「The Rational Edge」を@ITが厳選して翻訳
- 第1回 要件仕様の決定に時間を割かない結末は?
- 第2回 先駆者に学ぶ「開発プロセス改善の原則」
- 第3回 あるプロジェクトリーダーの成功ストーリー
- 第4回 ソフト開発の変革というWebサービスの可能性
- 第5回 プロダクト・マネジメントを成功に導くには
- 第6回 分散コンピューティング時代のテスト手法
- 第7回 プロジェクトの特性に合わせた要件定義手法の選択
- 第8回 優秀なテスターの育成と訓練方法
- 第9回 「アジャイル」「RUP」「Rational XDE」の融合
- 第10回 Dr.ユースケースの “ユースケース人生相談”
- 第11回 Webサービスのテスト技法進化論
- 第12回 要件定義の考古学
- 第13回 チェスとソフト開発、その相関関係を探る
- 第14回 開発計画が破たんするには理由がある
- 第15回 要件定義の管理技術(Lv0〜Lv5)
- 第16回 オン・デマンドの波をキャッチしろ
- 第17回 オープンソース時代のテスト手法、そのノウハウ
- 第18回 オープンソース時代のテスト手法、テストのロードマップ
- 第19回 オープンソース時代のテスト手法、テストのまとめ
- 第20回 『オープン』の正体 (前編)
- 第21回 『オープン』の正体 (後編)
- 第22回 サブシステムの「なに?」「なぜ?」「どうやって?」
- 第23回 サブシステムとはモデリング概念である
- 第24回 アスペクト指向プログラミング オーバービュー
- 第25回 「プロジェクト管理」を管理するために
- 第26回 レッスン1:何もせずに取り残されるな
- 第27回 レッスン3:相違に注意を払え
- 第28回 大規模プロジェクトにアジャイルを適用する方法(前編)
- 第29回 大規模プロジェクトにアジャイルを適用する方法(後編)
- 第30回 アジャイル開発:成熟期の到来、その道のり
- 第31回 UML 2.0のキホン:コンポーネント図の詳細解説
- 第32回 コーディングの知恵を要件定義で利用する
- 第33回 隣のテストチームが優秀ないくつかの理由(前編)
- 第34回 隣のテストチームが優秀ないくつかの理由(後編)
- 第35回 中国のソフトウェア開発現場はこんなにスゴイ
- 第36回 ソフトウェア開発の「いま」と「近未来」の話
- 第37回 ルネサンスの巨匠たちに学ぶエンジニアリングの技
- 第38回 オブジェクト指向を超えて
- 第39回 ユーザー要件を引出すテクニック
- 第40回 ITプロジェクトを見える化する
- 第41回 ソフトウェアアーキテクチャって何なの?(前編)
- 第42回 ソフトウェアアーキテクチャって何なの?(後編)
- 第43回 ソフトウェアアーキテクトの役割
- 第44回 ソフトウェアアーキテクティングのプロセス
- 第45回 ソフトウェアアーキテクティングのメリット
- 第46回 ウォーターフォールから反復型への移行手順
- 第47回 トランザクション管理の複雑性を克服する パート1
- 第48回 トランザクション管理の複雑性を克服する パート2
- 第49回 汎用グラフィカルモデリング言語「SysML」 パート1
- 第50回 グラフィカルなモデル言語で製品構造を記述
- 第51回 キミのコードが汚い理由
- 第52回 「設計」や「構築」よりも重宝されるスキル
- 第53回 専門家に聞くモデル駆動開発のメカニズム
- 第54回 プロジェクトのはじめに計画を立てるのは無謀
- 第55回 「この開発プロジェクトは中止!」の基準
- 第56回 なるほど! ビジネスユースケース
- 第57回 そうだったのか! システムユースケース
- 第58回 不完全なコードは推敲フェイズで潰しておきたい
- 第59回 ビルドが全滅する原因
- 第60回 初歩の「Perl」「Python」「Ruby」
- 第61回 開発プロジェクトを「統治」するベストプラクティス
- 第62回 開発プロジェクト「統治」のピンポイント解説
- 第63回 反復開発の「ここはぜひカバーしたいポイント」
- 第64回 開発プロセス導入のアンチパターン
- 第65回 プロセスはチャンスが訪れるたびに改善する
- 第66回 自己管理型チームの利点と弱点
- 第67回 人事評価と開発者のモチベーション
- 第68回 鈍重な開発チームは鈍重なシステムを作る?
- 第69回 ソフトウェアが複雑なのは仕方がない?
- 第70回 ソフトウェアの複雑性を手なずける
- 第71回 見積もりの精度 Accuracy of Estimation
- 第72回 アジャイル開発の広範な普及を目指して
- 第73回 アジャイルとシステムテストの新たな関係(前編)
- 第74回 アジャイルとシステムテストの新たな関係(後編)
ホワイトペーパー(TechTargetジャパン)
|
|

