(57)【特許請求の範囲】
【請求項１】
オペレーティング・システムの下で動作を行う複数のアプリケーションの制御及び動作特性を統合するワークステーション・データ処理システムにおいて、
ユーザによって操作され、コマンド、及び前記ワークステーションとそこで動作するアプリケーションの動作に関する選択を入力し、且つ、ユーザ識別コードを入力するユーザ入力装置と、
ユーザ・インタフェース・シェルを制御するプログラムと、前記シェルの動作特性に関するデータを記憶する構成データベースを記憶するためのメモリ手段と、
前記複数のアプリケーションに対して、一組の動作パラメータを与えるシェル制御手段とを有し、
前記一組の動作パラメータは、前記アプリケーション及び前記オペレーティング・システムから前記シェル制御手段に対して、前記複数のアプリケーションのコマンドと制御機能を従属させるための動作パラメータからなり、かつ、前記一組の動作パラメータは、リソース割り当て、コンテクスト、及び、表示特性を含み、
前記シェル制御手段が、更に、
前記複数のアプリケーション間で生じるイベントの発生を伝達するイベント・マネージャと、
前記複数のアプリケーション間で、データを分配すると共に記憶させ、データの変更をイベントとして識別する一方、前記ユーザ識別の機能として前記複数のアプリケーションへ構成情報を提供するコンテクスト・マネージャと、
前記複数のアプリケーションで要求され、前記構成データベース内に記憶されたリソースを管理するリソース・マネージャを備え、
前記イベント・マネージャ、前記コンテクスト・マネージャ、及び、前記リソース・マネージャはそれぞれユーザ識別コードによって決まる構成を有しており、更に、複数のコンテクスト判定パラメータ及び前記ユーザ識別コードに従って、前記複数のアプリケーションに関連する情報を表示するデータ・ディスプレイを有していることを特徴とするワークステーション・データ処理システム。
【請求項２】
請求項１に記載のシステムにおいて、前記イベント・マネージャが、予約によるイベントと強制イベントを含む複数のカテゴリのイベントを備えていることを特徴とするシステム。
【請求項３】
請求項１に記載のシステムにおいて、前記イベントが、予約によるイベント、暗示的イベント、強制イベント、及びそれらの組み合わせを含むグループから選択されることを特徴とするシステム。
【請求項４】
請求項１に記載のシステムが更に、リモート・コンピュータに対するリモートリンクを含むことを特徴とするシステム。
【請求項５】
請求項１に記載のシステムにおいて、前記データ・ディスプレイが、更にグラフィック・ユーザ・インタフェースを備えることを特徴とするシステム。
【請求項６】
請求項２に記載のシステムにおいて、前記イベント・マネージャが更に、暗示的イベントを備えていることを特徴とするシステム。
【請求項７】
請求項４に記載のシステムにおいて、前記リモート・コンピュータが前記リンクにデータベース情報を提供することを特徴とするシステム。
【請求項８】
請求項７に記載のシステムにおいて、前記データベース情報が、リアルタイムで使用可能なことを特徴とするシステム。
【請求項９】
請求項７に記載のシステムにおいて、前記データベース情報が、最新のものより時間的に遅れた内容で使用可能なことを特徴とするシステム。
【発明の詳細な説明】
発明の技術分野
本発明は、選択されたタスクの実行を行う個々のアプリケーション・プログラムが常駐するコンピュータ・ワークステーションにおいて使用する、新しいインタフェース管理システムに関する。本発明は、より詳しくは、特定のアプリケーション・モジュールに対する制御と、基礎となるオペレーティング・システムの一部を呼び出すことによって、複数の個別アプリケーション・プログラムへの継ぎ目のない(seamless)、即ち統合化されたアクセスを提供する。
発明の背景
１９７０年代後半に出現して以来、パーソナル・コンピュータは、そのシステム設計とオペレーティング技法の面で劇的な進化を経てきた。こうした進化は、プロセッサ能力の向上、メモリとデータ記憶装置の低価格化、及び販売数の増加等、多くの要因によって実現されてきた。システム設計の中で最も進化が顕著な部分は、基礎をなすオペレーティング・システムと、コンピュータ上でユーザ・インタフェースを実現するアプリケーション・プログラム、即ち「アプリケーション」とオペレーティング・システムとの対話である。これに関連して、アプリケーションは、ユーザの定義したタスクと動作を実行可能な個々のプログラム又はプログラムのグループを参照する。
１９８０年代の有力なオペレーティング・システムは、マイクロソフト社の製品であり、それは一般に「ＭＳ−ＤＯＳ」と呼ばれていた。事実、１９８０年代の終わりまでには、殆ど全てのパーソナル・コンピュータが、このオペレーティング・システムを備えて販売されていた。このオペレーティング・システムは、パーソナル・コンピュータのシステム装置とＩ／Ｏ操作を制御するものである。こうして、アプリケーションは、大くの部分において、ＭＳ−ＤＯＳと対話するよう設計された。ユーザ・インタフェースは、アプリケーション・コマンド、入力及び出力構造が外部へ露出されるものとして定義され、ディスプレイ上に表される情報、及び入力データのモード又はアプリケーションの各種サブシステムに関する操作モードによって、最も特徴付けられる。ユーザ・インタフェースは、コンピュータを効果的に使用し、操作を簡単にするための重要な要素であると、長い間考えられてきた。
オペレーティング・システムである、ＭＳ−ＤＯＳによって使用された初期のユーザ・インタフェースは、コマンドライン・オペレータとして知られるものを利用した。実質的に、そのオペレーティング・システムとの対話は、表示されたプロンプトに対してコマンドを入力することによって行われ、これらのコマンドは特定の構造（独特のものが多いが）を有している。コマンドが一旦入力されると、システムは、ロジックを制御するプログラムに従って、そのコマンドを処理し、生成された出力を表示・印刷する。このインタフェースは、当初は巧妙な技術の中でも特に有名なものであったが、幅広い階層に及ぶ潜在ユーザにとっては難しいということで嘲笑の的となった。実際、１９８４年にアップルコンピュータ社が発売した、マッキントッシュというクラスのコンピュータに使用する３２ビット・オペレーティング・システムは、コマンド・ライン・インタフェースが排除され、代わりに、ディスプレイ上に意味を有するアイコンなどを配するグラフィカル・ユーザ・インタフェース（ＧＵＩ）が採用された。これらのアイコンは、アプリケーションにリンクしており、従って、ＭＳ−ＤＯＳシステムに典型的に備わる独特のコマンド構造の入力を回避することができる。アップルコンピュータ社のシステムは、インタフェース設計において飛躍的進歩を達成し、今では、他の全てのオペレーティング・システムが、ある程度見習うべき標準のスタイルとなっている。
事実、新しいインタフェースは、１９８０年代後半に、Ｗｉｎｄｏｗｓという商標名のもと、ＭＳ−ＤＯＳに追加された。これは、実質的にユーザ・インタフェースからコマンド・ラインを取り除き、その代わりに、アプリケーションとコマンドに特有のアイコンを備えたグラフィカル・ユーザ・インタフェースを使用する。このシステムは、複数のアプリケーションの同時アクセス、及びデータ交換とバックグラウンド処理を含むアプリケーション間の対話を可能とする。このＷｉｎｄｏｗｓのインタフェースは、一気に業界標準となった。
しかし、以前から繰り返されているように、ＷｉｎｄｏｗｓTMと他のＧＵＩアプリケーションは、ユーザの観点からは決して最適なものではない。特に、現在のＧＵＩの全ては、ＷｉｎｄｏｗｓTMを含め、前述のコマンド・ライン同様、アプリケーション毎にしてインタフェースを取り扱う。そのため、インタフェースはアプリケーションに溝を作ってしまうのだが、アプリケーション自体はユーザの活動を調整するための有力な要素である。
これは潜在的ではあるが、現在のインタフェース設計においては重要な制限である。本質的に、全てのユーザは、タスク、機能、及び情報に基づきコンピュータ・システムと対話しようとする。これは、そのシステムで、タスクの実行や情報の提供が可能な個別アプリケーションがあるかどうかとは独立したものである。実際に、ユーザが、フォード・モーター社に関する現在の市場データと産業レポートを得ようとする場合、そのユーザは、どのネットワーク・アプリケーションとワード・プロセッサが使用されるかには、あまり関心がない。ユーザは、その情報を提供するのに必要なアプリケーション環境には関心がなく、必要な情報に迅速にアクセスし、その結果が明確な形式で提供されることに関心がある。
更に、今日のコンピュータ・システムは、例外なく１つ又はそれ以上のアプリケーションを同時に動作させるよう構成されており、これはマルチタスク・システムにおいて知られるプロセスである。マルチタスクは、データの操作と表示を同時に行うことができ、それによって、ワークステーションの機能を飛躍的に向上させることができる。数々の方法によるマルチタスクによって、前述のように、シェル・プログラムが、アプリケーション及びオペレーティング・システムへのユーザ・インタフェースを管理する必要性が生じた。しかし、現在のシェルは、そのコマンドの範囲に関して非常に制限されており、ユーザは３つ以上のアプリケーションの同時動作を監視することができないことが多く、特に、効果的な方法で複数のアプリケーションを効率よく動作させることができない。端的に言えば、現在のシェルの設計は、アプリケーションを起動するツールとして、それらの能力を制限する多くの欠点を有している。システムの要件が高度なものになるにつれて、より強力で柔軟なシェル・マネージャの必要性が生じてくる。これを満たさないシェル・マネージャは、ワークステーションの設計において、ボトルネックとなる。
発明の概要
従って、本発明の目的は、課題及びタスクに基づいて、機能及びデータに対する統合化されたアクセスを可能とする１つ以上のシェル・インタフェース・マネージャによって制御される、複数の個別アプリケーションを含むコンピュータ・ワークステーションを提供することにある。
また、本発明の別の目的は、ワークステーションに関する複数の動作を調整し、統一された方法で同時にいくつかのアプリケーションに対して直接制御を行うことができるシステムを提供することにある。
本発明の更なる目的は、ユーザによって構成されたインタフェースを生成し、他の点ではユーザに対して透過的な、基層における１つ以上のアプリケーションを指定する、ユーザ定義のタスクに基づいて、情報と動作を調整するデータ処理システムを提供することにある。
本発明の更に他の目的は、ユーザ透過的な方法で複数のアプリケーションを組織化し、ユーザが、１つ以上のアプリケーションに関連するタスク選択を行えるようにして、各動作及びアプリケーションにコンテクストを提供している間に、動作を実行するデータ処理システムを提供することにある。
本発明の更に他の目的は、コンテクスト・マネージャ、リソース・マネージャ、及びイベント・マネージャを含む複数の管理サブシステムを組み込んだシェルを提供することにある。
本発明の更に他の目的は、アプリケーション・ワークスペース、情報センタ、装置エリア、及び大規模なブック・メタファ・アプリケーション・アクセスを備えたユーザ・インタフェースを含むシステムを提供することにある。
上記の及び他の目的は、コマンドにとらわれずにオペレーティング・システムと複数の個別アプリケーションの機能を制御するシェル・プログラムを含むデータ処理システムとワークステーションにおいて実現される。シェル・アプリケーションは、オペレーティング・システムを拡張する形で形成され、アプリケーションにアクセスし、それを制御するための事前に定義されたユーザ・インタフェースを含む。このシェルは、ＯＬＥ（object linking and embedding）自動転送機構によってアプリケーションと通信する。この方法においては、アプリケーションが起動されるとき、定義によって、シェルがＯＬＥ自動転送機構とリンクして、コンテクストをアプリケーションに提供し、これによってその初期構成を定義することができる。更に、シェルは、シェルによって定義されたコンテクストによって制御される、複数の選択アプリケーションに対して統合化されたインタフェースを提供し、結果的に情報の処理及び検索は、アプリケーションにとって統一的なものになり、かつユーザにとって透過的なものになる。
本発明の様々な態様に従えば、システムは、特に財務管理アプリケーションの使用に適したワークステーション環境を定義する。とりわけ、システムは、顧客、商品、ユーザ、及び業務管理の４つの事前定義されたコンテクストの分類を有している。これらの４つのグループは更に、より多くのレベルの構成情報に分類される。そこで、アプリケーションが起動されると、そのアプリケーションに関するコンテクストが、これらの４つの領域のコンテクストに応じて調整される。例えば、現在のコンテクストが、ＩＢＭ社の株を大量に所有する特定の顧客によって定義されている場合、リアルタイムに相場の推移を提供するアプリケーションは、シェル内の顧客コンテクストにより示されるように、ＩＢＭ社の株情報を表示する様に自動的に構成される。構成データは、シェルからアクセス可能なマスタ構成データベースに記憶される。
動作及びアプリケーション・リソースの要求は、性能を劣化させ、システムの故障及びクラッシュの原因となる可能性がある。この種の問題を防止あるいは回避し、主要なアプリケーションに適切にリソースを割り当てるために、シェルは更にリソース・マネージャを含む。このサブシステムは、アプリケーション・リソース要求を監視し、他にリソースの枯渇と故障を防止するために事前定義された階層情報に従って、システム・リソースを調整する。
簡単な図面の説明
前述した本発明の特徴は、以下に挙げる添付図面を参照した、本発明の特定の実施例に関する、以下のより詳細な説明から、一層明確かつ容易に理解される。
図１は、本発明に使用されるワークステーションの概要を示す図である。
図２は、ワークステーションのシェル内で使用される操作フィールドの位置とウインドウを表示したディスプレイを示す図である。
図３は、本発明による、ディスプレイの代替例を示す図である。
図４は、ブック・メタファのリンクによって示された複数のアプリケーションの相関を示す図である。
図５は、４つのアプリケーション・ディスプレイの操作フィールド位置を示すディスプレイの代替例である。
図６は、本発明のワークステーションに使用される物理ネットワークのブロック構造図である。
図７は、本発明による、ワークステーション環境の管理のためのシステム・ソフトウエアを示すブロック関連図である。
図８は、サブシステムのリソース・マネージャを示すブロック関連図である。
図９は、サブシステムのイベント・マネージャを示す図である。
図１０は、システムＩ／Ｏにリンクされたサブシステムのイベント・マネージャを示す図である。
図１１は、システム出力にリンクされたアプリケーションを示す図である。
図１２は、構成データベースにリンクされたアプリケーションを示す図である。
図１３は、リソース・マネージャの動作フローを示すブロック図である。
図１４は、本発明に関する開始処理の論理フローチャートである。
図１５は、リソース・マネージャ（本発明のアクセス処理）の論理フローチャートである。
図１６は、リソース・マネージャ（本発明の解放処理）の論理フローチャートである。
図１７は、本発明のシステム・シャットダウン処理の論理フローチャートである。
発明の詳細な説明
まず概略を説明すると、本発明は、選択的に構成された、ユーザと複数のアプリケーションとの対話を拡張するシェル環境を有するワークステーション・システムであるということができる。このシェル環境は、オペレーティング・システムやアプリケーションを当初の状態から変更することなく、選択したオペレーティング・システムのパラメータによる制御と、選択したアプリケーションの機能による制御に従うものである。このシェルは、システム管理内のリストされたアプリケーションに関する、選択したコンテクスト生成パラメータを専門に記憶するデータベースを含んでいる。アプリケーションがユーザにアクセスされると、システムは、コンテクストを制御する構成データベースによって示されているように、アプリケーション構成を調整し、その結果、アプリケーションが、アプリケーションに必要な特定の機能及びデータに従って構成され、ユーザに提供される。これはユーザに、事前に調整され、かつ情報に特有のデータを表示し、それ以外の場合は、アプリケーション・インタフェースがシェル環境の後ろで待機する。
前述のシェル・アプリケーションは、シェル・オブジェクト、アプリケーション・オブジェクト、装置オブジェクト、ファインダ・オブジェクト、及びモニタ・オブジェクトの５つの個別システム・オブジェクトを含み、それらと関連して動作する。各オブジェクトは、オブジェクトのシステムに対する対話、及びそのシステム上で動作する１つ以上のアプリケーション・プログラムとの対話を定義する、事前に設計された方法の組を含んでいる。オブジェクトの特性は、構成データベースによって示される、システム内の「イベント」によって更に洗練される。前述のように、構成データベースは、個別のアプリケーションに対する詳細な構成データを含んでいる。このデータベース、ＤＢ（１）は、シェルに対して統一的な対話を提供する、既存及び新規のアプリケーションに関する設定を含んでいる。
イベント・マネージャは、コンテクストの変更、新規ユーザの出現等を含む、リアルタイムでのシステム環境の変化に対し、システム・アクセスの調整を行う。各アプリケーションは、事前に定義された方法で、イベント・マネージャと対話する。システム処理に使用可能なのは、（１）強制イベント、（２）予約によるイベント、及び（３）暗示的イベントの、３つのクラスのイベントである。事前に定義された基準に従って、各アプリケーションは、この３つのタイプのイベントのうち１つに従って、イベント・マネージャと対話する。
ここで、前述した簡単な説明を念頭に置いて、最初に図１を参照する。図１は、本発明で使用する典型的なワークステーションを非常に概略的に示したものである。このシステムは、ＣＰＵ１０と入力装置、即ちキーボード４０及びマウス（位置検出器）３０を備えるディスプレイ・モニタ２０を含んでいる。好ましい配置は、ペンティアムベースのプロセッサ、１６メガバイトのシステム・メモリ、及び１．２ギガバイトのハード・ディスク・ドライブを備えたパーソナル・ワークステーションである。好ましいオペレーティング・システムは、全てのＯＬＥをサポートしたＷｉｎｄｏｗｓＮＴである。このシステムは、シェル・インタフェースの骨格のプログラミングを行うモジュールを使用してプログラミングされる。本発明のシステムでは、Ｖｉｓｕａｌ  ＢａｓｉｃやＣ又はＣ＋＋などのようなプログラミング言語が使用されている。
次に図２を参照すると、システムのディスプレイ・スクリーン１００が示されている。この例では、ユーザ・インタフェースが、単一のアプリケーション・ワークスペース１１０の使用によって形成された特定の構成内に組織化され、活動化されたアプリケーションＡ１がワークステーションによって使用されていることを示している。このアプリケーションはまた、システム・メモリに完全なままロードされ、特別なアプリケーションに関連づけられた実質的に全ての機能の動作を可能としている。例えば、タブ１２０は、ユーザに提供されるものとして図内に示され、ワークスペースの上部に配置される。ユーザは、そのタブを選択し、ワークスペース１１０内の現在のＡ１にリンクされた様々なサブルーチン及び／又は他のアプリケーションに切り替えることができる。このタブは、構成データベース（１）からのコンテクストによって、アプリケーションに伝えられた構成に固有のものである。
更に、各アプリケーション・タブは、１つ以上の従属タブを有することができる。例えば、株式に関連付けられたタブは、特定の株式に関する社内の判断、その株式に関する外部の判断、その株式のチャート及び他のグラフ、その株式のニュース及び売買情報、及びその株式に関する文書を記録するユーザ用のデータベースといったサブタスクに関連付けられた従属タブを有することができる。現在のコンテクストにおいては、全てのブックが同時に稼働し、ユーザがその様々なブックを切り替える可能性があるが、各アプリケーション（Ａｉ）は、１つのブックと見なすことができ、それは一度に読み込まれる。ブック・メタファは、スクリーンの左側に配置された個々のブックで維持される。各ブック１３０は、そのワークステーションで個別アプリケーションが使用可能かどうかを示している。この例では、財務アプリケーションに特有の、いくつかの他の専用アプリケーションが、システムに常駐し、ディスプレイ・スクリーンの右側に表示される。このアプリケーションには、市場管理人、即ち現在の証券価格のリアルタイムに提供する株式表示１４０が含まれる。更に、市場管理人の証券リスト表示１５０は、選択された証券の詳細な情報を再びリアルタイムで提供する。プリンタ、ＦＡＸ、及び計算機１７０といったツール群は、開始時にスクリーンの下部に提供される。一連のプリセットボタン・アイコン１６０は、スクリーンの左下に配置される。これらは、ワークステーションのユーザによって使用されるため、予めプログラムされるものである。これらのボタン・アイコンは、例えばワード・プロセッサでレポートのフォーム（出張報告や売買請求メモ等）を呼び出す際に使用される。
前述のように、ユーザ・コンテクストは、特定のユーザＩＤ及び／又は職務に対して初期値を提供する。ユーザ・コンテクストは、初期値が与えられた後、プリセット・ボタンのコードにアクセスするよう適用され、前記職務にあるそのユーザに対するボタン（ボタン・アイコン）１６０を構成する。ユーザがシステムにログオンすると、ユーザは、ユーザ識別コード（ユーザ名の様な英数字及び／又はＩＤ番号のような数字）の入力を要求される。ユーザは、職務に設定されたデフォルトの条件がなければ、ユーザの職務（例えば口座管理者、口座管理者スーパーバイザ）の入力も要求される。システムは、そのユーザとユーザの職務に関する処理を行い、そのユーザによって使用されるアプリケーションに対して好適にリンクするユーザ・コンテクストを生成する。
図２に示す、組織化された表示は、数多く考えられる配置のうちの１つに過ぎない。それぞれの特定の構成は、構成データベース内に記憶された構成テーブルの値によって表現される。開始処理(startup)の間、最初のスクリーン表示を構成するために使用される構成データが、この構成データベースから読み込まれる。図３には、こうして構成されたスクリーンの例が示されている。図３のスクリーンは、４つのワークスペース・ウインドウを有し、スクリーンの右端に沿って６つのブックを有する。
図４に示すように、ブック１から４は、４つの個別のアプリケーション、又は共通の機能や目的を持つアプリケーションのグループを起動するトリガーになる。この方法では、ブックを選択することにより、１つ以上の関連付けられたアプリケーションが最前部に表示され、同時に今まで活動化されたアプリケーションは、背面におかれる。図４では、Ａ１がブック１に関連付けられ、Ａ２がブック２に関連付けられ、他も同様の関連づけがなされている。
構成テーブルに記憶されているデータに従って、複数の同時に起動されたアプリケーションＡ１〜Ａ４に関する、複数のワークスペース・ウインドウ１１０が表示される。例えば、図５に示すように、４つのワークスペース領域がディスプレイの１／４の領域に表示されている。図５に示すように、４角形の表示は、システムに記憶された値によって指示される。これらの値には、各ウインドウ毎の真の表示可能領域、各ウインドウ毎の他のシステム・リソース（例えば、ネットワーク帯域幅、データベースのアクセス速度、ＣＰＵの優先順位、メモリの使用率等である）が含まれる。これらの値はまた、構成データベース（１）の一部である表示制御テーブルに格納されている。シェルが初期化されるとき、初期表示のための構成値が、前記テーブルから読み込まれ、その構成値に基づく表示が行われる。このように、様々なユーザが、同じデスクトップ環境において個別のアプリケーション配置を希望する一方、同じユーザが異なるマシン（ラップトップとデスクトップ等）に対して異なる配置を望む場合がある。
この方法においては、ユーザ（１）と職務（１）が初期化の間に読み込まれ、それに従って最初のシェルの構成が決定される。これは、どのアプリケーションが最初に使用可能かを定義する。例えば、ラップトップを用いる「職務」においては、情報センタと最初に通信することはできない。それは、フィードデータを提供するネットワーク・アプリケーションに物理的にリンクする必要があるからである。自動的に初期構成を提供することは、情報センタに予約されることになるリソースの割り当てと、この「職務」に許可された残りのアプリケーションの性能を向上させることが可能な現在のリソース割り当てに関して有利である。
システム・ワークステーションは、前述のようにネットワークにリンクされていることが望ましい。本発明は、ラップトップにおける使用に適しており、ラップトップはリモートでネットワークにアクセスできることが望ましい。
典型的なネットワークの配置が図６に示されている。図６は、周知のネットワーク管理ソフトウエアによってローカル・ネットワーク２１０にリンクされる、複数の個別ワークステーションのＣＰＵ１０を示している。他に広域ネットワーク（ＷＡＮ）２４０を使用することもできる。図６を更に参照すると、ワークステーションに常駐するアプリケーションに提供されるリアルタイムのフィードデータのために使用されるリモートリンク２３０が例示されている。このフィードデータは、市場の会員及び他の財務情報アプリケーションのための、リアルタイム表示又はビジネスニュース購読サービスを提供する。
前のハードウエアの説明では、システムが複数のユーザ・アプリケーション及び環境を提供できることが述べられている。これらの環境の生成と管理を制御するシステム構成は、次のいくつかの図によって説明される。多くの可能なプログラム・コーディングの管理が、この環境を達成するために利用されうる。ここで、図７を参照すると、図１のワークステーションのブロック関連図が示されている。ブロック３００のユーザは、通常のユーザとシェル３２０との対話を表す。
シェルは、ユーザ３００と、ブロック３４０に示されるオペレーティング・システム（Ｏ／Ｓ）との間に位置づけられる。システム・リソース（メモリ、ＣＰＵ等）は全て、オペレーティング・システム３４０を介してリソース・マネージャ３３０によってアクセスされ、従って、シェルは、シェルの下で動作する各種アプリケーションの制御に従って、オペレーティング・システムと通信する（オペレーティング・システムを制御する）。とりわけ、シェルによって、複数のアプリケーションは、ユーザ・インタフェース・マネージャ（ＵＩＭ）３１０による制御に応じて、同時に動作することができる。
シェルの下で動作する各種アプリケーションのコンテクストにおけるリソース・マネージャの動作は、図８に概略示してある。特に、リソース・マネージャ３３０は、各アプリケーションと通信し、構成データベースＤＢ（１）内の特定のエントリによって割り当てられた内容に反して設定された、それぞれの内容に対する要求を送信する。このリソース・マネージャ３３０は、システム・リソースの使用レベルを表示し、特に、起動の際の、選択アプリケーションによるリソースの解放と他のアプリケーション（その従属アプリケーションを含む）によるリソースの呼び出しを表示するモニタ３３５を含む。リソースが呼び出された時、及び解放された時に、そのリソースに関連する情報は、リソース・データベース３４５に記憶される。リソース・マネージャは通常、アプリケーションの開始、監視、カウンタ参照、リスタート、及び停止をシェルに代わって行う。このアプリケーションには、他のアプリケーションを開始するためにシェル・インタフェースを用いるアプリケーションも含まれる。このことは、以下で、より詳細に説明する。
リソースの解放、又はリソースの要求を送受信する処理は、イベント・マネージャによって取り扱われる。イベント・マネージャは、アプリケーションとシェルの間のメッセージングと通信を制御し、ＯＬＥオブジェクトとして組み込まれることが好ましい。このことは、図９に示されている。図９では、イベント・マネージャがアプリケーションにリンクされ、システム内に「イベント」がないか確認するために、定期的に各アプリケーション及びオペレーティング・システムに対してポーリングする。前述のように、イベントは、以下の３つの形式のうちの１つに対応する。
１．予約によるイベント
２．暗示的イベント
３．強制イベント。
予約によるイベントは、極めて一般的なものであり、これについては、図９において、ブロック４１０のコンテクスト・マネージャの役割を説明することによって更に説明する。コンテクスト・マネージャは、事前に定義されたユニークなコンテクスト・タイプ（例えば、顧客、商品、ユーザ、及び業務管理）の選択に基づいて、現在のシステム環境についての情報を受信する。その後、コンテクスト・マネージャは、コンテクスト・マネージャに予約されている各アプリケーションに対する構成データを提供する。例えば、新しい顧客のコンテクストが生成された場合、この分野のコンテクスト・マネージャに予約されている各アプリケーションが、それに応じて更新される。これにより、新しい顧客のコンテクストに関連付けられた構成が得られる。コンテクストの各タイプにおいて、アプリケーション（又は現在のシステムにおける他の任意の部分）は、全て、あるいは一部が関連する情報を記憶することができる。例えば、「商品」コンテクストは、商品の識別に使われるティッカー符号、商品タイプコード（例えば、株式、債券等）、商品説明、内部データベースの参照等の情報を含むことができる。各コンテクストは、多くの属性（サブコンテクスト・レベル）を有する。この属性は、様々な属性のカテゴリに分類できる。例えば、顧客コンテクストは、特定の顧客の、各種口座、氏名（１つ又は複数）、住所（１つ又は複数）、電話番号（１つ又は複数）、及び所有財産（１つ又は複数）に分類できる（以下で参照する図１２）。コンテクストにおける変更は「イベント」であり、それは、イベント・マネージャ４００によって起動され、ファインダ・アプリケーション４２０を介してコンテクスト・マネージャ４３０と通信される。
この方法では、コンテクスト・マネージャは、ＤＤＥ、共用メモリ、名前付きパイプ等の以前の通信間のプロトコルに対する変更であると考えられる。コンテクスト・マネージャは、複数のアプリケーションの間の通信に関する配分及び記憶機構を提供する。これらのサービスを実行するために、コンテクスト・マネージャは、アプリケーション間のデータの送受信を行うＯＬＥ処理に関連付けられたプロトコルに依存する。ＯＬＥをサポートしていないサード・パーティのアプリケーションにまで適用範囲を広げるため、コンテクスト・マネージャは、コンテクストが変化したようなイベントが発生した際に、アプリケーションがデータを受信することを許可する機能を制限する。この処理は、システムをやや複雑にするが、深刻な制限をシステムに課すことなく、今までの重要なアプリケーション資産を保護する事ができる。
前述のように、予約によるイベントは、構成データベース内に記憶される、各アプリケーションが明示的に予約しなければならない、イベントのタイプである。暗示的イベントは、非常に似通っており、イベントが自動的に新しいアプリケーションによって予約されることが主に異なる点である。実際は、アプリケーションは、そのイベントを受信するのに、インストール／通知方法のコールを必要としない。イベントの通知は、自動的に配信されるからである。
最後のイベントのクラスは強制イベントである。強制イベントは、シェルの下の全てのオブジェクトに送信されるイベントである。強制イベントの良い例は、システムのシャットダウンである。これは、起動中のアプリケーションに明らかな影響がある。
以下の表１は、イベントの例をタイプ毎に示したものである。
0003940171.tif 000002
コンテクスト・マネージャに関する図が、更に図１０に示されている。図１０は、コンテクスト・マネージャとシェルのユーザ・インタフェース３１０との対話及びリソース・マネージャ（ＲＭ）３３０を示している。中でも、ユーザからのシェルコマンドは、イベント・マネージャ４００に受信され、影響のあるアプリケーションに送信される。同様に、イベント・マネージャは、そのリソース・マネージャからの送信（例えば、新しく解放されたリソース）を受信して、それを、構成データベース内に記憶されている、その受信データに対する予約内容に従って、影響のあるアプリケーションに提供する。イベント・マネージャは、影響のあるアプリケーション（１つ又は複数）に、イベントが発生したことをすぐに知らせることが好ましい。影響のあるアプリケーションが処理中（ビジー状態）、又は起動されていない場合は、イベントの通知は一旦キューに保存されて後で送信されることが望ましい。そうでない場合、イベント・マネージャは、アプリケーションの通知方法をコールして、そのアプリケーションに対してイベントを発生させる。イベント・キューの提供は、メッセージ転記(posting)によって、あるいは必要に応じて通知の後で各アプリケーション毎のイベント・キューに個別にポーリングすることによって、実施されることが望ましい。強制イベントが生じた場合は（アプリケーションが処理中であっても）、全てのアプリケーションがすぐに通知を行うよう強制されることが最も望ましい。同様に、暗示的イベントは特定のアプリケーションによって予約されているので、そのアプリケーションに関して予約されている暗示的イベントのどれが発生しても、そのアプリケーションにすぐに通知が行われる。イベント・マネージャは、そのシェルの範囲におけるものであり、そのシェルに専用である。更に、他のアプリケーションによって「公に」使用されていないことが好ましい。
前述のように、本システムは、オペレーティング・システム及びアプリケーション・コマンドを支配する。しかし、アプリケーションは、全く修正されず、追加のコーディングを行うことなく、シェルで使用できる。こうして、アプリケーションは、コンテクスト・マネージャによって設定されたコンテクストの追加入力があった場合を除いて、Ｉ／Ｏ（入力／出力）機能を設計通りに制御する。このことは、図１１に記載されている。図１１には、それぞれが、オペレーティング・システムのＩ／Ｏを介した電子メール３４２、ＦＡＸ、及び／又は印刷３４６に対する選択された出力を制御する、アプリケーションＡ１〜Ａ３が示されている。コンテクストによって、電子メール用に構成されると、Ａ１は、電子メールの出力を指示する。Ａ３が既存のコンテクストによって、印刷用に構成されると、出力は、オペレーティング・システムを介して印刷３４６に出力される。いずれの例においても、アプリケーション・コマンドとシェルを統合するための、アプリケーション・コーディングの追加は必要とされない。
次に、図１２を参照すると、構成データベースと、コンテクスト・マネージャによって制御される各アプリケーションとの関係が示されている。ここでは、構成データベース４４０は、ワークステーションのハードディスク・ドライブに記憶されている。このように、イベントを設定するコンテクストの入力には、構成データベース４４０の再検討と、予約されたアプリケーションの更新が必要とされる。
前述のシステム構成の説明は、図１４からのシェルの開始処理から始まる、一連の論理フロー図を参照することによって、一層理解することができる。この処理において、最初の論理パスは、図１４のブロック６００から始まり、テスト６１０に続き、シェルの他のインスタンスが既に実行中であるか否かを判定する。実行中であれば、処理はブロック６２０に進み、そこで終了する。これは、複数のシェルが同時に実行されるのを防ぐためである。同時に実行されると、システム・リソースを必要もないのに連携して使用する。テスト６１０の結果が「ＮＯ」であれば、処理はブロック６３０に進み、構成データベースの、システム開始時の特性の設定にアクセスする。まず、システムはテスト６４０で、データベースが使用可能かどうか判定し、使用可能でなければ、システムの実行は前述したのと同様に規則的に終了される。
データベースの確認がされると（テスト６４０で「ＹＥＳ」）、システムの初期化が、システムに記憶されている値に従って行われる（ブロック６５０〜６８０）。各シェル・コンポーネントがアクセスされ（ブロック６５５）、そのコンポーネントのディスパッチが生成され（ブロック６６０）、そのコンポーネントが、データベースから得られた値によって初期化され（６７０）、その後、テスト６８０で、そのコンポーネントがチェックされる。シェル内の全てのコンポーネントに対してこのルーチンが繰り返し処理される（テスト６９０）。シェル・コンポーネントは、前述したイベント・マネージャ、コンテクスト・マネージャ、リソース・マネージャ、及びシェルによって利用され、有効なタスクを実行するその他のオブジェクトを含んでいる。このそれぞれにおいて、ＯＬＥベースでプログラミングされたインタフェースによって、データ及びコマンドに特有のコンテクストを備えた構成が実現される。特に、ディスパッチは、後続の動作性能に特有のコンテクストを可能とするオブジェクトに対するポインタを提供する。
全てのコンポーネントが起動されると、シェルのフレームワークが完成し、特定のアプリケーションが最初にロードされる準備ができる。これらのアプリケーションは、(i)シェルの上部に表示されるアプリケーション、例えば市場管理人（図１の１４０）、(ii)ボタンやタブでアクセスできる、シェルで使用可能なワークスペース・アプリケーション、及び(iii)目に見えないが上記(i)と(ii)のアプリケーションのサポートをすることができるサービス・アプリケーションを含む。
図１４を再び参照すると、システムは次に、デスクトップ・アプリケーションの開始を指示する（ブロック７００〜７５０）。この繰り返し処理の中で、各アプリケーションには、適当なレベルのシステム・リソースが割り当てられる（ブロック７１０）。この処理は図１５で詳細に説明する。次に、アプリケーション環境を設定するための内部テーブルが更新され（ブロック７２０）、テーブル化された情報が適当な形式で配置される（ブロック７２５）。テーブルの値に基づき、選択されたアプリケーションが起動され（ブロック７３０）、スクリーンに表示される（ブロック７４０）。この処理が、初期の開始処理の間、構成テーブル内に定義されたデスクトップ・アプリケーション毎に繰り返される（ブロック７５０）。それが完了すると、シェルの開始ルーチンは終了する（ブロック７６０）。
前述のように、リソースの割り当ては、シェル・アプリケーション管理において重要な態様である。この処理に関する処理は、図１５に示されている。図１５の処理は、ブロック８００の、「リソース取得」ＯＬＥコマンドで開始される。最初に、システムは、テスト８１０で、検索されたリソースが使用可能かどうか判定し、使用可能であれば、テスト８２０で、そのリソースが既に開始されているかどうかを判定する。このリソースが既に開始されている場合、ブロック８３０で、そのリソースに関する参照カウンタが、新たなアプリケーションのリソース要求をサポートするように調整される。更に、システムは、そのリソースの追加使用による過負荷がないかどうか判定する。
システム・リソースは、２つのグループに分けることができる。リソースを使用するものの多くは、実際には、リアルタイムの市場データを得るためのプログラムや、顧客データベースにアクセスするプログラムのような、他のアプリケーションである。リソースの他のクラスは、他の全てのクラスであり、「名前付き」リソースに指定される。名前付きリソースは、ネットワーク接続、ＣＰＵ使用率、メモリ割り当て等の、広範なシステム属性を含むことができる。各リソースが１つ以上の従属関係を有する可能性があることは重要である。従属は、元のリソースによって動作のために要求された追加リソース（１つ又は複数）であり、これらの従属は、名前付きリソース又はアプリケーション・リソースであってもよい。例えば、リモート・データベースへのアクセスが、元のリソースに対するものである場合、そのリモート・データベースへのアクセスは、ネットワーク接続リソースの使用率には関係ない。更に、これらの従属が更にアクセスの必要がある従属を有することがある。従って、最初のリソースの割り当ては、システムに、最も低いレベルの従属リソースから最初のリソースに向けて開始し、最初のリソースをサポートするための動作の構築を開始する。次に、従属するリソース（１つ又は複数）を順次、反復的に起動し、そのリソースが使用可能かどうか確認し、構成データベースから得られたデータに従って各リソースを構成する。この処理は、図１３に記されている。
上記割り当て処理において、多くのリソースが、複数のアプリケーションによって共有されることになる。システムは、各リソースの使用率と、そのリソースから延びる従属ツリー構造を、正確に記録しなければならない。これを達成するために、各リソースは、参照カウンタに関連付けられる。このカウンタの値は、そのリソースを使用しているアプリケーションの番号を記録したものである。このカウンタによって、リソースが過大に予約されないということが保証される。このカウンタの最大値は、ある程度任意であるが、リソースにアクセスできるアプリケーションの最大番号の設定値を、プログラマが決めておくことが望ましい。更に、参照カウンタは、アプリケーションの解放の間、リソースの規則的な「解放」を可能にした。最終的に、システムは、参照カウンタが０になった時に、リソースをシャットダウンできる。これらの、従属とリソース割り当ての例として、１万人の本発明を使用しているユーザがいて、その各人が、リモート・データベースへのアクセスを要求する５つのアプリケーションに接続する場合を考える。この場合、一見すると、データベースへの５万のアクセス・ポートと、リモート・アクセスのための通信ポートが、各ワークステーションにつき５つ必要であるように思われる。しかし、本発明のシステムにおいては、いずれのワークステーションにおいても２つのアプリケーションだけがデータベースをアクセスできればよいように、各（ローカル）ワークステーション環境が設定される。これらのアプリケーションは、単一の通信ポートを使用し、その結果今度は、リモート・データベースは２万ポートからの要求を扱うだけで済み、それによって他のユーザの使用によるリソースの冗長性及び解放を回避することができる。
図１５を参照すると、リソースが以前に開始されていなかった場合、処理はブロック８２５〜９４０に分岐し、リソースとその従属の開始に関する処理が行われる。この処理においては、従属リストがメモリからアクセスされる（ブロック８２５）。従属リストは、リソースに関連付けられた従属のレベルを示すものである。リスト内の各従属に対して、システムはブロック８００の「リソース取得」に戻り、それがあたかも元のリソースであるかのようにその従属を処理する。リソースがアクセスされた後で（ブロック８５０）、それがチェックされる（テスト８６０）。テスト８６０の結果がＮＯである場合、処理は、テスト８７０に進み、リソースが必須かどうか判定する。必須である場合、処理は、ループを戻り、リストの次の従属に移動する（ブロック９５０）。ここで、従属が必須でない場合、即ちテスト８７０でＮＯである場合、処理は従属エラー処理（ブロック９３０）のループ８９０〜９２０に分岐する。ブロック９００は、「リソース解放」処理（エラーが起こった段階で起動される各リソースに対して（図１７））のトリガーとなる。ブロック９１０は、モニタ・リストから割り当てを削除する。
ブロック９５０においては、リソースが開始され（最初のリソース、又は従属（１つ又は複数）であり、処理における反復レベルに依存する）、テスト９６０で確認される。テスト９６０の結果がＮＯである場合は、リソースのエラーが生じた場合である。このエラーに従い、システムは、「リソース解放」処理に分岐し、この反復の間に起動された既存の及び従属のリソースを元に戻す（ブロック１０２０）。以前予約したリソースが一旦解放されると、リソース解放処理に従って、検索されたリソースの欠陥を示すエラーメッセージが生成される（ブロック１０３０）。
テスト９６０の結果がＹＥＳである場合、処理はブロック９７０で続けられ、この反復に関連したリソースは、メモリ・アドレス内に記憶される（ブロック９８０）。この新しいリソースの予約に応じて、参照カウンタはインクリメントされ（ブロック９９０）、予約内容がモニタ・リストに追加される（ブロック１０１０）。
次に、図１６に示されたシャットダウン処理を参照すると、これは、ブロック１１００から開始される。この処理は、すべてのアプリケーションにわたって繰り返される（ブロック１１１０）。ブロック１１２０ではリソースが解放され、ブロック１１３０では内部テーブルがクリアされる。これらの処理は、アプリケーション毎に繰り返される（テスト１１４０）。アプリケーション全てが閉じられると、シェルのコンポーネントは終了する（ブロック１１０５）。
シェルの動作中及びシャットダウンの間に、アプリケーションが閉じられ、従属が解除され、他のシステムのイベントがシステム・リソースを解放する。これらの処理を規則的な方法で実行するために、システムは、図１７に示すような構成の処理を提供する。リソース解放ルーチンが１２００で開始され、ブロック１２１０で、考慮中の特定のリソースについて参照カウンタが削減される。参照カウンタがデクリメントの後、０になったら、テスト１２２０で、リソースがシェルによって完全に解放されたことが示され、１２２５に分岐する。１２２５では、リソースのクローズ処理(shutting)とそのリソースに関連して実行されている処理が停止される。
しかし、リソースが他の使用（例えば、ローカル・ワークステーションにおける他のアプリケーション）に関して依然活動中である場合、テスト１２２０でＹＥＳと判定され、処理は、ブロック１２３０に進み、メモリからそのリソースに関する従属リストにアクセスする。このリストは、その使用に関して解放されるべきリソースに関する従属の全てを識別するが、システムの他の部分に関しても必要とされる。前に「リソース取得」ルーチンで行われたように、全ての従属が評価されたが、今度は逆の順序で処理がされる。従って、ブロック１２４０〜１２９０の処理において、システムは各従属を順に検査し、その参照カウンタを減算する（ブロック１２５０）。カウンタが０になった場合、従属はモニタ・リストから除かれ（ブロック１２７０）、シャットダウンされる（ブロック１２８０）。この処理は、ブロック１２９０で各従属毎に繰り返され、全ての従属が完全に処理されると、最初（最上位レベル）のリソースが解放される（ブロック１３００）。その後、処理は終了する（ブロック１３２０）。
本発明を、例示を目的に詳細に説明してきたが、これらの細部は、説明のためのものに過ぎず、当業者には、本発明の意図及び範囲から逸脱することなく様々な変更が可能であることが容易に理解される。本発明の意図及び範囲は、請求の範囲によって明らかとなる。
【図１】
0003940171.tif 000003
【図２】
0003940171.tif 000004
【図３】
0003940171.tif 000005
【図４】
0003940171.tif 000006
【図５】
0003940171.tif 000007
【図６】
0003940171.tif 000008
【図７】
0003940171.tif 000009
【図８】
0003940171.tif 000010
【図９】
0003940171.tif 000011
【図１０】
0003940171.tif 000012
【図１１】
0003940171.tif 000013
【図１２】
0003940171.tif 000014
【図１３】
0003940171.tif 000015
【図１４】
0003940171.tif 000016
【図１５】
0003940171.tif 000017
【図１６】
0003940171.tif 000018
【図１７】
0003940171.tif 000019