JP2016522476A - 再計算ユーザインタフェースにおける変換の編さん - Google Patents

Abstract

変換チェーンの１つ以上の結果表示を含む電子キャンバスを表示する、再計算ユーザインタフェースの変換チェーンの編さん。変換チェーンは、それぞれのデータソースとデータシンクとの間の変換を含む。再計算ユーザインタフェースをユーザが編集することにより、変換の１つ又は複数が再び実行されることになり、これにより再計算が生じる。編さんは、再計算ユーザインタフェースの変換チェーンを依存関係について分析し、エンティティ間の依存関係の依存関係グラフを作成することを含む。例えばある依存関係は、エンティティ間について、一方のエンティティが評価されるかどうか、次いで他方のエンティティも評価すべきかどうかを示すものであってよい。依存関係グラフは、次いで低レベルの実行ステップを作成するのに使用される。依存関係グラフは更に、プログラムのランタイムに提供され、これにより依存関係グラフを、再計算ユーザインタフェースの操作中に利用可能にすることができる。

Description

「再計算ドキュメント」は、様々なデータソース及びデータシンク（data sink）を示す電子ドキュメントであり、データソースとデータシンクとの間の宣言的変換（declarative transformation）を可能にする。様々なデータソース及びデータシンクを相互接続する変換の任意の所与のセットについて、データソースの出力は、データシンクによって使用されるか、あるいはデータソースの出力は、データシンクにより消費されることに先行して、変換の対象となり得る。これらの様々な変換を評価することで、再計算ドキュメントを通して表される１つ以上の出力が得られる。

ユーザは、コーディングについて詳細な知識を有する必要なく、宣言的変換を追加し、編集することができる。そのような編集により、自動的に変換が再計算されることになり、出力における変更が生じることになる。

再計算ドキュメントの具体的な例は、セルのグリッドを含む表計算ドキュメントである。任意の所与のセルは、セル内に表示される特定の値を出力するために評価される式（expression）を含み得る。式は、１つ以上の他のセル又は値といったデータソースを参照し得る。

本明細書で説明される少なくとも一部の実施形態は、再計算ユーザインタフェースの変換チェーンの編さん（compilation）に関する。変換チェーンは、それぞれのデータソースとデータシンクとの間の宣言的変換を含む。例えば表計算のコンテキストでは、データシンクは特定の表計算のセルであってよく、変換は、その特定のセルに関連付けられる式であってよく、データソースは、その式で参照される１つ以上の他のセル又は特定の値であってよい。再計算ユーザインタフェースのユーザの編集は、そのような変換のうちの１つ又は複数を再び実行させる可能性があり、これにより再計算が生じることになる。

編さんは、再計算ユーザインタフェースの変換チェーンを、依存関係について分析して、エンティティ間の依存関係の依存関係グラフを作成することを含む。例えば一部の依存関係は、エンティティ間について、一方のエンティティが評価されるかどうか、次いで他方のエンティティも評価すべきかどうかを示すものであってよい。他の依存関係グラフは、ユーザイベントを指定することがあり、このエンティティの評価はこのユーザイベントに依存する。依存関係グラフは、次いで低レベルの実行ステップを作成するのに使用される。依存関係グラフは更に、プログラムのランタイムに提供され、これにより依存関係グラフを、再計算ユーザインタフェースの操作中に利用可能にすることができる。

この「発明の概要」における記載は、特許請求に係る主題の主要な特徴又は本質的特徴を特定するようには意図されておらず、また特許請求に係る主題の範囲を確定する助けとして使用されるようにも意図されていない。

上記及び他の利点及び特徴が得られる方法を説明するために、様々な実施形態のより具体的な説明が、添付の図面の参照により提示される。これらの図面は単に例示の実施形態を示しており、したがって、本発明の範囲を限定するようには見なされないという理解の下に、添付の図面の使用を通して追加の仕様及び詳細とともに本発明を記載し、説明することにする。
本明細書で説明される一部の実施形態が使用され得るコンピューティングシステムを抽象的に示す図である。 数例のデータソースとデータシンクを介在する変換とともに例示し、本明細書で説明される広範な原理を説明するのに提供される具体的な例として使用される、例示の再計算ユーザインタフェースを抽象的に示す図である。 変換チェーンにアクセスし、編さん済みコード及び依存関係のチェーンを生成するコンパイラを含む、例示の編さん環境を示す図である。 再計算ユーザインタフェースの変換チェーンを編さんするための方法のフローチャートである。 入力データに依存するビュー構成を構築するデータ駆動構成フレームワークを含め、本発明の原理が使用され得る環境を示す図である。 図５の環境の一例を表すパイプライン環境を示す図である。 図６のパイプラインのデータ部分の実施形態を概略的に示す図である。 図６のパイプラインの分析部分の実施形態を概略的に示す図である。 図６のパイプラインのビュー部分の実施形態を概略的に示す図である。

本明細書で説明される少なくとも一部の実施形態は、再計算ユーザインタフェースの変換チェーンの編さんに関する。再計算ユーザインタフェースは、例えば表計算のような再計算ドキュメントであり得る。しかしながら、再計算ユーザインタフェースは、変換チェーンの１つ以上の結果表示を含む、任意の表示される電子キャンバスであってよい。変換チェーンは、それぞれのデータソースとデータシンクとの間の複数の宣言的変換を含む。再計算ユーザインタフェースのユーザ編集は、そのような変換のうちの１つ又は複数を再び実行させる可能性があり、これにより再計算が生じることになる。

編さんは、再計算ユーザインタフェースの変換チェーンを、依存関係について分析し、エンティティ間の依存関係の依存関係グラフを作成することを含む。例えば一部の依存関係は、エンティティ間について、一方のエンティティが評価されるかどうか、次いで他方のエンティティも評価すべきかどうかを示すものであってよい。依存関係グラフは、次いで低レベルの実行ステップを作成するのに使用される。依存関係グラフは更に、プログラムのランタイムに提供され、これにより依存関係グラフを、再計算ユーザインタフェースの操作中に利用可能にすることができる。

コンピューティングシステムの導入的議論は、図１に関連して説明される。次に、再計算ユーザインタフェースの変換チェーンの編さんについて、後続の図面に関連して説明する。

コンピューティングシステムは、現在ますます、多様な形式をとるようになっている。コンピューティングシステムは、例えばハンドヘルドデバイス、機器、ラップトップコンピュータ、デスクトップコンピュータ、メインフレーム、分散コンピューティングシステムであってよく、あるいは従来的にはコンピューティングシステムとは考えられていなかったデバイスでもよい。この説明及び特許請求の範囲において、「コンピューティングシステム」という用語は、少なくとも１つの物理的な有形のプロセッサと、該プロセッサによって実行可能なコンピュータ実行可能命令を有することができる物理的な有形のメモリとを含む、任意のデバイス又はシステムを含むものとして広く定義される。メモリは、任意の形式をとってよく、コンピューティングシステムの性質及び形状に依存し得る。コンピューティングシステムは、ネットワーク環境において分散されることがあり、複数の構成コンピューティングシステムを含み得る。

図１に図示されるように、そのほとんどの基本的構成において、コンピューティングシステム１００は、典型的に、少なくとも１つの処理ユニット１０２とメモリ１０４を含む。メモリ１０４は、物理的なシステムメモリであってよく、揮発性、不揮発性又はその双方の何らかの組合せであってよい。本明細書において、「メモリ」という用語は、物理的な記憶媒体のような不揮発性の大容量ストレージを指すのに使用されてもよい。コンピューティングシステムが分散される場合、処理、メモリ及び／又は記憶機能も分散され得る。本明細書で使用されるとき、「実行可能モジュール」又は「実行可能コンポーネント」という用語は、ソフトウェアオブジェクト、ルーチン又はコンピューティングシステムにおいて実行され得るメソッドを指す可能性がある。本明細書で説明される異なるコンポーネント、モジュール、エンジン及びサービスは、コンピューティングシステム上で実行するオブジェクト又はプロセスとして（例えば別個のスレッドとして）実装され得る。

以下の説明では、実施形態は、１つ以上のコンピューティングシステムによって実行される動作との関連で説明される。そのような動作がソフトウェアで実装される場合、その動作を実行する関連するコンピューティングシステムの１つ以上のプロセッサは、コンピュータ実行可能命令が実行されたことに応答して、コンピューティングシステムの動作を指示する。例えばそのようなコンピュータ実行可能命令は、コンピュータプログラム製品を形成する１つ以上のコンピュータ読取可能媒体上で具現化され得る。そのような動作の例は、データの操作を含む。コンピュータ実行可能命令（及び操作されたデータ）は、コンピューティングシステム１００のメモリ１０４内に格納され得る。コンピューティングシステム１００は通信チャネル１０８も含むことがあり、通信チャネル１０８は、コンピューティングシステム１００が、例えばネットワーク１１０を経由して、他のメッセージプロセッサと通信することを可能にする。コンピューティングシステム１００は、ユーザに視覚表現を表示するのに使用され得るディスプレイ１１２も含む。

本明細書で説明される実施形態は、コンピュータハードウェア、例えば以下で詳細に説明されるような１つ以上のプロセッサ及びシステムメモリ等を含む、専用又は汎用のコンピュータを備えるか、これを用いることができる。本明細書で説明される実施形態は、コンピュータ実行可能命令及び／又はデータ構造を担持又は格納するための物理的な他のコンピュータ読取可能媒体も含む。そのようなコンピュータ読取可能媒体は、汎用又は専用のコンピュータシステムによってアクセス可能な任意の利用可能な媒体とすることができる。コンピュータ実行可能命令を格納するコンピュータ読取可能媒体は、物理的な記憶媒体である。コンピュータ実行可能命令を担持するコンピュータ読取可能媒体は、伝送媒体である。したがって、限定ではなく例として、本発明の実施形態は、少なくとも２つの明確に異なる種類のコンピュータ読取可能媒体、すなわちコンピュータ記憶媒体とコンピュータ伝送媒体とを含むことができる。

コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ又は他の光ディスクストレージ、磁気ディスク又は他の磁気記憶デバイス、あるいはコンピュータ実行可能命令又はデータ構造の形式で所望のプログラムコード手段を格納するのに使用することができ、かつ汎用又は専用のコンピュータによってアクセス可能な任意の他の有形の媒体を含む。

「ネットワーク」は、コンピュータシステム及び／又はモジュール及び／又は他の電子デバイスの間の電子データの移送を可能にする、１つ以上のデータリンクとして定義される。ネットワーク又は別の通信接続（ハードウェワイヤード、無線又はハードワイヤードと無線の組合せのいずれか）経由で情報がコンピュータに転送又は提供されるとき、そのコンピュータは適切に、その接続を伝送媒体として見る。伝送媒体は、コンピュータ実行可能命令又はデータ構造の形の所望のプログラムコード手段を担持するのに使用することができ、かつ汎用又は専用のコンピュータによってアクセス可能なネットワーク及び／又はデータリンクを含むことができる。上記の組合せもコンピュータ読取可能媒体の範囲に含まれるべきである。

さらに、様々なコンピュータシステムコンポーネントに到達すると、コンピュータ実行可能命令又はデータ構造の形のプログラムコード手段を、伝送媒体からコンピュータ記憶媒体へ（又はその反対に）自動的に転送することができる。例えばネットワーク又はデータリンクを介して受け取ったコンピュータ実行可能命令又はデータ構造を、ネットワークインタフェースモジュール（例えば「ＮＩＣ」）内のＲＡＭにバッファすることができ、そして最終的に、コンピュータシステムＲＡＭへ、かつ／又はコンピュータシステム上の低揮発性のコンピュータ記憶媒体へ転送することができる。したがって、コンピュータ記憶媒体を、伝送媒体も（あるいは主として）使用するコンピュータシステムコンポーネントに含めることができることを理解されたい。

コンピュータ実行可能命令は、例えばプロセッサによって実行されると、汎用コンピュータ、専用コンピュータ又は専用の処理デバイスに、特定の機能又は機能のグループを実行させる命令及びデータを備える。コンピュータ実行可能命令は、例えばバイナリ、アセンブリ言語のような中間フォーマットの命令又はソースコードでもよい。本主題を、構造的特徴及び／又は方法の動作に特有の言語で説明しているが、理解されるように、添付の特許請求の範囲において定義される主題は、必ずしも説明される特徴又は上述の動作に限定されない。むしろ、説明される特徴及び動作は、特許請求の範囲を実装する例示の形式として開示される。

当業者は、本発明が、多くのタイプのコンピュータシステム構成を有するネットワークコンピューティング環境で実施されてもよいことを認識するであろう。そのようなコンピューティング環境には、パーソナルコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、メッセージプロセッサ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベース又はプログラム可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、モバイル電話、ＰＤＡ、ページャ、ルータ、スイッチ等が含まれる。本発明は、ネットワークを介して（ハードワイヤードデータリンク、無線データリンク又はハードワイヤードと無線データリンクの組合せのいずれかにより）リンクされるローカル及びリモートのコンピュータシステムの双方がタスクを実行する、分散システム環境で実施されてもよい。分散システム環境では、プログラムモジュールを、ローカルとリモートのメモリ記憶デバイスの双方に配置してもよい。

この説明及び特許請求の範囲において、「再計算ユーザインタフェース」とは、ユーザが対話することができ、かつ１つ以上のデータソースと１つ以上のデータシンクとが存在する環境内で生じるインタフェースである。さらに、１つ以上のデータソースと１つのデータシンクとの間で各々宣言的に定義され得る変換のセットも存在する。例えば１つのデータソースの出力が変換に供給され、その変換からの結果がデータシンクに提供され、これにより、潜在的に、ユーザに対する視覚表現において何らかの種類の変化が生じることになる。

変換は、ユーザが、具体的なコーディングの知識なしに、変換を定義する宣言を書くことができるという意味で「宣言的」である。変換が宣言的に定義されるので、ユーザは宣言的変換を変更することができる。これに応じて、再計算が実行され、その結果、恐らくは異なるデータがデータシンクに提供されることになる。

再計算ユーザインタフェースの代表的な例は、表計算ドキュメントである。表計算ドキュメントは、セルのグリッドを含む。最初はセルが空であり、したがって、表計算プログラムの任意のセルは、ユーザによって入力される宣言的な式の意味及びコンテキストに応じて、データソース又はデータシンクになる潜在性を有する。例えばユーザは所与のセルを選択し、そのセルに式をタイプする可能性がある。その式は、セルに割り当てられる、できるだけ簡単な式で表されるスカラ値とすることができる。そのセルは、後にデータソースとして使用され得る。あるいは、所与のセルの式は、入力値が１つ以上の他のセルから得られる数式（equation）の形式であってよい。この場合、所与のセルは、変換の結果を表示するデータシンクである。しかしながら、連続的な作成の間、そのセルは、作成者によって宣言的に作成される更に他の変換のデータシンクとして使用されてもよい。

表計算ドキュメントの作成者は、命令コードの専門家である必要はない。作成者は単に、変換を定義する宣言を作成し、対応するデータシンク及びデータソースを選択する。以下で説明される図５乃至図９は、より一般的な宣言的作成環境を提供しており、この環境において、より一般的な再計算ユーザインタフェースについて説明される。後述の環境では、視覚的なコントロールが、データソースとデータシンクの双方として機能することができる。さらに、宣言的変換は、これらのコントロールの簡単な操作によって、より直感的に作成され得る。

図２は、例示の再計算ユーザインタフェース２００を抽象的に示しており、この再計算ユーザインタフェース２００は、本明細書で説明される広範な原理を説明するために提供される具体的な例である。本明細書で説明される原理は、無数のアプリケーションのための無数の再計算ユーザインタフェースを作成するよう、任意の再計算ユーザインタフェースに適用され得るので、再計算ユーザインタフェース２００は単なる例示である。

再計算ユーザインタフェース２００は、数個の宣言的変換２１１〜２１５を含む。変換２１１〜２１６を表す各矢印の周囲の破線の円は、その変換が、それぞれ宣言的形式であることを表している。

この図２の具体的な例では、変換２１１は、それぞれのデータソース２０１とデータシンク２０２を含む。ある変換にとってのデータシンクは、別の変換にとってのデータソースでもあり得ることに留意されたい。例えば変換２１１にとってのデータシンク２０２は、変換２１２にとってのデータソースとしても機能する。さらに、変換は複数のデータソースを有することがある。したがって、変換チェーンは階層的に作成されるため、かなり複雑である可能性がある。例えば変換２１２は、データソース２０２とデータシンク２０３を含む。データシンク２０３は２つのデータソース、すなわち変換２１２用のデータソース２０２と、変換２１４用のデータソース２０５を含む。しかし、恐らくは単一の変換が、２つのデータソース２０２及び２０５をデータシンク２０３に導く。変換２１３は、データソース２０４とデータシンク２０５を含む。

再計算ユーザインタフェースが表計算ドキュメントであった場合、例えば様々なデータソース／シンク２０１〜２０５は表計算のセルである可能性があり、この場合、変換は各データシンクに関連付けられる式を表す。各式の出力がセル内に表示される。したがって、表計算の場合、データソース／シンクは、変換チェーンへの入力パラメータと、変換チェーンからの出力パラメータの双方を含んだ、複雑な視覚的コントロールである可能性がある。例えば図２では、データソース２０５からデータシンク２０１につながる追加の宣言的変換２１５がある。したがって、データソース／シンク２０１は、変換２１５からの出力を表す情報を視覚化し、他のデータシンクに更なるデータを提供し得る。

再計算ユーザインタフェースは視覚的コントロールを有する必要はない。この一例は、変換に基づく計算を実行するよう意図された再計算ユーザインタフェースであり、これは、ソースデータを使用してシンクデータを更新し、通常の場合の計算に関してユーザに対して表示される情報はない。例えば再計算ユーザインタフェースは、バックグラウンドでの計算をサポートし得る。第２の例は、処理コントロールの例におけるバルブ（valve）のような、外部アクチュエータを操作する出力コントロールを有する再計算ユーザインタフェースである。そのようなコントロールは、これらの状態が変換計算の結果によって、信号入力に対して制御されるという点でディスプレイコントロールに類似する。しかしながら、ここでは、出力は、ディスプレイへの視覚化ではなく、デバイスへの制御信号である。例えばロボットを制御するための再計算ユーザインタフェースを考える。この再計算ユーザインタフェースは、サーボ位置及びスピード、超音波の範囲発見測定等のような入力ロボットセンサに応じた、ロボットのアクション及び挙動についてのルールを有する可能性がある。あるいは、バルブ位置や流体流速等のような装置センサからの信号を得る再計算ユーザインタフェースに基づく処理制御アプリケーションを考える。

図３は、例示の編さん環境３００を図示しており、編さん環境３００は、変換チェーン３０１にアクセスするコンパイラ３１０を含む。変換チェーン３０１の例は、図２の変換チェーン２００である。図４は、再計算ユーザインタフェースの変換チェーンを編さんする方法４００のフローチャートを図示している。方法４００は、図３のコンパイラ３１０によって実行され得る。一実施形態において、方法４００は、プロセッサ１０２が、１つ以上のコンピュータ読取可能記憶媒体上で具現化されるコンピュータ実行可能命令を実行することに応答して、コンピューティングシステム１００により実行され得る。

方法４００は、再計算インタフェースの変換チェーンを、依存関係について分析することを含む（動作４０１）。例えば図２を参照すると、コンパイラ３１０は、変換２１１〜２１５までの各々を分析し得る。変換は宣言的であるので、変換が命令的コンピュータ言語を使用して表現されていた場合に依存関係を抽出する場合よりも、より容易にその依存関係を抽出することができる。

分析に基づいて、変換において参照されるエンティティ間の依存関係グラフが作成される（動作４０２）。本質的に、依存関係は、イベントを表すソースエンティティと、ターゲットエンティティとを有し、ターゲットエンティティは、当該ターゲットエンティティの評価がそのイベントに依存することを表す。イベントの例は、ユーザが、再計算ユーザインタフェースと特定の方法で対話するユーザイベントであり得る。別の例として、イベントは、ソースエンティティが評価される場合に、依存関係にあるターゲットイベントも評価する必要があるエンティティ間イベントであり得る。

コンパイラは、次いで、依存関係グラフに基づいて低レベルの実行ステップを作成する（動作４０３）。低レベルの実行ステップは、例えば命令的言語コードとすることができる。命令的実行コードは、イベントを検出し、イベントチャートを参照して実行すべき関数を決定し、その関数を実行するように応答するよう適合される。したがって、依存関係グラフ内の依存関係の各々は、関数へと低減され得る。依存関係グラフ自体は、ランタイムに対して提供され得る（動作４０４）。命令的言語コードは、例えばJAVASCRIPT（登録商標）といったスクリプト言語とすることができる。しかしながら、本明細書で説明される原理は、任意の特定の言語である命令的言語コードに限定されない。

例として、図３は、コンパイラ３１０が低レベルのコード３１１を生成することも図示している。そのような低レベルのコード３１１は、変換チェーン内の変換の各々の編さんを含む。例えば低レベルのコード３１１は、変換チェーン内の変換の各々の編さんを表す要素３２１を含むように図示されている。図２のコンテキストにおいて、要素３２１は、変換２１１〜２１５の各々の編さんを含むことがある。低レベルのコード３１１は、様々な関数３２２も含む。関数は依存関係グラフ内の各依存関係について生成される。関数は、命令的言語の関数であってよい。

命令的言語のランタイムが、依存関係グラフ内にリストされるイベントを検出すると、編さん済み関数３２２内の対応する関数も実行される。したがって、全ての変換が正確に編さんされ、特定のイベントに対する依存関係の各々が専用の関数によって実施されることで、宣言的再計算ユーザインタフェースは、命令的言語コードとして正確に表される。

したがって、宣言的再計算ユーザインタフェースを編さんするための効果的な機構が説明される。加えて、ランタイムには、より大規模なインタプリタではなく依存関係グラフが提供される。

再計算ユーザインタフェースを使用する複雑な挙動を有するプログラムを非プログラマが作成するのを可能にする作成パイプラインの具体的な例を、次に図５乃至図９に関連して説明する。

図５は、再計算ユーザインタフェースの形で対話的な視覚的構成を構築するのに使用される視覚的構成環境５００を図示している。再計算ユーザインタフェースの構築は、データ駆動分析及び分析結果の視覚化を使用して行われる。環境５００は、ビュー構成５３０の問題領域とは独立に実行されるロジックを実行する、構成フレームワーク５１０を含む。例えば同じ構成フレームワーク５１０は、都市計画、分子模型、日用品棚のレイアウト、機械性能若しくは組立分析又は他の領域特有のレンダリングについての対話的なビュー構成を構成するのに使用され得る。

しかしながら、構成フレームワーク５１０は、領域特有のデータ５２０を使用して、領域に特有の実際の視覚的構成５３０を構築する。したがって、構成フレームワーク５１０自体を再コーディングするのではなく、領域特有のデータ５２０を変更することによって、同じ構成フレームワーク５１０を、任意の数の異なる領域のための再計算ユーザインタフェースに対して使用することができる。したがって、パイプライン５００は、再コーディング及び再編さんするのではなく、データを変化させることにより、潜在的には無制限の数の問題領域に適用され、あるいは、少なくとも多数の問題領域に適用され得る。ビュー構成５３０はその後、命令として、適切な２Ｄ又は３Ｄレンダリングモジュールへ供給され得る。本明細書で説明されるアーキテクチャは、構築ブロックとして既存のビュー構成モデルの新たなビュー構成モデルへの便利な組み込みも可能にする。一実施形態では、複数のビュー構成が、一体的なビュー構成に含まれてもよく、モデルに対する２つの可能性ある解決策の容易な比較を可能にする。

図６は、パイプライン環境６００の形式で構成フレームワーク５１０の例示のアーキテクチャを図示している。パイプライン環境６００は、他の中でも特に、パイプライン６０１自体を含む。パイプライン６０１は、データ部分６１０、分析部分６２０及びビュー部分６３０を含む。これらの部分は、それぞれ後続の図７乃至図９及び関連する説明に関連して詳細に説明される。差し当たり、一般的なレベルでは、パイプライン６０１のデータ部分６１０は、様々なタイプの多様なデータを受け取ることがあり、そのデータを正規形式（canonical form）で、パイプライン６０１の分析部分６２０に提示する。分析部分６２０は、そのデータを、様々なモデルパラメータにバインドし、モデル分析を使用して、モデルパラメータにおける未知数の値を求める。次いで、様々なパラメータ値がビュー部分６３０に提供され、ビュー部分６３０は、モデルパラメータの場合、これらの値を使用して構成ビューを構築する。

パイプライン環境６００は、作成コンポーネント６４０も含み、作成コンポーネント６４０は、パイプライン６０１の作成者又は他のユーザが、パイプライン６０１へ提供するデータを定式化し、かつ／又は選択できるようにする。例えば作成コンポーネント６４０を使用して、データを（入力データ６１１によって表される）データ部分６１０、（分析データ６２１によって表される）分析部分６２０及び（ビューデータ６３１によって表される）ビュー部分６３０の各々に供給し得る。様々なデータ６１１、６２１及び６３１は、図５の領域特有のデータ５２０の例を表し、以下で更に詳細に説明される。作成コンポーネント６４０は、広範なデータの提供をサポートする。そのようなデータには、例えばデータスキーマ、モデルによって使用される実際のデータ又は外部ソースからもたらされるデータの位置又は可能性のある位置の範囲、視覚的（グラフィカル又はアニメーションの）オブジェクト、視覚表現に対して実行され得るユーザインタフェース上の対話、モデル化ステートメント（例えビュー、式、定数）、バインド等が含まれる。一実施形態において、作成コンポーネントは、（図６には図示されないが、図５の構成フレームワーク５１０によって表される）マネージャコンポーネントによって提供される機能の一部にすぎない。マネージャは、（ユーザ対話イベントや外部データイベント、ソルバ、オペレーティングシステム等といった他のコンポーネントのいずれかからのイベントといった）イベントに応じて、全ての他のコンポーネント（データコネクタ、ソルバ、ビューア等）の動作を制御して順序付ける全体的なディレクタである。

図６のパイプライン環境６００では、作成コンポーネント６４０は、既存のパイプライン６０１にデータを提供するのに使用され、ここで、このデータは、入力データを定義することから、（上記で「変換チェーンと呼ばれる」）分析モデルを定義し、変換チェーンの結果をビュー構成内でどのように視覚化するかについて定義することまでにわたる全体的な処理を駆動するデータである。したがって、パイプライン６０１を多様な領域及び問題のいずれか１つに適合させるために、いずれのコーディングも実行する必要がない。パイプライン６０１に提供されるデータは、パイプライン６０１を適用して異なる問題領域全体のいずれかから異なるビュー構成を視覚化するか、恐らくは既存の領域の値を求める問題を調整するために変更すべきもののみである。さらに、データを使用時間（すなわち、ランタイム）並びに作成時間に変更することができるので、モデルをランタイム時に修正及び／又は拡張することができる。したがって、モデルを作成することと、モデルを実行することとの間には、存在する場合であっても、あまり差異はない。全て作成することは、データアイテムを編集することを含み、ソフトウェアは、データからのその挙動の全てを実行するので、データに対する全ての変更は、再コーディング及び再コンパイルする必要なく挙動に影響を与える。

パイプライン環境６００は、ユーザ対話応答モジュール６５０も含む。ユーザ対話応答モジュール６５０は、ユーザが、表示されたビュー構成と対話している時を検出し、次いで、応答として何をすべきかを決定する。例えばあるタイプの対話は、パイプライン６０１に提供されたデータにおける変更を必要とせず、したがって、ビュー構成に対する変更も必要としない可能性がある。他のタイプの対話は、データ６１１、６２１、６３１のうちの１又は複数を変更することがある。この場合、この新しい、すなわち修正されたデータにより、新しい入力データが、データ部分６１０に提供されることになり、分析部分６２０による入力データの再分析が必要になるか、かつ／又はビュー部分６３０によるビュー構成の再視覚化が必要になる可能性がある。

したがって、パイプライン６０１を使用して、データ駆動分析の視覚化を、恐らくは無制限の数の問題領域まで、あるいは少なくとも様々な問題領域まで拡張することができる。さらに、様々な問題に対処するようビュー構成を変更するためにプログラマであることは必要とされない。次に、パイプライン６００のデータ部分６１０、分析部分６２０及びビュー部分６３０の各々を、それぞれ図７のデータ部分７００、図８の分析部分８００及び図９のビュー部分９００に関連してこの順序で説明する。図７乃至図９から明らかになるように、パイプライン６０１は、一連の変換コンポーネントとして構築されてよく、この場合、それぞれが、１）何らかの適切な入力データを受け取り、２）その入力データに応じて、何らかのアクションを実行し（例えば入力データに対する変換を実行すること等）、３）そして、次の変換コンポーネントへの入力データとして機能するデータを、出力する。

図７は、図６のパイプライン６０１のデータ部分７００の多くの可能性のある実施形態のうちの１つのみを図示している。データ部分７００の機能の１つは、データを、図８に関連して検討されるパイプラインの分析部分８００によって理解されるスキーマと互換性のある正規フォーマットで提供することである。データ部分は、異種データ７０１にアクセスするデータアクセスコンポーネント７１０を含む。入力データ７０１は、このデータが、データアクセスコンポーネント７１０へ、正規形式で提示され得る（が、そうである必要はない）という意味で、「異種」であり得る。実際、データ部分７００は、異種データが多様なフォーマットとなり得るように構築される。モデルによってアクセスされ、かつ操作され得る異なる種類の領域データの例には、テキスト及びＸＭＬドキュメント、テーブル、リスト、階層（ツリー）、ＳＱＬデータベースのクエリ結果、ＢＩ（ビジネスインテリジェンス）キューブのクエリ結果、様々なフォーマットの２Ｄ描画及び３Ｄ視覚モデルのようなグラフィカル情報、並びにこれらの組合せ（すなわち、複合体（composite）が含まれる。さらに、アクセス可能なデータの種類は、アクセスされるデータの定義（例えばスキーマ）を与えることにより、宣言的に拡張することができる。したがって、データ部分７００は、モデルへの様々な異種の入力を許容し、またアクセス可能なデータ型のランタイムの宣言的拡張もサポートする。

一実施形態において、データアクセス部分７００は、複数の異なるデータソースからデータを取得するための複数のコネクタを含む。コネクタの主要な機能の１つは、対応するデータを正規形式にすることであるので、そのようなコネクタを下記及び図面では、しばしば「カノニカライザ（canonicalizer）」と呼ぶことがある。各カノニカライザは、対応するデータソースの特定のアプリケーションプログラムインタフェース（ＡＰＩ）の合意を有することがある。カノニカライザは、その対応するＡＰＩとインタフェースしてデータソースからデータを読み出し、かつ／又はデータソースへデータを書込むための対応するロジックも含むことがある。したがって、カノニカライザは、外部データソースと、データのメモリイメージとの間をブリッジする。

データアクセスコンポーネント７１０は、入力データ７０１を評価する。入力データが既に正規的であり、したがって、分析部分８００により処理可能である場合、入力データは、正規データ７４０として直接提供されて、分析部分８００に入力されてよい。

しかしながら、入力データ７０１が正規的でない場合、次いで適切なデータ正規化コンポーネント７３０が、入力データ７０１を正規フォーマットに変換することができる。データ正規化コンポーネント７３０は、実際には、各々が特定の特性を有する入力データを正規形式に変換することができる、データ正規化コンポーネントの集合７３０である。正規化コンポーネントの集合７３０は、４つの正規化コンポーネント７３１、７３２、７３３及び７３４を含むものとして図示されている。しかしながら、省略記号７３５は、他の数の正規化コンポーネントも存在し得ることを表しており、恐らくは図示される４つよりも少ない正規化コンポーネントが存在してもよい。

入力データ７０１は、カノニカライザ自体及び相関データ特性の識別情報も含むことがある。データ部分７００は、次いで、相関データ特性を登録し、正規化コンポーネントをデータ正規化コンポーネントの集合７３０に提供し、この場合、この正規化コンポーネントは、利用可能な正規化コンポーネントに追加され得る。後にこれらの相関特性を有する入力データを受け取ると、データ部分７１０は、この入力データを、相関された正規化コンポーネントに割り当てる。正規化コンポーネントを、外部ソース、例えばウェブ上の定義済みコンポーネントライブラリから動的に見つけることもできる。例えば所与のデータソースのスキーマは分かっているが、必要なカノニカライザが存在しない場合、このカノニカライザを、外部のコンポーネントライブラリから、（外部のコンポーネントライブラリを発見することができ、必要なコンポーネントを含む場合には）探すことができる。パイプラインは、スキーマがまだ分からないデータを解析し、解析結果を既知のコンポーネントライブラリ内のスキーマ情報と比較して、データのタイプの動的な決定を試みるとともに、必要なカノニカライザコンポーネントを探すこともできる。

あるいは、入力データが正規化コンポーネントの全てを含む代わりに、入力データは、正規化変換を定義する変換定義を提供してもよい。集合７３０は次いで、変換定義を、その変換をゼロ又はそれ以上の標準のデフォルトの正規化変換とともに実施する、対応する正規化コンポーネントへと変換するように構成され得る。これは、データ部分７００が入力データを使用するが、パイプラインの更に下方では対応する正規化データを提供しない場合の例を表す。しかしながら、恐らくほとんどの場合、入力データ７０１は、生成されている対応する正規化データになる。

一実施形態において、データ部分７１０は、入力データを、入力データのファイルタイプ及び／又はフォーマットタイプに基づいて、データ正規化コンポーネントに割り当てるように構成され得る。他の特性には、例えば入力データのソースが含まれ得る。デフォルトの正規化コンポーネントを、指定された対応する正規化コンポーネントを有していない入力データに割り当てることができる。デフォルトの正規化コンポーネントは、ルールのセットを適用して、入力データを正規化するよう試みることができる。デフォルトの正規化コンポーネントがデータを正規化することができない場合、デフォルトの正規化コンポーネントは、入力データのスキーマ定義を提供するようユーザを促すように、図５の作成コンポーネント５４０をトリガする。スキーマ定義がまだ存在していない場合、作成コンポーネント５４０は、スキーマ定義の補助（schema definition assistant）を提示して、作成者が、入力データを正規形式に変換するのに使用され得る対応するスキーマ定義を生成するのを助けることができる。データが正規形式であれば、データに付随するスキーマは、パイプライン６０１の残りの部分はデータを解釈するのに新たなコードを必要としないという旨の、そのデータについての十分な説明を提供する。代わりに、パイプライン６０１は、アクセス可能なスキーマの宣言的言語を表すことができる任意のスキーマの観点でデータを解釈することができるコードを含む。

いずれにしても、正規データ７４０は、データ部分７００からの出力データとして提供され、かつ分析部分８００への入力として提供される。正規データは、様々なデータ型を含むフィールドを含むことがある。例えばそのようなフィールドは、整数、浮動小数点数、文字列、ベクトル、配列、集合、階層構造、テキスト、ＸＭＬドキュメント、テーブル、リスト、ＳＱＬデータベースのクエリ結果、ＢＩ（ビジネスインテリジェンス）キューブのクエリ結果、様々なフォーマットの２Ｄ描画及び３Ｄ視覚モデルのようなグラフィカル情報、あるいはこれらの様々なデータ型の組合せといった、簡単なデータ型を含むことができる。別の利点として、正規化処理は、多様な入力データを正規化することができる。さらに、データ部分７００が受け入れることができる様々な入力データは拡張可能である。これは、本説明において後述されるように、複数のモデルを組み合わせる場合に有益である。

図８は、図６のパイプライン６０１の分析部分６２０の例を表す分析部分８００を図示している。データ部分７００は、正規化済みデータ８０１をデータモデル・バインドコンポーネント８１０に提供した。正規化済みデータ８０１は任意の正規化された形式及び任意の数のパラメータを有するが、この場合、パラメータの形式及び数は、入力データのある部分と別の部分で異なっていてもよい。しかしながら、説明の目的で、正規データ８０１は、フィールド８０２Ａ〜８０２Ｈを有するものとし、ここでは、まとめて「フィールド８０２」と呼ぶことがある。

一方、分析部分８００は、複数のモデルパラメータ８１１を含む。モデルパラメータのタイプ及び数は、モデルに応じて異なってよい。しかしながら、特定の例の説明の目的で、モデルパラメータ８１１は、モデルパラメータ８１１Ａ、８１１Ｂ、８１１Ｃ及び８１１Ｄを含むものとして説明することにする。一実施形態において、モデルパラメータの識別と、モデルパラメータ間の分析関係は、命令コードを使用することなく宣言的に定義され得る。

データモデル・バインドコンポーネント８１０は、正規化済みデータフィールド８０２と、モデルパラメータ８１１との間を取り持って、これにより、フィールド間のバインドを提供する。この場合、データフィールド８０２Ｂは、矢印８０３Ａによって示されるようにモデルパラメータ８１１Ａにバインドされる。言い換えると、データフィールド８０２Ｂからの値は、モデルパラメータ８１１Ａに追加するために使用される。また、この例では、データフィールド８０２Ｅが（矢印８０３Ｂによって示されるように）モデルパラメータ８１１Ｂにバインドされ、データフィールド８０２Ｈが（矢印８０３Ｃによって示されるように）モデルパラメータ８１１Ｃにバインドされる。

データフィールド８０２Ａ、８０２Ｃ、８０２Ｄ、８０２Ｆ及び８０２Ｇは、モデルパラメータのいずれにもバインドされるようには示されていない。これは、入力データからのデータフィールドの必ずしも全てが、モデルパラメータとして使用される必要はないことを強調するものである。一実施形態では、これらのデータフィールドのうちの１つ以上を使用して、正規化済みデータのどのフィールドを（この正規化済みデータのために、あるいは恐らくはいずれかの将来の同様の正規化データのために）どのモデルパラメータにバインドすべきかという指示を、データモデル・バインドコンポーネント８１０に提供することができる。これは、図６の分析部分６２０に提供され得る分析データ６２１の例示の種類を表す。正規化済みデータのどのデータフィールドを、どのモデルパラメータにバインドするかについての定義は、幾つかの方法で定式化され得る。例えばバインドは、１）作成時間に作成者により明示的に設定されるか、２）使用時間に使用者により（作成者により課されるいずれの制限の下で）明示的に設定されるか、３）アルゴリズムのヒューリスティックに基づいて作成コンポーネント６４０による自動的なバインドであるか、かつ／あるいは、４）アルゴリズム的にバインドを作ることができないと決定されたときに、バインドを指定するよう、作成者及び／又は使用者の再生コンポーネントにより促すもの、とすることができる。したがって、バインドを、モデルロジック自体の一部として決めることもできる。

どのデータフィールドをどのモデルパラメータにマップするかについて定義する作成者の能力は、作成者が使い易い記号を使用してモデルパラメータを定義することができるという点で、作成者に多大な柔軟性を与える。例えばモデルパラメータの１つが圧力を表すとき、作成者は、そのモデルパラメータに、「Pressure」又は「P」又は作成者にとって意味をなす任意の他の記号で名前を付けることができる。作成者は、モデルパラメータの名前を変更することもでき、一実施形態では、この名前の変更により、データモデル・バインドコンポーネント８１０は、以前は古い名前のモデルパラメータにバインドしていたものを、代わりに新しい名前のモデルパラメータにバインドするようにバインドを自動的に更新することが可能になり、これにより所望のバインドを保持することができる。バインドのためのこの機構は、バインドを、ランタイムに宣言的に変更することも可能にする。

モデルパラメータ８１１Ｄは、アスタリスを付けて図示されているが、これは、この例では、モデルパラメータ８１１Ｄが、データモデル・バインドコンポーネント８１０によって値を割り当てられなかったことを強調するものである。したがって、モデルパラメータ８１１Ｄは未知のままである。言い換えると、モデルパラメータ８１１Ｄには値を割り当てられない。

モデル化コンポーネント８２０は、幾つかの機能を実行する。まず、モデル化コンポーネント８２０は、モデルパラメータ８１１の間の分析関係８２１を定義する。分析関係８２１は、式８３１、ルール８３２及び制約８３３を含む３つの一般的なカテゴリに分類される。しかしながら、ソルバのリストは拡張可能である。一実施形態では、例えば対応するシミュレーションエンジンがソルバとして提供され、登録される場合に、１つ以上のシミュレーションを、提供される分析関係の一部として組み込んでよい。

本明細書で使用されるとき、「式」という用語は、数学の分野で使用される際の用語と一致する。

本明細書で使用されるとき、「ルール」という用語は条件文を意味し、この場合、１つ以上の条件（条件文の条件の部分、すなわち「if」の部分）が満たされる場合、１つ以上の動作（条件文の結果の部分、すなわち「then」の部分）がとられることになる。１つ以上のモデルパラメータが条件文内で表される場合、あるいは１つ以上モデルパラメータが結果の文内で表される場合、ルールがモデルパラメータに適用される。

本明細書で使用されるとき、「制約」という用語は、制限が１つ以上のモデルパラメータに適用されることを意味する。例えば都市計画モデルでは、特定の家の要素は、全体の可能性のある区画指定のサブセットを有する地図位置上の場所に制限され得る。ブリッジ（bridge）要素は、特定の最大長又は特定のレーン数未満になるように制限され得る。

モデルに精通している作成者は、そのモデルに適用されるこれらの式、ルール及び制約の式を提供することができる。シミュレーションの場合、作成者は、モデルパラメータの間の適切なシミュレーション関係を提供する適切なシミュレーションエンジンを提供し得る。モデル化コンポーネント８２０は、式、ルール及び制約について自然な記号式を提供するための機構を作成者に提供することができる。例えば熱力学に関連するモデルの作成者は、単に熱力学のテキストブックから式をコピーアンドペーストすればよい。モデルパラメータをデータフィールドにバインドする能力は、作成者が、その作成者が精通している（例えば作成者の信頼しているテキストブック内で使用されている的確な記号のような）どのような記号でも使用することを可能にし、あるいは、作成者が使用する傾向のある的確な記号を使用することを可能にする。

解を求める処理（solving）に先行して、モデル化コンポーネント８２０は、どのモデルパラメータの解を求めるべきか（すなわち、以下では単数の場合「出力モデル変数」、複数の場合は「複数のモデル変数」、単数又は複数の出力モデル変数が存在し得る場合は「出力モデル変数（複数可）」とする）についても識別する。複数の出力モデル変数が未知のパラメータであってよく、あるいは複数の出力モデル変数が既知のモデルパラメータである可能性もあり、この場合、既知のモデルパラメータの値は、解を求める操作（solve operation）において変わる可能性がある。図８の例では、データモデルのバインド操作の後、モデルパラメータ８１１Ａ、８１１Ｂ及び８１１Ｃは既知であり、モデルパラメータ８１１Ｄは未知である。したがって、未知のモデルパラメータ８１１Ｄは、出力モデル変数の１つとなり得る。あるいはまた、既知のモデルパラメータ８１１Ａ、８１１Ｂ及び８１１Ｃのうち１つ以上も出力モデル変数であってもよい。ソルバ８４０は次いで、可能な場合、出力モデル変数の値を求める。以下で説明される一実施形態において、ソルバ８４０は、様々な出力モデル変数の値を求めることができ、解を求める操作を実行することができるよう十分な入力モデル変数が提供される限り、単一のモデル内について求めることもできる。入力モデル変数は、例えばその値が、値を求める操作中に変更の対象とならない既知のモデルパラメータとすることができる。例えば図８において、モデルパラメータ８１１Ａ及び８１１Ｄが入力パラメータ変数であったとすると、ソルバは、代わりに、出力モデル変数８１１Ｂ及び８１１Ｃの値を求める可能性がある。一実施形態において、ソルバは、単一のモデルパラメータに対して複数の異なるデータ型のうちのいずれか１つを出力する可能性がある。例えば一部の式の操作（例えば加算、減算等）は、オペランドが整数であるか、浮動小数点であるか、同じもののベクトルであるか又は同じものの行列であるかに関わらず当てはまる。

一実施形態において、ソルバ８４０が特定の出力モデル変数の値を求めることができない場合であっても、ソルバ８４０は、実際の数値結果（又は解が求められたどのようなデータ型であっても）に対する完全解が不可能であるとしても、その出力モデル変数について部分解を提示してもよい。これは、パイプラインが、完全な解に到達するのにどのような情報が必要であるかに関して作成者に促すことにより、増分的開発を促進することを可能にする。これは、様々な作成段階を通じて少なくとも部分解が利用可能であるので、作成時間と使用時間との間の区別をなくすことも助ける。抽象的な例として、分析モデルが、式ａ＝ｂ＋ｃ＋ｄを含むことを想定する。この場合、ａ、ｃ、ｄは出力モデル変数であり、ｂは、５という既知の値（この場合は整数）を有する入力モデル変数であるとする。解を求める処理において、ソルバ８４０は、出力モデル変数のうちの１つ「ｄ」についてのみ値を求め、「ｄ」と呼ばれるモデルパラメータに対して、値６（整数）を割り当てることができるが、ソルバ８４０は「ｃ」の値を求めることができない。「ａ」は「ｃ」に従属するので、「ａ」と呼ばれるモデルパラメータも未知で解が求められないままである。この場合、「ａ」に整数値を割り当てる代わりに、ソルバは部分解を行って、モデルパラメータ「ａ」に対して「ｃ＋１１」という文字列値を出力する。前述のように、これは、領域専門家が分析モデルを作成しているときに特に役立つ可能性があり、本質的に、モデルパラメータ「ａ」のコンテンツに関して部分的な情報を提供するように機能し、モデルパラメータ「ｃ」を解くことを可能にする幾つかの更なるモデル分析が与えられる必要があることを、その作成者に対して合図するようにも機能することになる。この部分的な解の結果は恐らく、何らかのやり方でビュー構成内に出力され、領域専門家が部分的な結果を見ることを可能にすることができる。

ソルバ８４０は、図８では簡単な形で示されている。しかしながら、ソルバ８４０は、図９に関連して説明されるように、複数の構成ソルバの動作を指示してもよい。図８では、モデル化コンポーネント８２０が、モデルパラメータ（既に既知であり、かつ解が求められた出力モデル変数を含む）を、図９のビュー部分９００に提供すべき出力として利用可能にする。

図９は、ビュー部分９００を図示しており、ビュー部分９００は、図６のビュー部分６３０の例を表し、かつ再計算ユーザインタフェース２００内の視覚化されたコントロールの例を表している。ビュー部分９００は、モデルパラメータ８１１を、図８の分析部分８００から受け取る。ビュー部分は、ビューコンポーネントの集合を含む、ビューコンポーネントリポジトリ９２０も含む。例えばビューコンポーネントリポジトリ９２０は、この例では、ビューコンポーネント９２１〜９２４を含むものとして図示されているが、ビューコンポーネントリポジトリ９２０は、任意の数のビューコンポーネントを含んでよい。ビューコンポーネントはそれぞれ、ゼロ又はそれより多くの入力パラメータを含み得る。例えばビューコンポーネント９２１は、入力パラメータを全く含まない。しかしながら、ビューコンポーネント９２２は２つの入力パラメータ９４２Ａと９４２Ｂを含む。ビューコンポーネント９２３は１つの入力パラメータ９４３を含み、ビューコンポーネント９２４は１つの入力パラメータ９４４を含む。しかし、これ単なる例である。入力パラメータは、必ずしも必要ではないが、視覚的アイテムがどのようにレンダリングされるかについて影響することがある。ビューコンポーネント９２１がいずれの入力パラメータも含まないという事実は、いずれのモデルパラメータも参照せずに生成されるビューが存在し得ることを強調する。単に、変化しない単に固定された（just fix）（組み込み）データを備えるビューを考える。そのようなビューは、例えばユーザのために参照情報を構成することがある。あるいは、単にカタログをブラウズする方法を提供するビューを考えると、そのカタログからモデルへインポートするためのアイテムを選択することができる。

各ビューコンポーネント９２１〜９２４は、対応するロジックを含むか、そのようなロジックに関連付けられる。対応するロジックは、対応するビューコンポーネント入力パラメータを使用してビュー構成コンポーネント９４０によって実行されると、存在する場合、対応するビューアイテムを、仮想空間９５０に配置させる。その仮想アイテムは、静的な画像又はオブジェクトであってよく、あるいは動的なアニメーション化された仮想アイテム又はオブジェクトであってよい。例えばビューコンポーネント９２１〜９２４の各々が、対応するロジック９３１〜９３４に関連付けられ、この対応するロジック９３１〜９３４は実行されると、それぞれ対応する仮想アイテム９５１〜９５４を仮想空間９５０内にレンダリングさせることになる。仮想アイテムは簡単な形状として図示されている。しかしながら、仮想アイテムは、かなり複雑な形式であってよく、恐らくはアニメーションも含む。この説明において、ビューアイテムが仮想空間内にレンダリングされるとき、これは、ビュー構成コンポーネントが十分な命令を作成し、これらの命令が、レンダリングエンジンに提供されると、該レンダリングエンジンが、ディスプレイ上に指定の位置及び指定の方法でビューアイテムを表示することができることを意味する。

ビューコンポーネント９２１〜９２４は恐らく、例えば図６の作成コンポーネント６４０を使用して、ビューデータとしてビュー部分９００に提供されてもよい。例えば作成コンポーネント６４０は、作成者が幾つかの図形形式から選択することを可能にし、あるいは、恐らくは他の図形形式を構成することも可能にするセレクタをしてもよい。作成者は、各ビューコンポーネントについて入力パラメータのタイプを指定してもよく、一方、入力パラメータのうちの一部は、ビュー部分９００によって課されるデフォルトの入力パラメータであってもよい。各ビューコンポーネント９２１〜９２４に関連付けられるロジックは、ビューデータを提供されることがあり、かつ／又はビュー部分９００自体によって提供される幾つかのデフォルトの機能を含んでもよい。

ビュー部分９００は、モデルビュー・バインドコンポーネント９１０を含む。モデルビュー・バインドコンポーネント９１０は、モデルパラメータの少なくとも一部を、ビューコンポーネント９２１〜９２４の対応する入力パラメータにバインドするように構成される。例えばモデルパラメータ８１１Ａは、矢印９１１Ａによって示されるように、ビューコンポーネント９２２の入力パラメータ９４２Ａにバインドされる。モデルパラメータ８１１Ｂは、矢印９１１Ｂによって示されるように、ビューコンポーネント９２２の入力パラメータ９４２Ｂにバインドされる。また、モデルパラメータ８１１Ｄは、矢印９１１Ｃによって示されるように、それぞれビューコンポーネント９２３及び９２４の入力パラメータ９４３及び９４４にバインドされる。モデルパラメータ８１１Ｃは、いずれの対応ビューコンポーネントパラメータにもバインドされるようには示されておらず、これは、モデルパラメータが分析部分において重要であったとしても、必ずしも全てのパラメータが、パイプラインのビューコンポーネントによって使用される必要はないことを強調している。また、モデルパラメータ８１１Ｄは、ビューコンポーネントの２つの異なる入力パラメータにバインドされるように示されており、これは、モデルパラメータが複数のビューコンポーネントパラメータにバインドされてもよいことを表している。一実施形態において、モデルパラメータとビューコンポーネントパラメータとの間のバインドの定義は、１）作成時間に作成者が明示的に設定すること、２）使用時間に使用者が（作成者によって課されたいずれかの制約の下で）明示的に設定すること、３）アルゴリズムのヒューリスティックに基づいて作成コンポーネント６４０により自動的にバインドすること、並びに／あるいは、４）アルゴリズムではバインドを作成することができないと決定したときに、バインドを指定するよう、作成者及び／又は使用者の作成コンポーネントにより促すことによって定式化され得る。

本発明は、その精神及び本質的な特性から逸脱することなく、他の特定の形式で具現化されてよい。説明される実施形態は、全ての点において、単なる例示であり限定的ではないものとして考えられるべきである。したがって、本発明の範囲は、上記の説明ではなく、添付の特許請求の範囲によって示される。特許請求の範囲と均等の意味及び範囲内の全ての変更は、その範囲内に包含されるものとする。

Claims (10)

1. 再計算ユーザインタフェースの変換チェーンを編さんする方法であって、
   前記再計算ユーザインタフェースの前記変換チェーンを依存関係について分析して、エンティティ間の依存関係の依存関係グラフを作成する動作と；
   前記依存関係グラフを使用して、低レベルの実行ステップを作成する動作と；
   前記依存関係グラフを、プログラムのランタイムに利用可能にする動作と；
   を含む、方法。
2. 前記依存関係グラフは、エンティティ間の依存関係の識別情報を含み、該エンティティ間の依存関係の識別情報から、第１のエンティティを評価するかどうか、次いで第２のエンティティも評価すべきかどうかを決定することができる、
   請求項１に記載の方法。
3. 前記依存関係グラフは、ユーザイベントの依存関係を含み、該ユーザイベントの依存関係から、ユーザイベントが生じるかどうか、次いでエンティティを評価すべきかどうかを決定することができる、
   請求項１に記載の方法。
4. 前記再計算ユーザインタフェースは、表計算ドキュメントである、
   請求項１に記載の方法。
5. 前記再計算ユーザインタフェースは、前記変換チェーンへの入力パラメータと前記変換チェーンからの出力パラメータを有する複雑なコントロールを有する、
   請求項１に記載の方法。
6. 前記変換チェーンは、宣言的に表される、
   請求項１に記載の方法。
7. 前記低レベルの実行ステップは、命令的言語コードで表される、
   請求項１に記載の方法。
8. コンピュータ実行可能命令を有する１つ以上のコンピュータ読取可能記憶媒体を備えるコンピュータプログラム製品であって、前記コンピュータ実行可能命令は、コンピューティングシステムの１つ以上のプロセッサによって実行されると、前記コンピューティングシステムに、編さん方法を実行させるように構成され、前記編さん方法は、
   再計算ユーザインタフェース内のデータソースからデータシンクまで変換を分析する動作と、
   前記変換の依存関係グラフを作成する動作であって、前記依存関係グラフは、イベントとエンティティとの間の依存関係を表す、動作と；
   前記依存関係グラフを使用して、低レベルの実行ステップを作成する動作と；
   を含む、コンピュータプログラム製品。
9. 前記編さん方法は、
   前記依存関係グラフを、プログラムのランタイムに利用可能にする動作を更に含む、
   請求項８に記載のコンピュータプログラム製品。
10. 前記データシンクはコントロールである、
    請求項８に記載のコンピュータプログラム製品。

Images