PR
表1
表1
[画像のクリックで拡大表示]
図1
図1
[画像のクリックで拡大表示]

 本連載も70回を超え,次回が最終回となります。そこで今回と次回の2回にわたり,これまでの連載で取り上げてきた内容を簡単に振り返ってみることにします。今回は,「コードの再利用とセキュリティ」という視点から振り返ります。

コードの再利用とは

 コードの再利用とは,読んで字のごとく,既存のコードを再利用し,新しいプログラムを作成する開発行為を指しています。既存コードの多くは各種のテストが完了しているため,そのまま無条件で再利用できれば,間違いなく開発効率が向上します。その意味では,コードの再利用は開発者に多大なメリットをもたらします。

 表1をご覧ください。この情報は,Internet Explorer (IE)を構成する代表的な3種類の再利用コードを示しています。これらのコンポーネントは,一般には,COMコンポーネントと呼ばれ,基本的なプログラミング知識を備えていれば,Windowsユーザーならだれでも再利用できます。

 「機能概要」欄を見ると分かるように,これらのコンポーネントをうまく再利用すれば,日常的に使用するWindows機能とWeb閲覧機能を効率的にプログラミングできます。基本的なWindows機能とWeb閲覧機能はこれらのコンポーネント内に実装され,Windowsユーザーは公開されているインタフェースを呼び出すだけで必要な機能を利用できるわけです。このようなソフトウエア開発手法は,「実装とインタフェースの分離」と呼ばれ,コードの再利用を根本から支えています。

 今度は,「バージョン」と「作成日」という2つの欄を見てみましょう。3つのコンポーネント間には微妙な違いがあることが分かります。3つのコンポーネント間のバージョンと作成日は同一ではありません。この事実から,私たちは次のような推測が可能になります。

  • 3つの再利用コンポーネントは,異なる開発チームにより開発された可能性がある
  • セキュリティ・ホールの発覚などの問題への対処がコンポーネント単位で行われた可能がある

 セキュリティについては後ほど説明しますので,ここでもう一度「機能概要」欄を見てください。すでに説明したように,これら3つのコンポーネントを再利用できれば,日常的な作業を効率的に自動化することができます。そしてその自動化技術は,Officeなどの他のWindowsアプリケーションの自動化にそのまま応用することができます。この自動化技術はCOM(Component Object Model)と呼ばれ,発表当時,米MicrosoftのBill Gates氏は「この技術に社運をかける」と豪語していました。ちなみに,Microsoft社が現在社運をかけようとしているCLR(Common Language Runtime)は,COMと深い関係にあり,当初「COM99」と社内では呼ばれていました(参照)。

 3つのコンポーネントのインターフェイス情報をOLEVIEW.EXEというツールで取得してみると,それぞれのコンポーネント開発者は「継承」という技術手法を応用し,バージョンアップを重ねてきていることが分かります。オブジェクト指向理論などを学習している方にはご存知だと思いますが,「継承」はCOM固有の技術概念ではありません。「継承」は,Simulaというプログラミング言語を設計したKristen Nygaard氏が考えた概念といわれています(参照)。

 筆者は以前,「MSHTML.DLL」のインタフェース情報をOLEVIEW.EXEで取り出したことがありますが,その出力情報量は数メガに及び,驚いたことがあります。そのインタフェース情報を調べてみると,W3C主導で行われているHTML仕様書の改定結果を必死で実装するMicrosoft社の担当開発者の姿が浮かび上がってきました。ここでは,再利用可能なコンポーネント開発では,オブジェクト指向開発が有効な開発手法であることを覚えておきましょう。

コードの再利用とセキュリティ

 この連載を最初から目を通してみると,セキュリティに関する記事が多いことが分かります。Microsoft社は発覚したセキュリティ・ホールに常に対応してきましたが,その対応は,基本的に,問題を抱えた再利用コンポーネントをインターネット経由で差し替える方向でとられてきました。3つのコンポーネントの「バージョン」と「作成日」情報が微妙に異なっているのは,おそらく,セキュリティ・ホールへの対策の痕跡を示しているのでしょう。前回触れたように,Microsoft社はVisual C++ 2005 Express Edition(VCEE)という無料開発ツールを提供していますが,VCEEの関連サイトは図1のようなページを公開しています。

 ご覧のように,セキュリティ・ホール対策への経験を生かし,バッファ・オーバーランなどの発生を防止する対策をプログラミング・レベルで行っています。今後も新たなセキュリティホールが発生することは,おそらく避けられないでしょう。このため,コンポーネント・レベルでのコードの差し替えは今後も続くことになると思います。このようなコンポーネント差し替え作業は,一見すると無意味な印象を受けてしまいますが,そこには,未来に向けた何らかの進歩が見られるはずです。

 来年以降のMicrosoft社のビジネスを技術面で主導するといわれる Ray Ozzie氏(chief technicalofficer)は,社内メールで次のようなことを述べています。

私たちには,MSNやWindows Updateの最新技術を迅速に投入する技術と経験がある。新しいビジネス・モデルに対応する技術基盤は80%備わっている。残りの20%を頑張って身に付けよう!

 この表現に興味のある方は,リンク先のメールに目を通してみるとよいでしょう。基本的には,セキュリティ・ホール対策で得た経験は,インターネットの更なる活用への道を開く基礎となっています。筆者は,shdocvw.dllやshell32.dllなどのインターネット経由でのコンポーネント差し替えは,Windowsシステム自体のバージョンアップに等しいのではないか,と考えたことがあります。そして今,セキュリティ・ホール対策で得た経験が私たちWindowsユーザーにどのような利益をもたらしてくれるのかを注目しています。

今回のまとめ

  • コードの再利用は開発効率を改善する
  • セキュリティ・ホールへの対策は,インターネット経由のコンポーネント単位の差し替えで行われてきた
  • コンポーネント単位の差し替え経験は何らかのメリットをWindowsユーザーにもたらすことが期待される