レベル: 初級 Eric Allen (eallen@cs.rice.edu), Ph.D. candidate, Java programming languages team, Rice University
2002年 6月 17日 Javaコードの診断 シリーズの最後となる今回、Eric Allen氏は、ソフトウェア開発における現在のいくつかの傾向について説明し、また今後の傾向はどうなっていくのかについて言及します。
読者のみなさん：今回のコラムがJavaコードの診断シリーズの最後となることをお伝えすることは、とても残念なことです。私は(ついに)Ph.D.を取得し、プログラミング言語における新しい研究プログラムを始めるためにindustrial labsを去ります。
この最後の記事では、楽しんで将来についての予測をしてみましょう。ソフトウェア開発の未来において、業界で主流となる傾向と、これらの傾向がもたらすであろう影響のいくつかについて説明をしていきます。また、ここ２年半の間このシリーズで扱ってきた効果的なソフトウェア開発の視点から話を進めていきます。エラー防止と診断に効果的な行いが、ますます複雑になるデジタルワールドをうまく管理するのに重要な役割を担っていることに、いつものように特に注意をしください。
業界が全体としてどこへ向かっているのかについて考察すべき３つの一般的な傾向があります。
- パーベイシブ・コンピューティングとワイヤレス・コンピューティングの激増
- 高信頼性ソフトウェア開発のための増加し続ける費用
- 早急なペースで進化し続けるコンピュータ・パフォーマンスの改良
これら３つの傾向は、ソフトウェアの基礎およびそれを構築するためのエンジニアリング取引に関して、新たな局面を開くことになります。ハイレベルでは、ソフトウェアの費用と普遍性はより抽象的な方向へ私たちを向かわせています。たとえば、明確なセマンティクスとセキュリティー特性を備えた強力なバーチャル・マシーンが、ソフトウェアの開発や保守をより簡単に、より多くのプラットフォームで可能にするということです。
同時に、進化し続けるコンピュータ・パフォーマンスによって、我々は受け入れ難いパフォーマンスの低下に直面することなく、これらの抽象化を実現できるようになるのです。私は次世代のソフトウェア製品を作り出す助けになるはずの新しい抽象化を構築できると信じているいくつかの方法で、挑戦を試みたいと思っています。
コンポーネント・ベースの開発
コンポーネント・ベースの開発では、ソフトウェアは外部参照が個々の実装から切り離されているモジュール単位で開発されています。これらのモジュールは本格的なアプリケーションを作るために、動的なリンクが可能です。「外部参照」は参照されるオブジェクトではなく、使用されサブクラス化される外部クラスを含むことに注目してください。(Javaプログラミングにおいてさまざまなパッケージがお互いを参照する方法について考えてみてください)。このコラムでは、Javaのコンポーネント・ベース・プログラミングの１つのビジョン、つまりJiazzi(2002年11月のコラム、「パッケージの依存関係の分離」を参照してください)について説明してきました。
コンポーネント・ベース・プログラミングは２つの補完的な利益を保証します。前述の３つの傾向がますます顕著になるとともに、これら２つの利益はますます重要になっていくでしょう。第一の利点は、コンポーネント・ベースのシステムは再利用が可能ということです。例えば、テキスト編集サポートを提供する今日の無数のプログラムを考えてみてください(メールクライアント、ワープロ、IDEなど)。またEメール処理のサポートを提供する多数のクライアントを考えてみてください。多数のプログラムがこれらのサービスを提供するにも関わらず、専用Eメールクライアントのように、Eメールを処理するプログラムはほとんどありません。同様に、専用テキストエディタと同じレベルでテキスト操作ができるメールプログラムはないと言って良いでしょう。しかし、なぜ全てのメールクライアント(IDE、ワープロなど)がそれ自身のテキストエディタを開発しなければならないのでしょうか？さまざまなサード・パーティ・コンポーネントによって実装される標準「テキストエディタ」APIがあれば、もっと便利になるでしょう。メールクライアントのようなツールは、このAPIから好みの実装を選択して、プラグインできるのです。つまり、アプリケーションの起動中、動的にリンクされた既成のコンポーネント(たとえば、好みのエディター、好みのメールクライアント)によって、ユーザが構築している環境を知ることさえできるようになるのです。
コンポーネント・ベース・モデルのもう１つの利点は、テスト性能向上の可能性です。Javaコードでは、I/O libraryクラスなどのクラスへの外部参照は、リコンパイルなしには変更されることができない組み込まれた参照です。その結果、外部参照をしているプログラムの一部を分割してテストすることは難しいです。例えば、ファイルシステムから読み書きすることはできない状態で、プログラムがファイルシステムを適切に利用しているかどうかをテストすることは難しいことと同様です。しかし、単体テストでのファイルの読み書きはテストを遅延させ、複雑さ増すことになります。(tempディレクトリを作成したり、使用後はファイルを消すといったことです)。理想的にはテスト目的のためのI/O libraryへの外部参照をプログラムから分割したいです。
私たちがコンポーネント・モデルを構築するには多数の方法があります。J2EEはWeb Serviceのオブジェクトレベルで、コンポーネント・モデルを提供しています。EclipseはIDEコンポーネントでモデルを提供しています。Jiazziはソフトウェアの分割コンパイルされた「unit」が完結したアプリケーションを作るためにリンク可能なモデルを提供しています。各構築法は個々のコンテキスト内でモデルの使用を明記します。私たちは今後数年でより多くの構築法を見ることになるでしょう。
アサーションと機能要件
コンポーネント・ベース・プログラミングとの協調では、アサーションとその他のメソッドを重要視していかなければなりません。このメソッドはコンポーネントを保持しているとされる機能要件が、実際に条件に合致することを保証しています。タイプ・システムそれ自身は全ての意図された機能要件を十分に補えられるよう表現されていません。例えば、テキスト編集APIのメソッドタイプが「開かれているドキュメントだけを閉じることができる」というような機能要件を補えられると思うべきではありません。私たちはそのような機能要件を明確にするのに、正式でない文書に頼ることができますが、正式なもので確認するほうがより良いのです。
不可欠な機能要件が満たされていることを明確にすることは、コンポーネントのカプセル化には必要なことです。一般的に、クライアントプログラマは、公開されたAPIに書かれたもの以外、どのようにコンポーネントがふるまうかについて判断することができないでしょう。APIに含まれていないコンポーネントのいかなるふるまいもクライアントプログラマが頼りにできるふるまいではありません。もし公開されていないふるまいが結果的にランタイムエラーとなったら、プログラマが問題の原因をつきとめて、修正することは非常に困難でしょう。
機能要件をコンポーネントに指定する方法を少しでも改善するために、進行中のいくつかの調査プロジェクトがあります。プロジェクトのうちのいくつかは、Time Rover(2002年6月のコラムを参照してください)のように、実行時のふるまいの属性を表現するために論理モデルやその他の論理形式を使っています。
機能要件を表現するための他のアプローチは、総称型（Generic Types）、つまりその他の型によってパラメータ化された型(この連載の直近のトピック)でタイプ・システムを強化することです。
より強力な機能要件を追加するためのアプローチは、依存型(dependent types)です。依存型は、実行時の値(他の型でパラメータ化された総称型と比較してください)でパラメータ化された型です。
依存型の標準的な例は、配列サイズでパラメータ化された配列型です。型にサイズを含むことで、コンパイルタイムチェッカーは配列へのアクセスを象徴的に分析して、配列を超えたアクセスが行われていないかを確認することができます。依存型のその他の強制的な使用は、Boyapatiと LiskovおよびShrira(オリジナルの論文へのリンクに関しては参考文献を参照ください)によって開発されたオーナーシップ型(ownership types)です。
オーナーシップ型はオーナー・オブジェクトによってパラメータ化されたオブジェクト型です。例えば、コンテナー上のイテレータを思い浮かべてください。イテレータはコンテナーによって所有されており、それゆえ、コンテナーはイテレータへ特別なアクセス権限をもっている、といえます。内部クラスはアクセス権限上、同じ制御のうちのいくつかを提供しますが、オーナーシップ型はより強力で柔軟なメカニズムを提供します。
リファクタリングツールの継続した進化
ソフトウェアアプリケーションは大きくなるとともに、コード・ベースを保守・改良したり、バグを診断することはますます難しくなってきています。この問題は、能力のある開発者の欠如により悪化しています。有難いことに、開発ツールは我々にソフトウェアシステムにとって強力なコントロールを提供しています。最も強力な２つのコントロールは単体テストツールと リファクタリング・ブラウザです。
単体テストツールにより、私たちはプログラムの主要な機能要件をチェックすることができます。そして、リファクタリング・ブラウザはふるまいを規定しているコードを修正するための直接的で強力な多くの方法を提供します。私たちはstatic typesと単体テストを相互に活用する「第二世代」の単体テストツールを知り始めています。これにより、コード範囲の自動的なテストや、テストの自動生成ができるようになっています。また、リファクタリング・ブラウザは標準的な範囲により多くのリファクタリングを追加しています。長期的には、我々はより洗練されたツールを探していくべきです。たとえば、プログラム内で設計パターンの用途(潜在的な使用)を認識し、それらを適合する「pattern savvy」リファクタリング・ブラウザのようなツールです。
我々はよりアグレッシブなリファクタリングを行うために、最終的に単体テストを活用する開発ツールさえ予見できます。Martin Fowlerの古典テキスト「Refactoring: Improving the Design of Existing Code」の中で、リファクタリングは、プログラムの外側に見える振る舞いを保持するよう定義されています。しかし一般的に、我々はプログラムの外側に見えるふるまいの全ての側面には関心がありません。代わりに、ふるまいのある主要な側面には注意しています。しかし、これらの主要な側面はまさしく単体テストでチェックすべきことなのです。
それゆえ、リファクタリング・ブラウザはふるまいのうちのどの側面が重要であるかを決定するために、単体テストを潜在的に活用するでしょう。その他の側面はコードを単純化するために、リファクタリング・ブラウザによって思いのままに改良されるでしょう。いわば、このようなリファクタリング・ブラウザの機能は、単体テストによって決定するリファクタリングの種類を決定しそれをプログラマに伝えることから、テスト範囲をチェックするためにも活用できるかもしれません。
対話式デバッガー
アプリケーションはより複雑になり、リモート・プラットフォームで実行されるようになっているため、バグの検証は、大きなチャレンジとなります。デプロイするプラットフォーム上でソフトウェアをデバッグすることは不可能であり非現実的です。理想は、リモート側でソフトウェアのデバッグをすることです。
Java Platform Debugger Architecture(JPDA)は、デバッガが別個のJVM上で実行できることで、リモートのような機能を提供します。そして、リモート・デバッキング・セッションでRMIを使うことができます。しかし、リモート・デバッキングに加えて、デバッグ開始時に利用可能なアクセスポイントとデバッグ中に計算状態が確認できるビューに関するより多くの制御をプログラマに与えると、診断はより効果的になされます。
現在のデバッガーでさえ、プログラマは必要な情報を得るためには、多くのコンテキスト内で「printlns」のお世話にならなければなりません。理想的は、「printlns」を使わないデバッガーをもつことでしょう。実際、Javaプログラミング言語チーム(JavaPLT)で、我々はちょうどそのデバッガーを作っています。このデバッガーは、2003年の秋にオープンソースがリリースされますが、シームレスに統合された「対話ウィンドウ」を使用します。これにより、より多くのコード評価が出来るようになるコード評価ができるようになります(2002年3月のコラムを参照してください)。対話ウィンドウは任意の式評価をとおしてデバッキングプロセスを開始させます。そして、コンテキスト内に実行プロセスと対話するためのブレークポイントを使用して、プロセス内でその時点での参照可能なスコープへアクセスし、思うままに改良することができます。JavaPLTデバッガーはDrJava IDEの一部として、また独立したEclipseのプラグインとしてリリースされるでしょう。.
操作が共通の開発ツール
開発ツールがより高機能になってきたため、全てのツールのうちで最もよいものを１つのベンダーが提供するのは非常に難しくなってきました。よって、開発者は異なったベンダーのいろいろなツールに頼らざるを得なくなります。もしさまざまなツールが、各ツールが他のツールでうまく機能するものを受け入れて、共にうまく機能すれば、どんなによいでしょう。
Eclipseのようなプロジェクトはこの一歩先をいく考えを採用し、お互いの機能を活用するためにツールを相互運用する方法を提供しています。やがて、このモデル(もしくはこれに相当するもの)が真に「eclipse」従来のオールインワンIDEとなることを期待するべきです。
メタレベルのアプリケーションロジック
最後の将来像として、ソフトウェアがまさに長い期間とるであろう１つの方向について考察してみましょう。アプリケーション内でおきる最も一般的なバグの多くは、ユーザが一度アプリケーションの基礎をなす詳細を理解すれば、簡単に修正できる単純な間違いです。問題は彼らが使用しているアプリケーション全体の基礎をなす詳細を理解する時間がユーザにないということです。
この問題への１つの解決法はメタレベルの知識を、アプリケーションが起動したら何をすべきかというようなコンテキストをエンコードしてアプリケーションへはめこむことでしょう。例えば、ワープロのメタレベルの知識は、後に他の人に読まれる英語ドキュメントを作成するために、PC上で人によってプログラムが使用されたという論理説明を含むでしょう。このエンコードされた知識があれば、アプリケーションは何か失敗した時、ユーザが何をしようとしていたのかを推測できるかもしれません。(もちろん、アプリケーションも最初の時点で何が悪かったのかを決めなければならないでしょう)
そのようなメタレベルの知識は、アプリケーションに頑健性を追加する強力なメカニズムです。このことはまた非常に危険でもあり、その危険性に関して最も心配なことは、この方向を推し進めようとしている強い支持者にはしばしばそれが見過ごされるということです。結局のところ、自身を動的に再構成するアプリケーションのふるまいは、非常に予測不可能になってしまうかもしれません。ユーザは、ある状況下でどのように彼のプログラムがふるまうかを知るのはとても大変だと思うようになるかもしれません。そして、プログラムの開発者もまたその信頼性に安心できるようになることは非常に難しいと思うようになるかもしれません。何度も見てきたように、プログラムのふるまいを予見したり理解することができないことは、容易に予測できる結果--つまりバグの多いソフトウェアをもたらすのです。
明らかに、コンテキストについてメタレベルの知識をもった順応性のあるソフトウェアは、ソフトウェアアプリケーションの性能をかなり改善する可能性を秘めていると私は考えています。しかし、もしそのような性能を加えたら、我々はプログラムについて効果的に判断できる方法を見つけなければなりません。
予測可能なふるまいを犠牲にすることなく、メタレベルの知識と順応性(非常に制限されてはいるが)の形を組み込んでいるソフトウェアシステムのすばらしい例は、TiVo パーソナル・デジタル・レコーダー(もしくは、同様の製品)です。Tivoはどの番組をあなたが見たいかをを決めるために、あなたのテレビ鑑賞の習慣を使用していますが、この順応性は非常に制限されています。TiVoはその番組が適応できるふるまいのレスポンスのいずれかであるかに関係なく、録画するというあなたの命令に常に従います。TiVoは非常にシンプルなメタレベルの知識のフォームをとりますが、使用されるメタレベルの知識はより複雑になっていくので、順応性のあるふるまいに対する管理を維持し続けるべきです。もしもSFの領域からのいくぶん架空な検討を許していただけるならば、我々はアイザック・アシモフ氏(Isaac Asimov)によって作られた前例に従うでしょう。Asimovianロボットは並外れて強力なマシーンでした。しかし、行動にある程度の予測を考慮に入れた、絶対的で不可侵のルールに制御されていたのです。
最後に
この議論を終えようと決めたのはAsimovianロボットのノートの上です。私は２年半の間のディベロッパーワークスのチームの努力に感謝したいです。このコラムを連載する機会を与えてくれたeditor のJenni Aloi氏、ディテールへのすばらしい配慮をもったcopy editor のChristine Stackel氏、最後にこのコラムのコンテンツの改良に大いに尽力していただいたdevelopmental editor のKane Scarlett氏
読者のみなさんへ：私はみなさんがこの記事によってなにか得るものを見つけてくださることを希望しています。この記事を書くことは、私にとて計り知れない貴重な経験となりました。みなさんに感謝をし、みなさんのプログラムからバグの回避と診断がうまくいくよう願っています。
参考文献
- Eric Allenの 「Javaコードの診断」 を読んでください。以下の記事は今回の記事に特に関係があります。
-
JSR-14プロトタイプ・コンパイラーをダウンロードして、Javaプログラミングの総称クラスを体験してください 。ここには、拡張言語で記述されたプロトタイプ・コンパイラーのソース、コンパイラーの実行および起動用のクラス・ファイルを含む1つのJARファイル、およびコレクション・クラス用のスタブを含む1つのJARファイルが含まれています。
- Javaコードへの総称型の追加については、Javaコミュニティー・プロセスの提案 「JSR-14」 を参照ください。
- 今すぐNextGenのプロトタイプをダウンロードすることができます。
-
DrJava を調べてください。これは、式やステートメントの対話式な評価やJavaの構文やコンパイルをサポートしている無料Java IDEです。
- また、OmniCoreのJ2SEおよびJ2EE開発用ハイ・パフォーマンス・コード分析エンジン、CodeGuide もお試しください。このエンジンでは、すでにJSR-14プロトタイプ・コンパイラーを使用して、Javaコード内の総称型のIDEサポートが提供されています。
-
効果的なリファクタリングの詳細については、Martin Fowler氏のWebサイトを参照してください。
- IBM研究所の「Automatic Code Generation from Design Patterns」 (PDF), はデザイン・パターンの実装を自動化するアーキテクチャーと実装について解説しています。
- Eric Allen氏のバグ・パターンに関する著書「Bug Patterns in Java」(Apress、2002年) も参照してください。この本では、バグ・パターンに重点を置いたコンピュータ・プログラムの診断とデバッグの方法論、エクストリーム・プログラミングの手法、およびテスト可能で拡張性の高い強力なプログラムの作成方法が紹介されています。
- Javaテクノロジーに関するその他の参考文献は、developerWorks のJavaテクノロジー・ゾーンでご覧いただけます。
著者について  | | | Eric Allen氏は、テクノロジーとコンピューター業界に関して、実践的な知識を幅広く持っています。コーネル大学ではコンピューター・サイエンスと数学の学士号を取得し、ライス大学ではコンピューター・サイエンスの修士号を取得し (CycorpでJava開発者主任としての実績も持つ)、現在は、ライス大学のJavaプログラミング言語チームの博士課程に在籍しています。Robert "Corky" Cartwright博士の助言のもと、氏は、主に、ソース・レベルとバイトコード・レベルでのJava言語のセマンティック・モデルと静的分析ツールの開発について研究しています。また、セマンティック形式論と型チェックによるセキュリティー・プロトコルの検証についても研究しています。 氏は、初心者向けに設計されたオープン・ソースのJava IDEであるDrJavaのプロジェクト・マネージャーおよび創立メンバーです。また、NextGenプログラミング言語 (付加的な実験機能を備えたJava言語の拡張版) に対するライス大学の実験的コンパイラーの開発主任でもあります。氏は、オンライン雑誌のJavaWorld でフォーラムの司会者を務めています。空き時間には、ライス大学のコンピューター・サイエンスの学生にソフトウェア・エンジニアリングを教えています。氏の連絡先は、eallen@cs.rice.edu です。
|
記事の評価
| 
