JPH08503323A

JPH08503323A - オブジェクト指向システムのロケータ・システム

Info

Publication number: JPH08503323A
Application number: JP7506389A
Authority: JP
Inventors: ヌグウェン，フランク，ティー．
Original assignee: タリジェントインコーポレイテッド
Priority date: 1993-08-04
Filing date: 1994-01-03
Publication date: 1996-04-09
Anticipated expiration: 2016-01-31
Also published as: AU6085194A; WO1995004967A1; EP0664028B1; DE69402523T2; CA2144731A1; JP3131223B2; DE69402523D1; EP0664028A1; US5379430A

Abstract

(57)【要約】オブジェクト指向システムのロケータ・システムを提供することを目的とし、導入プログラム（installation program）を実行することなく、システム・コンポーネント（ドキュメント、ツール、フォント、ライブラリなど）をコンピュータ・システムに追加する方法およびシステムが開示されている。探索基準で指定されたプロパティ（property）に一致するプロパティをもつシステム・コンポーネントを見つけるためにロケーション・フレームワーク（location framework）が採用されている。このフレームワークは、探索基準に一致するプロパティをもつシステム・コンポーネントがシステムに追加されたり、システムから除去されたりしたとき、システムから通知を受け取る。

Description

【発明の詳細な説明】オブジェクト指向システムのロケータ・システム関連特許出願の相互参照本特許出願は、「オブジェクト指向ロケータ・システム」（Objet-Oriented L ocator System）という名称で1993年８月４日に出願された特許出願（発明者Fra nk Nguyen、承継人Taligent）の関連出願であり、その開示事項は引用により本明細書の一部を構成するものである。また、本特許出願は、「コンテナ・オブジェクト・システム」（Container Ob ject System）という名称で1993年６月３日に出願された特許出願（発明者Frank Nguyen、承継人Taligent）の関連出願であり、その開示事項は引用により本明細書の一部を構成するものである。著作権所有表記本特許出願明細書の一部には、著作権保護の対象となる内容が含まれている。著作権所有者は、米国特許商標庁の特許ファイルまたは記録に記載されている特許文書または特許開示内容を、第三者がファクシミリ複製することを妨げるものではないが、他の方法による場合は、一切の著作権を所有することを留保する。発明の分野本発明は、一般的には、コンピュータ・システムにおける改良に関し、より具体的には、システム・コンポーネントを自動管理するためのシステムおよび方法に関する。発明の背景システム開発者に対して、システムおよびアプリケーションをより使いやすく、より直観的にする要求が高まっている。これまでに、エルゴノミクス（ergono mics−人間工学）の面で多くの進歩がなし遂げられているが、アプリケーションまたはシステム・プログラムで使用されるコンポーネントを、即座に（on the f ly）管理し、更新するという問題を取り上げているものはひとつもない。ここでいうコンポーネントとは、ドキュメント、フォント、ツール、共有ライブラリ、またはその他の資源のことである。類似した技術の例としては、IBM PS/2コンピュータがある。マイクロチャネル（MicroChannel）アーキテクチャに準拠するように正しく設計されたある種のカードは、PS/2システムにプラグインし、システムを構成し直さなくても使用できるようになっている。しかし、このカードでさえも、構成が必要になる場合があり、カード上に存在する資源を必要とするアプリケーション・プログラムはいずれも、その資源を利用するためには、その前に正しく設計し、コーディングし、コンパイルし、連係編集（link-edit）し、デバッグしておかなければならない。理想的には、システム・プログラムとアプリケーションは、システム・コンポーネントを動的に識別できるようになっていなければならない。また、システムは、システム内の変更が行われたとき、資源が更新されたことをすべてのシステム・プログラムやアプリケーションに知らせることができなければならない。現時点では、これらの問題を扱うどのアプローチも提案されていない。発明の概要従って、本発明の主要目的は、導入プログラム（installation program）を実行することなく、システム・コンポーネント（ドキュメント、ツール、フォント、ライブラリなど）をコンピュータ・システムに追加することである。探索基準（search criteria）で指定されたプロパティ（pro perties）に一致するプロパティをもつシステム・コンポネーントを探し出すために、ロケーション・フレームワーク（locationframework）が採用されている。このフレームワークは、探索基準に一致するプロパティをもつシステム・コンポーネントがシステムに追加され、あるいはシステムから除去されるときも、システムから通知を受け取るようになっている。本発明による方法およびシステムは、システム・ロケータ要求（system locat or request）のタイプを対話方式（interactively）で判断し、探索基準と探索範囲（scope of search）を取得し、指定されたシステム探索基準に一致する資源を突き止めるようにシステムに照会（query）する機能を備えている。一致したシステム・コンポーネントは要求を行った側（initiatingrequestor）に返却されるので、要求側はそのシステム・コンポーネントをアクセスすることが可能になる。図面の簡単な説明第１図は、好適実施例によるパーソナル・コンピュータ・システムを示すブロック図である。第２図は、好適実施例に従ってロケータ要求のタイプを検査するときの関連ロジックを示すフローチャートである。第３図は、好適実施例に従ってシステム・ロケータ要求の特定タイプを判断するときの関連ロジックを示すフローチャートである。第４図は、好適実施例に従ってネットワーク・ロケータ要求の特定タイプを判断するときの関連ロジックを示すフローチャートである。第５図は、好適実施例に従ってアプリケーション・ロケータ要求の特定タイプを判断するときの関連ロジックを示すフローチャートである。第６図は、好適実施例に従ってシステム・ロケータ要求を処理するときの関連ロジックを示すフローチャートである。第７図は、好適実施例に従ってネットワーク・ロケータ要求を処理するときの関連ロジックを示すフローチャートである。第８図は、好適実施例に従ってアプリケーション・ロケータ要求を処理するときの関連ロジックを示すフローチャートである。第９図は、好適実施例によるスマート・フォルダを示す図である。第10図は、好適実施例によるプレース（場所）のディスプレイをシミュレーションした図である。第11図は、好適実施例によるパーツビン・ディスプレイをシミュレーションした図である。発明の詳細な説明本発明は、好ましくは、IBM（登録商標）社PS/2（登録商標）またはアップル（登録商標）社マッキントッシュ（登録商標）コンピュータなどのパーソナル・コンピュータ上に置かれているオペレーティング・システムの環境（コンテキスト）で実施される。代表的なハードウェア環境を第１図に示す。同図は従来のマイクロプロセッサのように、非揮発性記憶機構11を内蔵した中央演算処理ユニット10、およびシステム・バス12を介して相互に接続された複数の他のユニットを装備した、本発明によるコンピュータの代表的ハードウェア構成を示している。第１図に示すワークステーションは、ランダム・アクセス・メモリ（RAM）14、リードオンリ・メモリ（ROM）16、ディスク・ユニット２０、ディスケット・ユニット21などの周辺デバイスをバスに接続するための入出力アダプタ18、キーボード24、マウス26、スピーカ28、マイクロホン32、および／またはタッチ・スクリーン・デバイス（図示せず）などのユーザ・インタフェース・デバイスをバスに接続するためのユーザ・インタフェース・アダプタ22、ワークステーションをデータ処理ネットワーク23に接続するための通信アダプタ34、およびバスをディスプレイ・デバイス38に接続するためのディスプレイ・アダプタ36を装備している。コンピュータには、アップル社System/7（登録商標）オペレーティング・システムなどのオペレーティング・システムが常駐している。好適実施例では、本発明は、オブジェクト指向プログラミング技法を使用してＣ++プログラミング言語で書かれている。この分野に精通しているものならば容易に理解されるように、オブジェクト指向プログラミング（Object-Oriented Pr ogramming - OOP）のオブジェクトは、データ構造とデータに対するオペレーション（操作、演算など）からなるソフトウェア・エンティティ（software entit y）である。これらのエレメントが協力し合うことにより、オブジェクトは、そのデータ・エレメントで表されたその特性、およびそのデータ操作関数（data m anupulation functions）で表されたその作用（behavior）からとらえて、ほとんどどのような実世界のエンティティでもモデル化することができる。この方法によると、オブジェクトは、人やコンピュータなどの具体物をモデル化することができ、また、数や幾何学的概念などの抽象概念をモデル化することができる。オブジェクト・テクノロジの利点は次の３つの基本的原理から得られるものである。それは、カプセル化（encapsulation）、多態（polymorphism）および継承（inheritance）である。オブジェクトは、そのデータの内部構造とその関数が実行されるときのアルゴリズムを隠蔽する。つまりカプセル化する。これらのインプリメンテーションの細部を見せる代わりに、オブジェクトは、外部情報（extraneous information）のないクリーンな形でその抽象化（abstractions）を表しているインタフェースを提示する。多態（polymorphism）はカプセル化をさらに一歩進めたものである。この考え方は、多数の形体をもつ、１つのインタフェースである。あるソフトウェア・コンポーネントは、別のコンポーネントがなんであるかを正確に知らなくても、その別のコンポーネントを要求することができる。要求を受け取ったコンポーネントはその要求を解釈し、その要求をどのように実行すべきかを、その変数とデータに従って判断する。三番目の原理である継承によれば、開発者は既存の設計やコードを再利用することができる。この機能を利用すると、開発者はソフトウェアを初めから作ることが回避される。むしろ、継承を通して、開発者は作用を継承するサブクラスを派生し、その作用を開発者独自の要求に合ったものにカストマイズすることができる。従来のアプローチでは、オブジェクトとクラス・ライブラリを手続き向き環境で階層化する方法がとられていた。市販されている多くのアプリケーション・フレームワークはこの設計手法を採用している。この設計では、モノリシック・オペレーティング・システム（monolithic operating s ystem）の上に１つまたは２つ以上のオブジェクト層が置かれている。このアプローチでは、カプセル化、多態および継承のすべての原理がオブジェクト層に採用され、手続き向きプログラミング技法を大幅に改善しているが、このアプローチにはいくつかの制約がある。これらの問題は、開発者が自身のオブジェクトを再利用することは容易であるが、他のシステムからのオブジェクトを使用することが困難であるため、手続き向きオペレーティング・システム（OS）のコールを使用して、下位の非オブジェクト層まで到達する必要があることに起因している。オブジェクト指向プログラミングが持つもう１つの側面は、アプリケーションを開発するのにフレームワーク・アプローチを採用していることである。フレームワークの最も合理的な定義の１つとして、イリノイ大学のRalph E．Johnsonと PurdueのVincent F．Russoによるものがある。両氏の1991年の論文「オブジェクト指向設計の再利用」（ReusingObject-Oriented Designs）、イリノイ大学技術報告書UIUCDCS91-1696の中で、次のような定義を提案している。「抽象クラスとは、一組の責任分担を協力し合って実行するオブジェクトの集合を設計したものである。従って、フレームワークとは、組で定義された計算責任分担を協力し合って実行するオブジェクト・クラスが集まったものである。」プログラミング側から見たときは、フレームワークとは、基本的には、実働アプリケーション（working application）の事前に作られた構造を提供する、相互に接続されたオブジェクト・クラスの集まりである。例えば、ユーザ・インタフェース・フレームワークは、描画ウィンドウ（drawing window）、スクロールバー、メニューなどをサポートし、これらの「デフォルト（省略時）」の作用を提供することができる。フレームワークはオブジェクト・テクノロジを基礎にいているので、この作用を継承してオーバライド（override）することにより、開発者はフレームワークを拡張し、カストマイズした解決手法を特定の専門分野で作ることができる。これが従来のプログラミングに比べて大きな利点であるのは、プログラマはオリジナル・コードを変更することなく、むしろソフトウェアを拡張できるからである。さらに、フレームワークは、アーキテクチャに関するガイダンスとモデリングを提供すると同時に、問題領域に特有の個々のアクションを指定することから開発者を解放するので、開発者はいくつかのコード層を通って盲目的に作業する必要がない。ビジネス側から見たときは、フレームワークは、特定の知識分野において専門知識をカプセル化または具現化する方法と見ることができる。企業の開発集団、独立ソフトウェア・ベンダ（Independent SoftwareVendors-ISV）およびシステム統合者（systemsintegrators）は、前述した例のように、製造、会計、通貨取引きといった特定分野における専門知識をもっている。この専門知識はコードで具現化されている。フレームワークを使用すると、企業は、その専門知識を企業のコードで具現化することにより、専門知識の共通特性を取り込んで、パッケージ化することができる。まず、そのようにすると、開発者は専門知識を利用するアプリケーションを作成または拡張できるので、問題がいったん解決されれば、ビジネス・ルールや設計は統一的に実施され、使用されることになる。また、フレームワークと、フレームワークの背景にある具現化された専門知識は、製造、会計、バイオテクノロジといった垂直的マーケットにおいて専門知識を得た企業にとっては、戦略的資産をもつことを意味し、企業の専門知識をパッケージ化し、再販し、流布し、テクノロジの進歩と普及化を促進するための分配メカニズムをもつことになる。歴史的には、フレームワークがパーソナル・コンピューティング・プラットフォーム上の主流概念として出現したのは、つい最近のことである。この移行を助長したのが、C++といったオブジェクト指向言語の出現である。従来までは、C++ は大部分がUNIXシステムと研究者のワークステーション上に搭載され、コマーシャル・ベースのパーソナル・コンピュータには搭載されていなかった。いくつかの大学や研究所のプロジェクトが今日の商用フレームワークおよびクラス・ライブラリの先駆けとなり得たのは、C++などの言語やSmalltalkなどの他のオブジェクト指向言語のお陰である。その例のいくつかを挙げると、スタンフォード大学のInterViews、カーネギ・メロン大学のAndrewツールキット、チューリッヒ大学のET++フレームワークがある。フレームワークは、どのレベルのシステムに関心があり、どのような問題を解決しようとしているかに応じて、多種類のものがある。フレームワークの種類はユーザ・インタフェースの開発を支援するアプリケーション・フレームワークから、通信、印刷、ファイル・システム・サポート、グラフィックスなどの基本的システム・ソフトウェア・サービスを提供する低レベルのフレームワークまでにわたっている。商用化されているアプリケーション・フレームワークの例をいくつか挙げると、MacApp（Apple）、Bedrock（Symantec）、OWL（Borland）、NeXt Step AppKit（NeXT）、Smalltak-80 MVC（ParcP1ace）がある。フレームワークでプログラミングを行うには、他の種類のシステムに慣れている開発者は考え方を変える必要がある。確かに、このプログラミングは、従来考えられていたプログラミングとはまったく異なっている。DOSやUNIXなどの旧スタイルのオペレーティング・システムでは、開発者自身のプログラムが構造全体になっている。オペレーティング・システムはシステム・コール（system call）を通してサービスを提供している。つまり、開発者のプログラムはサービスの必要時にコールを行い、サービスが提供されたとき制御が返却される。プログラム構造は制御の流れに基礎を置き、これは開発者が書いたコードに具現化されている。フレームワークが使用されるときは、これとは反対である。開発者は制御の流れに責任をもつ必要がなくなる。開発者は、プログラミング・タスクを実行の流れからとらえて理解しようとする癖を止めなければならない。むしろ、オブジェクトの責任分担からとらえて思考する必要があるので、タスクをいつ実行させるかを判断するには、フレームワークに頼らざるを得なくなる。開発者が書いたルーチンは、開発者が書かなかった、従って開発者には見えないコードによってアクチベート（activate−活性化）される。この制御の流れのフリップフロップは、手続き向きプログラミングだけに経験のある開発者にとっては、大きな心理的障壁となっている。しかし、このことをいったん理解してしまえば、フレームワーク・プログラミングによると、他のタイプのプログラミングによる場合よりも作業量が大幅に減少することになる。アプリケーション・フレームワークが開発者にプレハブの機能を提供するのと同じように、本発明の好適実施例に含まれているようなシステム・フレームワークはシステム・レベルのサービスを提供することによって同じ考え方を用いている。つまり、システム・プログラマといった開発者は、システム・レベルのサービスをサブクラス化またはオーバライドして、カストマイズした解決手法を作成することができる。例えば、オーディオ、ビデオ、MIDI、アニメーションなどの新規なデバイスや異種デバイスをサポートする基礎を提供できるマルチメディア・フレームワークについて考えてみることにする。新しい種類のデバイスをサポートする必要がある場合、開発者はデバイス・ドライバを書く必要が起こることになる。フレームワークでこれを行う場合は、開発者に要求されることは、その新デバイスに特有の特性と作用を指定するだけである。この場合の開発者は、マルチメディア・フレームワークから呼び出されるある種のメンバ関数（memberfunctions）のインプリメンテーションを用意することになる。開発者にとって即時に利点となることは、デバイスのカテゴリ別に必要になる汎用コード（generic code）がマルチメディア・フレームワークにすでに用意されていることである。このことは、デバイス・ドライバ開発者が書き、テストし、デバッグするコードが少なくなることを意味する。システム・フレームワークを使用するもう１つの例は、入出力フレームワークがSCSIデバイス、NuBusカード、およびグラフィックス・デバイス別になっていることである。機能は継承されるので、各フレームワークには、そのデバイス・カテゴリに見られる共通機能に対するサポートが用意されている。この場合、他の開発者は、これらの統一インタフェース（consistent interfaces）を通して、あらゆる種類のデバイスにアクセスすることが可能になる。好適実施例では、フレームワークの概念を採用し、システム全体にその概念を応用している。ベンダ開発者や企業開発者、システム統合者、またはOEMにとっては、このことは、MacAppのようなフレームワークの場合に上述してきたすべての利点を、テキストやユーザ・インタフェースといったものについては、アプリケーション・レベルで、グラフィックス、マルチメディア、ファイル・システム、入出力、テストなどのサービスについては、システム・レベルで活用できることを意味する。好適実施例のアーキテクチャでアプリケーションを作ることは、基本的には、フレームワーク・プロトコルに準拠するドメイン固有（domain-specific）のジグソーパズルのピース（puzzle pieces）を作るのと似ている。このように、プログラミングという概念全体が変わっている。複数のAPI階層をコールするコードを一行ずつ書いていくのではなく、ソフトウェアは、まず、この環境内の既存のフレームワークからクラスを派生し、次に、必要に応じて新しい作用（behavior）を追加し、および／または継承した作用をオーバライド（override−無効化）することにより開発される。従って、開発者のアプリケーションは、書かれたあと、他のすべてのフレームワーク・アプリケーションと共用されるコードが集まったものとなる。これが強力な概念となっているのは、開発者が開発者相互の作業の上に構築していくことができるからである。またこの概念よると、開発者は、必要な量だけカストマイズできるという柔軟性を得ることができる。フレームワークには、そのままで使用されるものがある。ある場合には、カストマイズ量は最小で済むことがあるので、開発者がプラグインするジグソーパズルのピースは小さくなる。他の場合には、開発者は大幅に変更を加えて、まったく新しいものを作ることもできる。好適実施例では、第１図に示すように、RAM 14に常駐しているCPU 10の制御下に置かれているプログラムは、オブジェクト指向フレームワークを使用して種々タスクの管理を担当している。フレームワークでは、システムに追加され、またはシステムから除去されるアイテムはコンポーネント（component）と呼ばれている。コンポーネントには、ドキュメント、フォント、ツール、共有ライブラリなどがある。コンポーネントは、それに関連づけられたプロパティ（property）をもつことができる。どのコンポーネントも、そのコンポーネントを識別するある種のプロパティを組でもっている。コンポーネントは従属関係（dependencies）をもつことができる。これらの従属関係は、コンポーネントが同じであってもシステムによって異なる場合がある。これらの従属関係を判断し、解決するためには、ユーザの意図とターゲット・システムの構成を予測する必要がある。例えば、ユーザがそのコンポーネントをどのシステムにインストール（導入）しようとしているのか、そのシステムにどのようなコンポーネントがインストールされているかを、システムに判断させる必要がある。システムは、導入プログラムを実行しなくても、ユーザがコンポーネントを追加できる設計になっている。この設計目標をサポートするために、導入プログラムは、次のような機能を備えたロケーション・フレームワークに置き換えられている。・システム・ソフトウェアは、ロケーション・フレームワークに対して指定されたプロパティに一致するプロパティをもつコンポーネントを探し出すことができる（例えば、タイプがツールのすべてのコンポーネント）。・システム・ソフトウェアは、ロケーション・フレームワークに対して指定されたプロパティに一致するプロパティをもつコンポーネントに関心があることを登録しておき、そのコンポーネントの追加／除去に関する通知を受け取ることができる。ロケーション・フレームワークには、ユーザ・インタフェースがない。ロケーション・フレームワークのクライアント、例えば、プレース・フレームワーク（ place framework）がユーザ・インタフェースとなって、ロケーション・フレームの機能が利用できるようになっている。アーキテクチャロケーション・フレームワークは拡張性をもつ設計になっている。このフレームワークは、システム内のコンポーネントを探し出し、あるコンポーネントが追加または除去されたときどのようにシステムに知らせるかを判断するためのロジックを含んでいる。ロケーション・フレームワークでキーとなる抽象化（abstra ction）はロケータ・クラス（locator class）である。そのセマンティックス（ semantics）は抽象基底クラス（abstract base class）TComponentLocatorによって定義されている。具体的サブクラス（concrete subclass）は異種の探索メカニズム（ロケーション・フレームワークの方法−ファイル・システム・プロパティ、ハードウェア機能など）を使用することができ、また異種のオブジェクトの集まり（ロケーション・フレームワークの内容−ファイル・システム・エンティティ、ハードウェア・オブジェクトなど）を返却することができる。TPropertyQueryを使用し、TFSEntityオブジェクトの集まりを返却する具体的なサブクラスはTFileLocatorである。ロケーション・フレームワークのクライアントはロケータに対して指定されたプロパティに一致するプロパティを持つコンポーネントに関心があることを登録しておき、そのコンポーネントの追加／除去に関する通知を受け取ることができる。クライアントは通知フレームワークからの、次のような抽象を使用することができる。すなわち、TNotifierConnector 、TInterest、およびTNotificationである。TNotifierConnectorは、クライアントとロケータとを結ぶ働きをする。関心があることは、TInterestのサブクラスの中で指定する。通知はTNotificationのサブクラスの中で受け取る。どのコンポーネントも、そのコンポーネントを識別する、いくつかのプロパティを持っている。システム・ソフトウェアはコンポーネントにプロパティを付けて、特定のコンポーネントを特定のフォルダ別にグループ化することができる。あるコンポーネントのプロパティをフォルダのそれと突き合わせることにより、システム・ソフトウェアは、コンポーネントをどこに置いておくかを判断することができる。将来のリリースは、ユーザ自身が、ユーザ定義のプロパティをコンポーネントに付けることが可能になる。好適実施例によるフローチャート第２図は、好適実施例に従ってロケータ要求（locator request）のタイプを検査するときの関連ロジックを示すフローチャートである。処理は端子200から開始され、即時に制御が判定ブロック210に渡されて、無効なタイプが見つかったかどうかが判断される。無効なタイプが見つかっていれば、該当のエラー・メッセージが出され、処理は端子250で中止される。無効なタイプが見つからなければ、判定ブロック220でテストが行われ、ロケータ要求がシステム・エンティティに対するものであるかどうかが判断される。そうであれば、制御は端子222 から第３図へ移り、どのシステム・エンティティに対するものであるかが判断される。そうでなければ、別のテストが判定ブロック230で行われ、ロケータ要求がネットワーク・エンティティに対するものであるかどうかが判断される。そうであれば、制御は端子232から第４図へ移り、どのネットワーク・エンティティに対するものであるかが判断される。そうでなければ、別のテストが判定ブロック240で行われ、ロケータ要求がアプリケーション・エンティティに対するものであるかどうかが判断される。そうであれば、制御は端子232から第５図へ移り、どのアプリケーション・エンティティに対するものであるかが判断される。そうでなければ、エラー条件が通知され、制御が端子250から返却される。第３図は、ロケータ要求がどのシステム・エンティティと関連があるかを判断するときの関連ロジックを示すフローチャートである。処理は端子300から開始され、即時に判定ブロック310に移り、無効なタイプが指定されていたかどうかが判断される。そうであれば、該当のエラー・メッセージが出され、制御が端子 350から返却される。そうでなければ、テストが判定ブロック320で行われ、デバイス・ドライバ・ロケータが必要とする特定システム・ロケータであるかどうかが判断される。そうであれば、制御は端子322から第６図へ移り、デバイス・ドライバ・ロケータが処理される。そうでなければ、テストが判定ブロック330で行われ、共有ライブラリ・ロケータが必要とする特定システム・ロケータであるかどうかが判断される。そうであれば、制御は端子322から第６図へ移り、共有ライブラリ・ロケータが処理される。そうでなければ、テストが判定ブロック34 0で行われ、ファイル・ロケータが必要とする特定システム・ロケータであるかどうかが判断される。そうであれば、制御は端子 342から第６図へ移り、ファイル・ロケータが処理される。そうでなければ、該当のエラー・メッセージが出され、制御は端子350から返却される。第４図は、好適実施例に従ってどのタイプのネットワーク・ロケータ要求であるかを判断するときの関連ロジックを示すフローチャートである。処理は端子40 0から開始され、即時に判定ブロック410に移り、無効なタイプが指定されていたかどうかが判断される。そうであれば、該当のエラー・メッセージが出され、制御が端子450から返却される。そうでなければ、テストが判定ブロック420で行われ、マシン・ロケータが必要とする特定ネットワーク・ロケータであるかどうかが判断される。そうであれば、制御は端子422から第７図へ移り、マシン・ロケータが処理される。そうでなければ、テストが判定ブロック430で行われ、プリンタ・ロケータが必要とする特定ネットワーク・ロケータであるかどうかが判断される。そうであれば、制御は端子422から第７図へ移り、プリンタ・ロケータが処理される。そうでなければ、テストが判定ブロック430で行われ、人／プレース（people/place）ロケータが必要とする特定ネットワーク・ロケータであるかどうかが判断される。そうであれば、制御は端子432から第７図へ移り、人／プレース・ロケータが処理される。そうでなければ、該当のエラー・メッセージが出され、制御が端子450から返却される。第５図は好適実施例に従ってどのタイプのアプリケーション・ロケータ要求であるかを判断するときの関連ロジックを示すフローチャートである。処理は端子 500から開始され、即時に判定ブロック510に移って無効なタイプが指定されていたかどうかが判断される。そうであれば、該当のエラー・メッセージが出され、制御が端子550から返却される。そうでなければ、テストが判定ブロック520で行われ、ツール・ロケータが必要とする特定アプリケーション・ロケータであるかどうかが判断される。そうであれば、制御は端子522から第８図へ移り、ツール・ロケータが処理される。そうでなければ、テストが判定ブロック530で行われ、ステーショナリ・ロケータ（stationary locator）が必要とする特定アプリケーション・ロケータであるかどうかが判断される。そうであれば、制御は端子52 2から第８図へ移り、ステーショナリ・ロケータが処理される。そうでなければ、テストが判定ブロック530で行われ、選好ロケータ（preferences locator）が必要とする特定アプリケーション・ロケータであるかどうかが判断される。そうであれば、制御は端子532から第８図へ移り、選好ロケータが処理される。そうでなければ、該当のエラー・メッセージが出され、制御が端子550から返却される。第６図は、好適実施例に従ってシステム・ロケータ要求を処理するときの関連ロジックを示すフローチャートである。処理は端子 600から開始され、即時に機能ブロック610へ移って、ロケータ・クラス・オブジェクトの探索基準が取得される。そのあと、機能ブロック620で探索範囲が入力され、機能ブロック630でその探索範囲が使用されて、指定された探索基準に一致するシステム・エンティティのセットが判断される。次に、機能ブロック640 で探索が行われ、該当するシステム・エンティティが突き止められ、これらのエンティティは機能ブロック650から要求側クラスへ返却され、処理は端子660で中止される。第７図は、好適実施例に従ってネットワーク・ロケータ要求を処理するときの関連ロジックを示すフローチャートである。処理は端子700から開始され、即時に機能ブロック710へ移って、ロケータ・クラス・オブジェクトの探索基準が取得される。そのあと、機能ブロック720で探索範囲が入力され、機能ブロック730 でその探索範囲が使用されて、指定された探索基準に一致するネットワーク・エンティティのセットが判断される。次に、機能ブロック640で探索が行われ、該当するネットワーク・エンティティが突き止められ、これらのエンティティは機能ブロック650から要求側クラスへ返却され、処理は端子660で中止される。第８図は、好適実施例に従ってアプリケーション・ロケータ要求を処理するときの関連ロジックを示すフローチャートである。処理は端子800から開始され、即時に機能ブロック810へ移って、ロケータ・クラス・オブジェクトの探索基準が取得される。そのあと、機能ブロック820で探索範囲が入力され、機能ブロック830でその探索範囲が使用されて、指定された探索基準に一致するアプリケーション・エンティティのセットが判断される。次に、機能ブロック840で探索が行われ、該当するアプリケーション・エンティティが突き止められ、これらのエンティティは機能ブロック850から要求側クラスへ返却され、処理は端子860で中止される。メカニズム TComponentLocatorの異種具体的クラスは、異なるメカニズムを使用して探索を行うことができる。 TFileLocatorによって使用されるメカニズムは TPropertyQueryである。他のメカニズムをロケーション・フレームワークで使用することも可能である。例えば、THardwareCapabilityがメカニズムとして用意されていれば、新しいサブクラスとして、 THardwareCapabilityLocatorを開発することが可能である。クラスの説明 TComponentLocator目的： TComponentLocatorはテンプレート化された純粋抽象基底クラス（templated p ure abstract base class）であり、システム内のコンポーネントを探し出すときのプロトコルを定義している。TComponentLocatorのサブクラスは、TComponen tLocatorによって定義されたプロトコルをインプリメント（実装）していなければならない。インスタンス化（instantiation）： TComponentLocatorは純粋抽象基底クラスである。派生クラス（deriving class）：特定の範囲内にある特定のアイテムを探し出すことを要求するクラスは、TCom ponentLocatorから派生することができる。各サブクラスは異なる探索メカニズムを使用することができる。同時並行性（concurrency）： TComponentLocatorは純粋抽象基底クラスである。ロケータは通常共有されないので、サブクラスをマルチスレッド（multi-thread）から保護する必要がない。資源の使用（resource use）： TComponentLocatorは純粋抽象基底クラスである。TComponentLocatorのサブクラスは、そのインプリメンテーションで使用される資源をすべて管理しなければならない。クラス・インタフェース（class interface）：メソッドの説明：このメソッドは多態的（polymorphically）に使用される純粋仮想関数（pure virtual function）である。その目的は、ある範囲内にあって、ロケータに対して指定されたプロパティに一致するプロパティをもつすべてのコンポーネントを見つけることである。探索範囲としては、ボリューム、マシン、またはサブクラスによってサポートされるものがある。探索条件（search condition）としては、プロパティ照会（property query）、ハードウェア機能（hardware capability）、またはサブクラスから提供されるインプリメンテーションに依存するものがある。探索結果としては、サブクラスによって指定された一切の種類の集合（any kind of collection）がある。なんらかのコンポーネントが見つかると、探索から真（true）が返される。このメソッドは多態的に使用される純粋仮想関数である。その目的は、ロケータに対して指定されたプロパティに一致するプロパティをもつ、指定された名前のコンポーネントを見つけることである。このメソッドは多態的に使用される純粋仮想関数である。その目的は、ロケータに対して指定されたプロパティ値に一致するプロパティ値をもつコンポーネントの追加に関する通知を得るために、クライアントが使用してロケータに登録できる関心（interest）を作成することである。このメソッドは多態的に使用される純粋仮想関数である。その目的は、ロケータに対して指定されたプロパティに一致するプロパティをもつコンポーネントの除去に関する通知を得るために、クライアントが使用してロケータに登録できる関心（interest）を作成することである。 TFileLocator目的： TFileLocatorはTComponentLocatorの具体的サブクラスであり、TComponentLoc atorによって定義されたプロトコルをインプリメントしている。 TFileLocatorの探索範囲はファイル・システム・エンティティTFSEntityである。探索条件はプロパティ照会TPropertyQueryである。探索結果はファイル・システム・エンティティの集合または単一ファイル・システム・エンティティである。 TFileLocatorは、ファイル・システムにインプリメントされているプロパティに依存する。インスタンス化： TFileLocatorは直接にインスタンス化（インスタンス生成）できるので、TCom ponentLocatorによって定義されたプロトコルを完全にインプリメントすることができる。派生クラス： TFileLocatorは、プロパティの異なるインプリメンテーションが使用されるときは、サブクラス化しなければならない。同時並行性： TFileLocatorのインスタンスは共有されることがないので、マルチスレッドから保護する必要がない。資源の使用： TFileLocatorは、それが作成するすべてのオブジェクトのストーレッジを管理する。クラス・インタフェース：メソッドの説明：このメソッドは、ボリュームまたはディレクトリ内のファイル・システム・エンティティを探し出すためにオーバライドされる。指定されたプロパティ照会に一致するプロパティをもつ１つまたは２つ以上のファイル・システム・エンティティの集合を見つけると、探索から真（true）が返される。このメソッドは、指定されたプロパティ照会に一致するプロパティをもつ、指定された名前のファイル・システム・エンティティを探し出すためにオーバライドされる。このメソッドは、指定されたプロパティ照会に一致するプロパティをもつファイル・システム・エンティティの追加に関する通知を得るために、クライアントが使用してファイル・ロケータに登録することができる関心を作成するためにオーバライドされる。このメソッドは、指定されたプロパティ照会に一致するプロパティをもつファイル・システム・エンティティの除去に関する通知を得るために、クライアントが使用してファイル・ロケータに登録することができる関心を作成するためにオーバライドされる。例次の例は、どのようにすれば、開発者がロケーション・フレームワークを使用できるかを示している。この例は、TFileLocatorを含んでいるTFontFileLocatorを示している。別の方法は、TFontFileLocatorを TFileLocatorから継承することである。クラス TFontFileLocatorの宣言は以下に示されている。 TFontFileLocatorはフォントを収めているファイルを見つけようとしている。 TFontFileLocatorコンストラクタは、指定された範囲でロケータ・サービスを構築する。 TFontFileLocatorデストラクタはなにも行う必要がない。 TFontFileLocator：：FindAllはロケータ・サービスを使用して探索を行う。 TFontFileLocator：：FindOneはロケータ・サービスを使用して指定された名前のフォント・ファイルを見つける。 TFontFileLocator：：CreateAddedInterstは、フォント・ファイルの追加に関する通知を得るために、クライアントが使用してロケータ・サービスに登録することができる関心を作成する。 TFontFileLocator：：CreateRemoveddInterstは、フォント・ファイルの除去に関する通知を得るために、クライアントが使用してロケータ・サービスに登録することができる関心を作成する。第９図はスマート・フォルダ900を示す図であり、ロケータを使用して、ユーザが収集することに関心をもっているドキュメント910、グラフィック・オブジェクト920、フォルダ903などを編成している様子を示している。そのあと、スマート・フォルダはロケータを呼び出し、フォルダに収集しようとする、望みの属性を収めている特定のドキュメントを要求する。さらに、スマート・フォルダは、望みの属性を収めている新しいドキュメントがシステムに追加されたり、システムから除去されるとき、そのことを通知するようにロケータに指示することができる。第10図は、好適実施例によるプレースのディスプレイをシミュレーションした図である。プレース1000はロケータを使用して、そのプレースで使用するための関連トラッシュ・ボックス1010を見つけて表示する。これは、システムがシステム定義の属性をトラッシュに付けることによって行われる。そのあと、プレースはロケータを呼び出し、そのプレースで使用しようとする望みの属性を収めている特定のトラッシュを要求する。ロケータは、表示された該当のトラッシュ・ボックスを返却する。第11図は、本発明によるパーツビン（Parts Bin）のディスプレイをシミュレーションした図である。パーツ・ビン1100はロケータを使用して、「潜在的に」接続可能なデバイスをすべて見つける。これは、システムがシステム定義の属性をこれらのデバイスに付けることによって行われる。そのあと、パーツビンはロケータを呼び出し、パーツビンにカタログ登録しようとする望みの属性を収めている特定のデバイスを要求する。パーツビンのプレゼンテーションはウィンドウ 1100からなり、各デバイス・タイプを表すタブをもっている。例えば、タブには、プリンタ1110とモデム1120を表すものがある。ユーザはプリンタ・タブを使用すると、すべてのプリンタ（プリンタ・デバイス・ロケータが見つけたもの）を表示することができる。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＧＢ，ＨＵ，ＪＰ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＵ，ＬＶ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＫ，ＵＡ，ＵＺ，ＶＮ

Claims

【特許請求の範囲】１．メモリと、メモリに常駐しているオペレーティング・システムとを有するコンピュータ上のシステム・コンポーネントを処理する方法であって、（ａ）ターゲット・システム・コンポーネントを判断するステップ、（ｂ）前記ターゲット・システム・コンポーネントに一致する１つまたは２つ以上のシステム・コンポーネントを識別するようにオペレーティング・システムに照会するステップと、（ｃ）一致したシステム・コンポーネントをロケータ要求を通して返却して、前記１つまたは２つ以上のシステム・コンポーネントへのアクセスを可能にするステップとを備えたことを特徴とする方法。２．探索範囲を判断するステップを含むことを特徴とする請求の範囲第１項に記載の方法。３．コンポーネントが、システム・コンポーネントを含むことを特徴とする請求の範囲第１項に記載の方法。４．コンポーネントが、ネットワーク・コンポーネントを含むことを特徴とする請求の範囲第１項に記載の方法。５．コンポーネントが、アプリケーション・コンポーネントを含むことを特徴とする請求の範囲第１項に記載の方法。６．ロケータから返却されたコンポーネントを使用して、そのコンポーネントをシステム全体で使用するために利用できるようにするステップを含むことを特徴とする請求の範囲第１項に記載の方法。７．オペレーティング・システムをブートし直さないでコンポーネントを動的に除去するステップを含むことを特徴とする請求の範囲第１項に記載の方法。８．オペレーティング・システムをブートし直さないでコンポーネントを動的に追加するステップを含むことを特徴とする請求の範囲第１項に記載の方法。９．ロケータに対して指定されたシステムに行った更新に基づいてアプリケーションを動的に更新するステップを含むことを特徴とする請求の範囲第１項に記載の方法。 10．ユーザの選択に従って情報を編成するステップを含むことを特徴とする請求の範囲第１項に記載の方法。 11．ロケータに対して指定されたデフォルト情報でフォルダを作成するステップを含むことを特徴とする請求の範囲第１項に記載の方法。 12．コンポーネントは、プレースに関連づけられた特定のトラッシュ・ボックスを含むことを特徴とする請求の範囲第１項に記載の方法。 13．メニューバーを利用してロケータ・エンティティを選択するステップを含むことを特徴とする請求の範囲第１項に記載の方法。 14．少なくとも１つのポップアップ・メニューを利用して、ロケータに対してターゲット・コンポーネントを指定するステップを含むことを特徴とする請求の範囲第１項に記載の方法。 15．コンポーネントへの直接アクセスを可能にするコンボーネント・ポインタのリストを作成するステップを含むことを特徴とする請求の範囲第１項に記載の方法。 16．少なくとも１つのプルダウン・メニューを利用するステップを含むことを特徴とする請求の範囲第１項に記載の方法。 17．少なくとも１つのプルダウン・メニューを利用して、特定のデータ・タイプと互換性のある複数のツールを表示するステップを含むことを特徴とする請求の範囲第16項に記載の方法。 18．少なくとも１つのプルダウン・メニューを利用して、特定のデータ・タイプで利用できる複数のビューを表示するステップを含むことを特徴とする請求の範囲第16項に記載の方法。 19．少なくとも１つのプルダウン・メニューを利用して、特定のデータ・タイプで利用できる複数のフォントを表示するステップを含むことを特徴とする請求の範囲第16項に記載の方法。 20．少なくとも１つのプルダウン・メニューを利用して、特定のツールと互換性のある複数の選好を表示するステップを含むことを特徴とする請求の範囲第16項に記載の方法。 21．メモリと、メモリに常駐しているオペレーティング・システムとを装備したコンピュータ上のシステム・コンポーネントを処理する方法であって、（ａ）探索基準を判断し、（ｂ）探索基準に一致する１つまたは２つ以上のシステム・コンポーネントを識別するようにオペレーティング・システムに照会し、（ｃ）一致したシステム・コンポーネントをロケータ要求を通して返却して、１つまたは２つ以上のシステム・コンポーネントへのアクセスを可能にするステップからなることを特徴とする方法。 22．メモリと、メモリに常駐しているオペレーティング・システムとを装備したコンピュータ上のコンポーネントを処理する装置であって、（ａ）ターゲット・システム・コンポーネントを判断する手段と、（ｂ）ターゲット・システム・コンポーネントに一致する１つまたは２つ以上のシステム・コンポーネントを識別するようにオペレーティング・システムに照会する手段と、（ｃ）一致したコンポーネントをロケータ要求を通して返却して、１つまたは２つ以上のシステム・コンポーネントへのアクセスを可能にする手段とを備えていることを特徴とする装置。 23．探索範囲を判断する手段を含むことを特徴とする請求の範囲第22項に記載の装置。 24．コンポーネントは、システム・コンポーネントを含むことを特徴とする請求の範囲第22項に記載の装置。 25．コンポーネントは、ネットワーク・コンポーネントを含むことを特徴とする請求の範囲第22項に記載の装置。 26．コンポーネントは、アプリケーション・コンポーネントを含むことを特徴とする請求の範囲第22項に記載の装置。 27．ロケータから返却されたコンポーネントを使用して、そのコンポーネントをシステム全体で使用するために利用できるようにする手段を含むことを特徴とする請求の範囲第22項に記載の装置。 28．オペレーティング・システムをブートし直さないでコンポーネントを動的に追加する手段を含むことを特徴とする請求の範囲第22項に記載の装置。 29．オペレーティング・システムをブートし直さないでコンポーネントを動的に除去する手段を含むことを特徴とする請求の範囲第22 項に記載の装置。 30．ロケータに対して指定されたシステムに行った更新に基づいてアプリケーションを動的に更新する手段を含むことを特徴とする請求の範囲第22項に記載の装置。 31．ユーザの選好に従って情報を編成する手段を含むことを特徴とする請求の範囲第22項に記載の装置。 32．ロケータに対して指定されたデフォルト情報でフォルダを作成する手段を含むことを特徴とする請求の範囲第22項に記載の装置。 33．コンポーネントは、プレースとリンクされた特定のトラッシュ・ボックスを含むことを特徴とする請求の範囲第22項に記載の装置。 34．メニューバーを利用してロケータ・エンティティを選択する手段を含むことを特徴とする請求の範囲第22項に記載の装置。 35．コンポーネントへの直接アクセスを可能にするコンポーネント・ポインタのリストを作成する手段を含むことを特徴とする請求の範囲第22項に記載の装置。 36．ロケータに対して指定されたデフォルト情報でフォルダを作成する手段を含むことを特徴とする請求の範囲第22項に記載の装置。 37．少なくとも１つのプルダウン・メニューを利用する手段を含むことを特徴とする請求の範囲第22項に記載の装置。 38．少なくとも１つのプルダウン・メニューを利用して、特定のデータ・タイプと互換性のある複数のツールを表示する手段を含むことを特徴とする請求の範囲第37項に記載の装置。 39．少なくとも１つのプルダウン・メニューを利用して、特定のデータ・タイプで利用できる複数のビューを表示する手段を含むことを特徴とする請求の範囲第 37項に記載の装置。 40．少なくとも１つのプルダウン・メニューを利用して、特定のデータ・タイプで利用できる複数のフォントを表示する手段を含むことを特徴とする請求の範囲第37項に記載の装置。 41．少なくとも１つのプルダウン・メニューを利用して、特定のツールと互換性のある複数の選好を表示すて手段を含むことを特徴とする請求の範囲第37項に記載の装置。