JPH08511116A - ドキュメント・フレームワーク・システム - Google Patents

Abstract

(57)【要約】 ドキュメントの変更が発生するとその変更を自動的に保存する方法及びシステムが開示されている。その処理を用いるためにオブジェクト指向フレームワークが用いられており、処理の間ドキュメントが無傷であることを保証する。

Description

【発明の詳細な説明】 ドキュメント・フレームワーク・システム 著作権上の注意 本特許出願の一部には、著作権による保護を受けるものが含まれている。本著 作権者は、特許庁における特許ファイルまたは記録に表れる特許書類または発明 の開示をそのまま複製することに異議はないが、他の場合の一切の著作権を保持 する。 関連する特許出願の参照 本特許出願は、Debra L.Orton，David B．Goldsmith，Christopher P．Moelle r，およびAndrew G．Heningerにより1992年12月23日に出願され、タリジェント に譲渡された「オブジェクト指向フレームワークシステム」という名称の特許出 願に関連する。その特許出願の記載を、参照によりここに組み入れることとする 。 発明の分野 本発明は一般的にはコンピュータシステムの改良に 関し、より詳細には、有用性が高いドキュメント・処理を行うシステムおよび方 法に関する。 発明の背景 ドキュメント処理は、コンピュータ技術の中で、近年最も広く行き渡ったアプ リケーションである。ワードプロセッシング技術の状態の例としては、ワードパ ーフェクト（登録商標）のテキストプロセッサーおよびマイクロソフト（登録商 標）のワードテキストプロセッサーがある。これらの製品は多様なオペレーティ ングシステムおよび異なるハードウエアプラットフォーム上で動作するように設 計されている。ハードウエアプラットフォームおよびオペレーティングシステム のいくつかは、他より信頼性がない。データや他の情報の喪失を防ぐために、こ れらの製品はシステムのセットアップ時に動作可能となるバックアップ能力を有 する。バックアップは、ユーザがその能力を動作可能に選択していれば、ユーザ が指定した時間が経過したときに行われる。もしシステムがバックアップの間で 障害を発生した場合は、最後のバックアップ以降の情報が失われる。 発明の概要 そこで、本発明の主要な目的は、オブジェクト指向技術をドキュメント処理に 適用することによりドキュメントを自動的に保存するシステムおよび方法を提供 することにある。このシステムは、ドキュメントの変更を自動的にオブジェクト として保存する。オブジェクトは、不揮発性記憶装置にログされる。電源の喪失 又は他の問題などのイベントがあったときは、ドキュメントにはログに保存され た順で変更が適用されて、そのドキュメントを再生する。 図面の簡単な説明 第１図は、好適な実施例としてのパーソナルコンピュータシステムのブロック 図である。 第2A図および第2B図は、好適な実施例において生じる処理を表すフローチャー トである。 第３図は、好適な実施例においてドキュメントを記憶装置に格納した時に生じ る処理を表すフローチャートである。 第４図は、好適な実施例における、ドキュメントの保存に関連するロジックを 表すフローチャートである。 発明の詳細な説明 本発明は、好適には、IBM（登録商標）PS/2（登録商標）またはアップル（登 録商標）マッキントッシュ（登録商標）コンピュータのようなパーソナルコンピ ュータ上にあるオペレーティングシステムの環境下で実現される。代表的なハー ドウエア環境を第１図に示す。第１図は本発明によるワークステーションの典型 的なハードウエア構成を示しており、汎用的なマイクロプロセッサ等のような中 央処理ユニット10、組込型不揮発性記憶装置11、および多くの他のユニットを有 する。これらはシステムバス12によって相互に接続されている。第１図に示すワ ークステーションは、ランダムアクセスメモリ（RAM）14、リードオンリメモリ （ROM）16、ディスクユニット20およびディスケットユニット21等のような周辺 デバイスをバスに接続するI/Oアダプタ18、キーボード24、マウス26、スピーカ2 8、マイクロフォン32、および／またはタッチスクリーンデバイス（不図示）の ような他のユーザインタフェースデバイスをバスに接続するユーザインタフェー スアダプタ22、ワークステーションをデータプロセッシングネットワーク23に接 続する通信アダプタ34、並びに、バスをディスプレイデバイス38に接続するディ スプレイアダプタ36を有する。ワークステーションは、アップルシステム７（登 録商標）オペレー ティングシステムのようなオペレーティングシステムを有する。 好適な実施例においては、本発明はオブジェクト指向プログラム技術を用いた C++プログラミング言語によってインプリメントされる。当業者に明らかなよう に、オブジェクト指向プログラミング（OOP）のオブジェクトはデータ構成およ びそのデータ上の動作を備えたソフトウエアエンティティである。オブジェクト のデータエレメントによって表される特徴およびオブジェクトのデータ操作機能 によって表される動作によって、オブジェクトが仮想および実際の世界のエンテ ィティをモデル化することを、それらのエレメントは共同して可能とする。この ようにして、オブジェクトは人物およびコンピュータのような具体的なものをモ デル化することができ、また、数値又は幾何学的な概念のような抽象的な概念を モデル化することができる。オブジェクト技術の利点は、カプセル化、多形（po lymorphism）、および継承の、３つの基本的な原理に表れる。 オブジェクトは、そのデータの内部構造およびそれらの機能が動作するアルゴ リズムをハイド、即ちカプセル化する。これらのインプリメンテーションの詳細 を表す代わりに、オブジェクトは外部の情報を用いることなく、それらの抽象性 をクリアに表すインタフェースを提供する。多形（polymorphism）は、更に一 歩カプセル化を進める。このアイデアは、多型、１インタフェースである。ソフ トウエア構成部品は、他の構成部品が何であるかを正確に知ることなくその構成 部品を要求することができる。要求を受け取った構成部品はそれを理解し、その 変数及びデータに従って、その要求をどのように実行するかを明らかにする。第 ３の原理は継承である。これは、開発者が既に存在するデザイン及びコードを再 使用することを許容する。この許容性は、開発者が傷を避けたソフトウエアを生 成することを可能とする。より正確には、継承により開発者は振る舞いを引き継 ぐサブクラスを得る。その振る舞いを、開発者は特定の要求に合うようにカスタ マイズすることができる。 従来技術のアプローチは、手続環境における階層オブジェクト及びクラス・ラ イブラリに向けられている。製品化された多くのアプリケーションフレームワー クは、このデザイン・アプローチを採用している。このデザインでは、単一のオ ペレーティングシステムの最上部の上に、一つまたはより多くのオブジェクト階 層がある。このアプローチは、カプセル化、多形（polymorphism）、およびオブ ジェクトレイヤにおける継承の全ての原理を用いており、先行のプログラミング 技術に対しては十分な改良であるが、このアプローチには限界がある。これらの 困難性は、開発者が 彼ら自身のオブジェクトを再使用することは容易であるが、他のシステムのオブ ジェクトを使用することは困難であり、開発者はなお、手続的なオペレーティン グシステム（OS）コールの下位の、オブジェクトではない階層に手を伸ばす必要 があるという事実に起因している。 オブジェクト指向プログラミングの他の側面は、アプリケーションの開発に対 するフレームワークアプローチである。フレームワークの最も合理的な定義の一 つは、イリノイ大学のRalph E．Johnsonおよびパーデュ（Purdue）のVincent F ．Russoに由来する。彼らの1991年の論文、オブジェクト指向デザインの再使用 （Reusing Object-Oriented Designs）、イリノイ技術レポートUIUCDCS91-1696 において、彼らは次の定義を行っている。「要約クラスは、一組の責任を遂行す るために共同する一組のオブジェクトである。そしてフレームワークは、定義さ れた一組の計算の責任を実行するために共同する一組のオブジェクトクラスであ る。」プログラミングの立場からは、フレームワークは本質的に、動作している アプリケーションの既に作られた構造を提供する、相互に接続されたオブジェク トクラスのグループである。例えば、ユーザインタフェースフレームワークは、 ウインドウ、スクロールバー、メニュー等を描画することに対するサポートお よび「デフォルト」動作を提供する。フレームワークはオブジェクト技術に基づ いているので、この動作は継承され、またオーバライドされる。これにより、開 発者がフレームワークを拡張し、特定の専門技術分野にカスタマイズされた解法 を生成することが可能になる。これは、伝統的なプログラミングと比較した大き な効果である。なぜならプログラマーは元のコードを変更するのではなく、ソフ トウエアを拡張しているからである。加えて、開発者は盲目的にコードの階層を 通り抜けるのではない。なぜなら、フレームワークは構造的なガイダンス及びモ デリングを提供するが、同時に問題の場所に固有の特定の動作を与えることも自 由だからである。 ビジネスの見地からは、フレームワークは特定の知識エリアにおける専門技術 のカプセル化又は具体化として見ることができる。共同開発組織である、独立ソ フトウエアベンダ（ISV）およびシステムインテグレータは、製造、会計、また はお金の移動などの、先の例に示した、特定エリアの専門知識を得ている。この 専門知識は彼らのコードに具体化される。フレームワークは、組織が専門技術の 共通の特徴をその組織のコードに具体化することにより、その共通の特徴を捉え てパッケージ化することを可能とする。これは第一に、開発者が経験を用いたア プリケーションを作り又は拡 張することを可能とする。従って、そのビジネスのルールおよびデザインが一度 統一的に施行され使用されると、その問題は解決される。また、フレームワーク の背後にあるフレームワークおよび具体化された専門知識は、それらの専門知識 をパッケージ化し、再販し、および開発する分配メカニズムがあれば、製造、会 計、またはバイオテクノロジーなどの垂直マーケットで得られた経験を有するそ れらの組織にとって、戦略的な資産価値となり、その技術を更に進め、普及させ る。 歴史的には、個人計算プラットホーム上のメインストリーム概念として、フレ ームワークはつい最近表れたものである。この変化はC++などのオブジェクト指 向言語の可搬性に助けられている。伝統的には、C++は、パーソナルコンピュー タ上ではなく、主にUNIXシステムおよび研究者のワークステーション上で作られ た。多くの大学および研究プロジェクトが、今日用いられているフレームワーク 及びクラスライブラリの先駆者を作り上げることを可能としたのは、C++およびS malltalkなどの他のオブジェクト指向言語である。これらのいくつかの例は、ス タンフォード大学のInterViews、カーネギー・メロン大学のAndrewツールキット 、およびチューリッヒ大学のET++フレームワークである。 どのレベルのシステムに関係していて、どのような種類の問題を解決しようと しているかに依存する、多くのフレームワークがある。フレームワークのタイプ はに、ユーザインタフェースの開発をアシストするアプリケーションフレームワ ークから、通信、プリント、ファイルシステムのサポート、グラフィックなどの 基本的なシステムソフトウエアサービスを提供する低位レベルのフレームワーク まである。アプリケーション・フレームワークの商品の例としては、いくつか名 前を挙げると、MacApp（Apple、登録商標）、Bedrock（Symantec、登録商標）、 OWL（Borland）登録商標）、NeXTStep App Kit（Next、登録商標）、およびSmal ltalk-80MVC（ParcPlace、登録商標）などがある。 フレームワークを用いたプログラミングは、他のシステムに慣れた開発者に新 しい考えかたを要求する。実際、伝統的な感覚では、それは“プログラミング” には全く似ていない。DOSまたはUNIXなどの古いスタイルのオペレーティング・ システムでは、開発者自身のプログラムが全ての構造を提供する。オペレーティ ング・システムは、システムコールを介してサービスを提供する。−−開発者の プログラムは、サービスが必要なときにコールを行い、そのサービスが達成され たときに制御が戻る。このプログラム構造は、開発者 が書くコードによって具体化される制御の流れに基づいている。 フレームワークが用いられるときは、これは覆される。開発者はもはや制御の 流れに貴任がない。開発者は実行の流れという観点でプログラミングタスクを理 解する傾向を無くさなければならない。むしろ、オブジェクトの責任を考えなく てはならない。そのオブジェクトは、フレームワークがそのタスクを実行するべ き時を判断することを信頼しなくてはならない。開発者が書いたルーチンは、開 発者が書いたのではなく開発者が見たこともないコードによって起動される。制 御の流れにおけるこのフリップ・フロップは、手続的なプログラミングのみを経 験した開発者にとって、顕著な心理的バリアとなる。しかしながら、一度このこ とが理解されれば、フレームワークのプログラミングは他のタイプのプログラミ ングより遥かに少ない仕事しか必要としない。 アプリケーションフレームワークが開発者に対して好適な機能を提供するのと 同様に、システムフレームワークは、実施例の中に記載してあるように、システ ムレベルサービスを提供することにより同一の概念に影響する。システムプログ ラマーのような開発者は、サブクラス／オーバーライドを用いてカスタマイズさ れた解法を生成する。例えば、オウディオ、ビデオ、MIDI、アニメーションなど の新しいさまざまなデバイスをサポートする基礎を提供することのできるマルチ メディアフレームワークを考える。新たなで種類のデバイスをサポートする必要 のある開発者は、デバイス・ドライバを書かなくてはならない。フレームワーク でこれを行うためには、開発者はその新しいデバイスに特有の特徴及び動作を提 供する必要があるだけである。 この場合開発者は、マルチメディアフレームワークによりコールされる特定の 部材の機能のインプリメンテーションを提供する。開発者にとっての直接的な利 益は、デバイスの各カテゴリの為に必要な一般的コードが既にマルチメディアフ レームワークによって提供されていることである。このことはデバイスドライバ の開発者がより少ないコードを書き、テストし、およびデバッグすることを意味 する。システムフレームワークを用いる他の例は、SCSIデバイス、NuBusカード 、およびグラフィックデバイスの為の分離したI/Oフレームワークを用いること であろう。継承された機能があるので、各フレームワークはそのデバイスのカテ ゴリーにおいて発見された共通の機能のサポートを提供する。他の開発者は、全 ての種類のデバイスに対してこれらの一貫したインタフェースに依存すること ができる。 好適な実施例はフレームワークの概念を採用しており、それをシステム全体に 適用する。商品の開発者、即ち会社の開発者、システムインテグレータ、または OEMにとっては、MacAppなどのフレームワークについて述べた全ての利点が、テ キスト及びユーザのインタフェースのようなアプリケーションレベルに作用する のみでなく、グラフィックス、マルチメディア、ファイルシステム、I/O、テス トなどのサービスのためのシステムレベルに作用できることを意味する。 好適な実施例の構造においてアプリケーションを生成することは、本質的にフ レームワークプロトコルに密着した分野固有のパズル・ピースを書くことと似て いる。このように、プログラミングの全ての概念が変更されている。マルチAPI 階級をコールするコードをライン毎に書くことなく、この環境の中で予め存在す るフレームワークからクラスを引き出し、必要に応じて新しい動作を加え、及び ／又は継承された動作をオーバーライドすることによりソフトウエアを開発する ことができる。 このように、開発者のアプリケーションは、記載されて共有されている全ての 他のフレームワークアプリ ケーションのコードの修正となる。開発者はお互いの仕事にの上で構築ができる ので、これはパワフルな概念である。これは又開発者が最小限必要なだけカスタ マイズするという柔軟性を提供する。いくつかのフレームワークはそのまま用い られるであろう。いくつかのケースにおいては、カスタマイゼーションの量は最 小であり、このため開発者が作業するパズルピースは小さいであろう。他のケー スでは、開発者は非常に広範囲な修正を行い全く新しいものを作るであろう。好 適な実施例では、第１図に示すように、RAM14に存在するアプリケーションプロ グラムは、CPU10の制御下ではオブジェクト指向ドキュメントフレームワークを 用いる多様なタスクを管理する貴任がある。 Apple Macintosh System 7のような他のシステムは、ユーザが明確にドキュメ ントを保存することを要求するモデルを用いる。これらのシステムにおいては、 ユーザがドキュメントを開き、変更し、およびドキュメントを保存する。通常は 、ドキュメントの新たなバージョンが古いものを置き換える。いくつかのアプリ ケーションは一つ又はそれ以上の、過去に保存されたバージョンを保持する。 ユーザが保存するまでは、加えられた変更はアプリケーションの内側にのみ存 在する。アプリケーション又はシステムがクラッシュすると、これらの変更は失 われる。いくつかのアプリケーションはそれらのデー タの一部をディスクに格納する。ユーザはこれらのディスクファイルからいくつ かをリカバーすることができる。いくつかのアプリケーション（例えば、マッキ ントッシュのQuickenおよびHyperCard、登録商標）は、ユーザが何か変更をする 毎に効果的に自動保存を行う。この処理は、クラッシュによりユーザが、過去の 作業を失うことを防ぐ。しかし望ましくない変更によってユーザが作業を失うこ とがある。他のアプリケーションは、ユーザがページを変更したときに別個のフ ァイル中にドキュメントを保存する。しかし、作業しているページ上の作業が失 われることを防ぐことはしない。 セーブレスモデル 好適な実施例は、ドキュメントの各変更を検査しディスクにそのログをとる。 クラッシュのときには、システムは最後に「保存」されたバーションから開始し て、コピーに対してユーザが行った全ての変更を再度適用する。その結果得られ るドキュメントはクラッシュのときにユーザが有していたドキュメントと等しく なる。要するに、システムは保存されたイメージ及びコマンドのログを自動的に 格納する。保存されたイメージは、ある時のドキュメント全体の状態を記録する 。またコマンドログはそのときからのドキュメント の全ての変更を記録する。 ユーザがドキュメントを校正するときの制御の基本的な流れは、以下の通りで ある。 ・ユーザがドキュメントを変更する毎に、その変更を表すコマンドオブジェク トのコピーをキューの最後に置く。 ・別個のバックグランドタスクは、コマンドオブジェクトをキューから取りは ずし、それらをコマンドログに保存する。このタスクは低い優先度で動作する。 これにより、この動作はユーザがシステムに対して働きかけていないときに実行 され、ユーザの生産性に対する影響を最小にする。 ・そのコマンドオブジェクトは、そのドキュメントを変更するために通常に処 理される。 第２図は、好適な実施例によって生じた処理を表すフローチャートである。処 理はターミナル200に進み、直ちに機能ブロック210に通過し、ディスク又は他の 格納デバイスからドキュメントを引き出すことによりドキュメントを開く。ドキ ュメントはテキスト、グラフィック、イメージ、オウディオ、または他の情報で あっても良い。判断ブロック220は、ドキュメントに加えられた変更を検出する 。次に、そのドキュメントに加えられた各変更ついて、コマンドオブジェク トが作られ、機能ブロック240に示す様に記憶装置のキューの最後に置かれる。 最後に、機能ブロック240に示したバックグランドタスクが、キューの中のオブ ジェクトに基づいて、不揮発性格納装置中にログを構築する。 ユーザがドキュメントを開くと、以下の処理が行われる。 ・ドキュメントで保存されたイメージがディスク、キャッシュ、またはメモリ から引き出される。 ・コマンドログが空でなければ、そのログの中のコマンドは再度実行される。 第３図は、好適な実施例に従ってドキュメントが格納されたときに起動される 処理を示すフローチャートである。処理はターミナル300に進み、直ちに機能ブ ロック310に進み、ディスク、ディスクキャッシュ、または他のメモリから、格 納されたドキュメントを引き出す。次に判断ブロック320で、コマンドログが空 であれるか否かの判断を行う。空であれば、ドキュメントは完成しており、制御 がターミナル350に戻る。空でなければ、ログに格納されたコマンドが再度、順 に読まれ、機能ブロック330に示したようにドキュメントに適用される。コマン ドログは機能ブロック340で消去され、制御はターミナル350に戻る。 あるところで、ドキュメントは格納され、 ・保存されたイメージ中にドキュメント全体を保存し、 ・コマンドログを消去する。 第４図は、好適な実施例に従ったドキュメントの保存に関係付けたロジックを 表すフローチャートである。処理はターミナル400に進み、機能ブロック410を直 ちに通過してドキュメントを保存する。次に、コマンドログが機能ブロック420 で消去され、ターミナル430で制御が戻る。この処理はユーザが要求したとき、 またはユーザが指定したとき、またはドキュメントが閉じられたときに自動的に 生じる。 ファイリング構造は、保存されたイメージ及びコマンドログの双方を含む、概 要モデルストアを定義する。ドキュメントは、モデルストアがアクセスを提供す る、別々のモデルオブジェクトから構成される。モデルオブジェクトは、個々の モデルのレベルにおけるドキュメント・イメージを含む。代表的には、そのモデ ルストアは、ディスクに保存される。しかしそのモデルストアがメモリ、キャッ シュ、または他の格納メディア中に存在しても良いことは、当業者に明らかであ る。

【手続補正書】特許法第１８４条の８ 【提出日】１９９５年５月２２日 【補正内容】 （原文明細書第１頁〜第２頁） 明細書 ドキュメント・フレームワーク・システム 著作権表記 本出願は、一部に著作権保護の対象となる内容を含んでいる。著作権者は、何 人が情報を得る目的で特許出願の一部として複製してもそれを妨げるものではな いが、他のすべての権利、特に本内容の商業的利用に関する権利を留保する。 発明の分野 本発明は一般的にはコンピュータシステムの改良に関し、特に、有用性が高い ドキュメント処理を行うシステムおよび方法に関する。 発明の背景 ドキュメント処理は、コンピュータ技術の中で、近年最も広く行き渡ったアプ リケーションである。従来のワードプロセッシング技術の状態の例としては、ワ ードパーフェクト（登録商標）のテキスト・プロセッサおよびマイクロソフト（ 登録商標）のワード・テキスト・プロセッサがある。これらの製品は多様なオペ レーティング・システムおよび異なるハードウエア・プラットフォーム上で動作 するように設計されている。ハードウエア・プラットフォームおよびオペレーテ ィング・システムのいくつかは、他より信頼性がない。データや他の情報の喪失 を防ぐために、これらの製品はシステムのセットアップ時に動作可能となるバッ クアップ能力を有する。バックアップは、ユーザがその能力を動作可能に選択し ていれば、ユーザが指定した時間が経過したときに行われる。もしシステムがバ ックアップの間で障害を発生した場合は、最後のバックアップ以降の情報が失わ れる。同様のバックアップ能力が、データベース、グラフィクス、画像技術アプ リケーションあるいは別のコンピュータ・アプリケーション用に用意されている 。このように、コンピュータ・アプリケーションにとり、バックアップの間のす べての失敗は損害の大きいものである。 IBM Technical Disclosure Bulletin，vol.33，no.12，pp.304-305（May 1991 ）では、Smalltalkのプログラマーがすばやく容易にイメージのクラッシュから 回復させることのできるように作成されたツールが開示されている。Smalltalk/ Vでは、ユーザがその作業の途中で生成したあるいは変更したメソッドのソース コードを保持する変更ログファイル（change log file）と呼ばれるファイルが 使われる。このファイルは環境イメージの一部分と考えられ、特にユーザがタイ プインしたすべてのものを含む。これらの変更は、ユーザがそのアプリケータョ ンのテストで明らかに実行したすべてのSmalltalkのコードの履歴と共に、メソ ッドの生成と変更、メソッドの削除、クラスの生成，変更およびクラスの削除を 含む。 ユーザが環境を変更すると、変更ログファイルおよびクラス階層ブラウザはそ のユーザが行った変更によりダイナミックに更新される。各変更は変更ログファ イルの終りに付け加えられる。システムのクラッシュ時、ユーザは環境をリスタ ートさせ、変更ログファイルを編集し、イメージが保存された最終時刻以降生じ たすべての変更を手動で取り出さなければならない。これは退屈でしかも時間が かかり、またしばしば、ユーザが自分が変更に満足するまでいく度の変更したメ ソッドのような多くの冗長データが含まれている。開発が進むにつれてこの変更 ログファイルは非常に大きくなってしまう。 引例に記載の解決方法は、最後の‘save image’が生じたロケーションを変更 ログ中に格納する‘unsaved changes’と呼ばれる新しいメソッドをオブジェク ト指向環境に加えることである。最後のセーブ後に環境中のすべての変更は、以 前と同様に、変更ログファイルに付加される。しかし、クラッシュが起きた時、 このメソッドを実行して、表面にあるウィンドウの内容にファイリングすること により、セーブされたロケーションからそのクラッシュの直前の状態までの変更 のみが迅速に環境に取り込まれる。最新の変更のみ引き出されるので、引出す速 度は非常に上がる。これら変更のファイリングはオブジェクト指向環境をクラッ シュ直前の状態に迅速に回復させ、Smalltalkのユーザにデバックおよび他のプ ログラムミング作業を続けさせる。 “Software Practice & Experience”，vol.17，no.11，pp.813-845（Novembe r 1987）には、ビットマップ・ディスプレイ用に意図された対話型マルチファイ ル・テキスト・エディタが開示されている。テキスト・コマンド言語がマウス駆 動のカット・アンド・ペイスト・インタフェースを補足し、複雑なあるいは反復 性の編集用タスクを容易に特定することができる。この言語は変更されるテキス トの構造を記述する正規表現の構成を特徴とする。アトミック・トランザクショ ンとして記録される変更と共に、データベースとしてのファイルを取り扱うこと により、一般的な‘undo’メカニズムの実現で素直にできる。Samは低域バンド 幅ストリーム（a low-bandwidth stream）で結ばれた２つのプロセスとして実現 され、１つのプロセスはディスプレイを扱い、もう一つのプロセスは編集アリゴ リズムである。したがって、Samは、ビットマップ・ターミナルでのディスプレ イ・プロセスとローカル・ホスト上のディタとして、ビットマップ・ターミナル およびローカル・ホストのエディタ上の２つのプロセスとして、ビットマップを 備えたホスト上の２つのプロセスとして、あるいは、ターミナルのディスプレイ ・プロセスとリモート・ホストのエディタとして、実行できる。ディスプレイ・ プロセスを抑制することにより、ビットマップ・ターミナルを使わなくてもSam を実行できる。システムはコンピュータのメモリにあるキャッシュを使う。 Samは、変更を行うための２パス・アルゴリズムを使って可変長ファイルに対 するファイルの変更を管理し、また処理データが登録されたデータベースとして 各ファイルを扱う。変更は直接には内容に対して行われない。その代わり、コマ ンドの実行が始まった時、一連番号を含む‘mark’が転写バッファに入れられ、 ファイルに対し行われる各変更、挿入が削除あるいはファイル名に対する変更が 写し（transcript）の終りに付加される。コマンドが完了した時、写しは‘mark ’へ巻戻され、内容に付加されるSamは、undoをundoする方法を備えていない。 写しの各markは、連続番号と以前のmarkの写しへのオフセットを含み、写しを巻 き 戻すときの支援としている。 “FOURTH ANNUAL SYMPOSIUM ON USER INTERFACE SOFTWARE AND TECHNOLOGY” ，11 November 1991，US，pp107-115，H．Wang & M．Green,‘An Event-Object Recovery Model For Object-Orienteed User Interfaces’で、オブジェクト指 向アプリケーション用のイベント・リカバリ・モデル（an event recovery mode l）が開示されている。この論文の中で述べられたアプローチでは、従来の履歴 とコマンド・リストを、オブジェクト指向構造に適するパーオブジェクト・リス ト（per-object lists）に分割する。このフレームワークに独特である特徴は、 アプリケーション構造を反映する局所リカバリ・オブジェクトの階層構造、その 簡単なセマンティスクおよびその容易に実行できることである。これにより、イ ンタフェース製作者により要求される作業を大幅に減らし、フレームワークを既 存のオブジェクト指向ユーザ・インタフェース構造に組み入れる。どの引例もオ ブジェクト指向環境でのドキュメントあるいは別のエンティティ（実体）を復元 させるためのコマンド・オブジェクト・ロギング・システムを教示していない。 発明の概要 そこで、本発明の主要な目的は、オブジェクト指向技術をドキュメント処理に 適用することによりドキュメントを自動的に保存するシステムおよび方法を提供 することにある。このシステムは、ドキュメントの変更を自動的に不揮発性記憶 装置にログされるコマンド・オブジェクトとして保存する。電力の喪失又は他の 問題などのイベントがあったときは、ログに保存された順で変更オブジェクトが 適用されて、そのドキュメントあるいは他のアプリケーション・イメージを再生 する。 図面の簡単な説明 第１図は、好適な実施例としてのパーソナルコンピュータシステムのブロック 図である。 第2A図および第2B図は、好適な実施例において生じる処理を表すフローチャー トである。 第３図は、好適な実施例においてドキュメントを記憶装置に格納した時に生じ る処理を表すフローチャートである。 第４図は、好適な実施例における、ドキュメントの保存に関連するロジックを 表すフローチャートである。 発明の詳細な説明 本発明は、好適には、IBM（登録商標）PS/2（登録商標）またはアップル（登 録商標）マッキントッシュ（登録商標）コンピュータのようなパーソナルコンピ ュータ上にあるオペレーティングシステムの環境下で実現される。代表的なハー ドウエア環境を第１図に示す。第１図は本発明によるワークステーションの典型 的なハードウエア構成を示しており、汎用的なマイクロプロセッサ等のような中 央処理ユニット10、組込型不揮発性記憶装置11、および多くの他のユニットを有 する。これらはシステムバス12によって相互に接続されている。第１図に示すワ ークステーションは、ランダムアクセスメモリ（RAM）14、リードオンリメモリ （ROM）16、ディスクユニット20およびディスケットユニット21等のような周辺 デバイスをバスに接続するI/Oアダプタ18、キーボード24、マウス26、スピーカ2 8、マイクロフォン32、および／またはタッチスクリーンデバイス（不図示）の ような他のユーザインタフェースデバイスをバスに接続するユーザインタフェー スアダプタ22、ワークステーションをデータプロセッシングネットワーク23に接 続する通信アダプタ34、並びに、バスをディスプレイデバイス38に接続するディ スプレイアダプタ36を有する。 請求の範囲 １．ユーザのオープン（open）、変更（modify）およびセーブ（save）コマンド に応答し、元のドキュメントを表わすドキュメント・データと記憶装置に存在す るドキュメント・データを変更する装置において、 （a）前記ユーザ・オープン・コマンドに応答して、前記元のドキュメント・ データを仕業領域にコピーする手段と、 （b）前記各ユーザ変更コマンドに応答して、前記元のドキュメント・データ の部分を識別するコマンド・データと前記元のドキュメント・データの部分を変 更するコマンド・メソッドを含むコマンド・オブジェクトを生成する手段と、 （c）前記各コマンド・オブジェクトに応答して、前記各コマンド・オブジェ クトにある前記コマンド・メソッドを実行し、前記作業領域にある前記元のドキ ュメント・データの部分を変更して前記作業領域に変更されたドキュメント・デ ータの部分を生成する手段と、 （d）前記各ユーザ変更コマンドに応答して、前記生成されたコマンド・オブ ジェクトを前記記憶装置に格納する手段と、 （e）前記ユーザのセーブ・コマンドに応答して、前記記憶装置にある前記元 のドキュメント・データを前記作業領域にある前記変更されたドキュメント・デ ータで上書きする手段と、 （f）前記元のドキュメント・データの前記上書きに応答して、前記記憶装置 にあるコマンド・オブジェクトを消去する手段と を具備することを特徴とする装置。 ２．前記コマンド・オブジェクトが、前記変更されたドキュメント・データの部 分に作用し前記変更されたデータの部分を前記元のデータの部分に回復させるア ンドウ（undo）・コマンド・メソッドを含むことを特徴とする請求の範囲第１項 に記載の装置。 ３．前記コマンド・オブジェクトが、前記元のドキュメント・データに作用し前 記変更されたデータの部分を再生するリドウ（redo）・コマンド・メソッドを含 むことを特徴とする請求の範囲第１項に記載の装置。 ４．前記元のドキュメント・データと前記コマンド・オブジェクトを格納するロ グを含むモデル・オブジェクトをさらに具備することを特徴とする請求の範囲第 １項に記載の装置。 ５．前記ドキュメント・データがテキスト、グラフィック、イメージ、あるいは オーディオ情報を具備することを特徴とする請求の範囲第１項に記載の装置。 ６．ユーザのオープン（open）、変更（modify）およびセーブ（save）コマンド に応答し、元のドキュメントを表わすドキュメント・データと記憶装置に存在す るドキュメント・データを変更する方法において、 （a）前記ユーザ・オープン・コマンドに応答して、前記元のドキュメント・ データを仕業領域にコピーするステップと、 （b）前記各ユーザ変更コマンドに応答して、前記元のドキュメント・データ の部分を識別するコマンド・データと前記元のドキュメント・データの部分を変 更するコマンド・メソッドを含むコマンド・オブジェクトを生成するステップと 、 （c）前記各コマンド・オブジェクトに応答して、前記各コマンド・オブジェ クトにある前記コマンド・メソッドを実行し、前記作業領域にある前記元のドキ ュメント・データの部分を変更して前記作業領域に変更されたドキュメント・デ ータの部分を生成するステップと、 （d）前記各ユーザ変更コマンドに応答して、前記生成されたコマンド・オブ ジェクトを前記記憶装置に格納するステップと、 （e）前記ユーザのセーブコマンドに応答して、前記記憶装置にある前記元の ドキュメント・データを前記作業領域にある前記変更されたドキュメント・デー タで上書きするステップと、 （f）前記元のドキュメント・データの前記上書きに応答して、前記記憶装置 に あるコマンド・オブジェクトを消去するステップと を具備することを特徴とする方法。 ７．ステップ（b）が、 （b1）前記変更されたドキュメント・データの部分に作用し前記変更されたデ ータの部分を前記元のデータの部分に回復させるアンドウ（undo）・コマンド・ メソッドを含むコマンド・オブジェクトを生成するステップ を具備することを特徴とする請求の範囲第６項に記載の方法。 ８．ステップ（b）が、 （b2）前記元のドキュメント・データに作用し前記変更されたデータの部分を 再生するリドウ（redo）・コマンド・メソッドを含む前記コマンド・オブジェク トを生成するステップ を具備することを特徴とする請求の範囲第６項に記載の方法。 ９．（g）前記元のドキュメント・データと前記コマンド・オブジェクトを格納 するログを含むモデル・オブジェクトを生成するステップ をさらに具備することを特徴とする請求の範囲第６項に記載の方法。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁶ 識別記号 庁内整理番号 ＦＩ 9288−5Ｌ Ｇ０６Ｆ 15/20 ５７０Ｍ 9288−5Ｌ ５７０Ｕ (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ， ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，Ｇ Ｂ，ＨＵ，ＪＰ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＵ，ＬＶ ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ， ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＫ，ＵＡ，ＵＺ，ＶＮ (72)発明者 アンダーソン，デイヴィッド，アール. アメリカ合衆国 95014 カリフォルニア 州 クパチーノ ウエスト エステイツ ドライブ 10761 (72)発明者 ローゼンシュタイン，ラリー，エス. アメリカ合衆国 95051 カリフォルニア 州 サンタ クララ ミューア アヴェニ ュ 182

Claims (1)

1. 【特許請求の範囲】 以上説明したように、新規なものとして特許請求し、特許権による保護を求め るのは： １．ドキュメントを処理するシステムであって、 （a）プロセッサと、 （b）前記プロセッサに接続された記憶手段と、 （c）前記プロセッサの制御下にあるディスプレイと、 （d）前記記憶手段に存在し、前記ディスプレイ上に表されるドキュメントと 、 （e）前記記憶装置に存在するドキュメントの各変更に関係づけられたコマン ドオブジェクトと、 （f）前記コマンドオブジェクトを格納するログと、 （g）前記記憶手段に存在するドキュメントが変更されたときに、コマンドオ ブジェクトを生成する処理手段と、 （h）前記ログをアクセスし、前記コマンドオブジェクトを得、前記コマンド オブジェクトを前記ドキュメントに適用することにより、前記ドキュメントを回 復する手段と を備えたことを特徴とするシステム。 ２．前記ドキュメントを格納するディスクおよび前記 ドキュメントが前記ディスクに格納されると前記ログを消去する処理手段とを更 に備えたことを特徴とする請求の範囲第１項に記載のシステム。 ３．コマンドオブジェクトがログに記載される前に、コマンドオブジェクトを保 持する、前記記憶手段に存在するキューを更に備えたことを特徴とする請求の範 囲第１項に記載のシステム。 ４．前記コマンドオブジェクトを前記キューから前記ログへ、ドキュメント処理 タスクより優先度が低いタスクとして移動する処理手段を更に備えたことを特徴 とする請求の範囲第１項に記載のシステム。 ５．前記ドキュメントが回復された後に、前記ログを消去する手段をさらに備え たことを特徴とする請求の範囲第１項に記載のシステム。 ６．前記ログが不揮発性の記憶手段に格納されていることを特徴とする請求の範 囲第１項に記載のシステム。 ７．コンピュータの記憶手段に存在するドキュメントを処理する方法であって、 （a）ドキュメントを前記コンピュータの前記記憶手 段にロードするステップと、 （b）前記記憶手段に存在する前記ドキュメントの各変更に関連づけれたコマ ンドオブジェクトを構築するステップと、 （c）前記記憶手段に存在する前記ドキュメントに変更が加えられたときにコ マンドオブジェクトを生成するステップと、 （d）前記記憶手段中のログに前記コマンドオブジェクトを格納するステップ と、 （e）前記ログをアクセスし、前記コマンドオブジェクトを得、前記コマンド オブジェクトを前記ドキュメントに適用することにより前記ドキュメントを回復 する手段と、 を備えたことを特徴とする方法。 ８．前記ドキュメントをディスクに格納するステップと、 前記ドキュメントが前記ディスクに格納されたときに前記ログを消去するステ ップと を更に備えたことを特徴とする請求の範囲第７項に記載の方法。 ９．コマンドオブジェクトが前記ログに書かれる前に、コマンドオブジェクトを 保持する、前記記憶手段中に存在するキューを保持するステップを更に備えた ことを特徴とする請求の範囲第７項に記載の方法。 10．ドキュメントを処理するタスクより優先度が低いタスクとして、前記コマン ドオブジェクトを前記キューから前記ログへ移動することを特徴とする請求の範 囲第９項に記載の方法。 11．前記ドキュメントが回復された後に、前記ログを消去するステップを更に備 えたことを特徴とする請求の範囲第７項に記載の方法。 12．前記ログを前記不揮発性記憶手段に記憶するステップを更に備えたことを特 徴とする請求の範囲第７項に記載の方法。