JP2001526421A

JP2001526421A - 異なるフレームワークバージョンで作成されたオブジェクト指向プログラムが通信することを可能にする装置および方法

Info

Publication number: JP2001526421A
Application number: JP2000524719A
Authority: JP
Inventors: マルクジャブロンスキー; マークデイビス
Original assignee: オブジェクトテクノロジーライセンシングコーポレイション
Priority date: 1997-12-08
Filing date: 1998-12-08
Publication date: 2001-12-18
Also published as: WO1999030226A3; WO1999030226A2; US6272521B1; CA2312814C; DE69802839D1; DE69802839T2; CA2312814A1; EP1038219B1; EP1038219A2

Abstract

(57)【要約】バージョン間のミスマッチが原因で起こるクラスの欠落という問題にもかかわらず、オブジェクトフレームワークが相互に通信できるようにする、ストリームライタとリーダのクラスおよびメソッド群が提供されている。ストリームライタは、将来のオブジェクトクラス情報がストリーム化されるとき、既存バージョンと互換性のある代替オブジェクト情報を書くことによって既存バージョンのクラスから拡張する新バージョンのクラスを取り扱うように改良されている。このようにして、代替オブジェクト情報は各より古いバージョン用に書かれる。各より古いバージョンに対応する、代替オブジェクトの各々の情報は既存オブジェクト情報の後にエクステンションとして追加され、そのエクステンションの長さは先頭に書かれている。ストリームリーダは、より古いバージョンのストリームリーダがオブジェクト情報を読み取りが、最初の代替オブジェクト（これは以後のバージョンに対応している場合がある）を理解しないとき、そのエクステンションで指定された長さをスキップし、２番目の代替オブジェクトを読み取るように改良されている。２番目の代替オブジェクト情報が理解できないときは、リーダはその理解不能オブジェクト情報をスキップし、各代替オブジェクトついて継続する。代替オブジェクトのどれもが理解されなかったときは、例外がスロー (throw) される。ある実施例では、使用されない代替オブジェクトの情報は破棄されないが、代わりに一時記憶域に格納される。そのあと、オブジェクトが再びストリームアウトされると、格納情報が追加され、ストリームに戻される。

Description

【発明の詳細な説明】

【０００１】（発明の分野）本発明はオブジェクト指向システムフレームワークから作成されたオブジェク
ト指向コンピュータプログラム、および、その基礎となるシステムフレームワー
クが変更されたとき、かかるプログラムの互換性を保証するための装置および方
法に関する。

【０００２】（発明の背景）ソフトウェアプログラムは絶えず複雑化している。初期のプログラムは単純な
手続き型コードから構成され、単純なコマンドラインインタフェースとテキスト
ディスプレイをユーザに提供していた。これらの単純なプログラムは、グラフィ
カルユーザインタフェースと多数の機能を備えた複雑なプログラムで徐々に置き
換えられている。

【０００３】プログラムが複雑化するのに伴い、プログラムを書き、デバッグするために必
要とされる作業量も、激増している。その結果、作業の大部分は、最新で、完全
機能を備えたプロダクトを作成するために必要なプログラミング量を低減化する
ことに向けられている。これらの作業で最も成功したものの１つは、オブジェク
ト指向プログラミング (object-oriented programming) の開発であり、そこではプログラムは「オブジェクト」と呼ばれる、個々のエレメントの集まりとして
設計されている。オブジェクトは、多くの場合、修正と再利用が可能であるため
開発作業が軽減化されている。

【０００４】この分野の精通者ならば理解されるように、オブジェクト指向プログラミング
で言う意味のオブジェクトとは、データとそのデータに作用を及ぼすオペレーシ
ョンを含むソフトウェアエンティティ（entity）のことである。オブジェクトは
プログラムのランタイムにのみ存在し、プログラマによって実際に書かれたオブ
ジェクトの「クラス」から作成されている。つまり、そのインスタンスが生成さ
れている。あるプログラマによって書かれたクラスコードは、そのコードからオ
ブジェクトのインスタンスを生成することにより、別のプログラマによる「再利
用」が可能になっている。さらに、開発者は、継承 (inheritance) と呼ばれるプロセスによって新しいクラスを既存のクラスから派生することにより、クラス
コードを再利用することができる。周知のように、派生クラス、つまり、サブク
ラスは、それが派生される元のクラスの特性を継承している。継承された特性は
オーバライドし、派生クラスをカスタマイズするように変更することができる。

【０００５】開発作業の負担をさらに軽減するために、オブジェクト指向プログラミングを
サポートする多くの製品は、開発者が上述したインスタンス生成とサブクラス化
によって使用し、再使用できるクラスライブラリを提供している。このようなラ
イブラリと継承の原理を利用すると、開発者は、そのコンテンツと振る舞いが異
なっていても、同じインタフェースを共有する関連オブジェクトのファミリを作
成し、使用することができる。

【０００６】クラスライブラリは非常に有用であるとしても、いくつかの欠点がある。例え
ば、大きなクラスライブラリは、場合によっては、数百のクラスを含んでいるこ
とがあるため、クラスの関係が非常に紛らわしくなっている。開発者が詳細なド
キュメンテーションをもっていなければ、クラスがどのような関数を実行するこ
とになっているかを、理解することが困難になっている。また、クラスの関係と
オペレーションを完全に理解していないと、変更や追加を行うことが困難になる
場合もある。さらに、クラスライブラリを使用して書かれたプログラムは、制御
の流れや、クラスからインスタンス生成されたオブジェクト間のやりとりに責任
を持つことが依然として要求されている。

【０００７】以上の結果として、アプリケーション開発作業をさらに軽減化するために、「
フレームワーク」と呼ばれる別のアプローチが使用されている。フレームワーク
とは、関連をもつクラスが集まったもので、お互いに協力し合って特定の問題を
解決するオブジェクトの集まりを生成し、前もって作られた実働アプリケーショ
ン (working application) の構造を提供している。フレームワークはオブジェクトテクノロジを基礎にしているので、オブジェクトの振る舞いを継承し、オー
バライドすることによって、開発者はフレームワークを拡張し、特定の専門分野
でカスタマイズしたソリューションを作成することが可能になっている。しかし
、フレームワークによって解決される問題は、クラスライブラリ内の個々のオブ
ジェクトによって解決される問題以上に、はるかにハイレベルである。例えば、
フレームワーク内のオブジェクトを使用すると、基本的なワードプロセッサアプ
リケーションが得られるのに対し、クラスライブラリを使用すると、テキストス
トリングの選択やコピーといったように、ワードプロセッサの個々の機能が得ら
れることがある。問題は、クラスライブラリまたはフレームワークのどちらかを
使用してアプリケーションプログラムを開発するときにも、起こっている。これ
らの問題が起こるのは、クラスライブラリとフレームワームが変更されることが
あり、新バージョンのクラスライブラリやフレームワークがクラスを除去したり
、新しいクラスを追加したりすることがあり得るからである。そのあとで、２つ
の異なるバージョンのフレームワークを使用して書かれたアプリケーションプロ
グラムが通信して、オブジェクトをやりとりしようとしたとき、双方のプログラ
ムが理解するオブジェクトが異なるので問題が起こっている。

【０００８】例えば、プログラムは、一方のプログラムから他方のプログラムへのデータを
ストリーム化することで、互いに通信することがよくある。このようなストリー
ミングオペレーションでは、ストリームライタは、オブジェクト情報をフラット
化して、つまり、マーシャリング (marshal) してシリアルデータストリームを形成している。このオブジェクト情報は、オブジェクトを作成するために使用さ
れたクラス情報の形体になっている。クラス情報は、オリジナルオブジェクトを
作成するために使用されたオリジナルクラス情報にすることができるが、そのオ
リジナルオブジェクトが別のオブジェクトの拡張であった場合には、拡張情報だ
けが送られる場合もある。

【０００９】シリアルデータストリームは、そのあと、別のアプリケーションに送られ、そ
こでは、ストリームリーダがシリアルデータストリームを復元して、つまり、デ
マーシャリング (de-marshal) してオリジナルオブジェクトのコピーを再構築し
ている。クラス情報が送信された場合は、このクラス情報がオブジェクトを構築
するために使用される。これとは別に、拡張データだけが送信された場合は、こ
のデータは送り先にすでに存在するクラス情報と結合され、オブジェクトを構築
するために使用される。通常、このようなオペレーションを行っても、問題は起
こらないが、２つの異なるフレームワークバージョンから作られたアプリケーシ
ョンプログラムが通信しようとすると、困難な問題が起こることがある。明らか
なように、将来バージョンは新しいクラスを含んでいることがあり得るので、現
行フレームワークバージョンにとって未知のクラスが、将来バージョンで書かれ
たストリーム上に存在することがある。しかし、旧クラスのいくつかが新バージ
ョンで削除されていると、将来バージョンは、過去のバージョンからのストリー
ム上のクラスのいくつかを認識できないことになる。多くのフレームワークでは
、ストリームリーダはインテリジェント機能をもっているので、読み取っている
オブジェクトデータが、それが一部となっているフレームワーク内のクラスデー
タに対応しているかどうかを認識できるようになっている。ストリームリーダが
認識しないオブジェクトデータが見つかったとき、ストリームリーダは、そのス
トリームが読み取り不能であると通知するだけである。

【００１０】この問題に対処する従来の方法の１つでは、ストリームの先頭にオブジェクト
のバージョン番号を挿入している。ストリームライタはクラスエレメントのどれ
かをストリームに書く前に、オブジェクトのバージョン番号を挿入している。ス
トリームリーダはストリームを受け取ると、オブジェクトバージョンを読み取り
、そのあと、オブジェクトをそのバージョンに見合った方法で処理している。例
えば、異なるバージョンを取り扱う一般的な方法では、新しいフレームワークバ
ージョンのストリームライタがバージョン番号を大きくしてから、その番号をス
トリームに書くことを要求しているが、これは新バージョンが新しいストリーミ
ングフォーマットになっているからである。さらに、新フレームワークバージョ
ンのストリームリーダは、旧バージョンのクラスを読み取る能力をもっているこ
とが要求されている。この従来の解決方法は、新バージョンのストリームリーダ
が旧バージョンのファイルを読み取るときは効率よく働くが、ファイルに新バー
ジョンのクラスが含まれていると、そのファイルは、旧フレームワークバージョ
ンのストリームリーダで読み取ることができなくなる。この問題は、ストリーム
化オブジェクトの終わりを示さないストリームライタではさらに悪化している。
このケースでは、ストリームリーダは未知のクラス情報を単純にスキップできな
いため、ストリームに未知のクラスが含まれていると、そのクラスから以降が読
み取れないことになる。

【００１１】以上に鑑みて、望まれていることは、後方データ互換性と前方データ互換性の
両方をもつフレームワークシステムを実現し、異なるバージョンのフレームワー
クで設計されたアプリケーションプログラムが通信できるようにすることである
。後方データ互換性とは、以前バージョンのフレームワークで生成されたストリ
ームを読み取れるようにすることであり、前方データ互換性とは、将来バージョ
ンのフレームワークで生成されたストリームを読み取れるようにすることである
。

【００１２】（発明の概要）本発明の原理によれば、バージョンのミスマッチが原因でクラスが欠落すると
いう問題にもかかわらず、オブジェクトフレームワークが相互に通信することを
可能にする、ストリームライタとリーダのクラスおよびメソッド群が提供されて
いる。ストリームライタは、将来のオブジェクトクラス情報がストリーム化され
るとき、既存バージョンと互換性のある代替オブジェクト情報を書くことによっ
て、既存バージョンのクラスから拡張された新バージョンのクラスを取り扱うよ
うに改良されている。この方法によると、代替オブジェクト情報は各々の旧バー
ジョンごとに書かれることになる。各旧バージョンに対応する代替オブジェクト
の各々の情報は、既存オブジェクト情報の後にエクステンションとして追加され
、そのエクステンションの長さは先頭に置かれている。ストリームリーダは、旧
バージョンのストリームリーダがオブジェクト情報を読み取り、最初の代替オブ
ジェクト（これは以後のバージョンに対応している場合もある）を理解しないと
き、そのエクステンションで指定された長さをスキップし、２番目の代替オブジ
ェクトを読み取るように改良されている。２番目の代替オブジェクト情報が理解
されないときは、リーダはその理解不能オブジェクト情報をスキップし、各代替
オブジェクトについて上記処理を続けていく。代替オブジェクトのいずれも理解
されないときは、例外がスロー (throw) される。

【００１３】ある実施形態では、使用されない代替オブジェクトの情報は破棄されるのでは
なく、テンポラリストレージ（「ビットバケット」）に格納される。そのあと、
オブジェクトが再びストリームアウトされたときは、ストアされた情報が追加さ
れ、ストリームに戻される。このようにすると、データは損失しない。

【００１４】（好適実施形態の詳細な説明）図１は、IBM THINKPAD 701（登録商標）コンピュータのように、ここに開示さ
れているフレームワークバージョン通信システムを実装させることができる、例
示のクライアントコンピュータ１００のシステムアーキテクチャを示す。図１の
例示コンピュータシステムは単に説明目的のために議論されているが、当然のこ
とながら、本発明を限定するものではない。以下の説明では、特定のコンピュー
タシステムを説明するとき普通に用いられる用語が引用されることがあるが、下
述の概念は他のコンピュータシステムにも等しく適用され、この中には、図１に
示すものとは異種のアーキテクチャをもつシステムも含まれている。

【００１５】クライアントコンピュータ１００は、中央処理ユニット(CPU)１０５（これは従来のマイクロプロセッサを搭載することができる）、情報を一時的に格納して
おくランダムアクセスメモリ(RAM)１１０、および情報を永続的に格納しているリードオンリメモリ(ROM)１１５を装備している。メモリコントローラ１２０はシステムRAM１１０を制御するためのものである。バスコントローラ１２５はバス１３０を制御するためのもので、割り込みコントローラ１３５は種々の割り込
みシグナル（信号）を他のシステムコンポーネントから受信し、処理するために
使用される。

【００１６】大容量ストレージはディスケット１４２、CD-ROM１４７、またはハードディス
ク１５２で提供することが可能である。データとソフトウェアは、ディスケット
１４２やCD-ROM１４７などの取り外し可能媒体を通してクライアントコンピュー
タ１００とやりとりすることができる。ディスケット１４２はディスケットドラ
イブ１４１に挿入可能であり、このドライブはコントローラ１４０によってバス
１３０に接続されている。同様に、CD-ROM１４７はCD-ROMドライブ１４６に挿入
可能であり、このドライブはコントローラ１４５によってバス１３０に接続され
ている。最後に、ハードディスク１５２は固定ディスクドライブ１５１の一部で
あり、このドライブはコントローラ１５０によってバス１３０に接続されている
。

【００１７】クライアントコンピュータ１００へのユーザ入力は、いくつかのデバイスから
与えることができる。例えば、キーボード１５６とマウス１５７は、キーボード
およびマウスコントローラ１５５によってバス１３０に接続することができる。
マイクロホンとスピーカ兼用の働きをするオーディオトランスジューサ１９６は
、オーディオコントローラ１９７によってバス１３０に接続されている。この分
野の精通者ならば当然に理解されるように、ペンおよび／またはタブレットおよ
び音声入力用のマイクロホンなどの、他の入力デバイスを、バス１３０と該当コ
ントローラを通してクライアントコンピュータ１００に接続することも可能であ
る。DMAコントローラ１６０は、システムRAM１１０に直接メモリアクセスできる
ようにするものである。ビジュアルディスプレイは、ビデオディスプレイ１７０
を制御するビデオコントローラ１６５によって生成される。

【００１８】クライアントコンピュータ１００は、クライアントコンピュータ１００をバス
１９１経由でネットワーク１９５に相互接続できるようにするネットワークアダ
プタ１９０も装備している。ネットワーク１９５は、ローカルエリアネットワー
ク(LAN)、広域ネットワーク(WAN)、またはインターネットにすることが可能であ
り、複数のネットワークデバイスを相互接続する汎用通信回線を利用することが
できる。

【００１９】コンピュータ１００は、一般的に、Apple Computer Corporation (Cupertino,
California) 提供のSYSTEM7（登録商標）オペレーティングシステムまたはInte
rnational Business Machines Corporation (Boca Raton, Florida) 提供のAIX （登録商標）オペレーティングシステムなどの、オペレーティングシステムソフ
トウェアによって制御され、調整されている。従来のオペレーティングシステム
は、特に、コンピュータプロセスの制御と実行のスケジューリングを行い、メモ
リ管理を実行し、ファイルシステム、ネットワーキング、および入出力(I/O) サ
ービスを提供し、グラフィカルユーザインタフェース（GUI) などのユーザインタフェースを提供している。エディタやスプレッドシートなどのユーザアプリケ
ーションは、直接的にも、間接的にも、オペレーティングシステムの上記および
他の機能に依存している。

【００２０】好適実施形態では、本発明は、オブジェクト指向プログラミング技法を使用し
てC++プログラミング言語で実現されている。この分野の精通者ならば理解されるように、オブジェクト指向プログラミング (OOP) のオブジェクトは、データ構造とデータに作用を及ぼすオペレーションを含むソフトウェアエンティティで
ある。これらのエレメントが一緒になって、オブジェクトが、そのデータエレメ
ントで表された特性とそのデータ操作関数で表された振る舞いからとらえて、ほ
とんどどの実世界エンティティでもモデル化することを可能にしている。このよ
うにして、オブジェクトは、人やコンピュータのような具体的な物をモデル化す
ることも、数のような抽象的概念や幾何学的概念をモデル化することも可能にな
っている。オブジェクトテクノロジの利点は次の３つの基本原理から生じている
。すなわち、カプセル化、多態および継承である。

【００２１】オブジェクトは、そのデータの内部構造およびその関数が作用するとき使用さ
れるアルゴリズムを隠蔽している。つまり、カプセル化している。これらの実施
詳細を外部に見せる代わりに、オブジェクトは、その抽象化を表し、クリーンで
外部情報のないインタフェースとなっている。多態はカプセル化を一歩進めたも
のである。その考え方は多数形状、１インタフェースである。ソフトウェアコン
ポーネントは、他のコンポーネントがなんであるかを正確に知らなくても、他の
コンポーネントの要求を行うことができる。要求を受け取る側のコンポーネント
はその要求を解釈し、要求をどのように実行するかを、その変数とデータに従っ
て判断する。第３の原理である継承は、開発者が既存の設計とコードを再利用で
きるようにする。この機能を利用すると、開発者は、ソフトウェアを初めから作
成しないで済むことになる。むしろ、継承によると、開発者は振る舞いを継承す
るサブクラスを派生することにより、開発者の具体的要求に合わせて振る舞いを
カスタマイズすることができる。

【００２２】さらに、好適実施形態では、フレームワークを使用してアプリケーションを開
発する方法も採用されている。プログラミングの立場から見たとき、フレームワ
ークとは、基本的に、相互に関連をもつオブジェクトクラスが集まったものであ
り、あらかじめ作られた実働アプリケーションの構造を提供している。例えば、
ユーザインタフェースフレームワークは、ドローイングウィンドウ、スクロール
バー、メニューなどのサポートと「デフォルト」の振る舞いを提供することもあ
り得る。フレームワークはオブジェクトテクノロジを基礎にしているので、その
振る舞いを継承し、オーバライドすることによって、開発者はフレームワークを
拡張し、特定の専門分野でカスタマイズしたソリューションを作成することがで
きる。開発者が関心を持っているシステムのレベルおよび解決しようとする問題
の種類に応じて、フレームワークには多種類のものがある。フレームワークのタ
イプは、ユーザインタフェースの開発を支援するアプリケーションフレームワー
クから、通信、印刷、ファイルシステムサポート、グラフィックスなどの、基本
的システムソフトウェアサービスを提供する低レベルのフレームワークまでの範
囲にわたっている。商用化されているアプリケーションフレームワークの例とし
て、そのいくつかを挙げると、MacApp (Apple)、Bedrock (Symantec)、OWL (Bor
land)、NeXTStep App Kit (NeXT)、およびSmalltalk-80 MVC (ParcPlace) がある。

【００２３】アプリケーションフレームワークが開発者にプレハブ機能を提供するのと同じ
ように、好適実施形態で採用されているような、システムフレームワークは同じ
考え方を基礎にしてシステムレベルのサービスを提供し、システムプログラマな
どの開発者が、そのサービスを利用してサブクラス化またはオーバライドし、カ
スタマイズしたソリューションを作成できるようにしている。本発明の好適実施
形態は、システムレベルのアプリケーションフレームワークの一部として実現さ
れている。システムレベルのフレームワークは、コンパイルされてアプリケーシ
ョンイメージに組み入れられるのではなく、プラットフォームのイメージとライ
ブラリ群の一部になっている。このようにすると、システムで実行されるアプリ
ケーションは、フレームワークコンポーネントを各アプリケーションのイメージ
に複製しなくても、フレームワークコンポーネントの使用を共有することができ
る。

【００２４】図２は、オブジェクトとクラス情報がどのようにストリーム化されて、フレー
ムワークバージョン２で作られた一方のアプリケーションプログラム２００から
、フレームワークバージョン１で作られた他方のアプリケーションプログラム２
１６に、データストリームを通して渡されるかを示すハイレベルのブロック概略
ｓ図である。例えば、クラスデータ２０２の形になったオブジェクト情報は、ア
プリケーション２１６に送られる属性とメソッドを収めている。このクラス情報
２０２はストリームライタ２０４に渡され、ストリームライタは、周知の方法で
データをシリアル化し、それを矢印２０６で図解して示すようにデータストリー
ム２０８上に置く。

【００２５】アプリケーションプログラム２１６側では、データは、矢印２１０で図解して
示すようにストリームリーダ２１２によってデータストリーム２０８から取り出
される。ストリームリーダ２１２は、データストリーム上のデータとフレームワ
ーク内のクラス情報の両方を使用して、オリジナルオブジェクト情報２０２のコ
ピー２１４を作成する。そのあと、オブジェクトクラス情報は、アプリケーショ
ンプログラム２１６側で新オブジェクトを構築するために使用される。

【００２６】ストリームリーダとストリームライタのオペレーション、およびデータストリ
ーム一般はこの分野では周知である。以下の説明では、CommonpointO System fo
r the AIX（登録商標）オペレーティングシステムという名称で、International
Business Machines Corporation (Armonk, New York) によって開発、販売され
ている特定のシステムフレームワーク群が例として使用され、本発明のオペレー
ションを示すコードの断片がシステムと関連付けて説明されている。Commonpoin
tシステムは、Commonpoint Application System, Version B for AIXという題名
の参考文献群 (Taligent, Inc. 1995) に詳しく説明されているが、その内容は引用により本明細書に記載されている。以下に説明されているストリーミング関
数は、Foundation Servicesという題名の巻に詳しく説明されている。しかし、本発明の原理はCommonpointシステムを使用することに限定されるものではなく、これを例として使用したことは、本発明が他のシステムに応用可能であること
を制限するものではない。

【００２７】基本的Commonpointシステムは、以下で説明するように、本発明の原理によれば、データ互換性を達成するように改良されているので、以下では、既存のComm
onpointストリーミング関数について簡単に説明することにする。Commonpointシ
ステムでは、Write()関数は、データをデータストリームに書き出すためのメイン関数である。これは、以下に示すコードの断片にストリームアウト記号 ">>="
で示されており、データを直接にデータストリームに書き出す。この関数が使用されるのは、他のオブジェクトインスタンスを指すポインタが関与しないとき
だけである。ポインタをストリーム化する必要があるときは、多態関数であるFl
atten()とResurrect()が使用され、該当データが書き出されることを保証する。

【００２８】 Commonpointアプリケーションシステムでは、このグローバル関数は、文字、整数などの、基本データ型のために用意されたものである。例えば、次に示すコ
ードの断片は、各ストリーム型がデータをどのように書き出すかを示している。
">>="の機能が使用されるときは、これは、実際には、データストリームのWrit
e()関数をコールする。

【００２９】

【数１】

【００３０】 Commonpointシステムでは、ライタは、各々のオブジェクトインスタンスに関連する「バージョン番号」を書き出す設計になっている。バージョン番号は、イ
ンスタンスの外部表現が変更されると、更新されるようになっている。

【００３１】 Read()関数は、情報をデータストリームから読み込むためのCommonpointのメイン関数である。これは、以下に示すコードの断片にストリームイン記号 "<<="
で示されている。Read()関数は、Write()関数がデータを書き出したのと正確に同じ順序で、データを読み込まなければならない。例えば、オブジェクａ、ｂ、
およびｃがストリームに書き出されていれば、リーダは、ストリーム化オブジェ
クトを読み戻してプログラムのメモリスペースに入れるとき、ストリームを順番
に読み戻して、ａ、ｂ、およびｃの突き合わせ変数 (matching variable) に入れなければならない。"<<="機能が使用されるときは、これは、実際には、データストリームのRead()関数をコールする。以下のコードは、上記Write()の例で使用されたものと同じストリーム (TFileStream f) を使用して、ストリームからどのように読み取って変数に入れるかを示している。

【００３２】

【数２】

【００３３】ポインタともっと複雑なオブジェクトが係わっている場合は、グローバルFlat
ten()関数を使用しなければならない。Flatten()がWrite()関数よりもインテリジェントであるのは、ストリーム化されるオリジナルインスタンスに含まれるす
べてのポインタとネストされたインスタンスの後に続いて、この関数が置かれて
いるからである。さらに、Flatten()関数は、オブジェクトインスタンスが復元されるとき正しいインスタンス構造を保持している。インスタンスへのポインタ
だけがデータストリームに書かれるときは、復元時に、ポインタは結局未知のデ
ータをポイントすることになる。これがランタイムエラーと扱われるのは、ポイ
ンタにアクセスすると、不明の結果が発生するからである。復元情報がフラット
化された情報と正確に同じであることを保証するために、インスタンスに関する
すべての情報がストリームに書き出される。

【００３４】さらに、Flatten()関数にはデフォルトの「コンテキスト」が用意されており、これは、同じオブジェクトインスタンスが、ストリーム化されるデータに２つ
以上存在するときそれを認識する。デフォルトでは、最初のインスタンスだけが
ストリームアウトされ、各類似インスタンスが最初のインスタンスの後でストリ
ームアウトされるたびに識別トークンが書かれるようになっている。トークンだ
けを書くと、ストリーム化されるデータ量が減少するので、データ圧縮による効
率が得られる。以下のコードの断片は、オブジェクトａをフラット化するための
Flatten()関数の使用を示している。

【００３５】

【数３】

【００３６】 TContext変数は、同じオブジェクトへの複数の参照がフラット化され、同じス
トリーム上で一緒にパックされる場合に使用される。TContextの要素は、反復さ
れるオブジェクトインスタンスへの参照を、格納される１組のオブジェクトから
割り当てるためにフラット化プロセス時に作られる、ダイナミックディクショナ
リである。下に示すコードサンプルは、オブジェクトインスタンスｄとａをフラ
ット化するための、複数インスタンスフラット化手法を示している。

【００３７】

【数４】

【００３８】 Resurrect()関数は、フラット化された形のインスタンスを受け取り、それからオブジェクトインスタンスを生成する。Resurrect()関数はストリームIDとコンテキストIDをパラメータとして受け取る。Resurrect()関数にパラメータとして渡されるストリームはフラット化されたインスタンスを収めている。この関数
に渡されるコンテキストの使い方は、Flatten()関数で説明したものと同じである。以下のコードの断片は、オブジェクトＡのシングルインスタンスをデータス
トリームaStreamから再構築するための、Resurrect()の使用を示している。

【００３９】

【数５】

【００４０】次のコードの断片は、オブジェクトＤとＡの２つのオブジェクトインスタンス
を同じストリームから復元する方法を示している。

【００４１】

【数６】

【００４２】次の断片は、基底クラスのFlattenルーチンを明示的にコールすることによって、そのインスタンスの基底クラスをフラット化するカスタムストリームアウト
演算子 (>>=) を定義したものである。これは、そのあと、メンバインスタンスのFlattenルーチンを明示的にコールすることによって、メンバインスタンスをフラット化している。最後に、基本データ型であるそのメンバおよび他のインス
タンスへの参照をフラット化している。単純データ型は、ストリームwrite()メンバ関数を使用してデータ型をストリームに書くことによってフラット化される
。他のインスタンスへの参照は、渡されたパラメータを指定してFlattenPointer
()ルーチンを再帰的にコールすることによってフラット化される。この例では、
クラスＣはクラスＡとＢから派生しており、クラスＤのメンバインスタンスｄを
もち、基本型がlongであるメンバ、基本型がcharであるメンバ、およびＥインス
タンス(e) へのポインタをもっているものと想定されている。WriteVersion()関
数は、上述したようにオブジェクトバージョン番号をストリームに書き出す。こ
の関数、および本発明に従って行われた改良については、以下で詳しく説明する
。その例示のコードの断片は次の通りである。

【００４３】

【数７】

【００４４】上記プロシージャによってフラット化されたオブジェクトを復元するためのカ
スタム化されたストリームイン演算子(<<=) は以下に示されている。ReadVersio
n()関数はWriteVersion()関数と対になるもので、バージョン番号を読み取る。これについても、以下で詳しく説明する。

【００４５】

【数８】

【００４６】（概観）異なるフレームワークバージョンで作られたアプリケーションプログラム間の
データ互換性という大きな問題は、いくつかの小さな問題を含んでいる。例えば
、データの非互換性はクラスバージョンのミスマッチとクラスの欠落が原因で起
こっている。また、非互換性が処理されるときデータ損失という問題もある。最
後に、基礎となるフレームワークバージョンのどれも使用しないで作られたアプ
リケーションがデータストリームを読み取るという問題がある。

【００４７】 1. クラスバージョンのミスマッチクラスバージョンのミスマッチ問題は、ストリームリーダが未知バージョンの
クラスをストリーム上に見つけたとき発生している。具体的には、未知バージョ
ンは、既知クラスには未知エクステンションとして見えるのが一般的である。本
発明の原理によれば、この問題は、未知拡張データをストリームリーダにスキッ
プさせ、可能ならば、破棄させることによって解決している。具体的には、スト
リームライタは、以下で詳しく説明するように、クラス拡張が書かれるときのフ
ォーマットを制御するように改良されている。

【００４８】具体的に説明すると、オリジナル基底クラスデータのフォーマットは、以下に
ストリームアウト演算子の例で示すように、バージョン番号を書き、基底クラス
データをストリーム化し、そのあと派生クラスデータをストリーム化するように
なっている。

【００４９】

【数９】

【００５０】ストリームイン演算子のフォーマットは次の通りである。

【００５１】

【数１０】

【００５２】さらに、将来バージョンのクラスは、その拡張フィールドをグループに追加し
なければならない。ストリームライタは、このグループの前にグループの長さを
置くように改良されている。このようにすると、クラス情報は図３に示すシーケ
ンスで読み書きされることになる。

【００５３】図３は、矢印３１６で示す順序で読み書きされるN個のエクステンションをもつクラスを示している。クラス情報がストリームに書かれるとき、バージョン番
号３００が最初に書かれ、そのあとに拡張フィールドのグループが続いている。
各フィールドグループは、その前にグループの長さが置かれている。例えば、拡
張フィールドグループ３０４は、その前にグループ長さ３０２が置かれている。
グループ３０８はその前に長さ３０６が、グループ３１２はその前に長さ３１０
が置かれている等である。以下、同様である。オリジナルクラスフィールド３１
４は最後に書かれる。非斜体のフィールドは、オブジェクト自体によって指定ま
たはストリームに書かれるデータを示すのに対して、斜体のフィールドは、本発
明の原理に従って作られたストリーミングサポートコードによってストリームに
書かれるデータを示している。「最新」のエクステンションが最初に書かれ、「
古い」エクステンションがその後に続いていることに注意されたい。以下は、２
つのバージョン拡張をもつクラスのストリームアウト演算子の例である。

【００５４】

【数１１】

【００５５】対応するストリームイン演算子は次の通りである。

【００５６】

【数１２】

【００５７】ストリームを読み取るとき、以前のフレームワークバージョンでは、バージョ
ン番号を読み取ったあとで、その長さを使用して、そのバージョンが理解するエ
クステンションに到達するまで拡張フィールドをスキップしている。スキップし
たエクステンションを廃棄することも、それらを「ビットバケット(bit bucket)
」と呼ばれる一時記憶域に格納しておき、クラスをストリームアウトするときに
使用できるようにもなっている。これについては、以下で説明する。

【００５８】このアプローチの欠点の１つは、ストリームライタが各エクステンションを書
く前に拡張グループの長さを予測できないことである。ランダムアクセスストリ
ームでは、このことは、システムがバックアップし、長さを書いた後で、リセッ
トする必要があることを意味する。このためには、データがバッファ境界にまた
がる場合、ファイルバッファを何度もフラッシュ（flush）する必要がある。非ランダムアクセスストリームでは、このことは、システムが拡張データをインメ
モリ (in-memory) ストリームに書いた後で、長さを書き、インメモリストリームをメインストリームにコピーする必要があることを意味する。これは、パフォ
ーマンスとメモリに重大な影響を与えることになる。この影響を軽減するために
、下述する互換性サポートは、それが絶対に必要であるときだけエクステンショ
ンをラップ (wrap) するだけである。ストリームが持続的でなければ、エクステ
ンションラッピングコード (extension-wrapping code) はなにもしない。

【００５９】 2. 欠落クラス欠落クラス(missing class) のデータ互換性の問題は、ストリームリーダが未
知のクラスをストリーム上に見つけたとき発生している。場合によっては、スト
リームライタは、前述したCommonpointシステムの場合と同じように、ストリーム化オブジェクトの終わりを通知しないことがある。従って、ストリームリーダ
は未知のオブジェクトをスキップできず、未知のクラスを含んでいるストリーム
は、そのクラスから以降読み取り不能になっている。

【００６０】このことは、前方と後方の両データ互換性の問題となっている。明らかなよう
に、新しいフレームワークバージョンからのストリーム上に未知のクラスが見つ
かることがあるのは、より新しいフレームワークバージョンが新しいクラスを含
んでいるためである。しかし、新フレームワークバージョンは、旧クラスのいく
つかが削除されていると、旧フレームワークバージョンからのストリーム上のク
ラスのいくつかを認識できないことが起こる。後者の問題を回避するために、持
続的クラスは旧フレームワークバージョンから削除されていない。

【００６１】新クラスにもなお問題があるが、幸いにも、すべての新クラスが問題を引き起
こす潜在性をもっているわけではない。問題は、新クラスが既存クラスから派生
しているときと、これらの新クラスが多態的にストリーム化されているときにだ
け起こっている。例えば、旧フレームワークバージョンにTTextStyleと呼ばれる
テキストスタイルがあり、新フレークワークバージョンがTTextStyleから派生し
ている、新しいテキストスタイルTWavyUnderlineStyleを取り入れたとする。新フレームワークでは、TWavyUnderlineStyleは新クラスによって多態的にストリーム化するか、旧クラスの新エクステンションによって多態的にストリーム化す
るかのいずれかが可能である。しかし、TWavyUnderlineStyleは旧フレームワークバージョンに存在しないので、旧クラスの基底バージョンで多態的にストリー
ム化することはできない。TWavyUnderlineStyleは旧クラスの基底バージョンでストリーム化できないので、また、これは旧フレームワークのストリーミング関
数によって読み取られる唯一のバージョンであるので、どの旧フレームワークに
も、多態的TWavyUnderlineStyleが現れることはない。そのため、欠落クラス問題は、多態的にストリーム化されたクラスでは起こることがない。

【００６２】しかし、旧フレームワークリーダは、多態的にストリーム化されたTWavyUnder
lineStyleに出会うことがある。例えば、テキストスタイルを多態的にストリーム化する、TStyleBundleと名付けられた旧クラスがあるとする。新フレームワー
クでは、TStyleBundleクラスはTWavyUnderlineStyleを含んでいる場合がある。T
WavyUnderlineStyleを含んでいるTStyleBundleが新フレームワークで作られたア
プリケーションプログラムによってストリーム化され、そのストリームが旧フレ
ームワークで作られたアプリケーションによって読み取られるとすると、TStyle
Bundleクラスのストリームイン演算子は旧TTextStyleを復元しようとする。旧TT
extStyleはTWavyUnderlineStyleによって置き換えられているので、この復元は失敗することになる。

【００６３】本発明の原理によれば、ストリームライタは、既存クラスから派生している、
すべての新クラスがストリーム化されるとき「代替(alternate)」旧クラスを書くように改良されている。代替クラスの各々は、オリジナルクラスを含めて、先
頭に置かれている長さのエクステンションと同じようにラップされる。このよう
にすると、クラス情報は図４に示すシーケンスで読み書きされることになる。

【００６４】図４は、矢印４１６で示す順序で読み書きされる代替をもつクラスを示してい
る。クラス情報がストリームに書かれるとき、開始代替名４００が最初に書かれ
る。この開始代替はオリジナルクラス情報である。各代替の情報はその前に代替
の長さが置かれている。例えば、開始代替４００の長さ４０２はその代替の情報
の前に置かれている。タイプ情報４０４が次に書かれ、代替バージョン番号４０
６が次に書かれ、その後に代替フィールドのグループ４０８が続いている。

【００６５】同じように、次の代替４１０は名前４１０とその後に続く長さ４１２、タイプ
情報４１４およびフィールドのグループ４１８からなっている。非斜体のフィー
ルドは、オブジェクト自体によって指定またはストリームに書かれるデータを示
すのに対して、斜体のフィールドは、本発明の原理に従って作られたストリーミ
ングサポートコードによってストリームに書かれるデータを示している。エクス
テンションの場合と同様に、「最新」代替が最初に書かれ、その後に「古い」代
替が続いている。その後、最初の代替を理解しないストリームリーダは長さを使
用して、それをスキップすることができる。その後、それらは、理解する代替に
到達するまで後続の代替を読んでいくことができる。スキップした代替は破棄す
るか、ビットバケットに格納できる。ストリームリーダが代替のどれも理解しな
いときは、本発明によるResurrect()関数はすべての代替をスキップし、例外をスローする。この例外をキャッチできるアプリケーションプログラムは、そのま
ま続けてストリームの残り部分を読み取ることができる。

【００６６】代替をもつクラスのストリームインとストリームアウトの演算子を示すコード
の断片の例は次の通りである。

【００６７】

【数１３】

【００６８】この解決方法の１つの欠点は、代替がストリーミング演算子をスローダウンさ
せ、ストリームのサイズを大きくすることである。代替クラスを構築し、初期化
し、ストリーム化する必要があるのでストリームを書く時間が長くなり、また代
替データを含んでいるためストリームが大きくなっている。このコストを軽減す
るために、以下に開示されている互換性サポートコードは、それが絶対に必要な
場合に代替データを書くだけにしている。オブジェクトが持続的でなければ、あ
るいはオブジェクトが多態的にストリーム化されるのでなければ、その時代替デ
ータは書かれないようになっている。

【００６９】代替を使用するストリーミング演算子の形式は次の通りである。

【００７０】

【数１４】

【００７１】事情によっては、特定のアプリケーションプログラムがクラスの代替を補足ま
たはオーバライドすることが望ましいことがある。この場合、これを行うために
FlattenWithoutAlternates()関数が使用される。FlattenWithoutAlternates()は
、その代替のいずれもなしで与えられたオブジェクトをストリーム上に置く。以
下のコードの断片は、FlattenWithoutAlternates()をアプリケーションでどのよ
うな使い方をすると、オブジェクトのデフォルト代替をオーバライドし、特殊な
代替ストリームを与えることができるかを示している。この例では、アプリケー
ションは、MGgraphicと名付けたタイプのオブジェクトをストリーム化することを望み、独自の代替オブジェクトを与えることを望んでいるものと想定している
。

【００７２】

【数１５】

【００７３】 3. データ損失の防止前述したデータ互換性サポートを使用すると、ストリームリーダに、それらが
理解しないストリーム化エクステンションと代替をスキップさせることができる
。その結果、ストリームがサイト間でやりとりされるときデータ損失が起こる可
能性がある。例えば、ユーザ１とユーザ２が拡張グラフィックオブジェクトを含
んでいるドキュメントで共同作業しているとする。このオブジェクトは多角形 (
polygon) であるが、新フレームワークでは、曲線を含むように拡張されている。ユーザ１は新フレームワークで作られたアプリケーションプログラムを使用し
ているが、ユーザ２は旧フレームワークバージョンで作られたプログラムを使用
している。ユーザ１はオブジェクトを編集し、曲線編集を導入してから、そのオ
ブジェクトをストリーム化してユーザ２に渡している。ユーザ２の旧ストリーム
リーダは未知の曲線データを破棄し、多角形をユーザ２に提示している。ユーザ
２は多角形を編集し、その多角形をストリーム化してユーザ１に送り返すが、ユ
ーザ１の曲線編集は紛失している。この種のデータ損失を防止するために、本発
明によるシステムは、未読み取りストリームデータをキャプチャし、保存してお
くために使用できる「ビットバケット」クラスを用意している。

【００７４】未読み取り拡張データを保存しておくために、本発明によるシステムはTExten
sionBitBucketクラスを用意している。使用時には、TExtensionBitBucketオブジ
ェクトが上述したReadVersion()関数に渡されると、スキップしたエクステンションは破棄されるのではなく、そのオブジェクトに入れられる。情報はその後一
時的に格納される。TExtensionBitBucketオブジェクトはWriteVersion()関数に渡すことも可能であり、格納されたコンテンツがストリームに書かれることにな
る。しかし、アプリケーションプログラムは、格納情報をストリームに書くかど
うかを判断しなければならない。ベースオブジェクトが変更されていなければ、
その時格納情報を書き出しても安全であることは明らかである。しかし、ベース
オブジェクトが変更されていたときは、格納情報は新オブジェクトと矛盾してい
るおそれがある。格納情報を書き出すかどうかを、クライアントが判断しやすく
するために、TExtensionBitBucketオブジェクトは「直交(orthogonal)」フラグを保存している。このフラグは、オブジェクトに入っている格納データが、ベー
スデータの影響を受けているか、それともベースデータとは無関係（直交）であ
るかを示している。フラグがTRUEであれば、格納データは、ベースオブジェクト
がどのように変更されたかに関係なく、ベースオブジェクトとの整合性が保たれ
ている。

【００７５】 BitBucketオブジェクトは上記の例で使用することができる。新フレームワークの開発者が、多角形クラスが将来拡張されるのではないかと思っているときは
、多角形クラスがストリーム化される個所にTExtensionBitBucketクラスを組み入れておくことができる。その結果のBitBucketオブジェクトはクラスの将来の拡張をキャッチすることになる。多角形オブジェクトが曲線を含むように拡張さ
れるときは、多角形のストリーミング演算子も、曲線を読み書きするように拡張
される。多角形クラスのストリームアウト演算子では、開発者は、曲線データが
多角形データに直交することを示すフラグをセットする。

【００７６】そのため、ここでは、ユーザ１が多角形をストリーム化してユーザ２に送ると
き、エクストラ曲線データは破棄されない。その代わりに、改良コードはそれを
ビットバケットに格納する。ユーザ２は多角形を編集した後、それをユーザ１に
送り返す。ユーザ２が多角形データをストリーム化するとき、直交フラグがTRUE
にセットされているのでストリームライタも格納データをストリーム化する。そ
のあと、編集された曲線データが、ユーザ２によって編集された多角形データと
一緒にユーザ１に送り返され、両ユーザの作業は維持される。

【００７７】未読み取り代替クラスデータを保存しておくために、本発明によるシステムは
TAlternateBitBucketクラスを用意している。使用時には、アプリケーションプログラムはTAlternateBitBucketオブジェクトをResurrect()関数に渡すことがで
き、未読み取り代替データのすべてがそこにダンプされることになる。アプリケ
ーションプログラムはTAlternateBitBucketオブジェクトをFlatten()関数に渡す
こともでき、フラット化クラスをもつ代替データが書き出されることになる。

【００７８】 TAlternateBitBucketクラスの使い方は、TExtensionBitBucketクラスのそれと
同じである。しかし、デフォルト代替の使用は、共同作業のシナリオが複雑であ
るため困難である。代替オブジェクトに対する編集はすべてのシステムが知って
いるとは限らないので、困難な問題が発生する。

【００７９】一実施例によれば、データ互換性システムは、従来のCommonpointストリーミングアーキテクチャをいくつか拡張したものから構成されている。データ互換性
システムは、ストリームラッパ (stream wrapper)、ビットバケットおよび強化されたストリーミングサポート関数を取り入れることによってストリーミングア
ーキテクチャを拡張している。ストリームラッパクラスのいくつかはパブリック
であり、開発者が利用できるようになっている。その他はプライベートであり、
種々の内部関数を実行するために使用される。

【００８０】 TAlternateInputStream、TAlternateOutputStream、TExtensionInputStreamお
よびTExtensionOutputStreamを含む、いくつかのストリームラッパクラスの機能
は、ストリームをラップし、ストリーム化データをフィルタリングすることであ
る。例えば、TExtensionOutputStreamは、すべてのクラス拡張フィールドグルー
プの前に、ストリーム上でその長さが置かれているかを確かめ、TAlternateInpu
tStreamは必要でない代替を破棄する。これらのクラスは、データ互換性をサポートするために使用されることを目的としているので開発者が利用できる。パブ
リックおよびプライベートストリーミングクラスの完全なクラス階層は図５と図
６に示されている。

【００８１】図５と図６は一連のいわゆるBoochクラス図で、種々の異なるフレームワークを形成するクラスを示している。クラスの各々とクラス間の関係は以下で詳しく
説明する。Booch図とそこで使用されている表記はこの分野では周知であり、ここで説明することは省略する。Booch図と表記の意味については、Grady Booch著
「アプリケーションに関するオブジェクト指向分析と設計」という書名でBenjam
in/Cummings Publishing Company, Incから出版されているテキストブックで解説されているが、その内容は引用により本明細書に記載されている。

【００８２】パブリックストリームラッパクラス図５を参照すると、TDelegatingStreamクラス５０２は、抽象クラスTStream５
００から派生し、別のストリームにデリゲート (delegate) する抽象ストリーム
クラスである。これは、すべてのストリームコールを目的ストリームに引き渡す
。これのクラス宣言は次のようになっている。

【００８３】

【数１６】

【００８４】 TAlternateInputStreamクラス５０８は、代替を読み取るためのデリゲートストリーム (delegating stream) を定義している。これはResurrect()関数とタン
デムで働き、代替を収めているストリームを読み取る。これは最初の既知代替を
戻し、その他はすべて破棄する。TAlternateInputStreamクラス５０８はサブクラス化されることを目的としていない。その宣言は次の通りである。

【００８５】

【数１７】

【００８６】 TAlternateOutputStreamクラス５１０は代替をストリームアウトするための指
名ストリーム (designating stream) を定義している。これは、ストリームが代
替を要求しているかどうかを判断するために使用できるPrepareForNextAlternat
e()メソッドをサポートしている。TAlternateOutputStreamクラス５１０はサブクラス化されることを目的としていない。その宣言は次の通りである。

【００８７】

【数１８】

【００８８】 TBufferSupportStreamクラス５０４は、バッファ付き入出力ストリームをサポ
ートする抽象ストリームラッパである。これは、ラップされるストリームをNIL 、ランダムアクセスによる非持続的または順次アクセスによる持続的であるもの
として分類している。その宣言は次の通りである。

【００８９】

【数１９】

【００９０】 TBufferSupportStreamクラス５０４から派生したクラスは図６に示されている
。TBufferInputStreamクラス６０２は、そのデータをバッファに入れる入力スト
リームを実行する。これは、ストリーム化データをストリームから直接に読み取
るのではなく、それを仮想バッファにストアしておくデリゲートストリームであ
る。TBufferInputStreamクラスは、バッファされたデータに関する統計を収めて
いるストリームヘッダオブジェクトを受け取る。ラップされたデータをストリー
ムから読み取るとき、最初にヘッダデータをストリームから読み取ってから、バ
ッファされたデータを読み取る。TBufferInputStreamクラス６０２は、ラップさ
れたデータをストリームから読み取ることなく、それをスキップするメソッドも
提供している。その宣言は次の通りである。

【００９１】

【数２０】

【００９２】 TBufferOutputStreamクラス６０４は、そのデータをバッファに入れる出力ストリームを実行する。これは、ストリーム化データをストリームに直接に書き出
すのではなく、それを仮想バッファにストアしておくデリゲートストリームであ
る。TBufferOutputStreamクラス６０４は、バッファされたデータに関する統計を収めているストリームヘッダオブジェクトを受け取る。ラップされたデータを
ストリームに書くとき、最初にヘッダをストリーム化してから、バッファされた
データをストリーム化する。TBufferOutputStreamクラス６０４は、ラップされたデータをストリームに書くことなく、それをダンプするメソッドも提供してい
る。その宣言は次の通りである。

【００９３】

【数２１】

【００９４】 TExtensionInputStreamクラス６０８は、エクステンションをストリームインするためのバッファ付き入力ストリームを定義している。これは、エクステンシ
ョンが以前のデータに直交しているかどうかを知らせるIsOrthogonal()メソッド
をサポートしている。その宣言は次の通りである。

【００９５】

【数２２】

【００９６】 TExtensionOutputStreamクラス６１２は、エクステンションを書き出すための
バッファ付き出力ストリームを定義している。その宣言は次の通りである。

【００９７】

【数２３】

【００９８】パブリックビットバケットクラスデータ互換性サポートコードは、未読み取りストリームデータを保存するため
に使用できるビットバケットクラスも含んでいる。アプリケーションはビットバ
ケットオブジェクトをReadVersion()関数とResurrect()関数に渡し、スキップさ
れたエクステンションと代替をキャプチャし、アプリケーションは満杯ビットバ
ケットをWriteVersion()関数とFlatten()関数に渡し、格納データをストリーム化する。

【００９９】ビットバケットクラスには、TAlternateBitBucketとTExtensionBitBucketの２
つがあり、どちらもルートをもっていない（別のクラスからも派生していない）
。これらの実行はパブリックでない。TAlternateBitBucketクラスは未読み取り代替をキャプチャするオブジェクトを構築する。アプリケーションは、TAlterna
teBitBucketオブジェクトをResurrect()関数に渡すことができ、Resurrect()関数はスキップした代替のすべてをそこに入れる。アプリケーションはTAlternate
BitBucketオブジェクトをFlatten()関数に渡し、フラット化オブジェクトの正規
代替ではなく、格納された代替をストリーム化することもできる。TAlternateBi
tBucketオブジェクトは代替の順序を保存しておくので、代替は、読み取られたときと同じ順序で書き出すことができる。TAlternateBitBucketクラスはサブクラス化されることを目的としていない。その宣言は次の通りである。

【０１００】

【数２４】

【０１０１】 TExtensionBitBucketクラスは、未読み取りエクステンションをキャプチャするオブジェクトを構築する。アプリケーションはTExtensionBitBucketオブジェクトをReadVersion()関数に渡すことができ、ReadVersion()関数はスキップされ
たエクステンションのすべてをオブジェクトに入れる。アプリケーションは満杯
TExtensionBitBucketオブジェクトをWriteVersion()関数に渡すこともでき、Wri
teVersion()関数は格納エクステンションをストリーム化する。TExtensionBitBu
cketオブジェクトは、そこに収められた拡張データが、そのクラスの他のストリ
ームデータと無関係であるかどうかを示すフラグを保存している。TExtensionBi
tBucketクラスはサブクラス化されることを目的としていない。これは次のように定義されている。

【０１０２】

【数２５】

【０１０３】ストリーミングサポート関数既存のCommonpointフレームワークは、上述したように、単態 (monomorphic)
および多態 (polymorphic) ストリーミングとストリームフォーマットバージョン処理のためのグローバル関数を用意している。本発明によるデータ互換性シス
テムでは、これらの関数は、ビットバケットを受け付け、代替を処理し、他の新
しい互換性機能を取り扱うように拡張されている。

【０１０４】例えば、従来のReadVersion()関数およびWriteVersion()関数は、アプリケーションがストリームフォーマットバージョン番号を読み書きすることを可能にし
、次のような形式になっている。

【０１０５】

【数２６】

【０１０６】本発明の原理に従って構築されたデータ互換性システムでは、ReadVersion() 関数とWriteVersion()関数は、エクストラ拡張データを格納し、書き出すための
ビットバケットを処理するように改良されている。これらの新規関数は次のよう
な形式になっている。

【０１０７】

【数２７】

【０１０８】 Commonpointフレームワークにおける従来のFlatten()関数とResurrect()関数は、上述したように多態的ストリーミングを行い、次のような形式になっている
。

【０１０９】

【数２８】

【０１１０】本発明によるデータ互換性システムでは、代替を格納し、書き出すためのビッ
トバケットを受け付けるバージョンのFlatten()関数とResurrect()関数が追加さ
れている。これらの新バージョンは次のような形式になっている。

【０１１１】

【数２９】

【０１１２】本発明によるデータ互換性システムでは、その代替をもたないオブジェクトを
フラット化するバージョンのFlatten()関数も追加されている。これらのバージョンは次のような形式になっている。

【０１１３】

【数３０】

【０１１４】プライベートストリームラッパクラス本発明によるデータ互換性システムでは、コンテキスト、ストリームおよびス
トリーミングサポート関数を強化し、仮想コンテキスト、ストリームラッパ、ス
トリームラッパヘッダおよびビットバケットを取り入れることによって、ストリ
ーミングアーキテクチャも拡張されている。これらの強化機能の多くは、参照さ
れたオブジェクトがストリームリーダによって認識されないとき、ストリーム上
の参照情報を保存しておくために必要になるものである。

【０１１５】特に、各ストリームはデフォルトコンテキストをもっている。このコンテキス
トは、ストリーム化オブジェクトへの参照をストアしている。オブジェクトがグ
ローバルストリーミング関数の１つを使用してストリーム化されている時はいつ
でも、ストリーミング関数は、オブジェクトへの参照をストリームのコンテキス
トにストアする。そのオブジェクトがすでにコンテキストにあれば、オブジェク
トを再びストリーミングする代わりに、この関数は、そのオブジェクトの以前に
ストリーム化されたインスタンスへの参照（「エイリアス(alias)」と呼ばれる）を書き出す。

【０１１６】エイリアスは、ストリームのサイズを減少し、ストリームライタが参照情報を
ストリーム内に保存できるようにする。エイリアスのオペレーションは図７Aと図７Ｂに示されている。図７Aは、エイリアスなしのストリーミングを示している。同図に示すように、ＡおよびＢと名付けた２つのオブジェクト７００と７０
２は、どちらもＣと名付けた同じオブジェクト７０４を参照している。エイリア
スがないときは、ストリームライタはオブジェクトＡをストリーム化し、オブジ
ェクトＣがストリーム化され、そのあと、ストリームライタはストリームＢをス
トリーム化し、オブジェクトＣが矢印７０６に図示されるように再びストリーム
化されることになる。データストリームの他方の終端では、ストリームリーダは
Ａ'と名付けたオブジェクトコピー７０８を、次にＣ'と名付けたオブジェクトコ
ピー７１２を作り、その２オブジェクト間の参照を作ることになる。その後、リ
ーダはＢ'と名付けたオブジェクトコピー７１０を、次にＣ"と名付けた別のオブ
ジェクトコピー７１４を作り、参照をセットアップすることになる。最終結果は
、オブジェクト７０８と７１０がＣの２つの異なるコピーである、オブジェクト
７１２と７１４をポイントすることになる。オブジェクト７０８と７１０が同じ
オブジェクトをポイントするはずという事実は、失われることになる。

【０１１７】図７Bはエイリアス付きのストリーミングを示している。このケースでは、ストリームライタはＡと名付けたオブジェクト７１６を、次にCと名付けたオブジェクト７２０を、次にＢと名付けたオブジェクト７１８を、次に＾Ｃと名付けた
エイリアスを、以前にストリーム化されたバージョンのＣに書き出す。これらの
アイテムは、矢印７２２で示すデータストリーム上を転送される。データストリ
ームの他方の終端では、ストリームリーダは、Ａ'と名付けたオブジェクトコピー７２４を、次にＣ'と名付けたオブジェクトコピー７２８を作り、２オブジェクト間の参照を作ることになる。その後、リーダはＢ'と名付けたオブジェクトコピー７２６を作ることになる。ストリームリーダにエイリアスが現れたとき、
リーダはオブジェクトコピー７２６を、以前に読み取られたバージョンのオブジ
ェクトＣ、つまり、オブジェクト７２８に接続することを知っている。従って、
参照は維持されることになる。

【０１１８】しかし、エイリアス付きオブジェクト (aliased object) がストリームリーダ
によって認識されないときは、問題が発生する。図７Ｂに示す上記例では、スト
リームリーダがストリーム化バージョンのオブジェクト７２０を読まないと、問
題が発生する。このようなことが起こるのは、オブジェクト７２０がエクステン
ションの一部であったか、リーダによってスキップされた代替であったときであ
る。その場合、認識されなかったオブジェクト（＾Ｃ）の後続エイリアスは無効
になる。

【０１１９】この問題が発生するのを防止するために、本発明によるデータ互換性システム
では、ストリームライタは、参照されたオブジェクトが、あるリーダによって読
み取られなかったこと、を検出するように改良されている。そのとき、ストリー
ムライタは、通常のエイリアスを書くのではなく、「ローバスト」エイリアス (
robust alias)をストリーム上に書く。ローバストエイリアスはエイリアス情報プラス、エイリアス付きオブジェクトの再ストリーム化コピーを収めている。ロ
ーバストエイリアスが読み取られるとき、リーダはエイリアス付きオブジェクト
が現れたかどうかをチェックする。現れていれば、ポインタをフィックスアップ
(fix up)し、再ストリーム化コピーをスキップする。エイリアス付きオブジェク
トが現れていなければ、次へ進み、再ストリーム化オブジェクトをローバストエ
イリアスから読み取る。

【０１２０】ローバストエイリアスが使用されるケースとしては、いくつかがある。例えば
、ローバストエイリアスはクラスエクステンションで使用することができる。ク
ラスエクステンションはリーダによって読み取られないことがあるので、リーダ
が出会うエイリアスは、それがカレントクラスエクステンションまたはカレント
エクステンションの親クラスの外にあるクラス情報（これはオブジェクトを作成
している）を参照していると、無効である可能性がある。後者の場合には、ロー
バストエイリアスを書き出さなければならない。そうでなければ、単純エイリア
ス (simple alias) が使用できる。

【０１２１】明らかなように、代替の間にエイリアシングがあり得ないのは、多くてもそれ
らの１つが読み取られるからである。従って、２つの代替が同じオブジェクトを
参照するときは、２回ストリーム化されるはずである。しかし、代替の一方にオ
ブジェクトへの外部参照がある場合は、その代替は読み取られることもあれば、
読み取られないこともあるので、ローバストエイリアスをストリーム化しなけれ
ばならない。

【０１２２】別のケースは、２つ以上の代替に現れるオブジェクトへの外部参照に関係する
ものである。例えば、２つの代替の各々が、あるオブジェクトのコピーを収めて
いて、外部オブジェクトもそのオブジェクトを参照しているとする。外部オブジ
ェクトが代替の一方にあるオブジェクトを参照していれば、そのときその参照は
、他方の代替を選択するストリームリーダでは壊されることになる。

【０１２３】本発明の原理によれば、重複オブジェクトに関する情報は代替ラッパ (altern
ate wrapper) に保管されている。各代替は、エクステンションと同じように、ストリーム上でその前にその長さを置くことができるようにラップされ、重複オ
ブジェクト情報は長さと一緒にストリーム上に書かれる。上記の例では、第２の
代替は、それが参照するオブジェクトが第１オブジェクトによって参照されるオ
ブジェクトと同じであることを示す情報を含むことができる。代替ヘッダは自動
的に読み取られるので、この情報はすべてのリーダに現れることになる。リーダ
はこの情報を使用してコンテキストを更新し、それがどちらの代替を選択したか
に関係なく、参照を保存している。

【０１２４】この新データは既存ラッパクラスのエクステンションであるので、新等価デー
タは長さの前にストリーム化されていなければならない（このようにすると、よ
り古いフレームワークで作られたアプリケーションはそれをスキップできる）。
等価情報の量は事前に分からないので、最大数の重複を収容できるだけの十分な
スペースをストリーム上に残しておく必要がある。この最大数は、以前の代替す
べてでストリーム化されたオブジェクトの数である。

【０１２５】本発明によるデータ互換性システムでは、与えられたストリームをラップし、
ストリーム化データをフィルタリングするオブジェクトを構築するプライベート
ストリームラッパクラスが取り入れられている。これらのクラスの全部は、図５
と図６に示すストリームラップクラス階層に含まれている。これらのプライベー
トクラスには、ローバストエイリアスのストリーム化を処理するTRobustAliasIn
putStreamクラス６０６とTRobustAliasOutputStreamクラス６１０、および、以下で説明するように、代替のストリーム化を最適化するために使用されるTAlter
nateEnableStreamクラス５０６が含まれている。

【０１２６】ストリーム化データをトラッキングするほかに、ラッパはストリーム化を最適
化することもできる。１つの例として、TAlternateEnableStreamクラス５０６か
ら構築されるTAlternateEnableStreamがある。後者のストリームは、代替がスト
リーム化されるかどうかを制御するデリゲートストリームである。前述したよう
に、代替を構築し、ストリーム化するプロセスはストリーム化プロセスを著しく
低速化する可能性があるので、重要なことは代替のストリーム化を可能な限り避
けることである。また、上記説明したように、代替をストリーム化する必要があ
るのは、オブジェクトが持続的ストリームにフラット化されるときだけである。
オブジェクトのストリーム化演算子内では、ストリームが持続的であるかどうか
を判断することが可能であるが、オブジェクトがフラット化されるかどうかを判
断することは不可能である。後者の条件を判断するためには、Flatten()関数は、オブジェクトがフラット化され、単態的にストリーム化されないことをストリ
ーム化演算子に通知できるようになっている必要がある。

【０１２７】本発明の原理によれば、Flatten()関数は、与えられたストリームをTAlternat
eEnableStreamでラップし、後者をオブジェクトのストリーム化演算子に渡すことによってこれを行っている。このオペレーションは図８に示されている。オブ
ジェクト８０４のFlatten()関数８０２は、まず、代替が必要であるかどうかを、ストリームが必要かどうかを判断することによって判断する。代替が必要であ
れば、Flatten()関数はクラス８０６（これはTDelegatingStreamクラス８００か
ら派生している）からTAlternateEnableStreamを構築し、ストリームをそれでラ
ップする。

【０１２８】ストリーム化演算子が代替を定義していれば、クラス８０８から構築されたTA
lternateOutputStreamがそこに入れられる。構築時に、TAlternateOutputStream
はストリームのタイプをチェックする。それがTAlternateEnableStreamであれば
、その時オブジェクトがフラット化されること、従って、代替をストリーム化さ
せることがTAlternateOutputStreamに知らされる。ストリームがTAlternateEnab
leStreamでなければ、その時オブジェクトはストリーム化されるだけであるので
、代替は必要とされない。

【０１２９】 TAlternateEnableStreamクラス５０６は、TAlternateOutputStreamオブジェク
トが代替をストリーム化することを可能にする内部デリゲートストリームを構築
する。TAlternateEnableStreamクラスの宣言は次の通りである。

【０１３０】

【数３１】

【０１３１】 TRobustAliasOutputStreamクラス６１０は、ローバストエイリアスをストリー
ムに書き出すオブジェクトを構築する。そのクラス宣言は次の通りである。

【０１３２】

【数３２】

【０１３３】 TRobustAliasInputStreamクラス６０６は、ローバストエイリアスをストリームから読み取るオブジェクトを構築する。その宣言は次の通りである。

【０１３４】

【数３３】

【０１３５】プライベートストリームラッパクラスはプライベートストリームヘッダクラス
を使用して実行されており、ヘッダクラスには、その長さ、データに収められて
いるフラット化オブジェクトの数、および外部オブジェクトにエイリアスがある
かどうか、といったラップデータに関する統計が収められている。このデータに
は、ストリームからのもの、コンテキストからのもの、および他の場所からのも
のがある。ヘッダには、各タイプのデータをトラッキングするように特殊化され
たものがある。完全なストリームヘッダクラス階層は図９に示されている。

【０１３６】各セットのラッパクラスは独自のヘッダクラスをもっている。例えば、TAlter
nateInputStreamオブジェクトとTAlternateOutputStreamオブジェクトはTAltern
ateStreamHeaderクラス９０２を使用し、TExtensionInputStreamオブジェクトと
TExtensionOutputStreamオブジェクトはTExtensionStreamHeaderクラス９０４を
使用している。ヘッダクラス９０２と９０４の各々は共通の親クラスであるTStr
eamHeader９００から派生し、その特定ラッパにとって重要なストリームデータだけをトラッキングするように特殊化されている。

【０１３７】 TStreamHeaderクラス９００は基本ヘッダクラスである。これは、ラップデータの長さ、ラップオブジェクトの数、およびデータが自己完結 (self contained
) であるかどうか、を記録している。そのクラス宣言は次の通りである。

【０１３８】

【数３４】

【０１３９】 TAlternateStreamHeaderクラス９０２は、代替間のエイリアスを記録するため
に使用されるオブジェクトインデックスの配列を保存しているオブジェクトを構
築する。クラス宣言は次の通りである。

【０１４０】

【数３５】

【０１４１】 TExtensionStreamHeaderクラス９０４は、このエクステンションに入っている
データが、以前のすべてのクラスデータに直交しているかどうかを示す直交フラ
グ (orthogonal flag) を収めているオブジェクトを構築する。クラス宣言は次の通りである。

【０１４２】

【数３６】

【０１４３】 TRobustAliasHeaderクラス９０６は、エイリアス付きオブジェクトのIDを収め
ているオブジェクトを構築する。クラス宣言は次の通りである。

【０１４４】

【数３７】

【０１４５】図１０はストリームヘッダの使い方を示している。TAlternateOutputStream１
０００は、TBufferedOutputStream１００２を初期化するために使用されるTAlte
rnateStreamHeader１００６を所有している。TBufferedOutputStream１００２は
ヘッダにエイリアスを付け、それとバッファ内データとの同期を保っている。バ
ッファ内データをストリームアウトする時間になると、TBufferedOutputStream １００２は、ヘッダがバッファ内データの前にストリームに書かれていることを
確かめる。

【０１４６】プライベートストリームコンテキストクラス上述したエイリアスの問題を処理するために、本発明によるデータ互換性シス
テムでは、オブジェクト間のネストされた可視スコープ (scopes of visibility
) をサポートする新規のTContextクラスが使用されている。これは、アプリケー
ションがスタック上にプッシュし、スタックからポップして可視範囲を定義でき
るようにする「仮想」コンテキストのスタックを構築し、維持している。また、
各オブジェクトと共に可視フラグ (visibility flag) をストアし、与えられたオブジェクトの可視性をコンテキストに入れて戻すIsVisible()メソッドを用意している。

【０１４７】 TContextクラスは、ストリームオブジェクトへの参照を保存しておくために使
用されるプライベートクラスである。これは、前述したCommonpointフレームワークに見られるTContextの改良したものである。データ互換性に関して最も注目
すべき追加は、仮想コンテキストスタック (virtual context stack) とエクストラオブジェクトデータ (extra object data) であり、これらについては以下で説明する。TContextクラスはパブリックTContextObjectDataオブジェクトイン
スタンスも構築し、オブジェクトデータを保存するようにしている。TContextOb
jectDataインスタンスは、Add()、AddAt()、Find()、IncrementCount()、Remove
()およびReset()メソッドをTContextオブジェクトで使用することにより作成され、維持される。TContextのクラス宣言は次の通りである。

【０１４８】

【数３８−１】

【０１４９】

【数３８−２】

【数３８−３】

【０１５０】 TVirtualContextクラスは、コンテキスト内のオブジェクトのスコープを定義するために使用される実行クラスである。これについては、以下で説明し、クラ
ス宣言は次のようになっている。

【０１５１】

【数３９】

【０１５２】上述したデータ互換性データライタTExtensionOutputStreamとTAlternateOutp
utStreamは、定義された範囲が受け取り側の視点を表すように仮想コンテキスト
のスタックを操作するようにコーディングされている。オブジェクトが可視であ
れば、これはストリームリーダによって読み取られていなければならないことを
意味する。従って、Flatten()関数のエイリアシングコードは、単純エイリアスを可視オブジェクトに、ローバストエイリアスを可視でないオブジェクトに書く
ことができる。

【０１５３】可視フラグを維持するアルゴリズムは単純である。コンテキストに置かれてい
る各オブジェクトは自動的に可視にされる。新しい仮想コンテキストがスタック
上にプッシュされるときは、なにも変更されない。しかし、仮想コンテキストが
スタックからポップされるときは、その仮想コンテキスト内のオブジェクトのす
べて（つまり、その仮想コンテキストがスタックに置かれているときコンテキス
トに追加されたオブジェクトのすべて）は不可視のマークが付けられる。

【０１５４】仮想コンテキストがスタック上にプッシュされ、スタックからポップされると
きのオペレーションのシーケンスは図１１Ａ〜図１１Ｆに示されている。これら
の図は、書かれているストリーム上のTContext::IsVisibleの戻り値を示している。各イメージの上部にある太線の水平ライン、例えば、ライン１１００はスト
リームを表し、各イメージの下部にある階段状ラインはストリーム上の仮想コン
テキストのスタックを表している。下向き矢印、例えば、矢印１１０２は、仮想
コンテキストがいつスタック上にプッシュされたかを示し、上向き矢印、例えば
、矢印１１０４は、仮想コンテキストがいつスタックからポップされたかを示し
ている。オブジェクトは、各図の左から右にストリーム上に書かれ、各図の右向
き矢印はストリームの現在位置を表している。ストリーム上のエリア１１０６の
ようなハッチされたエリアは現在位置から見えるオブジェクトを表し（IsVisibl
e()はTRUEを戻す）、ストリーム上の明るいエリアは現在位置から見えないオブジェクトを表している（IsVisible()はFALSEを戻す）。仮想コンテキストがポッ
プされるときはいつでも、その仮想コンテキスト内のストリームに書かれたオブ
ジェクトのすべては不可視のマークが付けられることに注意されたい。

【０１５５】スタックベースの親子関係のほかに、仮想コンテキストは兄弟 (sibling) 関係もサポートしている。値がTRUEでインスタンス生成される仮想コンテキストは
、以前にポップされた仮想コンテキストの兄弟であると宣言される。図１２Ａ〜
図１２Ｈは、書かれているストリーム上のTContext::IsInSiblingContextの戻り
値を示している。各イメージの上部にある太線の水平ライン、例えば、ライン１
２００はストリームを表し、各イメージの下部の階段状ラインはストリーム上の
仮想コンテキストのスタックを表している。下向き矢印、例えば、矢印１２０２
は、仮想コンテキストがいつスタック上にプッシュされたかを示し、上向き矢印
、例えば、矢印１２０４は、仮想コンテキストがいつスタックからポップされた
かを示している。Ｓ付きの下向き矢印、例えば、矢印１２０６は、兄弟仮想コン
テキストがいつスタック上にプッシュされたかを示している。オブジェクトは各
図の左から右にストリーム上に書かれ、各図の右向き矢印はストリームの現在位
置を示している。ストリーム上の陰影エリア、例えば、エリア１２０８は現在位
置からの兄弟コンテキスト内にあるオブジェクトを表し、一方ストリーム上の明
るいエリアは現在位置からの兄弟コンテキスト内にないオブジェクトを表してい
る。兄弟関係は、それが兄弟コンテキストであったかどうかに関係なく、以前に
ポップされたコンテキストに適用され、兄弟関係は過渡的なものであることに注
意されたい。

【０１５６】非兄弟仮想コンテキストは、エクステンションを実行するために使用される。
構築され、初期化されるとき、TOutputExtensionStreamオブジェクトは非兄弟仮
想コンテキストをスタック上にプッシュする。破壊時には、TOutputExtensionSt
reamデストラクタ(destructor) は仮想コンテキストをスタックからポップし、コンテキストに追加されていた拡張オブジェクトはすべて不可視にされる。この
ことは、これらの拡張オブジェクトの後続エイリアスがローバストであることを
示している。

【０１５７】兄弟コンテキストは代替を実行するために使用される。最初の代替の開始時に
、TAlternateOutputStreamオブジェクトは非兄弟仮想コンテキストをスタック上
にプッシュし、その代替の終了時に、TAlternateOutputStreamオブジェクトは非
兄弟仮想コンテキストをスタックからポップする。各後続代替の開始時に、TAlt
ernateOutputStreamオブジェクトは兄弟仮想コンテキストをスタック上にプッシ
ュし、その代替の終了時に、それをスタックからポップする。このようにすると
、内部ストリーミングコードはInSiblingContext()メソッドを使用して、参照さ
れたオブジェクトが以前の代替に現れているかどうかを判断することができる。
現れていれば、その時ストリーミングコードはこの情報を代替のヘッダに記録す
る。

【０１５８】仮想コンテキストスタックのほかに、TContextはエクストラオブジェクトデー
タを保存している。このエクストラオブジェクトデータは可視フラグとエイリア
スフラグから構成され、このデータはTContextObjectDataと名付けたプライベー
ト実装クラスから作られたオブジェクトに保存されている。TContextは各オブジ
ェクトの可視フラグを上述したようにセットし、IsVisible()メソッドでその値にアクセスできるようにしている。TContextはエイリアスフラグをセットしない
が、その代わりに、この値に対してMakeAlias()セッタメソッドを用意している。TContext::Findはエイリアスフラグを使用する。要求されたオブジェクトはNI
Lであるが、エイリアス値をもっていれば、Find()はそのエイリアス値を戻してくる。これは、前のセクションで説明した「複数代替のエイリアシング」問題を
部分的に解決している。

【０１５９】ストリーミングサポート関数 ReadVersion()関数とWriteVersion()関数は、本発明によるストリームフォーマット拡張ストラテジを受け入れるように改良されている。改良版WriteVersion
()関数は、ストリーム上にエクステンションが存在することを示し、オプション
として、それがストリームに書き出す拡張ビットバケットを受け付けている。改
良版ReadVersion()関数は、未知のエクステンションをスキップし、オプションとして、それらをビットバケットに格納し、理解できるストリームをアプリケー
ションに送り返す。次に示したものは、ReadVersion()関数の実行である。これは単なる例示目的であり、これに限定されるものではない。

【０１６０】

【数４０】

【０１６１】次は、WriteVersion()関数の擬似コードの例である。

【０１６２】

【数４１】

【０１６３】前述したように、Flatten()とResurrect()の関数は多態ストリーミングを実行
する。以下は、これらの関数のオペレーションのハイレベルな記述である。

【０１６４】

【数４２】

【０１６５】以下は、復元 (resurrect) 関数のハイレベルな記述例である。

【０１６６】

【数４３−１】

【０１６７】

【数４３−２】

【０１６８】

【数４３−３】

【０１６９】 Flatten()関数とResurrect()関数のパブリックセクションの説明で言及されて
いるように、ビットバケットを受け付け、その代替をもたないオブジェクトをフ
ラット化するバージョンもある。これらの関数は、与えられたストリームをTAlt
ernateEnableStreamオブジェクトでラップしそこなうことによって、オブジェク
トがその代替をストリーム化することを禁止している。これは、TAlternateOutp
utStreamオブジェクトは、ラップするストリームのタイプがTAlternateEnableSt
reamであれば代替を受け付けるだけなので、オブジェクトのストリームアウト演
算子でのTAlternateEnableStreamオブジェクトを使用不可にする。TAlternateEn
ableStreamの使用が禁止されると、最初の代替（そのオブジェクト自身）だけが
ストリームに書かれる。

【図面の簡単な説明】

本発明の上記およびその他の利点の理解を容易にするために、添付図面を参照
して、以下で説明する。

【図１】本発明を具現化しているソフトウェアプログラムを実行できる従来のコンピュ
ータシステムの概略ブロック図である。

【図２】オブジェクト情報をストリーム化して、一方のアプリケーションプログラムか
ら他方に渡すときに係わりをもつメインエレメントを示すブロック概略図である
。

【図３】エクステンションをもつオブジェクトのストリーム化クラスコードの概略図で
あり、そこでは、クラス情報がどのようにフォーマットされ、書き出され、読み
取られるかを示している。

【図４】代替をもつオブジェクトのストリーム化クラスコードの概略図であり、そこで
は、クラス情報がどのようにフォーマッティングされ、書き出され、読み取られ
るかを示している。

【図５】本発明によるストリーミングサポートクラスのクラス階層図である。

【図６】 TBufferSupportStreamクラスから派生した、本発明によるストリーミングサポ
ートクラスのより詳細なクラス階層図である。

【図７Ａ】参照を使用しないオブジェクトストリーミングを示す概略図である。

【図７Ｂ】参照を使用するオブジェクトストリーミングを示す概略図である。

【図８】 TAlternateOutputStreamオブジェクトをラップして代替を使用できるようにす
るTAlternateEnableStreamオブジェクトの使い方を示す概略図である。

【図９】本発明によるストリームヘッダサポートクラスのクラス階層図である。

【図１０】ストリームヘッダクラスの使用を示す概略図である。

【図１１Ａ】ストリームに書き出されるオブジェクトの可視性を制御するために仮想コンテ
キストの使用を示す概略データストリーム図である。

【図１１Ｂ】ストリームに書き出されるオブジェクトの可視性を制御するために仮想コンテ
キストの使用を示す概略データストリーム図である。

【図１１Ｃ】ストリームに書き出されるオブジェクトの可視性を制御するために仮想コンテ
キストの使用を示す概略データストリーム図である。

【図１１Ｄ】ストリームに書き出されるオブジェクトの可視性を制御するために仮想コンテ
キストの使用を示す概略データストリーム図である。

【図１１Ｅ】ストリームに書き出されるオブジェクトの可視性を制御するために仮想コンテ
キストの使用を示す概略データストリーム図である。

【図１１Ｆ】ストリームに書き出されるオブジェクトの可視性を制御するために仮想コンテ
キストの使用を示す概略データストリーム図である。

【図１１Ｇ】ストリームに書き出されるオブジェクトの可視性を制御するために仮想コンテ
キストの使用を示す概略データストリーム図である。

【図１１Ｈ】ストリームに書き出されるオブジェクトの可視性を制御するために仮想コンテ
キストの使用を示す概略データストリーム図である。

【図１２Ａ】ストリームに書き出されるオブジェクトの兄弟関係を制御するために仮想コン
テキストの使用を示す概略データストリーム図である。

【図１２Ｂ】ストリームに書き出されるオブジェクトの兄弟関係を制御するために仮想コン
テキストの使用を示す概略データストリーム図である。

【図１２Ｃ】ストリームに書き出されるオブジェクトの兄弟関係を制御するために仮想コン
テキストの使用を示す概略データストリーム図である。

【図１２Ｄ】ストリームに書き出されるオブジェクトの兄弟関係を制御するために仮想コン
テキストの使用を示す概略データストリーム図である。

【図１２Ｅ】ストリームに書き出されるオブジェクトの兄弟関係を制御するために仮想コン
テキストの使用を示す概略データストリーム図である。

【図１２Ｆ】ストリームに書き出されるオブジェクトの兄弟関係を制御するために仮想コン
テキストの使用を示す概略データストリーム図である。

【図１２Ｇ】ストリームに書き出されるオブジェクトの兄弟関係を制御するために仮想コン
テキストの使用を示す概略データストリーム図である。

【図１２Ｈ】ストリームに書き出されるオブジェクトの兄弟関係を制御するために仮想コン
テキストの使用を示す概略データストリーム図である。

───────────────────────────────────────────────────── フロントページの続き (72)発明者デイビスマークアメリカ合衆国 94025 カリフォルニア州メンロパークアルピンロード 2509 Ｆターム(参考） 5B076 AB10 AC01 DD05 DF06 【要約の続き】２番目の代替オブジェクト情報が理解できないときは、リーダはその理解不能オブジェクト情報をスキップし、各代替オブジェクトついて継続する。代替オブジェクトのどれもが理解されなかったときは、例外がスロー (th row) される。ある実施例では、使用されない代替オブジェクトの情報は破棄されないが、代わりに一時記憶域に格納される。そのあと、オブジェクトが再びストリームアウトされると、格納情報が追加され、ストリームに戻される。

Claims

【特許請求の範囲】

【請求項１】第１のフレームワークバージョンで作成された第１のオブジ
ェクト指向プログラムが、オブジェクト情報を多態的にストリーム化して、第２
のフレームワークバージョンで作成された第２のオブジェクト指向プログラムに
渡すことを可能にする装置であって、該装置は、第１オブジェクト指向プログラムに置かれていて、第１オブジェクト指向プロ
グラムによって認識されるオリジナルオブジェクト情報と第２オブジェクト指向
プログラムによって認識される置換オブジェクト情報をストリーム化するストリ
ームライタ関数と、第２オブジェクト指向プログラムに置かれていて、オリジナルオブジェクト情
報が第２オブジェクト指向プログラムによって認識されるときはオリジナルオブ
ジェクト情報を読み取り、オリジナルオブジェクト情報が第２オブジェクト指向
プログラムによって認識されないときはオリジナルオブジェクト情報をスキップ
し、置換オブジェクト情報を読み取るようにストリーム化オブジェクト情報に応
答するストリームリーダ関数とを具えたことを特徴とする装置。
【請求項２】請求項１に記載の装置において、前記ストリームリーダ関数
は、該ストリームリーダ関数がオリジナルオブジェクト情報を認識しないときオ
リジナルオブジェクト情報を破棄するメソッドを具えたことを特徴とする装置。
【請求項３】請求項１に記載の装置において、前記ストリームリーダ関数
は、該ストリームリーダ関数がオリジナルオブジェクト情報を認識しないときオ
リジナルオブジェクト情報を格納しておくメソッドを具えたことを特徴とする装
置。
【請求項４】請求項３に記載の装置において、第２オブジェクトに置かれ
た第２ストリームライタ関数をさらに具え、第２ストリームライタ関数は、格納
されたオリジナルオブジェクト情報をストリーム化して、第１オブジェクト指向
プログラムに送り返す手段を具えたことを特徴とする装置。
【請求項５】請求項１に記載の装置において、オリジナルオブジェクト情
報は、ベースオブジェクト情報と拡張情報を具え、ストリームライタは、ベース
オブジェクト情報が後に続く拡張情報をストリーム化する手段を具えたことを特
徴とする装置。
【請求項６】請求項５に記載の装置において、ストリームリーダ関数は、
ストリームリーダ関数が拡張情報を認識しないとき拡張情報をスキップし、ベー
スオブジェクト情報を読み取る手段を具えたことを特徴とする装置。
【請求項７】請求項１に記載の装置において、前記置換オブジェクト情報
は、第２オブジェクト指向プログラムによって認識される代替オブジェクトの情
報を含んでいることを特徴とする装置。
【請求項８】請求項７に記載の装置において、ストリームライタ関数は、
オリジナルオブジェクト情報と代替オブジェクト情報の両方をストリーム化する
Flatten関数を具えたことを特徴とする装置。
【請求項９】請求項７に記載の装置において、ストリームリーダ関数は、
ストリームリーダがオリジナルオブジェクト情報を認識するときはオリジナルオ
ブジェクト情報を再構築し、ストリームリーダがオリジナルオブジェクト情報を
認識しないときは代替オブジェクト情報を再構築するResurrect関数を具えたことを特徴とする装置。
【請求項１０】請求項１に記載の装置において、ストリームライタは、オ
ブジェクト情報への参照を収めているコンテキストオブジェクトを構築する手段
を具えたことを特徴とする装置。
【請求項１１】第１のフレームワークバージョンで作成された第１のオブ
ジェクト指向プログラムが、オブジェクト情報を多態的にストリーム化して、第
２のフレームワークバージョンで作成された第２のオブジェクト指向プログラム
へ渡すことを可能にする方法であって、該方法は、 (a) 第１オブジェクト指向プログラムによって認識されるオリジナルオブジェクト情報と第２オブジェクト指向プログラムによって認識される置換オブジェ
クト情報を、第１オブジェクト指向プログラムからストリーム化するステップと
、 (b) オリジナルオブジェクト情報が第２オブジェクト指向プログラムによって認識されるときは第２オブジェクト指向プログラム中のオリジナルオブジェク
ト情報を読み取るステップと、 (c) オリジナルオブジェクト情報が第２オブジェクト指向プログラムによって認識されないときはオリジナルオブジェクト情報をスキップし、置換オブジェ
クト情報を読み取るステップとを具えたことを特徴とする方法。
【請求項１２】請求項１１に記載の方法において、ステップ (c) は、 (c1) ストリームリーダ関数がオリジナルオブジェクト情報を認識しないとき
オリジナルオブジェクト情報を破棄するステップを具えたことを特徴とする方法。
【請求項１３】請求項１１に記載の方法において、ステップ (c) は、 (c2) ストリームリーダ関数がオリジナルオブジェクト情報を認識しないとき
オリジナルオブジェクト情報を格納しておくステップを具えたことを特徴とする方法。
【請求項１４】請求項１３に記載の方法において、 (d) セーブされたオリジナルオブジェクト情報をストリーム化して、第１オブジェクト指向プログラムに送り返すステップを含んでいることを特徴とする方
法。
【請求項１５】請求項１１に記載の方法において、オリジナルオブジェク
ト情報はベースオブジェクト情報と拡張情報を含み、ステップ (a) は、 (a1) ベースオブジェクト情報が後に続く拡張情報をストリーム化するステッ
プを具えたことを特徴とする方法。
【請求項１６】請求項１５に記載の方法において、ステップ (c) は、 (c3) ストリームリーダ関数が拡張情報を認識しないとき拡張情報をスキップ
し、ベースオブジェクト情報を読み取るステップを具えたことを特徴とする方法。
【請求項１７】請求項１１に記載の方法において、ステップ (a) は、 (a2) 第２オブジェクト指向プログラムによって認識される代替オブジェクト
の情報を置換オブジェクト情報としてストリーム化するステップを具えたことを特徴とする方法。
【請求項１８】請求項１７に記載の方法において、ステップ (a) は、 (a3) オリジナルオブジェクト情報と代替オブジェクト情報の両方をストリー
ム化するステップを具えたことを特徴とする方法。
【請求項１９】請求項１７に記載の方法において、ステップ (b) は、 (b1) ストリームリーダがオリジナルオブジェクト情報を認識するときはオリジナルオブジェクト情報を再構築するステップを具え、ステップ (c) は、 (c4) ストリームリーダがオリジナルオブジェクト情報を認識しないときは代
替オブジェクト情報を再構築するステップを具えたことを特徴とする方法。
【請求項２０】請求項１１に記載の方法において、ステップ (a) は、 (a4) オブジェクト情報への参照を収めているコンテキストオブジェクトを構
築するステップを具えたことを特徴とする方法。
【請求項２１】第１のフレームワークバージョンで作成された第１のオブ
ジェクト指向プログラムが、オブジェクト情報を多態的にストリーム化して、第
２のフレームワークバージョンで作成された第２のオブジェクト指向プログラム
へ渡すことを可能にするコンピュータプログラムプロダクトであって、該コンピ
ュータプログラムプロダクトは、コンピュータ読み取り可能なプログラムコード
がそこに格納されているコンピュータ使用可能媒体を含んでおり、前記コンピュ
ータ読み取り可能なプログラムコードは、第１オブジェクト指向プログラムによって認識されるオリジナルオブジェクト
情報と第２オブジェクト指向プログラムによって認識される置換オブジェクト情
報をストリーム化するための第１オブジェクト指向プログラム内のプログラムコ
ードと、オリジナルオブジェクト情報が第２オブジェクト指向プログラムによって認識
されるときにオリジナルオブジェクト情報を読み取るための第２オブジェクト指
向プログラム内のプログラムコードと、オリジナルオブジェクト情報が第２オブジェクトプログラムによって認識され
ないときにオリジナルオブジェクト情報をスキップし、置換オブジェクト情報を
読み取るためのプログラムコードとを含むことを特徴とするコンピュータプログラムプロダクト。
【請求項２２】請求項２１に記載のコンピュータプログラムプロダクトに
おいて、オリジナルオブジェクト情報をスキップするためのプログラムコードは
、ストリームリーダ関数がオリジナルオブジェクト情報を認識しないときオリジ
ナルオブジェクト情報を破棄するためのプログラムコードを含むことを特徴とす
るコンピュータプログラムプロダクト。
【請求項２３】請求項２１に記載のコンピュータプログラムプロダクトに
おいて、オリジナルオブジェクト情報をスキップするプログラムコードは、スト
リームリーダ関数がオリジナルオブジェクト情報を認識しないときオリジナルオ
ブジェクト情報をセーブするプログラムコードを含んでいることを特徴とするコ
ンピュータプログラムプロダクト。
【請求項２４】請求項２３に記載のコンピュータプログラムプロダクトに
おいて、セーブしたオリジナルオブジェクト情報をストリーム化して第１オブジ
ェクト指向プログラムに送り返すためのプログラムコードをさらに含むことを特
徴とするコンピュータプログラムプロダクト。
【請求項２５】請求項２１に記載のコンピュータプログラムプロダクトに
おいて、オリジナルオブジェクト情報はベースオブジェクト情報と拡張情報を含
み、オリジナルオブジェクト情報と置換オブジェクト情報をストリーム化するた
めの第１オブジェクト指向プログラム中のプログラムコードは、拡張情報とその
後に続くベースオブジェクト情報をストリーム化するためのプログラムコードを
含むことを特徴とするコンピュータプログラムプロダクト。
【請求項２６】請求項２５に記載のコンピュータプログラムプロダクトに
おいて、オリジナルオブジェクト情報をスキップするためのプログラムコードは
、ストリームリーダ関数が拡張情報を認識しないとき拡張情報をスキップし、ベ
ースオブジェクト情報を読み取るためのプログラムコードを含むことを特徴とす
るコンピュータプログラムプロダクト。
【請求項２７】請求項２１に記載のコンピュータプログラムプロダクトに
おいて、オリジナルオブジェクト情報と置換オブジェクト情報をストリーム化す
るための第１オブジェクト指向プログラム内のプログラムコードは、第２オブジ
ェクト指向プログラムによって認識される代替オブジェクトの情報を置換オブジ
ェクト情報としてストリーム化するためのプログラムコードを含むことを特徴と
するコンピュータプログラムプロダクト。
【請求項２８】請求項２７に記載のコンピュータプログラムプロダクトに
おいて、オリジナルオブジェクト情報と置換オブジェクト情報をストリーム化す
るための第１オブジェクト指向プログラム内のプログラムコードは、オリジナル
オブジェクト情報と代替オブジェクト情報の両方をストリーム化するためのプロ
グラムコードを含むことを特徴とするコンピュータプログラムプロダクト。
【請求項２９】請求項２７に記載のコンピュータプログラムプロダクトに
おいて、オリジナルオブジェクト情報を読み取るためのプログラムコードは、ス
トリームリーダがオリジナルオブジェクト情報を認識するときオリジナルオブジ
ェクト情報を再構築するためのプログラムコードを含み、オリジナルオブジェク
ト情報をスキップするためのプログラムコードは、ストリームリーダがオリジナ
ルオブジェクト情報を認識しないとき代替オブジェクト情報を再構築するための
プログラムコードを含むことを特徴とするコンピュータプログラムプロダクト。
【請求項３０】請求項２１に記載のコンピュータプログラムプロダクトに
おいて、オリジナルオブジェクト情報をストリーム化するための第１オブジェク
ト指向プログラム内のプログラムコードは、オブジェクト情報への参照を収めて
いるコンテキストオブジェクトを構築するためのプログラムコードを含むことを
特徴とするコンピュータプログラムプロダクト。