【誤訳訂正書】
【提出日】平成21年8月21日(2009.8.21)
【誤訳訂正１】
【訂正対象書類名】明細書
【訂正対象項目名】全文
【訂正方法】変更
【訂正の内容】
【書類名】      明細書
【発明の名称】  オブジェクトを編集するための方法、及びそのプログラムを記録したコンピュータ読み取り可能な記録媒体
【特許請求の範囲】
【請求項１】
プロセッサを含むコンピュータが実行するオブジェクトを編集するための方法であって、前記オブジェクトはアプリケーションに関連付けられたオブジェクトのダイナミック・プロパティを割り当てるためのプロパティ入力シートを有し、
前記方法は、
前記プロセッサが、前記プロパティ入力シートをユーザのためにディスプレイ上に表示する段階であって、前記プロパティ入力シートは、前記プロパティの識別子を収めるための属性名セクションと、前記属性名セクションにより識別される関数式を収めるためのプロパティ入力セクションとを有し、前記関数式はデータ値としてランタイムで参照可能である、前記表示する段階と、
前記プロセッサが、前記ディスプレイ上に表示された前記プロパティ入力シートを使用して入力され且つデータ値としてランタイムで参照可能な前記関数式を入力機器から受けとる段階と、
前記プロセッサが、前記受けとった関数式を構文解析する段階と、
前記プロセッサが、メモリーに記憶されているデータソースを用いて、前記構文解析により特定される式エレメントについての関数を生成する段階と、
前記プロセッサが、前記生成された関数を前記オブジェクトの前記プロパティのためのランタイム値として前記メモリーに記憶する段階と
を前記コンピュータに実行させる、前記方法。
【請求項２】
前記オブジェクトがバイトコード又はハイレベル・コードとして表わされるバーチャル・ワールドの実行画像であるバイトコード実行画像を有し、且つ
前記方法は、
前記構文解析したあとに、前記プロセッサが、前記バイトコード実行画像を無効化する段階と、
前記無効化したあとに、前記プロセッサが、前記メモリーに記憶されているアプリケーション・リソースから新しいバイトコード実行画像を生成する段階と
を前記コンピュータに更に実行させる、請求項１に記載の方法。
【請求項３】
前記プロセッサが、前記オブジェクトのランタイムでの表示が自動的に更新されるか否かを決める段階と、
自動的に更新される場合は、前記プロセッサが、バイトコードを前記メモリーに記憶されているアプリケーション・リソースから生成して実行する段階であって、該実行により前記表示を更新する、前記生成して実行する段階と
を前記コンピュータに更に実行させる、請求項１に記載の方法。
【請求項４】
前記プロセッサが、前記関数が定数である場合、前記関数のクローンを作成し、当該クローンをクエリの実行なしでオブジェクトを表示するためのデザインタイム値を当該クローンに替えて前記メモリー内に記憶する段階を前記コンピュータに更に実行させる、請求項１に記載の方法。
【請求項５】
前記プロセッサが、前記関数式が無効である場合にはエラーメッセージを前記ディスプレイ上に表示する段階を前記コンピュータに更に実行させる、請求項１に記載の方法。
【請求項６】
前記プロセッサが、前記関数式を構文解析する段階において、関数、演算子、データベース列名、変数、及び定数の内の１つ又はそれ以上を特定する段階を前記コンピュータに実行させることを含む、請求項１に記載の方法。
【請求項７】
コンピュータに、請求項１〜６のいずれか１項に記載の方法の各ステップを実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データベース管理システム（ＤＢＭＳ）上にアプリケーションを構築するためのビジネス・インテリジェンス・ツールに関する。
【０００２】
【発明の背景】
プロセッサ、メモリー及びデータ記憶装置の進化によって、高性能で、しかも経済的なコンピュータが出現したことにより、コンピュータは現代の企業にとって不可欠なものとなった。これらのコンピュータにとって重要なアプリケーションには、情報がデータモデルに従って収集及び構成され、クエリを使用して検索されるＤＢＭＳが含まれる。ＤＢＭＳを使えば、ユーザは、レコードを構成する情報がコンピュータ内で実際にどのように記憶されているのか詳細に知らなくても、コンピュータ内に記憶されているレコードの場所をつきとめ、追加し、削除し、そして更新するような操作を実行できるようになる。
【０００３】
高性能型ＤＢＭＳの一つは、記憶されている情報がユーザには、各々がリレーションと呼ばれているテーブルのセットのように見える、リレーショナルＤＢＭＳとして知られている。各リレーションでは、当該情報は行列状に配置されているように見え、データの列が一つ又はそれ以上の所定の関数よって互いに関連付けられる。
【０００４】
リレーショナルＤＢＭＳ内の特定の情報にアクセスするために、クエリ・コンパイラは、クエリ言語、例えば構造化クエリ言語（ＳＱＬ）において典型的に表現されるユーザの要求を、ユーザの要求に応じたソリューションを作り出すために１つ又はそれ以上の入力されたリレーション上で実行される一式のオペレーションに変換する。ＤＢＭＳによって提供されるクエリ言語を使えば、ユーザは、ＤＢＭＳからのデータ検索、データ処理及びデータのレポートへの編成を容易にするアプリケーション・プログラムを開発することもできる。
【０００５】
ビジネス・インテリジェンス・ツールを開発する際の問題の一つは、ツールが作成しようとするレポートのタイプである。典型的に、当該ツールは、クエリ言語を使って予めフォーマットされているレポートを生成する。クエリ言語はベーシック又はＣ言語のような従来型プログラミング言語よりは使い易いが、新しい各レポートの生成には、更に或る程度のプログラミング技術が必要であり、かなりの時間がかかる。
【０００６】
【発明の概要】
本発明は、ダイナミック・プロパティをサポートするプロパティ入力シートを使って編集されるダイナミック・プロパティを有するオブジェクトをサポートする。ある態様では、アプリケーションに関連付けられたオブジェクトのプロパティを文脈的に割り当てるための、コンピュータが実行するプロパティ入力シートには、プロパティの識別子（アイデンティフィケーション）を収めるようになっている属性名セクションと、属性名セクションによって識別されたプロパティに関する関数式を収めるようになっているプロパティ入力セクションとが含まれており、当該関数式はデータ値としてランタイムで参照可能である。
【０００７】
プロパティ入力シートの実装には以下のことのうち、１つ又はそれ以上を含みうる。関数式は、関数、演算子、データベース列名、変数及び／又は定数でありうる。プロパティ入力シートはまた、プロパティの識別子を収めるようになっている属性名セクションと、属性名セクションにより識別されたプロパティに関する静的データ値を収めるようになっているプロパティ入力セクションとが含まれている。更に、オブジェクトは複数のプロパティを有しており、各プロパティの属性名セクション及びプロパティ入力セクションは各プロパティに対する名前値の対を形成する。関数式は構文解析され、ランタイム値として記憶される関数を生成し、関数に関連付けられたバイトコードが生成される。関数が定数であれば、関数のクローンが作られ、デザインタイム値として記憶される。更に、もし式が無効であれば、エラーメッセージが表示され、現行のバイトコード実行画像が無効化され、新しいバイトコードが生成されて現行のバイトコード実行画像に置き換えられる。
【０００８】
もう１つの態様では、アプリケーションに関連付けられたオブジェクトのプロパティを割り当てるための方法は、データ値としてランタイムで参照可能な式をプロパティ入力シートのプロパティ入力セクションに収める段階と、式を構文解析する段階と、式から関数を生成する段階と、関数をランタイム値として記憶する段階とを含む。
【０００９】
本発明の実装は以下を含む。本方法は、オブジェクトのバイトコード実行画像を無効化しうる。本方法はまた、オブジェクトのランタイムでの表示が自動的に更新されるか否かを決め、もし更新されるのであれば、本方法はバイトコードを生成して実行しうる。本方法はまたどのオブジェクト・プロパティを変更された属性にマッピングするかを決め、変更された属性値を表す定数関数を生成し、定数関数をランタイム・プロパティ値及びデザインタイム・プロパティ値として記憶することにより、オブジェクトの属性を変更する。オブジェクトがバイトコード実行画像を有している場合、本方法はバイトコード実行画像を無効化し、オブジェクトのランタイム表示が自動的に更新されるか否かを決め、そしてまた、もし自動的に更新されるのであれば、バイトコードが生成され実行される。本方法はまた、関数が定数であれば、関数のクローンを作りデザインタイム値として記憶する。
【００１０】
もう１つの態様では、コンピュータが実行するオブジェクトは、オブジェクト・ステートと、各々が関数式として定義されデータ値としてランタイムで参照可能な複数の属性を通してオブジェクト・ステートへのアクセスを提供する１つ又はそれ以上のインタフェースを備えている。
【００１１】
オブジェクトの実装には以下のことが含まれる。オブジェクトの関数式は、関数、演算子、データベース列名、変数及び／又は定数を含む。また、属性は静的データ値である。各プロパティは名前値の対を有している。オブジェクトの関数式は構文解析され、ランタイム値として記憶される関数が生成される。関数が定数である場合、関数のクローンが作成され、当該クローンをデザインタイム値として記憶する。式が無効である場合は、エラーメッセージが表示され、現行のバイトコード実行画像が無効化され、新しいバイトコードが生成され、現行のバイトコード実行画像に置き換えられる。
【００１２】
本発明の利点には、次の一つ又はそれ以上が含まれる。本発明は、従来のフォームベース又はレポートベースのアプリケーションにとって本質的な制約を越えて拡張するアプリケーションを構築するためのビジュアルなビジネス・インテリジェンス・ツールである。専門化したプログラマーはアプリケーション開発過程から除外され、ユーザをデータに近づけて、アプリケーション開発時間が低減できるようにする。ユーザ・インタフェースは、情報豊かなデータベースと、データウェア・ハウス及び決定支援のようなアプリケーション用に、すぐにしかも簡単に作成できる。
【００１３】
本発明のハイパーリンクは、コンテクストと「先見力（look-ahead）」情報をアプリケーションに提供する。この機能は、データ駆動アプリケーションを構築する際に幾つかの効果的な優位性をサポートする。まず、ユーザは、現在いる場所のコンテクストを失うことなく、ポータルを通してデータの他のビューを調べることができる。アプリケーションをブラウジングするユーザがたどるパスがアプリケーション自体にも影響を与え、アプリケーションのダイナミックなカスタマイゼイションが行われることもある。更に、コンテクスト・ポータルは、単一のアプリケーション内の様々なデータソースの統合を簡単にする。ポータルによって設定されているパラメータによってパラメータ化されたクエリの場合、異なるデータベースからのデータを有意義な手段で組み合わせられるようにして、事実上、汎用のクライアントサイドのクエリ結合を提供する。その結果、コンテクスト・ポータルは、ユーザがデータをハイレベルで理解できるようにし、より良い業務決定ができるようにする。
【００１４】
ダイナミック・オブジェクト・プロパティはデータ駆動アプリケーションの開発を容易にし、スプレッドシートの使用以外にはプログラミング経験の無い専門領域のエキスパートが、ツール作成の強力なアプリケーションを容易に使えるようにする。ダイナミック・オブジェクト・プロパティは、コンパイルされるときにアプリケーションにハードコード化されるスタティックオブジェクトプロパティを凌ぐ幾つかの利点を有している。第一の利点は、プロパティが継ぎ目無く、自動的にデータに結合されるということである。更に、前記結合は、単に一つのオブジェクトではなく、むしろオブジェクトの全クラス（データエレメントノードで表される全オブジェクト）に適用される（即ち、各オブジェクトに対する計算値はオブジェクトにより示される行によって決まる）。もう一つの利点は、さもなければ、オブジェクトの色をデータソースからの一つの列か又は列のセットの値によって決めるような簡単なタスクを実行するために必要となる、特殊なコーディングを省略できることである。更に、２つ以上のオブジェクト・プロパティを、一行の一つの列に（又は全行で実行される計算にさえ）結合することができる。各オブジェクトが一つのリンクに制限されている従来の開発ツールとは対照的に、本発明では、１つのオブジェクトに関連付けられている各列又は行を、別々のプロパティへリンクできるようにする。
【００１５】
シーングラフからコードを生成すればマニュアル・プログラミングが不要になるので、開発者は、ツールそのものではなく問題領域に集中できるようになる。その結果、プログラミング経験のない専門領域のエキスパートでも、すぐに強力なアプリケーションを作成できる。更に、シーングラフ表示は、アプリケーションの内容をブラウジングし、ワードプロセッサ内で書類に関するアウトラインをできるだけ簡単に再順序付けできるようにアプリケーションを構成変更するのに効果的な方法を提供する。
【００１６】
更に、本発明は、個々のデータポイントの表示を、できるだけ一般的にトップ・レベル・シーンそれ自体として編集できるようにする。この機能により、ドリルダウン及び検索ナビゲーションをサポートする高性能のアプリケーション作成が可能となる。このナビゲーションにより、ユーザはデータをより深く理解できるようになり、より良い業務決定を下せるようになる。
【００１７】
他の特性及び利点は、以下の説明および請求項から明らかとなるであろう。実施例
アプリケーションを構築するためのビジュアルビジネスインテリジェンスシステムについて以下説明する。このシステムでは、開発者が対話型でバーチャル・ワールドを構築するが、その構築ブロックはシーンと、データソースと、グローバルパラメータと、リソースとを含んでいる。シーンは、情報がデータベースに記憶されているデータにリンクされている場合を除いて、プレゼンテーションのスライドに良く似た情報の視覚的な表示である。シーンの中では、データソースから作り出された値が、ユーザ指定のデータエレメントとして図表で表される。データソースは、一つ又はそれ以上のデータベースクエリを作成するブロック図表作成ツールを使って組み立てられる。クエリは、ＳＱＬクエリであってもよい。シーンは、データソースをシーンのグラフィカル・エレメントに透過的に結合するドローイング・エディタを使って作成される。バーチャル・ワールドが完成すると、バーチャル・ワールドの実行画像は、バイトコード又は逐次インタプリットされることになるハイレベル・コードとして表わされる。バーチャル・ワールドを表示するバイトコードは、ランタイム・コントロール、例えばアクティブＸコントロールよって実行されうる。ランタイム・コントロールは、ウェブページ内、又はアクティブＸコントロールをサポートする何れかのアプリケーション、例えばVisual Basic、Ｃ又はＣ＋＋内に埋め込まれうる。
【００１８】
シーンは、一つ又はそれ以上のオブジェクトを有しうる。シーン内のオブジェクトは一組のプロパティによって表示され、クリック、ユーザのシーンへの接近、及びマウス位置のようなイベントによってトリガされるアクションを割り当てられている。ビュー・ポイントは、シーンを見るための三次元配置である。当該配置は、シーン中心からのユーザのその時点のカーソルのＸ及びＹ方向オフセットと、ユーザのその時点のズームレベル（しばしば倍率レベルと呼ばれる）とを使って表わされる。ビュー・ポイントは、ワールド内でのナビゲーションを容易にするために、固有名が付けられており且つセーブされうる。名前の付けられたビュー・ポイントはユーザによってマニュアル・ナビゲーションのために使用されることができ、又はイベント・ベースのジャンプ・アクションのための目標として使用されうる。
【００１９】
データ・エレメントは、クエリから生じる行のグラフィカル的な表示である。それはレイアウト及びデータソースに常に関連付けられており、シーンと同様に構成されている。それはレイアウト及び他のシーンへのワームホールを始めとする、オブジェクトのどんな組み合わせを含んでいてもよい。データエレメントを構成するオブジェクトに関するプロパティは、基準シーン・パラメータであるだけではなく、関連したデータソースにある基準列名でもある。シーンエレメント及びデータエレメントはユーザのズーム・レベルに応じて別々に表示してもよい。それぞれの表示は詳細さのレベル（ＬＯＤ）と呼ばれ、他のＬＯＤとは、視覚的に、互いに排他的である。例えば、一つのドット表示で始まるオブジェクトが、ユーザがより近くにズームするとアイコンに変化し、更に近くにズームするとチャートに変化するようにしてもよい。
【００２０】
詳細さのレベル（ＬＯＤ）同士の間の移行点は、ズーム比に関して、ユーザによって定義される。シーンエレメント又はデータエレメントはＮ個の詳細さのレベル（ＬＯＤ）に対してＮ−１個の移行点を持つ。視認性はまた、オブジェクト毎ベースに、「視認性（visibility）」プロパティを下記のような条件式に設定することによって制御されうる。
【００２１】
If（UserZoom ＞ ２、真、偽）
従って、遷移領域は、互いの表示が互いに排他するというよりはむしろズームレベルの或る範囲で重なり合うように作られうる。重なり合いは、多種多様なデータエレメントを含む層状マップ作成時には特に重要である。更に、他の効果を達成するために、より複雑な表示を視認性の制御に用いることができる。データソースは、ランタイムで設定される１つ又はそれ以上の識別子によってパラメータ化できるＳＱＬクエリに指定される。データソースが定義される際には、上記指定され、ワールドに追加され、ワールド・マネージャーのデータ・ソース・カテゴリに表示される。するとこれらを実行に利用できるようになる。その結果はデータシートでブラウジングすることができ、またレイアウトの中で用いることができる。レイアウトの中で用いる場合、クエリの結果できる各行はデータエレメントで表示される図表に転換される。その結果生じるデータソース内の列は、データエレメントに含まれるオブジェクトの属性にリンクされる。データソースクエリ内に存在するパラメータはグローバルプログラム変数、ローカルシーンパラメータ、又はワールドツリー階層で上位階層にあるデータソース内の列に関連付けられる。
【００２２】
図１は、一つ又はそれ以上のワールドを同時に編集するための多様なドキュメントのインタフェースを示している。ユーザ・インタフェースの主要な部分は、ワールド・マネージャー・ウィンドウ１０と、プロジェクトワーク・スペース及びエディタ・ウィンドウ２０及び２２と、オブジェクト・インスペクタ３０と、コントロールバー４０と、アウトプットウィンドウ２４である。
【００２３】
ワールドワークスペースは、エディタ・ウィンドウを含むバックグラウンドエリアである。４タイプのエディタ・ウィンドウが提供されている。シーン・エディタと呼ばれる図表描画エディタが、トップ・レベル・シーンを構成するために提供されている。データ・エレメント・エディタと呼ばれる図表描画エディタが、各データポイントの表示をレイアウト内に定めるために提供されている。クエリ・エディタと呼ばれるツールが、クエリの図形ブロック・ダイアグラムを構築するか、又はＳＱＬを直接手動で入力するかのどちらかによって、ＳＱＬクエリを定義するために提供されている。クエリ・エディタはまた、クエリの結果を見るためのデータシートも提供する。更に、全バーチャル・ワールドの二つの視界を示すワールドエディタが提供されており、その２つの内第１はパラメータのリンクと共にワールドのナビゲーション階層を示すワールドの構造ビューであり、第２は全ワールドに文書化及び検索の機能を提供する読み出し専用の疑似コード・ビューである。
【００２４】
ワールド・マネージャー・ウィンドウ１０は、ユーザのオープンワールドを編集し管理するための基本的なインタフェースである。これは、タブ１２，１４，１６を備えたドック可能なコントロールバーと対応する情報のパネルとを有している。ユーザがタブをクリックすると、タブは最上部へ移動し下にあったパネルが表示される。各パネルは、情報のカテゴリを表示するため順に一式のボタンを提示する。ボタンをクリックすると、そのボタンに関連する情報のカテゴリが表示される。図表タブ１６は、シーン又はデータエレメントに追加できる全図表オブジェクトの分類別パレットを提示する。
【００２５】
ワールド・マネージャー１０は、ワークスペース２０の左右どちらかにドックしておくことができる。ドックされている状態では、パネルの寸法を横方向に拡大又は縮小することができる。浮動状態では、縦横の両方向に拡大又は縮小させることができる。
【００２６】
図１の例では、ワールドタブ１２と呼ばれる一つのタブが、その時点で開いているワールドの構成と階層に関して３つの異なるビューを表示する。各オープンワールドは、ツリー・コントロール１８内の主要ワークスペースの項目の下に表示される。コンテクストメニューは、ツリー・コントロール内に表示される各項目に関して利用でき、右のマウスボタンをクリックされたときに、選択された項目に関する共通メニュー・コマンドのリストを提供する。
【００２７】
この例では、シーンカテゴリは、グローバルパラメータと各オープンワールド内に含まれているシーンを表示する。グローバルパラメータは、オブジェクト・プロパティとイベント・アクションとの両方に含まれ、あらゆるシーンの階層内のどこからでも参照される識別子である。各シーンの下には、シーンに関する詳細さのレベル（ＬＯＤ）に従い各詳細さのレベル（ＬＯＤ）を含むオブジェクトの階層リストと共に、そのローカルパラメータ（あれば）とビュー・ポイントのリストがある。見られたとき、各詳細のレベル（ＬＯＤ）は互いに排他的である。言い換えると、一時に一つの詳細さのレベル（ＬＯＤ）が見られるだけである。詳細さのレベル（ＬＯＤ）の下にあるツリー内のオブジェクトの順番は、それらの描画順を決定する。別のオブジェクトの下に表示されるオブジェクトは、チャイルド・オブジェクト（子オブジェクト）と呼ばれ、その所有者はペアレント・オブジェクト（親オブジェクト）又は複合オブジェクトと呼ばれる。ツリー内のある項目は、別のシーンを参照するワームホール（後述する）のようなツリー内の他の項目を参照として載せてもよいし、或いはデータ・ソース・カテゴリに関するツリー内のデータソースを参照するデータエレメントを参照として載せてもよい。
【００２８】
データ・ソース・カテゴリは、各オープンワールドに含まれるクエリのリストを表示する。各データソースは、クエリ・パラメータのリスト、列名又は別名のリスト、及びクエリを構成するのにクエリ・ダイアグラム・エディタが使われた場合はダイアグラムのリストを順に含んでいる。提示されるときには、クエリ・ダイアグラムには、構成に使われているブロックとコネクションのリストが含まれている。リソースカテゴリは、シーンやその図表コンテンツ（ノード）に関するプロパティ値の計算に使われる実行リソースのリストを表示する。基本的リソースタイプには、カラー・マップ、カラー・シーケンス、ストック画像、及びユーザクラスが含まれる。
【００２９】
データ・タブ１４は二つの情報のカテゴリを含んでおり、その１つはクエリ・ダイアグラムを構成するのに用いられるエレメントのパレットを提供するクエリ・デザインであり、もう１つはアクティブなデータベーススキーマのコンテンツをブラウジングできるようにするデータベースコンテンツである。クエリ・デザインカテゴリのコンテンツはパレット・フォームで提示される。データベースコンテンツのカテゴリはツリー・フォームで提示され、そこでは各表の下の列名と視界は、列名と種類がダブルコロンで分けられて（例えば、employee_name::varchar）表示される。データベース・コンテンツ・ツリーは、アクティブなスキーマをブラウジングするのに用いることができる。
【００３０】
各オープンワールドは、ゼロ又はそれ以上のオープンエディタウィンドウを含んでいる。４つのタイプのエディタはそれぞれ、エディタのタイプ及びエディタのコンテンツを記述するテキストに従う独自のアイコンを表示する。テキストのフォーマットは、下記のような省略フォーマット又は拡張フォーマット、即ち、EditorType : Contents又は、EditorType :WorldName[.ExtendedContents]であり、ここで、EditorTypeとはエディタのタイプ（「シーン」、「データエレメント」、「クエリ」又は「ワールド」）であり、WorldNameとはコンテンツを含むワールドの名前であり、Contentsとは編集されているオブジェクトの短い名前（例えば「DataElement１」）であり、ExtendedContentsとは編集されているオブジェクトの長い名前であり、これはピリオドで分けられた全ペアレント・オブジェクトのトークン化された名前を含んでいる（例えば「Scene１．ScatterChart 1. DataElement 1」）。
【００３１】
２つ以上のエディタ・ウィンドウがワールドの所与の部分に対し開かれる。例えば、同一のシーンは、シーン全体を見るために、１００パーセントの倍率で、一つのエディタの中で編集され、一方別のエディタがそのシーンのより細かい部分にズームインする。どちらかのエディタでシーンが変更されると、両方のウィンドウに反映される。
【００３２】
シーン・エディタ・ウィンドウは、トップ・レベル・シーンのコンテンツを図表的に編集し、デバッグするために用いられる。エディタは、デザインモードとランタイムモードとの二つのモードを有している。デザインモード・ビューでは、オブジェクトはグラフィック・パレットから追加され、クエリの実行なしで表示される。一つ又はそれ以上のプロパティ値を通してデータソースに結合されるオブジェクトは、プレースホルダー・オブジェクトで表示される。更に、オブジェクト・イベントは何も生成されないので、オブジェクトに関連する何らのアクションも実行されない。シーンは何れのズームレベルででも編集することができ、それはナビゲーション・ツール・バーから設定することができる。
【００３３】
デザインモード・ビューは、セレクター・バーとパラメータ・バーの二つのオプションのドッキング・ツール・バーを提供する。シーンは別々に異なるズームレベルで表示されるが、そこでは、各表示又はドローイングによってＬＯＤが定められる。セレクターバーは、現在ＬＯＤが編集されているコントロールを提供する。パラメータ・バーはシーン内の各パラメータ用のボタンを表示する。シーンがパラメータを有していなければ、ビュー・メニューから手動でオンに切り替えられない限りバーは表示されない。パレットに表示されるパラメータは、オブジェクトのプロパティの値を設定するためのオブジェクト・インスペクタで用いられる。パラメータ・バーは、パラメータが作成、削除、又は編集されると、自動的に更新される。
【００３４】
ランタイムモードが選択されると、シーンのコンテンツは、以下に述べるように、バイトコードへコンパイルされて表示される。何らかの関連するクエリが実行されると、オブジェクト・イベントが生成され関連するアクションが実行される。ランタイムモードがナビゲーションの全性能をサポートするので、他のシーンへのワームホール又はジャンプリンクはアクセス可能である。他のシーンへジャンプすると、デザイン・ビューも新しいシーンに切り替えられる。ランタイムモードは、第二のウィンドウを開くことによりデザイン・ビュー内の編集作業の間に同時に見ることができる。同一シーンを表示している多種多様なランタイム・ビューは独立して作動し、互いに従属関係にはない。各・ビューは、アクティブなランタイム・ビューのためのワールド・シーン・ツリー内に反映されるグローバルパラメータの各々のコピーを有している。
【００３５】
データエレメントエディタウィンドウは、クエリの結果によるデータポイントの表示を図表的に編集するために用いられる。データエレメントエディタウィンドウが、デザインモードで図１２に示されている。セレクターバーとデータソースバーの両方を見ることができる。
【００３６】
シーン・エディタ・ウィンドウと同様に、データ・エレメント・エディタはデザイン・モードとランタイム・モードの二つのモードを有している。デザインモード・ビューでは、オブジェクトはグラフィック・パレットから追加され、クエリの実行なしで表示される。一つ又はそれ以上のプロパティ値を通してデータソースに結合されるオブジェクトは、プレースホルダー・オブジェクトで表示される。更に、オブジェクト・イベントは何も生成されないので、オブジェクトに関連する何らのアクションも実行されない。データ・エレメントは何れのズームレベルででも編集することができ、それはナビゲーション・ツール・バーから設定することができる。
【００３７】
データエレメントは別々に異なるズームレベルで表示されるが、そこでは、各表示又はドローイングによってＬＯＤが定められる。更に、データエレメント内の異なるオブジェクトは、異なる軸に関連付けられる。例えば、取引の量に関するバーを有するストックチャートは二つのＹ軸を有する。各取引日に関するデータエレメントは、価格軸に関連するハイ／ロー／クローズバーと、量軸に関連するボリューム・バーとを有している。セレクターバーは、ＬＯＤと編集される軸のセットとの制御を提供する。パラメータ・バーはシーン内の各パラメータ用のボタンを表示する。パレットに表示されるパラメータは、オブジェクトのプロパティの値を設定するためのオブジェクト・インスペクタで用いられる。パラメータ・バーは、パラメータが作成、削除、又は編集されると、自動的に更新される。
【００３８】
データソースバーは、データエレメントの範囲内にある各データソース用のボタンの帯を表示する。各ボタンは、オブジェクト・インスペクタで用いられる列名に対応している。レイアウトを単純にするため、単一のデータソースが表示される。ネストされたレイアウトでは、各クエリに関して一つの行が表示される。クエリは、その関連付けられたデータエレメントのオブジェクトが、データエレメントの先祖としてワールド・シーン・ツリー内に存在するかどうかという視野で考えられる。データソースの列が作成、削除、又は編集されると、データソースバーが自動的に更新される。
【００３９】
クエリ・エディタは、３つのクエリのビューを提示するが、その３つとは、正しく書式化されたクエリの結果を表示するデータシートと、クエリの構成のブロック・ダイアグラムを提供するクエリ・ダイアグラム・ビューと、実際のＳＱＬテキストを表示するＳＱＬビューとである。ユーザは、ウィンドウの一番下でスクロールバーの左にある、対応するモードボタンの一つをクリックすることにより、ビュー間の切り替えを行う。
【００４０】
データシート・ビューは、クエリのテーブル状の結果を示す読み出し専用のビューである。クエリがパラメータ化されていれば、データシートは、デフォルト値がクエリに含まれる各パラメータについて利用可能であるときだけ有効でありうる。データシートは、第二ウィンドウを開くことにより、クエリ・ダイアグラム又はＳＱＬテキスト・ビュー内での編集作業の間に、同時に見られうる。クエリへの変更は、データシートが対話的にリフレッシュされることになる。データシートモードが選択されない場合は、他のビューへの変更があってもリフレッシュされない。行は、ビューへ入ってくる場合、データシートへロードされる。
【００４１】
ユーザは、ワールド・マネージャーのデータ・タブか又は挿入メニューからブロックを選択することによって、クエリ・ダイアグラムにブロックを追加する。ブロックは、ソースブロックの出力ポート及び目標ブロックの入力ポートをクリックすることによって接続される。替わりに、ブロックは、マウスをポートの一つから他のポートへドラッグし、ユーザがマウスボタンを放すまで表示される「ゴム結合(rubber-banding)」接続ラインによっても接続することができる。どちらの場合も、カーソルは、接続操作を示すために、ポート選択アクションの間変更される。
【００４２】
ＳＱＬビューは、任意のＳＥＬＥＣＴクエリが作成され、編集できるようにする。更に、ダイアグラム・エディタによって生成される式の編集もできるようにする。しかし、ＳＱＬが編集されれば、ダイアグラムは利用できなくなる。この場合、ユーザに警告するために確認ダイアログが表示される。
【００４３】
ワールドエディタは、バーチャル・ワールドと対話するために、構成ビューと疑似コード・ビューの２つのビューを提供する。ワールド構成ウィンドウは、全ワールドに関する機構の階層的なビューを表示する。ワールド・ルート・ボックスの下にあるボックスはそれぞれ、１つのシーンに対応している。シーンの下にあるボックスは、データエレメント又はワームホールにより接続されている他のシーンに対応している。これらの何れかのボックスをダブルクリックすると、対応するシーン・エディタ又はデータ・エレメント・エディタが開く。ボックス間のリンクは、ワールド・シーン・ツリー内の階層を表す。
【００４４】
一つのボックスは、図表コンテンツに含まれる各データソース及びワームホール用の一つのチャイルドボックスを有している。ワールドの構成次第であるが、ツリーの深さは無限である。例えば、一つのシーンがもう一つのシーンまでのワームホールを含んでおり、そのシーンが今度は第一シーンまで戻るワームホールを含んでいれば、ツリーは第一及び第二シーンの無限の縦方向シーケンスを含んでいることになる。その結果、ツリーは、ユーザによって明示的に拡張される場合にのみレベルを拡張することとなる。
【００４５】
その下の各リンクとボックスは、リンクのトップにあるボタンをクリックすることにより、表示されたり隠されたりする。最初に表示されるとき、ワールドボックスはワールドに含まれる全シーンを表示するために拡張される。ボックスが拡張されると、ツリー構造は新たに表示されるボックス用の空間を作るようになっている。更に、ワールドのパラメータ化も構成ダイアグラムに表示される。グローバルパラメータ、シーン・パラメータ、及びクエリ・パラメータは、その入力としての役割を示すボックスの左側に伸びるテキストボックスとして表示され、一方クエリ列は、その出力としての役割を示すボックスの右側に伸びるテキストボックスとして表示される。パラメータと列名が別のエディタ・ウィンドウで追加、削除、又は変更される度に、その変更を反映させるためにボックスが更新される。
【００４６】
シーン・パラメータ又はクエリ・パラメータが、階層中でより上層のパラメータ若しくは列に設定されている場合には、パラメータのテキストボックスは、元の値に対して「配線されている(wired)」と示される。これらの接続は構成ダイアグラム内で編集することもできる。新規接続を確立し、パラメータの値を設定するためには、当該パラメータに対する入力接続点と、元のパラメータ又は列に対する出力接続点とをマウスでクリックする（順不同）。代わりに、接続点は、マウスを一方からもう一方へドラッグして、その結果ユーザがマウスを放すまで表示される「ゴム結合(rubber-banding)」接続ラインによっても接続できる。どちらの場合も、カーソルは、接続操作を示すために、選択アクションの間で変更される。ここでの注意点は、接続を有効なものにするためには、ソースはツリー階層中のより上位階層に存在せねばならないということである。リンクを排除するには、ユーザは当該リンクを選択して消去キーを押せばよい。
【００４７】
疑似コード・ビューは、ワールドの全コンテンツの読み出し専用・ビューをテキストフォーマットで提供する。疑似コードは、ワールド名と初期シーンから成る初期ヘッダーを表示するが、これに引き続いて以下のセクション、即ち、
グローバルパラメータ（Global parameters）
ユーザクラス(User classes)
カラー・マップ(Colormaps)
カラー・シーケンス(Color sequences)
ストック画像(Stock images)
データベース接続(database connections)
データソース(Data sources)
シーン(Scenes)
が表示される。
【００４８】
１つの実行例では、セクションは下記のように１組の点線によって囲まれている。
−−−−−−−−−−−−−−−−−−−−
セクション名(SectionName)：
−−−−−−−−−−−−−−−−−−−−
【００４９】
更に、データソースとシーンは、下記のように一本の点線によって分けられている。
−−−−−−−−−−−−−−−−−−−−
【００５０】
これに続くセクションは、各疑似コードエレメントに対するフォーマットを表示する。ここで、角括弧（‘［’と‘］’）はオプションのテキストを意味し、垂直分離線（‘｜’）は、二者選択を意味する点に注意されたい。
2000163490.tif 000001
2000163490.tif 000002
2000163490.tif 000003
疑似コードは、カラーコード型構文を使用して表示されうる。例えば、セクションのヘディングは緑で、データ型(DataType)は青で、そして他の全テキストは黒で表示されうる。疑似コードは、ワールド内のどこかで変更がある都度更新されることになる。
【００５１】
出力ウィンドウは、ワールドが展開され見えてくるにつれ、コンパイル情報及び実行情報を表示する、ドック可能なコントロールバーである。これはまた、警告メッセージ及びエラーメッセージも表示する。出力ウィンドウは、ドックされている時は縦方向にサイズを変えることができ、浮動時には縦横両方向にサイズ変更できる。
【００５２】
ランタイムモードでは、ビュー・ポイント・ダイアログ・ボックスがワールドをナビゲートするために設けられる。直接アクセスできるようになっているシーンは、シーン・コンボボックスに表示される。選択されたシーンのためのビュー・ポイントは、ビュー・ポイント・リスト・ボックスに表示される。ビュー・ポイントを選択すると位置編集コントロールの値が更新される。これらのコントロールの値は、位置とズーム係数を指定することにより、カスタム指定に変更される。
【００５３】
レイアウト・ウィザードは、新しくレイアウトを作るときにユーザを各段階を通して案内するために設けられている。全レイアウトに共通な最初の２段階は、レイアウトを選択して、次にデータソースを選択することである。次に、各レイアウトは、当該レイアウトを生成するために必要な限りの多数の追加的レイアウト特有の段階を有する。
【００５４】
レイアウトは、軸のセットのようなサポートするコンテクスト情報を伴うデータソースに由来するデータ・エレメントを空間的に配列させたものである。レイアウトは、以下の５つのカテゴリのセット、即ち、
チャート−連続情報を提示するために使用される、
マップ−１つのデータ・ソース内の多数の曲線又は連続情報をレイアウトするために使用される、
階層−オブジェクトの従属を示すために使用される、
パターン−独立したオブジェクトを順序付けられたパターンでレイアウトするために使用される、
フォーム−データソース内の単一のレコードを表示するために使用される（当該データソースが１行より多い行をもたらす場合、続きの行は無視される）、
のどれかに当てはまる。
【００５５】
レイアウトは、シーン又はデータ・エレメント描画上のどこにでも配置されうる。幾つかのレイアウト・タイプ、例えばマップ及び分散チャートは、２つ以上のデータ・エレメントをサポートし、このようにして情報の「階層化」を許す。この場合、各データ・エレメントには、現行のズームレベルに依存する視認性が割り当てられるわけで、ズームレベルを上げるとより多くの情報が提示できるようになる。
【００５６】
軸ノードは、それらを必要とするレイアウトに添付されている。数値ではなくてテキスト・ラベルに基づく軸を有する棒チャートや列チャートのような幾つかのチャートタイプでは、これらの軸の内の１つ又はそれ以上がデータソースを必要とするので、データ結合型である。サポートされる軸には、線形軸、対数軸、及び日付／時間軸が含まれる。これらの軸は、自動調整式ラベルと小刻みな増分もサポートするので、ズーミングはより多くの情報を正確な軸値で提供することができる。
【００５７】
あるレイアウト・タイプでは、データ・エレメントを位置づけるために、軸よりもむしろロケーターを使用しうる。これらのロケーターは、デザインタイムには目に見えて表示されないが、そのプロパティは、レイアウトの他のオブジェクトのプロパティと共に、オブジェクト・インスペクタ内に表示される。レイアウト内のデータエレメントがレイアウトそのものを保有するという複合レイアウトも使用できる。普通は、第２レイアウトに関連付けられるデータソースがパラメータ化され、１つ又はそれ以上のパラメータが親レイアウトのデータソースの列とリンクされる。
【００５８】
識別子は、バーチャル・ワールド内のエレメント、例えばオブジェクト、データソース、シーン、パラメータ、ユーザクラス、カラー・マップ、カラー・シーケンス及びビュー・ポイントのための名前である。識別子は、大文字・小文字を区別せず、１文字に等しいかそれ以上ならどんな長さでもよい。
【００５９】
オブジェクトのプロパティは、関数式の観点でオブジェクトの外見を定義する名前の付いた属性から成る。これらのプロパティへのアクセスは、オブジェクト・インスペクタを介して提供される。それらの値は、式の計算された結果に基づき、ランタイムで設定される。式は、ランタイムで結果として出る行に自動的に結合される１つ又はそれ以上のデータソース列の名前を含みうる。
【００６０】
オブジェクト・プロパティ式は、下記基本データ型：Boolean、Numeric、String、Point、PointList、及びImageの１つをもたらす。派生のNumeric型は、Color、DateTime、Enum、Integer及びPercentageを含む。派生のString型は、FilePath（又はＵＲＬ）及びFontNameを含む。
【００６１】
図２を参照すると、オブジェクト・インスペクタ３０がより詳しく示されている。オブジェクト・インスペクタ３０は、属性名列１００とプロパティカラム１１０という２つの列を提供する。図２で検査されるオブジェクトは、プロパティ１１２、１１４、１１６、１１８、１２０、１２２、１２４、及び１２６を有する。特に、プロパティ１１４、１１６、１１８、１２０、１２４、１２６は静的定数である。しかしながら、プロパティ１１２及び１２２は、動的であって、且つランタイムで評価されうる。動的なプロパティ１１２及び１２２に起因して、データ駆動型アプリケーションを生成するために、ユーザは当該動的プロパティを入力しさえすればコードが自動的に生成される。従って、動的プロパティ１１２及び１２２のデータ結合は、プロパティシート３０にシームレスに統合される。
【００６２】
オブジェクト・インスペクタ・ウィンドウ３０は、オブジェクトのプロパティとイベントを表示するドック可能なコントロールバーである。オブジェクト・インスペクタは、ドックされている時には横方向にサイズ変更することができ、浮動時には縦横両方向にサイズ変更することができる。ウィンドウは、ドラッグ中にその位置がドッキング・サイトと重なるときには、ワールドのワークスペースの左又は右にドックされる。オブジェクト・インスペクタ３０は、シーン・エディタ又はデータ・エレメント・エディタ・ウィンドウが、デザインモードで稼働しているときに表示され、エディタの範囲内の全オブジェクトのリストを保有するドロップダウン・コンボボックスを表示する。「ドット」表記法は複合オブジェクトを示すために使用される。例えば、“ScatterChart1．DataElement1"は、DataElement1がScatterChart1に所有されるオブジェクトであることを表している。
【００６３】
オブジェクト選択コンボボックスの下には、あるオブジェクトに関してのプロパティ又はイベントの何れかを表示するタブ式シートがある。プロパティのタブが選択されると、選択されたオブジェクトのプロパティの値を設定するため、２列入力フォームが表示される。左列は、プロパティの名前を表示する読み出し専用列であり、もう一方の右列は、プロパティの値を表示する読み出し／書き込み列である。右列に入力される値は、定数でもよいし、或はデータソースからのパラメータの関数又は列名を含んでいる計算値であってもよい。プロパティ値が計算されるタイプのもの（有限な数の値にしか設定できない値）であるときは、ドロップダウン・コンボボックスはそのプロパティにとって正当な値をリストにして表示させる。計算されるタイプには、これに限定するわけではないが、次のもの、即ち、フォント名（例：“Arial"，“Courier"）、カラー（例：赤、青）、テキスト整列（例：左、右）、テキストの固定ポイント（例：左下、右上）、ブール値（例：真又は偽）、線スタイル（例：実線、点線）、塗りつぶしパターン（例：べた、横方向）が含まれる。
【００６４】
プロパティが日付或いは時間であれば、フィールドがアクティブになるとカレンダーコントロールがプロパティ値の下に表示される。
【００６５】
フォーム及びデータエレメントオブジェクトは、オブジェクト・インスペクタのリストに載っているQueryParametersオブジェクトを介してクエリ・パラメータの値の制御を提供する。QueryParametersオブジェクトは、フォーム又はデータエレメントの子オブジェクトであり、各クエリ・パラメータについてのプロパティを保有している。クエリがパラメータ化されていない場合には、QueryParametersオブジェクトは、オブジェクト・インスペクタに表示されない。オブジェクトに含まれる値は、当該クエリが実行される前に、ランタイムでクエリのプロパティを設定するために使用される。
【００６６】
図３は、抽象基底クラスVcPropertyBag２００のプロパティオブジェクトモデルを示している。VcPropertyBag２００は、１つ又はそれ以上の派生クラスに特有のプロパティのセットに対しコンテナの役目を果たす。VcPropertyBag２００は、プロパティとそれらの値にアクセスしそれらを操作するためのインタフェースを提供する。それはまた、派生オブジェクトのプロパティのセットについての型情報を入手するための純粋仮想メソッドも提供する。
【００６７】
VcPropertyBag２００から派生されるのは、抽象基底クラスVcScene２０２、及び抽象基底クラスVcDrawingNode２０４である。VcScene２０２はシーンのためのクラスであって、VcPropertyBag２００からのプロパティを継承する。VcDrawingNode２０４は、シーン内に表示される全グラフィカル・オブジェクト用の抽象基底クラスであり、及びまたVcPropertyBag２００からのプロパティを継承する。VcDrawingNode２０４は、動き、スケーリング、及び他の標準的な編集操作をサポートするプロパティを操作するための純粋仮想メソッドのセットを提供する。派生クラスは、適切なプロパティに対する編集操作をマッピングすることに責任を負う。
【００６８】
VcPropertyBag２００はまた、クラスVcProperty２１０のm＿propertiesというプロパティのセットを有しており、このセットは、名前と列挙型情報、及びm＿expectedTypeを含む、特定オブジェクト・プロパティについての全情報が含まれている。m＿expectedTypeは、求められたプロパティ値のデータ型（例：boolean、numeric、string等）を記述し、オブジェクトへアクセスするパスm＿pathを記憶し、そして当該プロパティに関するデザインタイム値m＿designValueとランタイム値m＿runtimeValueを管理する。デザインタイムはコンテナオブジェクトが（データ又はパラメータにリンクされずに）孤立して表示されうるように常に定数に決められる。ランタイムの値も定数である場合、この２つの値は同じ値に設定される。
【００６９】
VcProperty２１０はプロパティの名前用の保管場所を提供するための標準的なストリングクラスであるCString２１２に属するm＿nameプロパティを有する。VcPropertyオブジェクト２１０はまた、VcPropertyPath２１４と呼ばれるクラスのプロパティであるm＿pathも有しており、これはVcPropertyBagのプロパティのセット内だけに特有のものであるプロパティに対する識別子を記憶し、ポインターm＿nextをVcPropertyPathのリンクされたリストに提供して一まとめにされたプロパティバッグをサポートする。
【００７０】
VcProperty２１０はまた、VcPropertyValue２１６と呼ばれるクラスに属する、プロパティm＿design値も有する。VcPropertyValue２１６は、プロパティ（VcFunction２２０）にとってのデザインタイム値を表現する関数を記憶し、またユーザにより入力された式を記憶するので、大文字・小文字の区別、スペーシング、及び他の特定項目が、ユーザの入力に応じて表示されることになる（CString２１８）。
【００７１】
VcFunction２２０は、構文解析された式エレメントのための抽象基底クラスであり、この関数はコンテクスト・オブジェクトを供給することによって求められる式ツリーにとってのルート・エレメントである。CString２１８は、ユーザにより入力される式の保管場所を提供する標準的なストリングクラスである。
【００７２】
最後に、VcPropertyオブジェクト２１０はまた、抽象基底ベースクラスVcPropertyValue２２２に属するプロパティであるm＿runtime値も有する。VcPropertyValue２２２は、当該プロパティに対するランタイム値を表す関数を記憶し、またユーザにより入力された式を記憶するので、大文字・小文字の区別、スペーシング、及び他の特定項目が、ユーザの入力に応じて表示されることになる。
【００７３】
これより図４に移るが、ここでは模範的バイトコードの実行を表すダイアグラムが示されている。本例では、ユーザは関数を式の形で規定している。式は続いてバイトコードを生成するために構文解析されるが、このバイトコードは所望のオペレーションを表すインストラクションのハイレベルのセットであり、ランタイムで実行されるものである。バイトコードの実行については図４に示されている。
【００７４】
図４は、例示的なVcStmtCreatShapesバイトコード３０２の実行を示す。バイトコード３０２は、実行されると特定の形態オブジェクトのインスタンスを生成し、そしてそのオブジェクトに対するトークン化された名前をハッシュテーブル・ルックアップ用に記憶する。バイトコード３０２により生成されるオブジェクト形態を構築するための１つの模範的実行例としての疑似コードをブロック３１０として示している。当該オブジェクトの形態を構築するための実行疑似コードブロック３１０では、VcStmtCreatShape'sPerform()メソッドが呼び出されると、それはファクトリィ・オブジェクトのCreatShape()メソッドを新しい形態のオブジェクトを生成するために呼び出し、次にそのオブジェクトに対するポインターを、プロパティ設定時に、あとのルックアップのためのコンテクスト・オブジェクトにより所有されているハッシュテーブルに記憶する。最後に、本メソッドは、その生成時に設定される形態への参照を解放する。
【００７５】
バイトコード３０２は、当該形態のトークン化された名前の保管場所を提供するための標準的なCStringクラス３００のメンバーであるm＿objectIdプロパティを有する。バイトコード３０２は、シーン内で形態を生成することに責任を負う抽象基底クラスVcShapeFactory３０４のメンバーであるm＿factoryプロパティを有する。VcShapeFactory３０４の派生クラスは、形態の特定のクラスを生成し且つそれをキャンバス表示リストに加えるために、実体のないCreatShape()メソッドをオーバーライドしなければならない。
【００７６】
VcShapeFactory３０４は、抽象基底クラスVcShape３０６から派生する形態オブジェクトのインスタンスを生成する。VcShape３０６は、全形態オブジェクトにとっての抽象基底クラスである。それは、形態プロパティを設定するためのトランザクション指向の多形態インタフェースを提供する。VcShapeの派生クラスは、レンダリングとヒット検知サポートを実行することに責任を負う。
【００７７】
図４はまた、抽象クラスVcStmtSetProperty３２０についても示しているが、これは、実行されると形態のプロパティの値を設定するバイトコード・ステートメントのための抽象クラスである。VcStmtSetProperty３２０の派生クラスは各データ型を表現する。抽象クラスVcStmtSetProperty３２０は、形態のトークン化された名前と、プロパティに独自的にアドレスするために必要なプロパティアイデンティティのセットとを記憶する。VcStmtSetProperty３２０は、CStringクラス３２２のメンバーであるプロパティm＿objectIdと、クラスVcPropertyPath３２４のメンバーであるm＿propPathプロパティとを有する。VcPropertyPath３２４は、プロパティの形態セット内に特有のプロパティのための識別子を記憶して、１まとめにされた形態をサポートするために、リンクされたリストVcPropertyPathにポインターm＿nextを提供する。
【００７８】
今度はVcStmtSetProperty３２０がVcStmtSetStringProperty３２６により継承されるが、VcStmtSetStringProperty３２６は、形態のプロパティの値をストリング値に設定し、且つ、形態のプロパティを設定する前にプロパティ値を評価するための抽象ストリング関数VcSftn３２８へのポインターを保有している。VcSftn３２８は所与のコンテクストのためのストリングに対し評価を行うVcFunctionから派生されるが、この関数は、関数の構文解析されたエレメントを保有している構文解析表現ツリーに対するルート・エレメントである。
【００７９】
VcStmtSetStringPropertyの実装の１つであるバイトコード３２６を、ブロック３３０に示す。形態のプロパティを設定するためのこの実装においては、VcStmtSetStringPropertyのPerform()メソッドが呼び出されると、それはコンテクストのハッシュテーブルから当該形態を検索する。それは次に、所与のコンテクストを用いてストリング関数を評価し、その結果をプロパティパスによって当該形態に渡す。
【００８０】
これより図５に入るが、ここではサンプル構文解析されたプロパティ関数を説明するダイアグラムを示している。本例中の関数は、VcStmtSetStringProperty関数３５０である。関数３５０は、オブジェクト識別値“Text1"３５２を有しているが、これはクラスCStringのメンバーである。これは、設定予定のプロパティを保有する形態オブジェクトのトークン化された名前である。VcStmtSetStringProperty３５０は、オブジェクトText1により所有されるTextプロパティの値を、スペース記号によって分離され付記されているlast＿nameからfirst＿nameまでにより作り出される計算値に設定する、サンプル・バイトコード・ステートメントである。本例では、m＿objectIdは目標オブジェクト“Text1"を識別するストリングを指し、m＿propPathはテキストオブジェクト内に設定される予定のプロパティのアドレスを指し、m＿ftnはプロパティの値に対し評価を行うストリング関数を指す。
【００８１】
VcStmtSetStringProperty３５０は、その値がブロック３５４で設定されるプロパティパスを有する。最後に、VcStmtSetStringProperty３５０はVcSftnConcatenate関数３６０を実行するように指定されている。VcSftnConcatenate３６０は、２つのメンバーストリング関数であるm＿ftn1（first＿name＋〃〃）とm＿ftn2（last＿name）の結果を連結する、VcSftnから派生されるストリング関数である。
【００８２】
ブロック３６０内では２つの関数が更に細かく規定される。ツリーの左枝を下って行くとVcSftnConcatenate関数３６２が示されている。VcSftnConcatenate３６２は、２つのメンバーストリング関数m＿ftn1とm＿ftn2を使用して、式（first＿name＋〃〃）を評価することに責任を負う。ブロック３６２内には、２つの追加の関数、即ちm＿ref（“first＿name"）に記憶されている識別子の現在値を調べる責任を負うストリング関数であるVcSftnLookup関数３６４と、定数のストリング値を記憶する責任を負うストリング関数であるVcSftnConstant３７０とが追加されている。
【００８３】
ルックアップ関数３６４の値は文字ストリング３６６により求められるが、これは識別子の名前、“fisrt＿name"、を保管する場所を提供する標準ストリングクラスである。定数関数３７０で値を求めると、その結果はブロック３７２のスペース（ストリング定数“ ”）である文字ストリングになる。
【００８４】
VcSftnConcatenate関数３６０からツリーの右側を下っていくと、VcSftnLookup関数３８０が求められる。VcSftnLookup３８０は、m＿ref（“last＿name"）に記憶されている識別子の現在値を調べる責任を負うストリング関数である。VcSftnLookup関数３８０の評価を求めると、文字ストリングになる。
【００８５】
シーンからコードを生成するプロセスのオブジェクトモデルについては、図６により詳しく示す。当該シーンは、シーン内の各形態と論理エレメントのためのコードジェネレータを表す描画ノードのリストを保有する。オブジェクトVcScene４００は、視認区域に表示される全グラフィカルオブジェクト用の描画層若しくはキャンバスを定義する。CreatMethod(）関数は、実行されると、グラフィカルオブジェクト付きのシーンを生成しそしてまとめ、一連のバイトコード・ステートメントを生成する。これらのステートメントは、VcCGMethod４１０と呼ばれるオブジェクトに記憶される。
【００８６】
VcScene４００は、クラスVcDrawingNode４０２から派生されるオブジェクトのリストm＿nodesを保有している。VcDrawingNode４０２は、シーンのコンテンツを表現する全形態と論理ノードのための抽象基底クラスである。VcDrawingNode４０２は、派生クラスにおけるVcStmt実行ステートメントのリストを生成するためのインタフェースGetExecStmts(）を定義する。VcDrawingNode４０２は、VcShapeNode４０４のサブクラスである。VcShapeNode４０４は、形態を生成するノード用の抽象基底クラスである。VcShapeNode４０４の派生クラスは、各タイプの形態のプロパティを構築し設定するのに必要なバイトコード・ステートメントを生成する。
【００８７】
またVcShapeNode４０４は、VcDataNodeクラス４０６のサブクラスであるが、これは、データソースをオブジェクトのレイアウトを表すグラフィカルテンプレートにクエリ内の各行ごとに結合させる形態ノードのクラスである。VcDataNodeにより生成されるバイトコードは、データソースにより供給される結果のセットを反復し、オブジェクトのセットを生成し、それらをアクティブなシーンに付け加える。
【００８８】
VcDrawingNode４０２はまた、描画ノードのクラスVcLogicNode４０８によっても継承されるが、このクラスが今度はVcDataSource４１０に継承される。VcLogicNode４０８は、形態ノードとユーザの間の関係を定義するバイトコードを生成する描画ノードのクラスである。VcDataScouce４１０は、データの抽象ソースを表現する論理ノードのクラスである。派生クラスは、レイアウト中のグラフィックを生成するためのデータノードにより使用されるデータの表になるバイトコードを生成することに責任を負う。
【００８９】
VcDataNodeクラス４０６は、VcDataSource４１０のインスタンスを保有する。VcDataSource４１０は、VcQueryDataSourceクラス４１２に継承される。VcQueryDataSource４１２は、ランタイム・パラメータに取って代わり、クエリ実行するクエリ・インスタンスを構築するバイトコードを生成するためのクエリ・オブジェクトと対話をすることに責任を持つデータソースのクラスである。
【００９０】
次にVcQueryDataSource４１２は、列のタイプとパラメータ、及び名前を始めとする、ＳＱＬクエリについての情報を記憶するVcQuery４１４のメンバーであるクエリ・オブジェクトm＿queryを指す。またVcQueryオブジェクト４１４は、VcColumnクラス４１６に記憶されている列のセットと、VcParameterクラス４１７に記憶されているパラメータのセットとを有する。VcColumn４１６は、データベースから検索されるデータの列についての情報を記憶するので、バイトコード実行ステートメントにより使用されるコンテクスト・オブジェクトにより参照されることができる。VcParameter４１７は、ＳＱＬのＳＥＬＥＣＴステートメントに対する引数の役をする名前の付けられたプレースホルダー・オブジェクトを表している。ＳＱＬステートメントが実行される時にはその前に、パラメータは、パラメータのランタイム値に置き換えられる。
【００９１】
VcSceneオブジェクト４００は、そのCreatMehtod（）メンバー関数が呼び出されると、クラスVcCGMethod４１０のインスタンスを生成する。このVcCGMethod４１０は、抽象基底クラスVcStmt４２０に属するオブジェクトのセットを有する。VcStmt４２０は、全バイトコード・ステートメント用の抽象基底ベースクラスである。その実体のないメソッドPerform(）は、全ての派生クラスに実装されるべき実行インタフェースを定義する。VcStmt抽象基底クラス４２０は、４２２、４２４、４２６、４２８、４３０を始めとする多数のバイトコード・ステートメントにより継承される。VcStmtCreatShape４２２は、実行されると特定の形態オブジェクトのインスタンスを生成するバイトコード・ステートメントである。ステートメント４２２は、ハッシュテーブル・ルックアップのために、オブジェクトのトークン化された名前を記憶する。VcStmtCreatQuery４２４は、実行されると特定のクエリ・オブジェクトのインスタンスを生成するバイトコード・ステートメントである。VcStmtBeginProperties４２６は、そのプロパティが設定される予定の形態インスタンスを通知するバイトコード・ステートメントである。VcStmtSetProperty４２８は、実行されると形態のプロパティの値を設定するバイトコード・ステートメント用の抽象クラスである。派生クラスは、形態のトークン化された名前と当該プロパティを独自的にアドレスするのに必要とされるプロパティＩＤのセットを記憶する各データタイプを表す。最後に、VcStmtEndProperties４３０は、そのプロパティに対する変更が完了しており、２つ以上のプロパティに依存する何れの計算をも実行できることを、形態インスタンスに通知するバイトコード・ステートメントである。
【００９２】
コード実行処理のオブジェクトモデルは、図４に示すオブジェクトモデルと同様のものである。簡単に言うと、VcStmtCreatShapeバイトコードは、実行されると、ハッシュルックアップテーブルのオブジェクト用にトークン化された名前を記録し、特定の形態を呈するオブジェクトのインスタンスを生成する。VcStmtCreatShapeバイトコード・ステートメントは、シーン内に形態を生成することに責任を持つVcShapeFactory抽象基底クラスから派生されたファクトリィ・オブジェクトを保有する。更に、VcStmtSetProperty抽象基底クラスは、形態のトークン化された名前と当該プロパティを独自的にアドレスするのに必要とされるプロパティＩＤのセットとを記憶する。VcStmtSetStringPropertyバイトコード・ステートメントは、ストリング値に形態プロパティの値を設定するが、形態のプロパティを設定する前にプロパティ値を求めるための抽象ストリング関数へのポインターを保有する。
【００９３】
図７を参照し、プロパティシート入力プロセス４４０について説明する。プロパティシートの使用に際して、ユーザはある式を入力する（ステップ４４２）。その式は次に構文解析され（ステップ４４４）、有効性がチェックされる（ステップ４４６）。当該式が無効の場合には、必要に応じてデザイン値を使用してランタイム値をクリアするよう処置され（ステップ４４８）、エラーメッセージが表示される（ステップ４５０）。そうではなく当該式が有効である場合には、関数を生成してその関数をランタイム値として記憶する処置がとられる（ステップ４５２）。次に、その関数が定数であるかどうかを確定し（ステップ４５４）、もしそうであるなら、関数のクローンを作りデザインタイム値をそれに替えて記憶する（ステップ４５６）。
【００９４】
次に、バイトコードについてのランタイム実行可能コードを保有するバイトコード実行画像を無効にする処理が行われる（ステップ４５８）。次に、ランタイム表示を自動的に更新する必要があるかどうかをチェックする（ステップ４６０）。更新が必要であるなら、バイトコードが生成され（ステップ４７０）、実行される（ステップ４７２）。ステップ４６０又はステップ４７２から出て処理は終了する（ステップ４７４）。
【００９５】
次に図８に移るが、ここではオブジェクトを目に見えるように操ることについてのプロセス８２０を詳しく説明する。先ずどのオブジェクト・プロパティをどの変更された属性にマッピングするのかを確定する（ステップ８２２）。次に、新しい属性値を表すために定数関数が生成されるが、この値は次にランタイム・プロパティ値とデザインタイム・プロパティ値として記憶される（ステップ８２４）。バイトコード実行画像は、ここで無効とされる（ステップ８２６）。次に、ランタイム表示を自動的に更新する必要があるかどうかを確定する（ステップ８２８）。もし必要であれば、バイトコードが生成される（ステップ８３０）。ステップ８３０については、図９により詳細を示す。ステップ８３０に続いてバイトコードが実行される（ステップ８３２）。ステップ８３２については、図１１により詳細を示す。ステップ８２８又はステップ８３２から出て処理は終了する（ステップ８３４）。
【００９６】
次に図９に入るが、ここではバイトコードを生成するプロセス６００について示す。先ず、事前に記憶されたアプリケーション・リソースを入力値とみなし（ステップ６０２）、第１シーンを入手する（ステップ６０４）。次に当該シーン中の第１ノードを入手する（ステップ６０６）。次に、そのノード用のバイトコード実行ステートメントを検索する（ステップ６０８）。このステップについては、図１０により詳しく示す。ステップ６０８に続いて、ノードを追加して処理する必要があるかどうかを確定し（ステップ６１０）、必要があれば、ステップ６０８にループバックする前に次のノードを入手する（ステップ６１２）。
【００９７】
全ノードの処理が済むと、VcCGMethodを生成して、当該シーンに関連するステートメントを記憶する（ステップ６１４）。次に、他にもまだ処理する必要のあるシーンがあるかどうかを確定する（ステップ６１６）。もしあれば、次のシーンを入手して（ステップ６１８）から、ステップ６０６までループバックし、バイトコード生成プロセスを継続する。全シーンの処理が済むと、バイトコード実行画像を生成し（ステップ６２０）て、本プロセスは終了する（ステップ６２２）。
【００９８】
次に図１０について説明するが、ここではオブジェクトノードについてのバイトコード実行ステートメントを入手するためのプロセス６３０を示す。先ずノードタイプを確認する（ステップ６３２）。ノードが形態なら、形態生成ステートメントを生成し（ステップ６３４）、同様にプロパティ捕捉を開始するためのステートメントを生成する（ステップ６３６）。次に、ステップ６３８−６４４で検索された各プロパティを設定するためのステートメントを生成する。最後に、当該プロパティをコミットするためのステートメントを生成する（ステップ６４６）。
【００９９】
一方、ノードがクエリ・データソースである場合には、クエリを入手して、パラメータ化されたＳＱＬステートメントを生成する（ステップ６４８）。次に照合可能な識別子として使用される列名を確定する（ステップ６５０）。次に、クエリを生成するためのステートメントを生成する（ステップ６５２）。次に、ステップ６５４−６６０で、各クエリ・パラメータ値を設定する１つ又はそれ以上のステートメントを生成する。最後に、クエリを実行するステートメントを生成する（ステップ６６２）。ステップ６４６又はステップ６６２から出て処理は終了する（ステップ６６４）。
【０１００】
図１１を参照すると、ここではバイトコードを実行するためのプロセス６６６が示されている。先ず、実行コンテクストが生成される（ステップ６６８）。次に、当該プロセスはVcCGMethodPerform()メソッドを呼び出す（ステップ６７０）。当該ステートメントが検索される（ステップ６７２）。次に、当該ステートメントが分類される（ステップ６７４）。ステップ６７４に続いて、VcStmtCreatShapeステートメントが見つかると、新しい形態を生成し（ステップ６７６）、その形態をコンテクストハッシュテーブルにトークン化された形態名を使用して記憶する（ステップ６７８）。ステップ６７４に続いて、VcStmtBeginPropertiesステートメントが見つかると、形態情報をハッシュテーブルで調べる（ステップ６８０）。次に、形態のOnPropertiesBegin(）メソッドを呼び出す（ステップ６８２）。VcStmtSetPropertyステートメントが見つかると、形態情報をハッシュテーブルで調べる（ステップ６８４）。次に、その値をプロパティに割り当てるために形態のSetProperty()メソッドを呼び出す前に、プロパティ式を求める（ステップ６８６）。VcStmtEndPropertiesステートメントが見つかると、形態情報をハッシュテーブルで調べる（ステップ６９０）。次に、形態のOnPropertiesEnd()メソッドを呼び出す（ステップ６９２）。次に、当該形態は初期化され（ステップ６９４）て、キャンバス・ディスプレイリストに付け加えられる（ステップ６９６）。
【０１０１】
ステップ６７８、６８２、６８８又は６９６に続いて、ステートメントを追加して実行する必要があるかどうかをチェック（ステップ６９８）して、必要があれば、ステップ６７４へとループバックする前に、次のステートメントを入手する（ステップ８００）。
【０１０２】
ステップ６９８に続いて、実行コンテクストを削除し（ステップ８０２）、キャンバスを新しくする（ステップ８０４）。最後に、処理は終了する（ステップ８０６）。
【０１０３】
グラフ編集システムを説明する図解を図１２に示す。シーングラフ４８０はアプリケーションの階層表現を提供する。シーングラフ４８０中の各エレメントはノードと呼ばれ、バイトコードの生成に際してこのノードが使用される。更に、２つのデータのビュー４８２と４８４を示している。ビュー４８２は、２つのデータセットから検索されたデータを示すレイアウト（マップ）である。
【０１０４】
ビュー４８４では、データポイントは単一画像４８５として表示してもよく、図１２では強調表示されている。画像４８５は、プレースホルダ・イメージ付きのデザインモードで示されている。画像４８５に関連する属性はウィンドウ４８６に示される。各データエレメントは自身の描画ウィンドウを有しているのでユーザは何れのデータエレメントでも編集することができる。このように、グラフはデータポイントに配置されるので、グラフはデータポイント内に存在することになる。
【０１０５】
図１２の編集システムを使えば、ユーザは、それが次にグラフ自身の中にネストされるデータポイント内のグラフを定義することができるようになるので、図１２の編集システムは、細部を掘り下げ見る方法を提供しているといえる。このように、詳細さのレベル（ＬＯＤ）を変えながらシーンを示すために使用される場合には、ユーザがドットにズームするとそれはグラフに変わり、ユーザがグラフにズームすると、そのデータポイントは追加的なグラフになってユーザがより詳細なものをみるために掘り下げることができるようになっている。グラフ編集システムは、単一データポイントの表現と、親シーン自身と同じ程度に広範囲にわたるデータポイント用のあらゆる任意の表現とを編集する便利な方法を提供する。
【０１０６】
ワームホールの数学理論について次に説明する。ワームホールは、ユーザが１つのシーンのウィンドウを通して別のシーンを覗けるようにする特別なオブジェクトである。図１３は、この効果を図解し、目標シーンに合わせて複合ズーム係数がどのように計算されるのかについて示している。
【０１０７】
図１３はワームホールを示し、これはハイパーリンクの１つの型式であって、ユーザに、ハイパーリンクを介してコンテクストの情報を渡すと同時に、ハイパーリンクを介して他の側を見せるようにしている。ハイパーリンクの反対側が観察できるので、この反対側はユーザにとって「透けている」ことになる。図１３では、ワームホール４９０は、第１シーン４９２から第２シーン４９４へのウィンドウとして示されている。従来型のハイパーリンクがステートレスであるのに対し、ワームホール４９０は、ステート情報を提供する。ユーザ位置４９１からの、第１シーン４９２に対する第１高度（elev1）４９６と第２シーン４９４に対する第２高度（elev2）との間の関係は、以下の式で表される。
2000163490.tif 000004
本例では、ズーム係数はそれぞれ倍率係数を表す。また、ズーム係数は、関連付けられた高度パラメータに関して逆比例する値である。例えば、１００％のズーム係数では、高度パラメータは１となるが、一方ズーム係数が２００％の場合には、高度パラメータは０．５となる。
【０１０８】
ワームホール・ウィンドウは、シーンに対して定義されているパラメータの値を設定する。ワームホール・ウィンドウはまた、目標シーンを拡大することのできるあるタイプのレンズとしての役割も果たす。ワームホールの目標シーンは、同じシーンを再帰的に表示するためのソースシーンと同じであってよい。ワームホールに適用される増加するズーム係数は、データの密集域の乱雑さ（clutter）を減らすために、或いは倍率を追加して詳細さのレベルを増やすために利用できるので、これは格別有用である。ワームホールは反復限界を定義するパラメータを有するので、反復が無限に続くことはない。
【０１０９】
ユーザは、より多くの情報を求めて「掘り下げる(ドリルダウン)」ために、そしてまた目標シーンのオブジェクトを「アクティブにする」ために、ワームホールを抜けてジャンプすることができる。これにより、ズーム係数が増大する影響が排除されるだけでなく、第１シーンのオブジェクトに使用されるメモリーも開放される。ユーザがマウスを使用して、ワールドをナビゲートし、オブジェクトと対話すると、トリガとして振る舞う通知イベントが生成される。振る舞いは、デザインタイムにディベロッパにより決められており、次の２つのオプション段階（順番通り）、即ち、シーン及び／又はグローバルパラメータの値を設定する段階と、アクションを実行する段階とから成る。
【０１１０】
ワームホールは、オブジェクト・インスペクタのリストに掲載されているSceneParametersオブジェクトを介してシーン・パラメータの値について制御を行う。SceneParametersオブジェクトは、ワームホールの子オブジェクトであり、各パラメータに関するプロパティを保有している。目標シーンがパラメータ化されていなければ、SceneParametersオブジェクトは、オブジェクト・インスペクタに表示されない。この値は、オブジェクトに保有され、ランタイムでシーンのプロパティを設定するために使用される。
【０１１１】
３タイプのパラメータがクエリのランタイム値を駆動し、更に種々のユーザコンテクスト変数、即ちグローバルパラメータ、シーン・パラメータ、クエリ・パラメータのモニターと制御をも行う。グローバルパラメータは、ランタイムのユーザに、コンテナアプリケーションによって設定され又はモニターされるべきプロパティとして公開される。更に、組み込み型グローバルパラメータ、即ち、UserX（ユーザの中心からの現在の横方向オフセットをインチ幅で追跡又は設定する）、UserY（ユーザの中心からの現在の縦方向オフセットをインチ幅で追跡又は設定する）、UserZoom（ユーザの現在のズーム（倍率）レベルを追跡又は設定する）、及びUserClass（ユーザのプロファイルクラス名を保有する）を利用することもできる。
【０１１２】
クエリ・パラメータは、クエリが実行される前にデータソースにより設定される。シーン・パラメータはワームホール又はイベント・アクションにより設定される。それらは、次の属性、即ち、
名前−パラメータ識別子
データタイプ−値タイプ
ディスクリプション−内部文書に対して有効
デフォルト値−ワームホールのSceneParameters子オブジェクト又はイベント・アクションにより設定されない場合に使用される値。デフォルト値が有効でないならばシーンは見ることができない。
を有する。
【０１１３】
ユーザクラスは、バーチャル・ワールドの動作又は外見をユーザの識別子に基づいてカスタマイズするために使用することができる。例えば、売上予測に対するワームホールは販売職員と管理職社員にしか見えないようにするとか、病院の間取り図のレイアウトでは、管理者向けには空きベッドを強調表示するのに対し、心臓専門医向けには心臓病患者のベッドを強調表示するなどしてもよい。全ての新しいワールドのデフォルトユーザクラスは「匿名(Anonymous)」である。
【０１１４】
ワールドにとっての現在のユーザクラスは、UserClassグローバルパラメータに記憶される。プロパティ値或はイベント・メソッドは、UserClassがclass＿nameユーザクラスのメンバーであるかどうかに応じて真の値か偽の値を戻すIsUser（class＿name）プロパティ関数を使用することにより、現在のユーザクラスに基づくものとなる。標準的なブール式は、直接比較用又は表示用のUserClassパラメータも保有できる。
【０１１５】
ユーザクラスは、クラスを更に洗練するためにサブクラスに分けられる。ある１つのクラスのユーザサブクラスは、別のクラスのサブクラスであってもよいので、その結果、ユーザクラスは柔軟で多数の継承性を持つ階層となる。あるユーザクラスがユーザによって削除されても、２つ以上の他のユーザクラスのサブクラスとして存在する場合、ユーザはユーザクラスの全出現を消去するか否か、或いは選択されたインスタンスだけを消去するかを問われることになる。
【０１１６】
これより図１４について説明するが、ここではワームホールのオブジェクトモデルがより詳しく示されている。VcSceneクラス５００は、視認域に表示される全グラフィカルオブジェクトに対する描画層（キャンバス）の輪郭を定める。VcScene５００は、シーン内に含まれているノードのプロパティによって参照されるパラメータのセットを提供する。当該シーンがレンダーされる前に、各パラメータは設定されねばならず、同様のやり方で、関数に対する引数は関数が呼び出される前に設定されねばならない。次に、ワームホール設定ノードは、ワームホールを通してシーンが見えると、計算された設定を各シーン・パラメータに供給する。
【０１１７】
VcSceneクラス５００は、VcParameterクラス５０２のメンバーであるプロパティと、VcDrawingNode基底クラス５０４から派生したノードのリストを有する。VcParameter５０２は、名前とデータタイプを始めとするシーン・パラメータについての情報を記憶し、一方VcDrawingNode５０４は、シーンのコンテンツを表現する全形態及び論理ノードのための抽象基底クラスである。VcDrawingNode５０４は、定数であっても計算されてもよいプロパティを保有する。計算されたプロパティは１つ又はそれ以上のシーン・パラメータに依存する。
【０１１８】
VcDrawingNode抽象基底クラス５０４は、今度はVcShapeNode５０６に継承されるが、これは更にVcWormhoeNode５０８に継承される。VcShapeNode５０６は、全視認ノードタイプ用の抽象基底クラスである。VcShapeNode５０６の派生したクラスは、形態の各タイプの特定の属性及び動作を実行する。VcWormholeNode５０８は、別のシーンにリンクするシーンの形態ノードのクラスである。それは、シーンが描画される前に全シーン・パラメータの値を設定するための設定用ノードに対するポインターを保有している。
【０１１９】
VcWormholeNode５０８は、VcWormholeSettingNode５１２クラスのメンバーであるm＿sceneParameterSettingsプロパティを有する。VcWormholeSettingNode５１２は、接続シーンのパラメータ毎にワームホール特定の設定を保持する論理ノードのクラスである。これらの設定は、数値を計算されて、シーンがワームホールに描画される前に当該シーンに渡される。
【０１２０】
VcWormholeSettingNode５１２はまたVcLogicNode５１０から派生され、このVcLogicNode５１０はVcDrawingNode５０４から派生される。VcLogicNode５１０は、形態ノードとユーザの間の関係を定義するノードのための抽象基底クラスである。
【０１２１】
図１５及び１６は、模範的なワームホールの使い方を示している。図１５には４つのワームホール、即ち、ポートフォリオリスク管理ワームホール７００、市場データ・ワーム・ホール７１０、考慮中の投資ワームホール７２０、ファースト・コール・アナリスト推薦ワームホール７３０が示されている。ポートフォリオリスク管理ワームホール７００は、当該シーンの第３レベル・ビューを表示する３つの詳細なワームホール７０２、７０４、７０６とチャート７０８を示している。この３つの詳細なワームホール７０２、７０４、７０６は各々、３種類の別個のファンド又はポートフォリオに関連する金融動向を示す。その上、ある１つのファンド又はポートフォリオを代表する１つのワームホールから生じる所与のシーンのビューは、別のファンドを代表する別のワームホールから生じる同じシーンのビューとは異なる。このようなわけで、例えば、ポートフォリオリスク管理ワームホール７００に穴を開け、ファンド７０２、７０４、７０６の１つを通って更に特定のポートフォリオ内の会社に行き当たるまで穴を掘り下げてゆけば、コンテクスト情報は穴を開ける都度累積されていくので、当該会社の最終的なビューは特定のファンド又はポートフォリオに対する関係で生成されることになる。その情報にはそのファンドにより保有される会社の株式の量や、会社の株主である期間、その他が含まれる。
【０１２２】
図１６の各ワームホールに表現されているシーンは、関数に対する引数に類似した方法で、company＿IDでパラメータ化される。本例では、シーンそれ自体がユーザが何の会社を見ているかを特定する引数を有しており、当該シーンは従ってカスタマイズされる。従って、ユーザがこれらのワームホールの何れかを通して見るときには、シーンはユーザが見ている特定のワームホール独自の姿をしているので、そのシーンは違って見える。
【０１２３】
先に述べたように、本システムは、プログラミングの専門知識無しに、データのダイナミック・ビューを提供する。従って、ユーザは、アプリケーション開発時間が短縮されるようにデータに近づくことができる。ユーザ・インタフェースは、情報豊富なデータベースに関して、そしてデータウェア・ハウジングとデシジョンサポートのようなアプリケーションに関して素早く容易に生成できる。更に、従来型のフォームベース若しくはレポートベースのアプリケーションについてまわる制限は回避される。
【０１２４】
その上、ここに説明した技法は、ハードウェア又はソフトウェアで実行してもよいし、或いは両方を組み合わせて実行してもよい。この技法は、１台毎にプロセッサと、プロセッサが読み込み可能な記憶媒体（揮発性、非揮発性メモリー及び／又は記憶素子を含む）と、適切な入出力装置とを含んでいる、プログラム可能なコンピュータ上で実行するコンピュータ・プログラムで実行するのが望ましい。プログラムコードは、入力機器を使用して入力されるデータに適用され、記述済みの関数を実行し、出力情報を生成する。出力情報は、１つ又はそれ以上の出力装置に適用される。
【０１２５】
各プログラムは、コンピュータシステムと通信するために、高レベルの手続言語又はオブジェクト指向プログラム言語で実行することが望ましい。しかしながら、本プログラムは、必要に応じアセンブリ言語又は機械語で実行されることもできる。何れの場合でも、言語はコンパイル又はインタプリタで翻訳された言語である。
【０１２６】
このような各コンピュータ・プログラムは、上記手続きを実行するためにコンピュータが読み込めば構成され、そして作動できるような、汎用或は特殊用途のプログラム可能なコンピュータが読み出すことのできる記憶媒体若しくは記憶装置（例；ＣＤ−ＲＯＭ、ハードディスク、又は磁気ディスケット）に記憶されることが望ましい。本システムはまた、コンピュータ・プログラムにより構成された、コンピュータが読み出し可能な記憶媒体としても実行できるが、その場合には、そのように構成された記憶媒体がコンピュータを特定且つ事前に指定された方法で作動させることになる。
【０１２７】
他の実施例は、先の請求項の範囲にある。
【図面の簡単な説明】
【図１】１つ又はそれ以上のワールドを編集するための、多文書インタフェースである。
【図２】オブジェクト・インスペクタを示す図である。
【図３】アブストラクトベースクラスVcPropertyBagのプロパティオブジェクトモデルを示す図である。
【図４】２バイトコード実行クラスである、VCStmtCreatShape及びVcStmtSetPropertyを示す図である。
【図５】サンプル構文解析型プロパティ関数を示す図である。
【図６】シーンからのコード生成プロセスのオブジェクトモデルを示す図である。
【図７】プロパティシート入力プロセスを示すフローチャートである。
【図８】オブジェクトを目に見えるように操作するためのプロセスを示すフローチャートである。
【図９】バイトコード生成用のプロセスを示すフローチャートである。
【図１０】ノード向けのバイトコード実行ステートメントを入手するためのプロセスを示すフローチャートである。
【図１１】バイトコードを実行するためのプロセスを示すフローチャートである。
【図１２】グラフ編集システムを示す図である。
【図１３】ワームホールを示す図である。
【図１４】ワームホールのオブジェクトモデルを示す図である。
【図１５】ワームホール使用法の１例を示す図である。
【図１６】ワームホール使用法の別の例を示す図である。
【符号の説明】
１０  ワールド・マネージャー・ウィンドウ
１２，１４，１６，４０  コントロール・バー
１８  ツリー・コントロール
２０  プロジェクト作業空間
２２  エディタ・ウィンドウ
２４  出力ウィンドウ
３０  オブジェクト・インスペクタ
１００  名前列
１１０  プロパティ列
１１２，１１４，１１６，１１８，１２０，１２２，１２４，１２６  プロパティ
２００  VcPropertyBag
２０２，４００，５００  VcScene
２０４，４０２，５０４  VcDrawingNode
２１０  VcProperty
２１２，２１８，３００，３２２  CString
２１４，３２４  VcPropertyPath
２１６，２２２  VcPropertyValue
２２０  VcFunction
３０２  バイトコード
３０４  VcShapeFactory
３０６  VcShape
３１０  疑似コードブロック
３２０  VcStmtSetProperty
３２６  VcStmtSetStringProperty
３２８  VcSftn
３３０  ３２６のバイトコード
３５０  VcStmtSetStringProperty関数
３５２  テキスト１
３５４  ３５０のプロパティ経路値
３６０，３６２  VcSftnConcatenate
３６４，３８０  VcSftnLookup関数
３６６，３７２  文字列
３７０  VcSftnConcatenate関数
４０４，５０６  VcShapeNode
４０６  VcDataNode
４０８，５１０  VcLogicNode
４１０  VcCGMethod，VcDataSource
４１２  VcQueryDataSource
４１４  VcQuery
４１６  VcColumn
４１７，５０２  VcParameter
４２０ VcStmt
４２２，４２４，４２６，４２８，４３０  バイトコード・ステートメント
４８０  シーン・グラフ
４８２，４８４  ビュー
４８５  画像
４８６  ウィンドウ
４９０、７０２、７０４、７０６  ワーム・ホール
４９２，４９４  シーン
４９６，４９８  高度
５０８  VcWormholeNode
５１２  VcWormholeSettingNode
７００  ポートフォリオリスク管理ワーム・ホール
７０８  チャート
７１０  市場データ・ワーム・ホール
７２０  考慮中の投資ワーム・ホール
７３０  ファースト・コール・アナリスト推薦ワーム・ホール
【誤訳訂正２】
【訂正対象書類名】図面
【訂正対象項目名】図７
【訂正方法】変更
【訂正の内容】
【図７】
2000163490.tif 000005
【誤訳訂正３】
【訂正対象書類名】図面
【訂正対象項目名】図８
【訂正方法】変更
【訂正の内容】
【図８】
2000163490.tif 000006
【誤訳訂正４】
【訂正対象書類名】図面
【訂正対象項目名】図９
【訂正方法】変更
【訂正の内容】
【図９】
2000163490.tif 000007
【誤訳訂正５】
【訂正対象書類名】図面
【訂正対象項目名】図１０
【訂正方法】変更
【訂正の内容】
【図１０】
2000163490.tif 000008
【誤訳訂正６】
【訂正対象書類名】図面
【訂正対象項目名】図１１
【訂正方法】変更
【訂正の内容】
【図１１】
2000163490.tif 000009