JP2006260540A - データバインドされたリッチなアプリケーション - Google Patents

Abstract

【課題】ソフトウェア開発者による多くのグラフィック設計も、グラフィック設計者による多くのソフトウェア知識も必要としないアプリケーション開発を可能にする。
【解決手段】アプリケーションはビュー５１０とモデル５４０とに分離される。ビュー５１０中のプロパティ５５０とモデル５４０中のプロパティ５６０とは、例えばデータバインディングエンジンによる、データバインディングを通じて関連付けられる。この関連付けにより、ビューを宣言的に定義することができる。データバインディングを可能にするために、変換が必要な場合もある。データバインディングにより、モデル中のデータおよび機能を、ビュー中で定義されたようにＵＩを介して使用することができる。自動生成されたＵＩおよびコマンドバインディングもまた可能になる。
【選択図】図５

Description

本発明は一般に、コンピュータ処理に関し、より詳細には、ユーザインタフェースを有するアプリケーションの開発および動作に関する。

グラフィカルユーザインタフェース（ＧＵＩ）を備えるリッチなクライアントアプリケーションを生産するには、高品質なグラフィック設計作業と、従来のソフトウェアエンジニアリングスキルとの両方が必要とされる。グラフィック設計作業は、アプリケーションのＧＵＩの外観を提供するために行わなければならない。従来のソフトウェアエンジニアリングスキルは、アプリケーションの機能を提供するために必要とされる。

グラフィック設計とソフトウェア開発は、非常に異なる２つの分野である。グラフィック設計者とソフトウェア開発者とが共に生産的に作業するのはしばしば困難であり、そのため、高品質なＧＵＩと高品質な機能との両方を備えるクライアントアプリケーションを生産するのは困難になる。

典型的には、グラフィック設計者は、Ｐｈｏｔｏｓｈｏｐ（Ａｄｏｂｅ Ｓｙｓｔｅｍｓ社製）、Ｉｌｌｕｓｔｒａｔｏｒ（同じくＡｄｏｂｅ Ｓｙｓｔｅｍｓ社製）、Ｆｌａｓｈ（Ｍａｃｒｏｍｅｄｉａ社製）、Ｄｉｒｅｃｔｏｒ（同じくＭａｃｒｏｍｅｄｉａ社製）などのグラフィックツールを使用して、ＵＩが呈するべきビューを生み出すことになる。この「モックアップ」は、次いで開発者によって、Ｖｉｓｕａｌ Ｓｔｕｄｉｏ（本出願人による）などのプログラミングツールを使用して再実装される。通常、元のグラフィック設計要素が最終的な実装において再使用されることはほとんどない。時には、最初のアプリケーションからのいくつかのビットマップおよびアイコンが新しいアプリケーション中で再使用されることもあるが、試作されたどんな制御および対話性も使用されることはない。

このプロセスに伴う追加の問題は、容易に描けるいくつかの効果はソフトウェア開発者による再現が困難または不可能であるために、グラフィック設計者によって生み出されたデザインの一部がこのプロセス中で失われることである。グラフィック設計者のビジョンを実現することにおける制限の１つは、ソフトウェア開発者がコードおよび現在のアプリケーションプログラムインタフェース（ＡＰＩ）を使用して実際にできることに限りがあることである。もう１つの本質的な制限は、開発者がデザインを完全に理解しておらず、グラフィック設計者の意図とは異なる選択を実装において行う場合があることである。

加えて、結果として生じるアプリケーションは再使用可能ではない。時の経過に伴ってデザインが修正された場合、グラフィック設計者は、デザインツールを使用してＵＩを描き直さなければならず、プログラマは、デザインに合うようにコードの各部分を書き直さなければならない。これは、フォームまたはアプリケーションのレイアウト全体から、単一の制御の外観までの、複数のレベルのいずれかで生じる場合がある。一般に、前述のようにして作成されたコードは、デバッグ、保守、および拡張が困難である。

ＵＩを外部から指定できるようになる前に、アプリケーションビジネスロジックをプレゼンテーションから分離する必要がある。この２つを分離する手法の１つは、モデル−ビュー−コントローラ（ＭＶＣ）設計パターンである。ＭＶＣは、アプリケーションを３つの領域、すなわち抽象モデルと、そのモデルのビューと、各ビューごとのコントローラとに分割することによって、この問題を解決しようとする。コントローラは、入力イベントを処理し、それらをビューまたはモデルに対する変化に変換する。反対に、ビューおよびコントローラは、オブザーバをモデルに取り付けており、モデルが変化したときは、ビューおよびコントローラは自身を更新することができる。例えば、ユーザがカタログを検索してカタログ情報を見ることのできるウェブクライアントアプリケーションの場合、モデルは、カタログ情報が記憶されている場所である。ビューはユーザへのプレゼンテーションである。コントローラは、入力イベント（ユーザからのクリックやテキストなど）を処理し、結果としてどのように変化すべきかをビューおよびモデルに伝える。ビューおよびコントローラは、モデル内の変化、すなわちビューおよびコントローラがオブザーバを介して知った変化の結果として変化することもある。

ＭＶＣパターンは、概念的にはクリーンである。しかし実際は、ビューとコントローラを分離するのはしばしば困難である。この困難のため、この２つは通常、単一のＶｉｅｗＣｏｎｔｒｏｌｌｅｒクラスに結合されるが、このクラスは依然としてデザインとロジックの混合であり、したがってやはり、グラフィック設計者とソフトウェア開発者とがただ作成のためにこのクラスに対して協働するのも、このクラスに向けて協働するのも困難である。さらに、イベントを処理すること、ならびに、ＶｉｅｗＣｏｎｔｒｏｌｌｅｒとＭｏｄｅｌとを結び付けるのに必要なオブザーバおよび更新機構を実装することは、面倒でコード集約的な作業であり、これらの作業は、エラーが起きやすくグラフィック設計者には適さない。さらに、オブザーバおよび更新コードは通常、あるインスタンスから次のインスタンスまで類似する。

したがって、前述のように、現在のソフトウェア開発者／グラフィック設計者ワークフローおよびアプリケーションアーキテクチャには、多くの問題が内在する。以上の欠点に鑑みて、ユーザインタフェース（ＵＩ）コンポーネントを有するアプリケーションまたはアプリケーションの一部を作成および設計するための、改善された方法が必要とされている。本発明はこの必要性を満たすものである。

オブザーバおよび更新処理コード（the observer and update handling code）を最小限に抑えながらビューとモデルとの分離を可能にするために、データバインディングが使用される。ビューは、少なくとも１つのビュープロパティを含み、ビュープロパティは、モデル中の少なくとも１つのモデルプロパティにバインドされる。このバインディングは、ビューを設計と噛み合わせる作業を簡略化し、以前ならイベント処理、オブザーバ、更新機構が処理していた機能を自動的に実施する。

いくつかの実施形態では、トランスフォーマを使用して、モデルからのデータをビュー中で使用されるように変換することができる。いくつかの実施形態では、ビューから生じるＵＩの各部分が自動的に生成され得る。いくつかの実施形態では、コマンドバインディングを使用して、ＵＩ中でトリガされたコマンドがモデル中で処理されるようにすることができる。

本発明の他の特徴および利点は、後続の本発明の詳細な説明および添付の図面から明らかになるであろう。

前述の概要、ならびに現時点で好ましい実施形態に関する後続の詳細な記述は、添付の図面と共に読めばよりよく理解される。本発明を説明するために、図面には、本発明の例示的な構造が示されている。しかし本発明は、開示される特定の方法および手段に限定されない。

（例示的なコンピューティング環境）
図１に、本発明を実施することのできる適切なコンピューティングシステム環境１００の例を示す。コンピューティングシステム環境１００は、適切なコンピューティング環境の一例に過ぎず、本発明の使用または機能の範囲についてどんな限定を意味するものでもない。またコンピューティング環境１００は、この例示的な動作環境１００に示すコンポーネントのいずれか１つまたは組合せに関して、どんな依存や要件を有するとも解釈されるべきではない。

コンピュータまたはその他のクライアントデバイスまたはサーバデバイスは、コンピュータネットワークの一部として配置されてもよく、あるいは分散コンピューティング環境内に配置されてもよいことは、当業者なら理解することができる。これに関して、本発明は、任意の数のメモリまたは記憶装置と、任意の数の記憶装置またはボリュームにわたって発生し本発明と共に使用できる任意の数のアプリケーションおよびプロセスとを有する、任意のコンピュータシステムに関係する。本発明は、ネットワーク環境または分散コンピューティング環境内に配置された、リモートまたはローカル記憶装置を有するサーバコンピュータおよびクライアントコンピュータを有する環境に適用することができる。本発明はまた、リモートまたはローカルサービスと共に情報を生成し、受信し、および送信するためのプログラミング言語機能ならびに解釈および実行能力を有するスタンドアロンコンピューティングデバイスに適用することもできる。

本発明は、その他多くの汎用または専用コンピューティングシステム環境または構成でも機能する。本発明と共に使用するのに適するであろう周知のコンピューティングシステム、環境、および／または構成の例には、限定はしないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドデバイスまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータや、これらのシステムまたはデバイスのいずれかを含む分散コンピューティング環境などが含まれる。

本発明は、プログラムモジュールなど、コンピュータによって実行されるコンピュータ実行可能命令の一般的な文脈で述べることができる。一般に、プログラムモジュールは、特定のタスクを実行するか、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明は分散コンピューティング環境で実施することもでき、その場合、タスクは通信ネットワークまたはその他のデータ伝送媒体を介してリンクされたリモート処理デバイスによって実施される。分散コンピューティング環境では、プログラムモジュールおよびその他のデータは、メモリ記憶デバイスを含めたローカルとリモートの両方のコンピュータ記憶媒体に位置することができる。分散コンピューティングは、コンピューティングデバイスおよびシステム間の直接交換によって、コンピュータリソースおよびサービスの共有を容易にする。これらのリソースおよびサービスには、情報交換、キャッシュ記憶、およびファイル用ディスク記憶が含まれる。分散コンピューティングは、ネットワーク接続性を活かし、クライアントがその集合的な力を利用して企業全体を益することができるようにする。これに関して、様々なデバイスが、本発明の技法を利用できるアプリケーション、オブジェクト、またはリソースを有することができる。

図１を参照すると、本発明を実施するための例示的なシステムは、コンピュータ１１０の形の汎用コンピューティングデバイスを含む。コンピュータ１１０のコンポーネントには、限定はしないが、処理ユニット１２０と、システムメモリ１３０と、システムメモリを含めた様々なシステムコンポーネントを処理ユニット１２０に結合するシステムバス１２１とを含めることができる。システムバス１２１は、様々なバスアーキテクチャのいずれかを用いた、メモリバスまたはメモリコントローラ、ペリフェラルバス、およびローカルバスを含めた、いくつかのタイプのバス構造のいずれかとすることができる。限定ではなく例として、このようなアーキテクチャには、ＩＳＡ（Industry Standard Architecture）バス、ＭＣＡ（Micro Channel Architecture）バス、ＥＩＳＡ（Enhanced ISA）バス、ＶＥＳＡ（Video Electronics Standards Association）ローカルバス、およびＰＣＩ（Peripheral Component Interconnect）バス（メザニンバスとも呼ばれる）が含まれる。

コンピュータ１１０は通常、様々なコンピュータ読取り可能記憶媒体を備える。コンピュータ読取り可能記憶媒体は、コンピュータ１１０からアクセスできる任意の利用可能な媒体とすることができ、揮発性および不揮発性の媒体、取外し可能および取外し不可能な媒体の両方が含まれる。限定ではなく例として、コンピュータ読取り可能記憶媒体には、コンピュータ記憶媒体および通信媒体を含めることができる。コンピュータ記憶媒体には、コンピュータ読取り可能命令、データ構造、プログラムモジュール、またはその他のデータなどの情報を記憶するための任意の方法または技術で実現された、揮発性および不揮発性、取外し可能および取外し不可能な両方の媒体が含まれる。コンピュータ記憶媒体には、限定はしないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤＲＯＭ、ディジタル多用途ディスク（ＤＶＤ）、または他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、または他の磁気記憶デバイスが含まれ、あるいは、所望の情報を記憶するのに使用できコンピュータ１１０からアクセスできるその他の任意の媒体が含まれる。通信媒体は通常、コンピュータ読取り可能命令、データ構造、プログラムモジュール、またはその他のデータを、搬送波やその他のトランスポート機構などの被変調データ信号に組み入れるものであり、任意の情報送達媒体がこれに含まれる。用語「被変調データ信号」は、信号中の情報が符号化される形で１つまたは複数の特性が設定または変更される信号を意味する。限定ではなく例として、通信媒体には、有線ネットワークや直接有線接続などの有線媒体と、音響、無線周波数、赤外線などの無線媒体および他の無線媒体とが含まれる。以上のいずれかの組合せもコンピュータ読取り可能記憶媒体の範囲に含まれるべきである。

システムメモリ１３０は、読取り専用メモリ（ＲＯＭ）１３１やランダムアクセスメモリ（ＲＡＭ）１３２など、揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。ＲＯＭ１３１には通常、起動中などにコンピュータ１１０内の要素間で情報を転送するのを助ける基本ルーチンを含むＢＩＯＳ（basic input/output system）１３３が記憶されている。ＲＡＭ１３２は通常、処理ユニット１２０がすぐにアクセス可能な、かつ／または処理ユニット１２０が現在作用している、データおよび／またはプログラムモジュールを含む。限定ではなく例として、図１には、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、プログラムデータ１３７を示す。

コンピュータ１１０は、その他の取外し可能／取外し不可能、揮発性／不揮発性コンピュータ記憶媒体を備えることもできる。例に過ぎないが図１には、取外し不可能な不揮発性の磁気媒体に対して読み書きするハードディスクドライブ１４１と、取外し可能な不揮発性の磁気ディスク１５２に対して読み書きする磁気ディスクドライブ１５１と、ＣＤ ＲＯＭやその他の光媒体など取外し可能な不揮発性の光ディスク１５６に対して読み書きする光ディスクドライブ１５５を示す。この例示的な動作環境で使用できるその他の取外し可能／取外し不可能、揮発性／不揮発性コンピュータ記憶媒体には、限定されないが磁気テープカセット、フラッシュメモリカード、ディジタル多用途ディスク、ディジタルビデオテープ、固体ＲＡＭ、固体ＲＯＭなどが含まれる。ハードディスクドライブ１４１は通常、インタフェース１４０などの取外し不可能なメモリインタフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は通常、インタフェース１５０などの取外し可能なメモリインタフェースでシステムバス１２１に接続される。

以上に論じ図１に示したドライブおよびそれらに関連するコンピュータ記憶媒体は、コンピュータ読取り可能命令、データ構造、プログラムモジュール、その他のデータの記憶域をコンピュータ１１０に提供する。例えば図１には、ハードディスクドライブ１４１がオペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、およびプログラムデータ１４７を記憶しているのが示されている。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、その他のプログラムモジュール１３６、プログラムデータ１３７と同じものとすることもでき、異なるものとすることもできることに留意されたい。ここでは、オペレーティングシステム１４４、アプリケーションプログラム１４５、その他のプログラムモジュール１４６、プログラムデータ１４７が少なくとも異なるコピーであることを示すために、異なる番号を付けてある。ユーザは、キーボード１６２やポインティングデバイス１６１（一般にマウス、トラックボール、またはタッチパッドと呼ばれる）などの入力デバイスを介して、コンピュータ１１０にコマンドおよび情報を入力することができる。その他の入力デバイス（図示せず）には、マイクロホン、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどを含めることができる。これらおよび他の入力デバイスは、システムバスに結合されたユーザ入力インタフェース１６０を介して処理ユニット１２０に接続されることが多いが、パラレルポート、ゲームポート、ユニバーサルシリアルバス（ＵＳＢ）など、他のインタフェースおよびバス構造で接続されてもよい。モニタ１９１または他のタイプの表示デバイスも、ビデオインタフェース１９０などのインタフェースを介してシステムバス１２１に接続される。モニタに加えて、コンピュータは、スピーカ１９７やプリンタ１９６など、その他の周辺出力デバイスも備えることができ、これらは出力周辺インタフェース１９５を介して接続することができる。

コンピュータ１１０は、リモートコンピュータ１８０など１つまたは複数のリモートコンピュータへの論理接続を用いて、ネットワーク化された環境で動作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般的なネットワークノードとすることができ、図１にはメモリ記憶デバイス１８１だけしか示されていないが、通常はコンピュータ１１０に関して上述した要素の多くまたはすべてを備える。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３を含むが、他のネットワークを含むこともできる。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネット、インターネットにおいては一般的である。

ＬＡＮネットワーキング環境で使用されるときは、コンピュータ１１０は、ネットワークインタフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用されるときは、コンピュータ１１０は通常、インターネットなどのＷＡＮ１７３を介した通信を確立するためのモデム１７２または他の手段を備える。モデム１７２は内蔵でも外付けでもよく、ユーザ入力インタフェース１６０または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク化された環境では、コンピュータ１１０に関して示したプログラムモジュールまたはその一部をリモートのメモリ記憶デバイスに記憶することができる。限定ではなく例として、図１には、リモートアプリケーションプログラム１８５がメモリデバイス１８１上にあるのが示されている。図示のネットワーク接続は例であり、コンピュータ間で通信リンクを確立するための他の手段を使用してもよいことは理解されるであろう。

本明細書のいくつかの例示的な実施形態は、コンピューティングデバイス上にあるソフトウェアに関して述べるが、本発明の１つまたは複数の部分は、オペレーティングシステム、アプリケーションプログラミングインタフェース（ＡＰＩ）または「中間者（ｍｉｄｄｌｅ ｍａｎ）」オブジェクト、制御オブジェクト、ハードウェア、ファームウェアなどを介して実施することもでき、したがって本方法は、すべての．ＮＥＴ言語およびサービスならびにその他の分散コンピューティングフレームワークに含めることができ、これらのフレームワークにおいてサポートすることができ、これらのフレームワークを介してアクセスすることができる。

（データバインドされたアプリケーションにおけるデータバインディングコンポーネントの使用）
より高い生産性と、アプリケーション要素のよりよい再利用性と、開発者と設計者との間のより容易な協働をもたらすために、本発明は、ユーザインタフェース（ＵＩ）の外観（または「ビュー」）と、基礎をなす挙動（「モデル」）との間のクリーンな分離を提供する。図２は、本発明の一実施形態による、ＵＩコンポーネントを含むアプリケーションのブロック図である。図２において明らかなように、アプリケーション２００は、ビュー２１０およびモデル２４０を含む。これらは、アプリケーション設計のＭＶＣパターンにおけるビューおよびモデルに対応する。モデル２４０は、アプリケーションのロジックに関する、ＵＩフリーなコードを表す。例えば、カタログに関するデータベースおよびビジネスロジックは、モデル２４０内に実装されることになる。追加の例として、アプリケーション２００によってユーザがファイルシステムを探索することができる場合、この例示的な場合におけるアプリケーションに関するモデル２４０は、ファイルシステム、すなわち、選択されたディレクトリ内の一組のフォルダおよびファイルである。モデル２４０は、データ（カタログデータ）と、データに関するロジック、例えば一貫性規則（consistency rules）との両方を含む。一貫性規則は、例えば、カタログ中の製品の価格がマイナスでないことを必要とすることができる。

モデル２４０を使用することにより、モデルが従来のプログラミング言語において定義されること、したがって、モデルがソフトウェア開発者にとって理解可能であることの利益が維持される。ファイルシステムの例では、モデルは、ファイルの移動、コピー、名前変更のためのメソッド、フォルダ作成のためのメソッド、アプリケーションファイルの実行のためのメソッドなどからなる。これらの操作は必然的に、タスク特有のビジネスロジックだがこれらの操作をエンドユーザに公開するのに使用されるＵＩからは独立した、ビジネスロジックを必要とする。ビュー２１０は、宣言的（declaratively）に指定される。例えば、ビュー２１０は、本件出願人によるＶｉｓｕａｌ Ｓｔｕｄｉｏ製品やＭａｃｒｏｍｅｄｉａ社製のＦｌｅｘ製品などのツールを使用して定義することができる。

ビュー２１０とモデル２４０との間のリンクを提供するために、アプリケーション２００は、総合（general）データバインディングコンポーネント２２０を使用する。総合データバインディングコンポーネントは、アプリケーション２００内に示されているが、いくつかの実施形態では、アプリケーション２００によって使用される利用可能なリソースである。いくつかの実施形態におけるデータバインディングコンポーネント２２０は、データバインディングエンジン２２０である。このようなデータバインディングエンジンは、モデル上のプロパティとビュー上のプロパティとの間の関連など、１対のオブジェクト上のプロパティ間の動的なバインディングを可能にする。データバインディングエンジン２２０は、これらのオブジェクトに関するプロパティ変化通知をリッスンし、これにより、ソースプロパティの変化は自動的にターゲットプロパティに反映することになる。また、その逆も同様である。データバインディングエンジンは、ターゲットの特定部分をソースの特定部分にバインドできるようにするために、プロパティパスを評価することをサポートすることができる。本発明のいくつかの実施形態では、ターゲットオブジェクトプロパティをソースオブジェクトプロパティにバインドすることは、ＨＴＭＬ（ハイパーテキストマークアップ言語）、ＸＭＬ（拡張可能マークアップ言語）、ＸＡＭＬ（拡張可能アプリケーションマークアップ言語）、またはその他の適切なマークアップ言語など、マークアップ言語で宣言的に行うことができる。

したがって、データバインディングエンジン２２０は、ビュー２１０とモデル２４０との間の媒介として機能する。そのため、データバインディングエンジンを使用することにより、ビュー２１０からのイベントを明示的に処理してモデル２４０に対するオブザーバおよび更新機構を実装するためのアプリケーションコードを必要とせずに、モデルとは別に構築されたユーザインタフェースを有するアプリケーションを設計することができる。データバインディングエンジン２２０は、そのソースとターゲットとの同期を自動的にとる。したがって、ビュー２１０へのユーザ入力またはモデル２４０内の変化が発生した場合は、適切な更新が行われる。

例として、アプリケーション２００は、温度を表示する単純なアプリケーションとすることができる。ビュー２１０は、グラフィック設計者によってグラフィックツール中で生み出すことができる。例えば、図３に単純なビューを示す。図３に示すように、グラフィック３００は、テキストボックス３１０および温度計グラフィック３２０を含む。この例では、アプリケーション２００は、ユーザが郵便番号をテキストボックス３１０に入力できるようにして、この郵便番号における対応する温度を温度計グラフィック３２０に表示するように意図されている。温度計の示度は、グラフィック設計者によって、グラフィック３００に関連する変数「Ｌｅｎｇｔｈ」に対応するように設定される。テキスト入力ボックスからのデータは、変数「ｚｉｐｃｏｄｅ」に関連する。この例の一変形では、ｚｉｐｃｏｄｅに対する正しい温度を取り出すために、データベースが参照される。データベースストアは、各郵便番号について、温度計グラフィック３２０の表示の長さを記憶している。データバインディングエンジン２２０は、グラフィック３００のｚｉｐｃｏｄｅおよびＬｅｎｇｔｈをデータベース中のそれとバインドする。図３の温度計アプリケーションの場合、データベースはモデル２４０である。

（データバインディングコンポーネントおよびアダプタ層の使用）
図４は、本発明の一実施形態による、アプリケーションの各部分のブロック図である。図４は、ビュー４１０と、データバインディングコンポーネント４２０と、モデル４４０とを有するアプリケーション４００を示している。ビュー４１０、データバインディングコンポーネント４２０、およびモデル４４０は、図２の対応する要素に関して上述したとおりである。しかし、図４はアダプタ層４３０も含み、アダプタ層４３０は、ビュー４１０中の概念を、モデル４４０中の概念へまたは概念から変換する必要があれば、その変換を実施する。

例えば、温度計アプリケーションの例に関する別の変形では、図３に示した温度計アプリケーションのモデル４４０は、ワールドワイドウェブを介して利用可能なサービスによって実装される。このウェブサービスは、以下の例のようにモデル４４０によってアプリケーション中で公開することができ、この例では、ＴｅｍｐｅｒａｔｕｒｅＭｏｄｅｌが、述べたモデルである。

示したように、このウェブサービスは、ビュー４１０中で直接使用できるＬｅｎｇｔｈ値ではなく、度で表される温度（temperature in degrees）に対応する浮動小数点数を返す。このような場合、アダプタ層４３０は、この浮動小数点数を、ビュー４１０中で使用できる長さに変換することになる。データバインディングコンポーネント４２０は、例えばインターネットを介してウェブサービスへのアクセスを可能にするラッパ（wrapper）を通して、サービスに対して直接に作用することができるが、サービスから提供される結果はビュー４１０に理解可能ではなく、ビュー４１０は、度で表される温度ではなく長さを必要とする。そのため、アダプタ層４３０が変換を提供する。ウェブベースの温度計アプリケーションの例についてのアダプタ層４３０の例は、以下のとおりである。

このアダプタ層４３０は、ウェブサービスから返された温度からＬｅｎｇｔｈが決定されるようにする。温度はウェブサービスから得られる。すなわち、モデル４４０のＴｅｍｐｅｒａｔｕｒｅプロパティからワールドワイドウェブ（「ｗｅｂｓｅｒｖｉｃｅ．ｇｅｔ＿ｔｅｍｐ（ｚｉｐｃｏｄｅ）」）を介して公開されるリモートメソッドを呼び出すためのクライアント側スクリプトから得られる。Ｌｅｎｇｔｈは、得られた温度に基づく。次いで、データバインディングコンポーネント４２０は、アダプタ層４３０を介して、ビュー４１０のｚｉｐｃｏｄｅをモデル４４０中のｚｉｐｃｏｄｅにバインドし、ビュー４１０のＬｅｎｇｔｈをモデル４４０中のＬｅｎｇｔｈにバインドすることになる。ビュー４１０中のＬｅｎｇｔｈに関するバインディング宣言は、モデル４４０中のＴｅｍｐｅｒａｔｕｒｅとアダプタ層４３０中のｃｏｎｖｅｒｔｅｒとの両方を参照することになる。新しい郵便番号がビュー４１０に入力されたときは、データバインディングコンポーネントは、モデル４４０中のＺｉｐＣｏｄｅプロパティを更新することになる。その結果として、モデルは、モデル中のＺｉｐＣｏｄｅとＴｅｍｐｅｒａｔｕｒｅの両方のプロパティが変化したことをリスナに通知することになる。次いで、データバインディングコンポーネントは、モデル４４０（ウェブサービス）を使用して新しいＬｅｎｇｔｈを計算し、更新済み温度値を得て、次いで変換をアダプタ層４３０中で適用する。得られたＬｅｎｇｔｈ値は、ビュー４１０に提供されることになる。

図５は、本発明の一実施形態による、ビューとデータバインディングコンポーネントとモデルとの間のデータフローを示すブロック図である。データバインディングコンポーネント５２０は、矢印５１２で示すように、ビュー５１０からのプロパティ変化通知をリッスンする。加えて、データバインディングコンポーネント５２０は、矢印５４２で示すように、モデル５４０からのプロパティ変化通知もリッスンする。変化通知を受け取った場合、データバインディングコンポーネント５２０は、矢印５２５および５２６で示すように、ビュー５１０中のビュープロパティ５５０をモデル５４０中のモデルプロパティ５６０と同期させることになる。アダプタ層５３０がある場合は、前述のように、プロパティが直接対応しない場合にアダプタ層５３０がこの同期を可能にする。

（トランスフォーマ、自動生成されたＵＩ、およびコマンドバインディング）
再び図２を参照すると、前述のように、アダプタ層はトランスフォーマを提供し、それによりビュー２１０中のプロパティはモデル２４０中のプロパティに対応することができる。トランスフォーマは、データの特定クラスを、ある値セットから別の値セットに変換するオブジェクトである。トランスフォーマは、片方向または両方向に作用することができる。上述したように、温度計の例では、ウェブサービスから取り出された結果をＬｅｎｇｔｈに変換するためのトランスフォーマが提供された。温度値に逆変換する必要はなく、単方向トランスフォーマだけが必要とされたので、この変換は単方向性であった。しかし、双方向トランスフォーマが必要な場合もある。例えば、図３のグラフィック３００上に米国地図も表示されており、郵便番号をテキストボックス３１０にタイプ入力する代わりに地図上の地点をユーザが選択することができる場合を考えてみる。このような場合、クリックの位置を保持するビュー２１０中のプロパティが、郵便番号を識別するモデル２４０中のプロパティに変換されることになる。次いで、この郵便番号を使用して、追加の変換を介して、テキストボックス３１０中に表示された値および温度計グラフィック３２０上に表示された値が変更される。

トランスフォーマは、ＵＩがデータを種々のフォーマットで公開できるようにし、モデル２４０がデータを単一の、一貫したフォーマットで公開できるようにする。トランスフォーマはまた、モデル２４０に重複情報を公開させることなく、モデル２４０上の同じデータが同時にいくつかの異なる方式で表示されるようにする。プロパティをＵＩコンポーネントにバインドすることに加えて、データバインディングはまた、モデル２４０に基づいてユーザインタフェースのためのコンテンツを自動生成する強力な機能も提供する。例えば、モデル２４０は、データの集合であるプロパティを公開することができる。ビューは、モデル集合中の各項目について、新しいユーザインタフェースコンポーネントがビュー中で作成されるように、宣言的に指定することができる。次いで、ビュー側の集合は、データの集合であるモデル上のプロパティにバインドされる。そのため、このバインディングは、ＵＩ中のユーザインタフェースコンポーネントの自動生成を引き起こす。したがって例えば、モデル中の名前のリストから、ＵＩ中に各名前がリストされたメニューが得られる。ビュー２１０は、いくつの要素が名前リスト中にあるかを知る必要はなく、バインディングに基づいて正しい数のリストが自動生成される。このようにして、メニューの項目をポピュレートすること、リストビューをポピュレートすること、およびコンボボックスをポピュレートすることを含む方法によって、種々のＵＩ要素を作成することができる。

コマンドバインディングを使用して、モデル中の操作がＵＩ要素にバインドされる。図６は、本発明の一実施形態による、コマンドバインディングの使用を示すブロック図である。ビュー２１０中で、ＵＩ要素６４０（例えばメニュー項目）が、プロパティ６４５を公開することになる。プロパティ６４５は、データバインディングする間のシンク（ターゲット）として働く。例えば、ＵＩ要素６４０は、ファイルシステムの例における削除ボタンとすることができ、プロパティ６４５は、選択されたファイルを削除するための対応するモデルコマンドに結び付けられたコマンドプロパティである。コマンドの機能をプロパティ６４５に結び付けることは、モデル２４０をデータソースとして割り当てて、ＵＩ要素６４０上のプロパティ６４５を、モデル上のコマンド６５０のコマンドプロパティ６５５にデータバインドすることによって達成することができる。したがって、ビュー２１０中のコマンドの機能は、どんな命令型プログラムコードも呼び出さずに、宣言的に達成することができる。この例におけるボタンＵＩ要素は、関連するコマンドが何であろうかにかかわらず、単にボタンが押された場合にそのコマンドを呼び出すことを担う。

宣言的バインディングは、いくつかの実施形態では、プロパティパスを使用して、まずモデル２４０中のアクティブ文書をアドレス指定し、次いで、ユーザインタフェース６４０上のボタンのコマンドプロパティ６４５中で指定されたアクティブ文書上の編集コマンドを、このプロパティパスで選択することによって、達成することができる。

（本発明による、ユーザに機能を提供する方法）
図７は、本発明の一実施形態による、ユーザインタフェースを介してユーザに機能を提供する方法の流れ図である。このような機能は、データバインドされたリッチなアプリケーションを提供することができる。ステップ７００において、ユーザインタフェースを記述するビューデータが提供される。ビューデータは、少なくとも１つのビュープロパティを含む。加えて、ステップ７１０において、機能を実現するモデルデータが提供される。このモデルデータは、機能のためのデータを（例えばデータベースまたはその他のデータストアから）提供することによって、あるいはプログラムに基づく機能を提供することによって、機能を実現することができる。ステップ７２０において、ビュープロパティの少なくとも１つが、モデルプロパティの少なくとも１つにバインドされる。本発明のいくつかの実施形態では、これはデータバインディングエンジンによって行われる。ステップ７２０は、モデルプロパティをビュー準拠プロパティ（view-compliant property）に変換し、次いでこのビュー準拠プロパティをモデルプロパティにバインドすることによって、達成することができる。加えて、ステップ７２０は、ビュープロパティをモデル準拠プロパティに変換し、このモデル準拠プロパティをビュープロパティにバインドすることによって、達成することもできる。バインドするステップ７２０を介して、ビューのためのＵＩ要素の自動生成、およびコマンドバインディングを達成することができる。

ビューデータを提供してバインドすることによって、モデルデータからアプリケーションを作成する場合と同様に、モデルデータを提供していくつかのモデルデータプロパティをビューデータプロパティにバインドすることによって、ビューデータからアプリケーションを作成することも可能である。

（結び）
本明細書に述べた様々な技法は、ハードウェアまたはソフトウェア、あるいは適切ならこの両方の組合せで実施することができる。したがって、本発明の方法および装置、またはそのいくつかの態様または部分は、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、ハードドライブ、またはその他の任意のマシン読取り可能記憶媒体など、有形媒体に組み入れられたプログラムコード（すなわち命令）の形をとることができ、プログラムコードがコンピュータなどのマシンにロードされマシンによって実行されると、このマシンは本発明を実施するための装置になる。プログラムコードがプログラム可能なコンピュータ上で実行される場合、このコンピューティングデバイスは一般に、プロセッサと、プロセッサによって読取り可能な記憶媒体（揮発性と不揮発性のメモリおよび／または記憶素子を含む）と、少なくとも１つの入力デバイスと、少なくとも１つの出力デバイスとを備えることになる。例えばデータ処理ＡＰＩなどを使用して、本発明の領域特有なプログラミングモデル態様の作成および／または実施を利用することのできる１つまたは複数のプログラムは、コンピュータシステムと通信するための高レベルのプロシージャ指向またはオブジェクト指向プログラミング言語で実現されることが好ましい。しかし、この１つまたは複数のプログラムは、望むのであれば、アセンブリ言語またはマシン言語で実現することもできる。いずれの場合でも、言語はコンパイルまたは解釈される言語とすることができ、ハードウェアの実装と組み合わせることができる。

本発明の態様を実施することのできる例示的なコンピューティング環境のブロック図である。 本発明の一実施形態による、ＵＩコンポーネントを含むアプリケーションのブロック図である。 本発明の一実施形態による、モデルと共に使用することのできるビューを示す図である。 本発明の一実施形態による、アプリケーションの各部分のブロック図である。 本発明の一実施形態による、ビューとデータバインディングコンポーネントとモデルとの間のデータフローを示すブロック図である。 本発明の一実施形態による、コマンドバインディングの使用を示すブロック図である。 本発明の一実施形態による、ユーザインタフェースを介してユーザに機能を提供する方法の流れ図である。

Claims (20)

1. ユーザインタフェースを介して機能を提供する方法であって、前記方法は、
   ユーザインタフェースを記述する、少なくとも１つのビュープロパティを含むビューデータを提供することと、
   前記機能を実現する、少なくとも１つのモデルプロパティを含むモデルデータを提供することと、
   前記ビュープロパティの少なくとも１つを前記モデルプロパティの少なくとも１つにバインドすることと
   を含むことを特徴とする方法。
2. 前記バインドすることは、データバインディングエンジンを使用してバインドすることを含むことを特徴とする請求項１に記載の方法。
3. 前記ビュープロパティの少なくとも１つを前記モデルプロパティの少なくとも１つにバインドする前記ステップは、
   前記モデルプロパティの変換を提供し、前記変換の結果としてビュー準拠モデルプロパティを得ることと、
   前記ビュー準拠モデルプロパティを前記モデルプロパティにバインドすることと
   を含むことを特徴とする請求項１に記載の方法。
4. 前記ビューデータは、少なくとも１つの特定のビュープロパティに基づいてユーザインタフェース要素のプレゼンテーションを記述し、前記特定のビュープロパティは、少なくとも１つの特定のモデルプロパティにバインドされ、前記バインディングにより前記プレゼンテーションは前記少なくとも１つのモデルプロパティに基づいて前記ユーザインタフェース要素を自動的に生成できることを特徴とする請求項１に記載の方法。
5. 前記自動的な生成は、メニューの項目をポピュレートすること、リストビューをポピュレートすること、コンボボックスをポピュレートすることから選択された１つまたは複数を含むことを特徴とする請求項４に記載の方法。
6. 前記モデルプロパティはコマンドであることを特徴とする請求項１に記載の方法。
7. 請求項１に記載の方法を実施するためのコンピュータ実行可能命令を備えることを特徴とするコンピュータ読取り可能記憶媒体。
8. ユーザインタフェースを有するアプリケーションを提供するシステムであって、前記システムは、
   ユーザインタフェースを記述するビューデータを含むビューであって、前記ビューデータは少なくとも１つのビュープロパティを含むビューと、
   前記機能を実現するモデルデータを含むモデルであって、前記モデルデータは少なくとも１つのモデルプロパティを含むモデルと、
   前記ビュープロパティの少なくとも１つを前記モデルプロパティの少なくとも１つにバインドするデータバインディングコンポーネントと
   を備えることを特徴とするシステム。
9. 前記バインドすることは、データバインディングエンジンを使用してバインドすることを含むことを特徴とする請求項８に記載のシステム。
10. 前記ビュープロパティを前記モデルプロパティにバインドする前記ステップは、
    前記モデルプロパティの変換を提供し、前記変換の結果としてビュー準拠モデルプロパティを得ることと、
    前記ビュー準拠モデルプロパティを前記モデルプロパティにバインドすることと
    を含むことを特徴とする請求項８に記載のシステム。
11. 前記ビューデータは、少なくとも１つの特定のビュープロパティに基づいてユーザインタフェース要素のプレゼンテーションを記述し、前記特定のビュープロパティは、少なくとも１つの特定のモデルプロパティにバインドされ、前記バインディングにより前記プレゼンテーションは前記少なくとも１つのモデルプロパティに基づいて前記ユーザインタフェース要素を自動的に生成できることを特徴とする請求項８に記載のシステム。
12. 前記自動的な生成は、メニューの項目をポピュレートすること、リストビューをポピュレートすること、コンボボックスをポピュレートすることから選択された１つまたは複数を含むことを特徴とする請求項１１に記載のシステム。
13. 前記モデルプロパティはコマンドであることを特徴とする請求項８に記載のシステム。
14. ビューデータからアプリケーションを作成する方法であって、前記ビューデータはユーザインタフェースを記述し、前記ビューデータは少なくとも１つのビュープロパティを含み、前記方法は、
    機能を実現する、少なくとも１つのモデルプロパティを含むモデルデータを提供することと、
    前記ビュープロパティの少なくとも１つを前記モデルプロパティの少なくとも１つにバインドすることと
    を含むことを特徴とする方法。
15. 前記バインドすることは、データバインディングエンジンを使用してバインドすることを含むことを特徴とする請求項１４に記載の方法。
16. 前記ビュープロパティの少なくとも１つを前記モデルプロパティの少なくとも１つにバインドする前記ステップは、
    前記モデルプロパティの変換を提供し、前記変換の結果としてビュー準拠モデルプロパティを得ることと、
    前記ビュー準拠モデルプロパティを前記モデルプロパティにバインドすることと
    を含むことを特徴とする請求項１４に記載の方法。
17. 前記ビューデータは、少なくとも１つの特定のビュープロパティに基づいてユーザインタフェース要素のプレゼンテーションを記述し、前記特定のビュープロパティは、少なくとも１つの特定のモデルプロパティにバインドされ、前記バインディングにより前記プレゼンテーションは前記少なくとも１つのモデルプロパティに基づいて前記ユーザインタフェース要素を自動的に生成できることを特徴とする請求項１４に記載の方法。
18. 前記自動的な生成は、メニューの項目をポピュレートすること、リストビューをポピュレートすること、コンボボックスをポピュレートすることから選択された１つまたは複数を含むことを特徴とする請求項１７に記載の方法。
19. 前記モデルプロパティはコマンドであることを特徴とする請求項１４に記載の方法。
20. 請求項１４に記載の方法を実施するためのコンピュータ実行可能命令を備えることを特徴とするコンピュータ読取り可能記憶媒体。

Images