JP2005346719A - 完全な柔軟性を有する自動化に基づくユーザインターフェースを生成する方法および装置 - Google Patents

Abstract

【課題】 アプリケーションモデルを示すためにモデルドリブンフォームユーザインターフェースを生成する、方法、コンピュータ読み取り可能な媒体、およびシステムを提供する。
【解決手段】 方法は、複数の異なる論理フォームタイプのどれが、アプリケーションモデルを示すために、フォームユーザインターフェースを生成するために使用するかを選択することを含む。方法は、また第１のマップを提供することも含む。ディスプレイターゲットから独立した論理フォームは、アプリケーションモデル、選択されたフォームタイプ、および第１のマップを使用して生成される。
【選択図】 図８

Description

本発明は、フォーム（ｆｏｒｍ）の生成に関する。より詳細には、本発明は、フォームユーザインターフェース（ＵＩ）を生成する方法および装置に関する。

同じ日に出願された以下の同時係属の、本願譲受人に譲渡された特許出願、すなわち、どちらもその全体が参照により本明細書に組み込まれる、２００４年６月３日に出願された「ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＧＥＮＥＲＡＴＩＮＧ ＦＯＲＭＳ ＵＳＩＮＧ ＦＯＲＭ ＴＹＰＥＳ」という名称の米国特許出願第１０／８６０２２６号、および２００４年６月３日に出願された「ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＭＡＰＰＩＮＧ Ａ ＤＡＴＡ ＭＯＤＥＬ ＴＯ Ａ ＵＳＥＲ ＩＮＴＥＲＦＡＣＥ ＭＯＤＥＬ」という名称の米国特許出願第１０／８６０２２５号を参照する。

エンタープライズリソースプランニング（Ｅｎｔｅｒｐｒｉｓｅ Ｒｅｓｏｕｒｃｅ Ｐｌａｎｎｉｎｇ、ＥＲＰ）システムおよびカスタマ関係管理（Ｃｕｓｔｏｍｅｒ Ｒｅｌａｔｉｏｎｓｈｉｐ Ｍａｎａｇｅｍｅｎｔ、ＣＲＭ）システムなどの一般的なビジネスソフトウエア製品およびアプリケーションにおいて、多数のフォーム（ｆｏｒｍｓ ｏｒ ｆｏｒｍ）ユーザインターフェースが使用される。フォームは、データを見るかつ／またはデータを入力するためのウィンドウ、ダイアログ、ページ、または他のＵＩ要素である。ビジネスソフトウエアアプリケーションとともに使用される多数のフォームが、数千を超えることは珍しくない。多数のフォームを開発することは、従来、ソフトウエア開発者（ｄｅｖｅｌｏｐｅｒ）の労働集約的な（ｌａｂｏｒ−ｉｎｔｅｎｓｉｖｅ）タスクであった。

さらに、ＥＲＰシステム、ＣＲＭシステム、およびアプリケーションに基づく他のフォームなどのビジネスアプリケーションにおける複雑さが増大した。これは、以下を含む多数の要因によって引き起こされる。（１）増大された機能性のためである各システムにおいて増大する数のフォーム、（２）ウェブページ有用性に慣れたエンドユーザにより生じる増大する有用性に対するフォーカス（ｆｏｃｕｓ）、（３）異なるプラットフォーム、デバイス、および技術の増大する数、（４）ユーザ権利に応じて異なるフォームを結果として生じることができるセキュリティに対する増大するフォーカス、および（５）柔軟性、効率、およびパーソナリゼーション（ｐｅｒｓｏｎａｌｉｚａｔｉｏｎ）に対する増大する要求。同時に、システムがより早くかつより高い信頼性で開発を推し進められる。

実生活ビジネスアプリケーションの一例として、結果として２０００個に近いフォームを生じる、３０００個に近いテーブルを有するＭｉｃｒｏｓｏｆｔ Ｂｕｓｉｎｅｓｓ Ｓｏｌｕｔｉｏｎｓ−Ａｘａｐｔａ（登録商標）が考えられる。各フォームは、実行時データが結び付けられる各テーブルのレイアウトとアライン（ａｌｉｇｎｅ）されなければならない。フォームおよび関連するフォーム論理は、テーブルレイアウトが変化したときはいつでも、およびビジネス論理が変化したとき、アラインされなければならない。複雑さに加えて、異なるクライアントプラットフォーム技術の数が増大する。従来のＷｉｎｄｏｗｓ ＵＩは、今やウェブブラウザ（Ｗｅｂ Ｂｒｏｗｓｅｒ）によって達成される。近い将来において、携帯情報端末（ＰＤＡ）、携帯電話、および他のＵＩ技術が、複雑さに加わるであろう。

インターネットは、アプリケーションをどのように使用するかを学ぶために１４日間のコースを必要としないことを、エンドユーザに教えた。エンドユーザは、アプリケーションがタスクを介してそれらをガイドすることを期待し、かつエンドユーザは、アプリケーションがアピールを見せることを期待する。より多くのユーザ役割（ｒｏｌｅ）が、ビジネスアプリケーションを介して示される情報技術に曝されるので、フォームが、各ユーザの必要性、および各役割が達成すべきタスクの情報を反映することへの要求が増大している。概してユーザ経験に対する要求は増大している。

一般に、ユーザ経験と開発者の経験は反対方向に働く。良好なユーザ経験は、アプリケーション開発者が作成しかつ維持することをより長くする。優れたユーザ経験を有するビジョンと、同時により高い開発者生産性をサポートすることは、両立しないように思われることがある。これは、ビジネスアプリケーションに関するフォーム生成の領域において特に真実である。

情報を呈するアプリケーションは、非常に様々な能力（ユーザのデスクトップで動作するリッチクライアント（ｒｉｃｈ ｃｌｉｅｎｔ）から、ユーザのブラウザで動作するウェブクライアントへ、ポケットデジタルアシスタンス（Ｐｏｃｋｅｔ Ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）、電話技術に基づくデバイス、およびスピーチインターフェースまでに及ぶ）のプラットフォームに可能な限りリッチな経験を、それらのユーザに提供しなければならない。ビジネスアーキテクト（ａｒｃｈｉｔｅｃｔ）は、顧客に関する問題を解決するためにビジネスエンジニアリングにおける知識を使用する。このビジネスアーキテクトは、コンピュータプログラム開発者ではなく、プログラム開発者の複雑性から保護されなければならない。

本発明は、１つまたは複数の上述の問題に対する解決方法を提供し、かつ／または従来技術に対して他の利点を提供する。

アプリケーション／ビジネスモデル（データモデルまたは問題ドメインモデル（ｐｒｏｂｌｅｍ ｄｏｍａｉｎ ｍｏｄｅｌ）とも呼ばれる）を表すために、モデルドリブン（ｍｏｄｅｌ ｄｒｉｖｅｎ）フォームユーザインターフェースを生成する方法、コンピュータ可読媒体、およびシステムが提供される。この方法は、アプリケーションモデルを表すフォームユーザインターフェースを生成する論理フォーム（ｌｏｇｉｃａｌ ｆｏｒｍ）に適用するために、複数の異なる論理フォームタイプのどれかを選択することを含む。この方法は、第１のマップを提供することをも含む。ディスプレイターゲットから独立した論理フォーム（ｄｉｓｐｌａｙ ｔａｒｇｅｔ ｉｎｄｅｐｅｎｄｅｎｔ ｌｏｇｉｃａｌ ｆｏｒｍ）は、アプリケーションモデル、選択されたフォームタイプ、および第１のマップを使用して生成される。本発明の実施形態において、第１のマップは、いくつかの実施形態において必須で定義された機能または態様を有することができるが、第１のマップは、宣言マップ（ｄｅｃｌａｒａｔｉｖｅ ｍａｐ）である。

第１のマップを使用するディスプレイターゲットから独立した論理フォームの生成は、ディスプレイターゲットから独立した論理フォームにおけるディスプレイターゲットから独立した論理制御に、アプリケーションモデルの適切なデータのタイプをマッピングすることを含む。いくつかの実施形態において、第１のマップは、ディスプレイターゲットから独立した論理フォームを生成するために使用されるマッピングエンジン（ｍａｐｐｉｎｇ ｅｎｇｉｎｅ）に対して外側である。

いくつかの実施形態において、宣言で適用される挙動（ｂｅｈａｖｉｏｒ）は、ディスプレイターゲットから独立した論理フォームに機能性を追加する。宣言で適用される挙動は、ディスプレイターゲットから独立した論理フォームに付けられ、フォームにおけるイベントによってアクティベートされる。宣言挙動は、論理制御の値および特性に応じて、他の制御に特性を設定する論理のパターンとすることができる。

この方法は、第２のマップを使用する物理的フォームに論理フォームをマッピングするステップをさらに含むことができる。論理フォームは、複数の論理制御を含むが、物理的フォームは、ディスプレイターゲットへの論理フォームのレンダリング（ｒｅｎｄｅｒｉｎｇ）で使用可能な複数の物理制御を有する。第２のマップを使用する物理的フォームへの論理フォームのマッピングは、複数の利用可能な物理制御の１つへの論理フォームの各論理制御のマッピングを含む。一般に、特定のディスプレイターゲットへの特定のフォームタイプの特定のレイアウトへのマッピングも含む。

本発明の実施形態を特徴付ける他の特徴および利点は、以下の詳細な説明を読み、関連する図面を検討することによって明らかになるであろう。

ビジネスアプリケーションおよび他の管理的なまたはフォームに基づくソフトウエアアプケーションにおいて常に複雑性が増大し、自動化に関する要求が増大する。本発明は、そのような自動化を容易にしかつ強化する方法を提供する。本発明は、革新に対する自由度を損なうことなく、ユーザインターフェースを開発するための自動化されかつ宣言的な解決方法を使用する。

本発明のシステムおよび方法を使用するアプリケーション開発者は、ビジネスモデルの開発に集中することができる。ビジネスモデル（ＵＭＬ、ＥＲダイアグラム、クラスなど）は、１つまたは複数のステップで、ディスプレイターゲットに特定の技術およびレイアウト（Ｗｉｎｄｏｗｓ、ウェブブラウザ、ＰＤＡ、電話など）に再びマッピングされる技術に独立の中間フォーマットに後でマッピングされる。フレームワーク開発者は、次に、アプリケーション開発者に無関係に、ディスプレイターゲット特有の技術をリッチにし、それを開発したアプリケーション全体に適用することができる。中間フォーマットは、フォーム毎に１回作成され、いくつかのディスプレイターゲットにわたって使用される。マッピングは、マッピングエンジンによって使用されるオープンかつ変更可能なマップにより、本来柔軟である。中間ＵＩモデルおよび最終ディスプレイターゲットフォーマットもまたオープンかつ変更可能であり、独自のレベルの柔軟性を可能にする。以下の考察は、発明概念をさらに例示した。

図１は、本発明を実施することができる適切なコンピューティングシステム環境１００の一例を示す。コンピューティングシステム環境１００は、適切なコンピューティング環境１００の一例にすぎず、本発明の使用または機能性の範囲に関して任意の制限を示唆することを目的とするものではない。コンピューティング環境１００は、任意の従属性を有するものとして解釈されるべきではなく、また例示的なコンピューティング環境１００に示される任意の１つの構成要素または構成要素の組み合わせに関連する要件であるとして解釈されるべきではない。

本発明は、多数の他の一般的な目的、または特定の目的のコンピューティングシステム環境または構成で動作する。本発明での使用に適切とすることができる良く知られているコンピューティングシステム、環境、および／または構成の例は、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサに基づくシステム、セットトップボックス、プログラム可能な消費者電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、任意の上述のシステムまたはデバイスを含む分散コンピューティング環境などを含むが、それらに限定されない。

本発明は、コンピュータによって実行されるプログラムモジュールなど、コンピュータ実行可能命令の一般的な文脈で述べることができる。一般に、プログラムモジュールは、特定のタスクを実行しまたは特定の抽象データタイプを実施する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明は、タスクが、通信ネットワークを介してリンクされたリモート処理デバイスによって実行される分散コンピューティング環境で実行することもできる。分散コンピューティング環境において、プログラムモジュールは、メモリストレージデバイスを含むローカルおよびリモートコンピュータ記憶媒体の両方に位置することができる。

図１を参照して、本発明を実施するための例示的なシステムは、コンピュータ１１０の形態での一般的な目的のコンピューティングデバイスを含む。コンピュータ１１０の構成要素は、処理装置１２０、システムメモリ１３０、システムメモリを含む様々なシステム構成要素を処理装置１２０に結合するシステムバス１２１を含むが、それらに限定されない。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺バス、および任意の様々なバスアーキテクチャを使用するローカルバスを含む、任意のいくつかのバス構造のタイプとすることができる。一例として、限定されずに、このようなアーキテクチャはＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとしても知られるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスを含む。

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

システムメモリ１３０は、読取専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性および／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。起動時などコンピュータ１１０内の要素間で情報を転送することを助ける基本的ルーチンを含む、基本入出力システム１３３（ＢＩＯＳ）は、一般にＲＯＭ１３１内に格納される。ＲＡＭ１３２は、一般に、処理装置１２０によって即時アクセス可能であり、かつ／または処理装置１２０によって現在処理されているデータおよび／またはプログラムモジュールを含む。例示として、図１は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示すが、それらに限定されない。アプリケーションプログラムの特定のグループは、ビジネスアプリケーションと呼ばれる。これらは、総勘定元帳、在庫、給与、顧客、販売、購買、財務報告、およびビジネスに関して関係がある任意の他のデータの取り扱いを含むが、それらに限定されない企業の管理を目標とする。

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

上記で論じた、また図１に示されている、ドライブおよびそれらに結合されるコンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造、プログラムモジュール、コンピュータ１１０に関する他のデータのストレージを提供する。例えば、図１において、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するものとして示される。これらのコンポーネントは、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じとすることも、異なるものとすることもできることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７は、それらが最低異なるコピーであることを示すために、本明細書で異なる番号が与えられている。

ユーザは、キーボード１６２、マイクロフォン１６３、およびマウス、トラックボール、またはタッチパッドなどのポインティングデバイス１６１などの入力デバイスを介して、コマンドおよび情報をコンピュータ１１０に入力することができる。他の入力デバイス（図示せず）は、ジョイスティック、ゲームパッド、衛星パラボラアンテナ、スキャナなどを含むことができる。これらおよび他の入力デバイスは、システムバスに結合されるユーザ入力インターフェース１６０を介して処理装置１２０にしばしば接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースおよびバス構造によって接続することができる。入力デバイスは、データを作成し、修正し、および削除するために使用される。入力デバイスは、本明細書におけるアプリケーションプログラムおよび特定の機能を制御（開始および停止）するためにも使用することができる。機能は、フォームを開き（示し）かつフォームを閉じることを含む。モニタ１９１または他のタイプのディスプレイデバイスは、ビデオインターフェース１９０などのインターフェースを介して、システムバス１２１にも接続される。モニタに加えて、コンピュータは、スピーカ１９７およびプリンタ１９６など、出力周辺インターフェース１９５を介して接続することができる他の周辺出力デバイスを含むこともできる。モニタまたは他のディスプレイデバイスは、フォームを示す（レンダリングする）ために使用される。

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

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

図２は、代替の例示的なコンピューティング環境であるモバイルデバイス２００のブロック図である。モバイルデバイス２００は、マイクロプロセッサ２０２、メモリ２０４、入出力（Ｉ／Ｏ）コンポーネント２０６、およびリモートコンピュータまたは他のモバイルデバイスと通信するための通信インターフェース２０８を含む。一実施形態において、後述されるコンポーネントは、適切なバス２１０にわたって互いに通信のために結合される。

メモリ２０４は、モバイルデバイス２００に対する一般的な電力がシャットダウンされたとき、メモリ２０４内に格納された情報が失われないように、バッテリバックアップモジュール（図示せず）を有するランダムアクセスメモリ（ＲＡＭ）などの不揮発性電子メモリとして実装される。メモリ２０４の一部は、好ましくはプログラム実行のためにアドレス指定可能なメモリとして割り当てられ、一方、メモリ２０４の他の部分は、ディスクドライブのストレージをシミュレートするなど、ストレージのために使用されることが好ましい。

メモリ２０４は、オペレーティングシステム２１２、アプリケーションプログラム２１４、ならびにオブジェクトストア２１６を含む。動作中、オペレーティングシステム２１２は、好ましくは、メモリ２０４からプロセッサ２０２によって実行される。好ましい一実施形態において、オペレーティングシステム２１２は、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎから利用可能な市販のＷＩＮＤＯＷＳ（登録商標）ＣＥブランドオペレーティングシステムである。オペレーティングシステム２１２は、好ましくはモバイルデバイス用に設計され、一組のエクスポーズされたアプリケーションプログラミングインターフェースおよびメソッドを介して、アプリケーション２１４によって利用することができるデータベース機能を実装する。オブジェクトストア２１６内のオブジェクトは、エクスポーズされたアプリケーションプログラミングインターフェースおよびメソッドに対する呼出しに少なくとも部分的に応答して、アプリケーション２１４およびオペレーティングシステム２１２によって維持される。

通信インターフェース２０８は、モバイルデバイス２００が情報を送信しかつ受信することを可能にする多数のデバイスおよび技術を表す。デバイスは、二、三の例をあげれば、有線および無線モデム、衛星受信器、およびブロードキャストチューナを含む。モバイルデバイス２００は、間でデータを交換するためにコンピュータに直接接続することもできる。そのような場合、通信インターフェース２０８は、赤外線受信器またはシリアルあるいはパラレル通信接続とすることができ、それら全ては、ストリーミング情報を転送することができる。

入出力コンポーネント２０６は、タッチセンシティブスクリーン、ボタン、ローラ、およびマイクロフォンなどの様々な入力デバイス、ならびにオーディオジェネレータ、振動デバイス、およびディスプレイを含む様々な出力デバイスを含む。上で列挙されたデバイスは、例示であり、モバイルデバイス２００に必ずしも全て存在する必要はない。さらに、他の入出力デバイスが、モバイルデバイス２００に取り付けられ、またはモバイルデバイス２００とともに見出される可能性がある。

層状にされ（ｌａｙｅｒｅｄ）かつマッピングされたＵＩアーキテクチャおよび方法
上述のように、情報を示すアプリケーションは、非常に様々な能力のプラットフォーム（例えばディスプレイターゲット）で、可能な限りリッチな経験をユーザに提供しなければならない。これらのプラットフォームは、ユーザのデスクトップ上で実行するリッチなクライアントから、ユーザのブラウザで動作するウェブクライアントへ、ＰＤＡへ、電話技術に基づくデバイスへ、さらにはスピーチインターフェースに及ぶ。他のプラットフォームも可能である。本発明の実施形態によれば、当該プラットフォーム上でネーティブ（ｎａｔｉｖｅ）制御に、どのようにデータタイプをマッピングするかを規範的に定義するスキーマが用いられる。

ビジネスアーキテクトは、顧客に関する問題を解決するためにビジネスエンジニアリングでの知識を使用する。しかしながら、このビジネスアーキテクトは、一般にコンピュータプログラム開発者ではなく、理想的にはプログラム開発の複雑性から保護される。本発明は、ビジネスアーキテクト（ユーザ）が、アプリケーションのビジネス論理に焦点を合わすが、どのようにデータが、所定のプラットフォーム上に存在するかに焦点を合わせないことを可能にする方法および装置を提供する。提示された発明は、アプリケーション開発者が、ビジネスのモデルに基づき、複数のディスプレイターゲットを目標にし、かつ各ディスプレイターゲットの技術的能力を利用するユーザインターフェースを導き出すことを可能にする。

これは、開発者が、「正しい」抽象レベルを有する層に対する知的な労力に焦点を合わせることを可能にする、層状にされたＵＩ定義によって達成される。パターンは、各抽象化レベルで捕捉されかつ再使用される。抽象化のより高いレベルからより多くの特定のレベルへのマップは、マッピングプロセスにおけるパターンを捕らえるが、アプリケーション開発者が、結果を微細に調整することも可能にする。本発明は、制御、論理フォームタイプ、および挙動にしたがって、ターゲットの特定の物理モデルを表示するビジネスモデルをマッピングするために、これらのマップを使用する。

本発明の方法において、ビジネスモデルがマスタである。ビジネスモデルに行われる知的作業は、保存され、かつユーザインターフェースを生成することに基づくように使用される。モデルは、Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ（ＵＭＬ）、ｅｎｔｅｒｐｒｉｓｅ ｒｅｓｏｕｒｃｅ（ＥＲ）ダイアグラム、または任意の他のグラフィカルまたは非グラフィカルモデリング言語で記述することができる。ビジネスモデルは、従来のオブジェクト指向プログラム、関連データベース、または他のフォーマットに見出すこともできる。以下に記載されるように、本発明のいくつかの例示的な実施形態において、ビジネスモデルは、プロパティを有するエンティティのクラス階層である。

本発明の実施形態において、ビジネスモデルは、ディスプレイターゲットから独立したユーザインターフェースの中間モデルにマッピングされる。ＵＩモデルは、最終ディスプレイターゲットについてどんな技術知識をも必要とすることなしに、アプリケーション開発者がそれを見てかつ修正することを可能にする高い抽象化レベルで記述される。コードは、全てのディスプレイターゲットに関して作用するＵＩモデルに追加することができる。ＵＩモデルにおけるパターンが捕捉され、それらは再使用することができ、結果として同種のＵＩを生じる。ＵＩモデルを記述するために使用されるビルディングブロックは、拡張することもできる。

以下により詳細に記載されるように、本発明のいくつかの実施形態において、エンティティは、論理制御を有する論理フォームを含む「論理ＵＩ」と呼ばれるＵＩモデルにマッピングされる。エンティティおよび特性は、設計時に、それぞれ論理フォームおよび論理制御にマッピングされる。実行時において、論理フォームおよび論理制御データは、エンティティおよび特性に結び付けられる。フォームにおけるパターンは、フォームタイプと呼ばれる。フォームおよび制御は、コアクライアントマッピングエンジンによって使用されるが、コアクライアントマッピングエンジンの一部ではない。コアクライアントは、ＵＩクライアントのディスプレイターゲットの独立した部分である。本発明の実施形態において、論理制御およびフォームタイプのリストは、拡張することができる。本発明のこれらの態様のさらなる考察は、また以下に提供される。

本発明のいくつかの実施形態において、ＵＩモデルは、アクティブサーバページ言語（ＡＳＰ．ＮＥＴ）、無線マークアップ言語（ＷＭＬ）、ハイパーテキストマークアップ言語（ＨＴＭＬ）などのディスプレイターゲットに特定のマークアップ言語にマッピングされる。ＵＩモデルは、他のディスプレイ技術（例えば、Ｗｉｎ３２、ＷｉｎＦｏｒｍｓ、ＰｏｃｋｅｔＰＣ）にマッピングすることができる。本発明の１つの特定の例示的な実施形態において、論理的なフォームは、ウェブクライアントディスプレイターゲット、ＷｉｎＦｏｒｍｓクライアントディスプレイターゲットなどにマッピングされ、新たなディスプレイターゲットが動的に追加することができる。

本発明の実施形態によれば、マッピングは、オープンでありかつ変更可能な宣言マップに基づく。ＵＩにおけるパターンは、マップにおいて捕捉される。マップは、結果として高いレベルの柔軟性を生じるいくつかの条件に基づいて行うことができる。異なるモデルは、それらがマッピングされた後、（コードを介することを含み）手動で修正することができる。これは、最終レベルの柔軟性を開発者に与える。マップの動的な性質は、制御などの新たなＵＩ要素の開発および使用を可能にする。新たな制御は、新たな制御に特性をマッピングすることによって、フォームで簡単に使用可能にされる。新たな制御は、所定の契約に従わなければならず、この実施形態において、新たな制御は、特定のベースクラスを引き継がなければならない。実行時に、論理フォームはエンティティに結合され、ディスプレイターゲットは論理層に結合される。これは、ディスプレイターゲット間に共通の全ての機能性（セキュリティ、パーソナリゼーション、イントラフォーム論理）が、論理層で１回実装されかつ多くの例で使用されることを可能にする。

フォームタイプ
本発明は、ビジネスおよび他のアプリケーションのためのフォームユーザインターフェース（フォーム）を構築する新規な方法を提供するために、論理フォームおよび論理フォームタイプの概念を使用する。本発明の例示的実施形態または実装において、論理フォームおよび論理フォームタイプが使用されるが、論理層の使用は、全ての実施形態で必要ではない。したがって、本発明は、一般的なフォームを形成するためにフォームタイプの使用に適用される。現在のビジネスアプリケーションは、一般に、しばしばわずかな数のカテゴリに入りまたは同様のパターンに従う多数のフォームからなる。カテゴリの数は、一般に２から２０であるが、より多く定義することができる。本発明のフォームタイプは、設計時および実行時の両方でビジネスまたはアプリケーションモデルに保存しおよび作用することによって、モデルドリブンユーザインターフェースを容易にする。これは、ソフトウエア開発者に抽象化の高いレベルを提供する。さらに、本発明によるフォームタイプの使用は、全てのフォームは、わずかな個別のタイプになるので、より多くの均一なフォームユーザインターフェースの１組の再使用することを確実にし（１つの層が多数回使用される）、より容易に維持されるフォームを確実にする（タイプのレイアウトは、フォームを変更することなく変更することができ、異なるタイプは、フォームを変更することなく適用することができる）。本発明は、アプリケーション開発者が、アプリケーションのルック・アンド・フィールの複数のディスプレイターゲットにわたる完全な制御を有し、アプリケーション内のどのようにナビゲーションが行われるかを確実にする。ディスプレイターゲットの例は、現在および将来のオペレーティングシステムの各複数のタイプ、ならびに多くの利用可能なまたは将来の各モバイルデバイスを含む。他の例として、特定のオペレーティングシステム上の各レンダリング技術が、ディスプレイターゲットにもなり得る。

本発明の概念を使用して、論理フォームは、論理フォームをディスプレイターゲット自体に独立にする、論理制御に独立のディスプレイターゲットを含む。論理フォームは、論理フォームが従わなければならないパターンを定義する論理フォームタイプを参照する。論理フォームによって参照される論理フォームタイプは、論理フォームの外観およびコンテンツを迅速に確立するために、複数の異なる論理フォームタイプから選択することができる。本発明の実施形態において、論理フォームタイプは、ビジネスまたは他のアプリケーションモデルと組み合わされたとき、結果として論理フォームの生成を生じるモデルである。

論理フォームタイプは、フォームが、ビジネスモデルを論理的モデルに（アプリケーション開発者を介して自動的にまたは手動で）、かつこれから物理的モデルへマッピングするマップ（またはルール）に従わなければならないスキーマ（フォームの構造を記述し、どの要素をそれが含むことができるなど）を明らかにする。さらに、フォームタイプは、（論理的）フォームの動的挙動を修正するコードを含むことができる。それゆえ、フォームタイプは、スタイルおよびレイアウト情報、およびディスプレイターゲットの他のタイプの特定情報を明らかにする。しかしながら、それらは、論理フォームおよびそのコンテンツに関するルールも特定するので、それらは、より大きな役割を果たす。本発明のフォームタイプの特定の態様は、以下のように導入される。

異なるフォームタイプ
上述のように、本発明の一般的な使用において、複数の異なるフォームタイプは、フォームの形成においてアプリケーション開発者による使用のために提供される。例えば、１つの例示的な実施形態において、フォームタイプは、Ｄｉａｌｏｇフォームタイプ、ＣａｒｄまたはＣａｒｄＶｉｅｗフォームタイプ、ＬｉｓｔＶｉｅｗフォームタイプ、ＥｎｔｉｔｙＯｖｅｒｖｉｅｗフォームタイプ、およびＡｃｔｉｖｉｔｙＣｅｎｔｅｒフォームタイプを含むことができる。これらのフォームタイプは、一例におけるビジネスアプリケーションにおいて使用されるフォームの典型的な異なるカテゴリに対応する。したがって、複数のフォームタイプを提供することは、アプリケーション開発者が、従来技術のビジネスアプリケーションを作るフォーム全てを構築することを可能にする。当業者によって理解されるように、これらの特定のフォームタイプは、単に一例であり、本発明は、任意の特定のフォームタイプまたは任意の特定の数のフォームタイプに限定されない。

フォームタイプレイアウト
レイアウト情報のコンテンツおよび構造は、各フォームタイプに関して異なることがある。さらに、レイアウト情報は、ディスプレイターゲットに特定であり得る。例えば、ＡｃｔｉｖｉｔｙＣｅｎｔｅｒフォームタイプに関するレイアウト情報は、特定のオペレーティングシステムプラットフォーム上でフォームをディスプレイするためのＨＴＭＬ（すなわち、Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂすなわちインターネット）ディスプレイターゲットによって使用される、Ｔｈｅｍｅｓ／Ｓｋｉｎｓ／ＳｔｙｌｅｓおよびＭａｓｔｅｒ Ｐａｇｅのためのサポートを有することができる。これは、異なるディスプレイターゲットを刷新し、かつ必要なだけ多くのフォームユーザインターフェースを微調整（ｔｗｅａｋ）するために、ビジネス開発者に自由を与える。

プラグ可能（ｐｌｕｇｇａｂｌｅ）および拡張可能
フォームタイプは、独立ソフトウエアベンダ（Ｉｎｄｅｐｅｎｄｅｎｔ Ｓｏｆｔｗａｒｅ Ｖｅｎｄｏｒ、ＩＳＶ）が、それらを修正しまたは拡張することができ、新たなフォームタイプを作ることができるので、完全な柔軟性および拡張性を提供し、それによってアプリケーション全体に関するルック・アンド・フィールを変更する。

さて図３−１および図３−２を参照すると、本発明の例示的な実施形態にしたがって、Ｃａｒｄフォームタイプを使用して作られた販売注文論理フォームの概略が示される。この例において、販売注文論理フォームは、３つの異なる論理制御グループにまとめられる一組の論理制御を含む。以下にさらに記載されるように、Ｃａｒｄフォームタイプは、どのようにかつどこで制御が、異なるディスプレイターゲットで物理的フォームに現れるかを定義する。図３−１および図３−２は、同じ情報を示し、図３−２は、論理フォームタイプと論理フォームとの間の関係および情報の起源と、論理フォームから物理的フォームの生成とを示す矢印を含む。

図３−１および図３−２は、フォームタイプ３００を使用して生成されたフォームインスタンス（ｆｏｒｍ ｉｎｓｔａｎｃｅ）３０５を概略的に示す。コアクライアント３１０で、フォームインスタンス３０５は、（フォームの概念モデルとして示される）論理フォーム３０６であり、フォームタイプ３００は、論理フォームタイプ３０１である。ディスプレイターゲット３２０で、フォーム３０５は、論理フォーム３０６を使用し、かつ最終的には論理フォームタイプ３０１から作られたレンダリングされたフォーム３７０である。レンダリングされたフォーム３７０は、１つの特定の実装であるが、多くの他の実装またはレンダリングを達成することができる。レンダリングされたフォーム３７０は、物理的フォームとして参照することもできる。

フォームタイプ３００は、２つの部分を含む。すなわち、何が、フォームタイプを使用する特定のフォームに含まれるべきかを定義するスキーマ３３０、およびどのようにフォームが、特定のディスプレイターゲットにレンダリングされまたは引き出されるかを特定する制御を含むレイアウト３３１である。フォームタイプは、コードビハインド（ｃｏｄｅ−ｂｅｈｉｎｄ）クラスを含むこともできる。フォームタイプによって使用することができる異なるレイアウトを有することによって、フォームタイプを使用して作られるフォームは、異なるディスプレイターゲット（例えば、携帯電話ディスプレイ、携帯情報端末ディスプレイ、パーソナルコンピュータモニタなど）に合わせることができる。複数のフォームで使用されるべき捕捉されたパターンを示すフォームタイプ３００で、複数のフォームインスタンス３０５は、フォームタイプ３００を使用して生成することができる。

この例に関して、販売注文エンティティまたはオブジェクトモデル（すなわち、ビジネスまたはアプリケーションモデル）に関してフォームを作るために、開発者が行うことができるプロセスを考慮する。第１に、開発者は、どの種類のフォームを開発者が選択すべきかを知るために見ることができる。図３−１および図３−２に３２５で示されるように「Ｃａｒｄ」フォームタイプを選択することは、図３−２に矢印３２６によって示されるように、Ｃａｒｄスキーマ３３０を呼び出しまたは指定する。

開発者は、特定のフォームタイプおよび関連スキーマを特定するときに、開発者は、いくつかの実施形態において、ユーザのビジネスからのメタデータ（ｍｅｔａ ｄａｔａ）またはフィールド値にポピュレーティング（ｐｏｐｕｌａｔｉｎｇ）する他のモデルで、スキーマによって示される情報またはフィールドをフォームに含むように選択する。例えば、Ｃａｒｄフォームタイプ３０１（および選択されたＣａｒｄスキーマ３３０）を選択することによって、論理フォーム３０６は、スキーマ３３０において定義されるコンテンツエリア３３５に対応するコンテンツエリア３３６を含む。コンテンツエリア３３５に対応するコンテンツエリア３３６の起源は、図３−２で矢印３３７によって示される。同様に、Ｃａｒｄフォームタイプのスキーマ３３０は、ＵＩパートエリア３４０、関連するエンティティＵＩパートエリア３４５、およびアクションエリア３５０を含むため、論理フォーム３０６は、３４１、３４６、および３５１で示されるこれらエリアまたはフィールドを含む。再び、これらフィールドの起源は、矢印３４２、３４７、および３５２によって概略的に図示される。

上述したように、フォームが、どのように特定のディスプレイターゲットにレンダリングされまたは引き出されるべきかを特定する制御を含む、少なくとも１つのレイアウト３３１（通常は、ディスプレイターゲット毎に１つ）も含む。図３−１および図３−２に概略的に図示されるように、ｃａｒｄフォームタイプに関するレイアウトは、ディスプレイターゲット３２０が、コンテンツエリア３３９、ＵＩパートエリア３４４、関連するエンティティＵＩパートエリア３４９、およびアクションエリア３５４を含むことをもたらす制御を含む。矢印３３８、３４３、３４８、および３５３は、Ｃａｒｄスキーマにおけるそれらの対応するエリアに対する、ｃａｒｄレイアウトにおけるこれらのエリアの相関を図示する。選択された論理フォームタイプおよびアプリケーションモデルからのメタデータを使用して生成された論理フォーム３０６（この例では販売注文エンティティ）は、ディスプレイターゲット３２０上の物理的フォーム３７０としてレンダリングされる。このプロセスは、矢印３６１および３６２を使用して図３−２に示される。

モデルおよびマップ
多くの情報システムは、モデルを使用する。モデルの例は、オブジェクトダイアグラム、拡張可能なマークアップ言語（ＸＭＬ）スキーマ、データベース定義、およびフォーム定義である。モデルは、特性、組成、および関連をそれぞれ含む、しばしば一組のオブジェクトとして識別される。ビジネスＵＩにおいて、フォームをレンダリングするために使用される制御階層は、Ｗｉｎｄｏｗｓ制御ツリー、およびハイパーテキストマークアップ言語（ＨＴＭＬ）オブジェクトモデルなどのモデルとして考えることができる。また、ユニファイドモデリング言語（ＵＭＬ）などのシンタックスは、モデル（例えばクラス定義）を定義するために使用することができる。本発明の方法を図示するために使用される例のフレームワークにおいて、アプリケーションは、ビジネスエンティティを使用してモデル化される。したがって、ビジネスモデルは、エンティティと呼ばれるこれらのビジネスオブジェクト、エンティティ間の関係、およびエンティティの特性からなる。単純なモデル３８０の一例に関して、図４−１に示されるエンティティ３８１、３８２、３８３、および３８４を参照されたい。エンティティは、特性（例えば、エンティティ３８１の特性３８５を参照）、および他のエンティティとの関係（例えば、エンティティ３８１および３８４間の関係３８６を参照）を有する。

モデルが他のモデルに変換されるとき、マップは、明示的にまたは時々暗示的に使用される。マップは、モデル間の関係を記述する。いくつかの例は、ＸＭＬへＸＭＬをマッピングするような拡張可能なスタイルシート言語変換（ＸＳＬＴ）、特定のデバイスサーフィスにオブジェクトモデルをレンダリングするために使用される制御、１つのアプリケーションから他のアプリケーションへのオーダのマッピング（異なるアプリケーションにおけるオーダは、異なるフォーマットを有することがあるので）、およびクラス定義へＵＭＬをマッピングするコンピュータ支援ソフトウエアエンジニアリング（ＣＡＳＥ）ツールを含む。

現在のビジネスアプリケーションにおいて、マップは、マッピングが、入力として特定のオブジェクトを取りかつ他のオブジェクトに戻るコード内の「ｓｗｉｔｃｈ」ステートメントとしてコード化される、オブジェクトアットアタイム（ｏｂｊｅｃｔ−ａｔ−ａ−ｔｉｍｅ）マッピングを使用して主としてプログラムされる。したがって、従来のビジネスアプリケーションは、一般に、一般的なプログラミング言語のコードで書かれた必須のマップを使用する。本発明にしたがってモデルアットアタイム（ｍｏｄｅｌ−ａｔ−ａ−ｔｉｍｅ）を使用して、生産性を桁単位で改善することができることが提示される。生産性の利益に加えて、マップを使用して他のモデルに対するモデルのマッピングとして、ＵＩ生成の問題がわかる精神的な利益がある。さらに、他の利点は、本発明の宣言的に定義されたマップに見出されるより高いアブストラクションレベルである。本発明は、マップが明示されかつ宣言されることを可能にする。本発明において、マップは、宣言的または必須である（コードにおけるマッピングより優先できる事実による）ことができる。

マップの明示的な性質は、マップが、マッピングまたはレンダリングするために使用される生成エンジンに対して外部にあり、かつマップが、それ自体マップであることを意味する。つまり、マップの明示的な性質は、それらが、制御およびフォームから別個に定義されることを意味する。従来、このマッピングは、コントロールコードおよびフォームコードの内部で暗示的に行われていた。

マップの宣言的な性質は、マップが、必須ではない（一般的にプログラミング言語でコード化される）ことを意味する。本明細書で使用されるように、句「宣言的に定義される」は、マップが、従来の場合のようにコードだけで定義されるのでなく、マップを容易に変更することを可能にするフォーマットで定義されることを意味する。宣言的に定義されたフォーマットの例は、限定はしないが、ＸＭＬドキュメント、コンマ分離された（ｃｏｍｍａ−ｓｅｐａｒａｔｅｄ）ファイル、ＢｉｚＴａｌｋマップ（データスキーマの他へのマッピング）、およびＭＢＦエンティティマップ（データスキーマへのオブジェクトモデルのマッピング）を含む。広範な様々な宣言的なマッピングフォーマットは、本発明にしたがって使用することができ、選択されるフォーマットは、特に重要ではない。宣言マップが制限された一組の可能性を有することが重要であり、したがって、マップを定義するために、直感的な（ｉｎｔｕｉｔｉｖｅ）設計ツールを提供することをより容易にする。対照的に、必須なマップ（コードを使用する）は、プログラミング言語を介してほぼ制限されない可能性を有し、したがって、直感的な設計ツールを作ることは非常に困難である。代わりに、プログラミングスキルは、それを作るために必要である。

宣言マップを使用する本発明の実施形態において、マップは、必ずしも宣言的である必要はないことに留意されたい。宣言的に定義されるには複雑過ぎるマップを作ることが必要な場合には、そうでなければ宣言的であるマップに必須マッピングの態様を含むことができる。例えば、複雑な機能を作成し、マップに含むことができる。一例は、送り状アドレス（Ｉｎｖｏｉｃｅ Ａｄｄｒｅｓｓ）および輸送アドレス（Ｓｈｉｐｐｉｎｇ Ａｄｄｒｅｓｓ）が、ほぼ同じであれば、送り状アドレスだけがフォームに示されることであり得る。２つのアドレスがほぼ同じであるかどうかを決定するアルゴリズムは、マップ内で使用される暗示的に定義された関数とすることができる。

本発明は、分散されたサービス指向のアーキテクチャに基づくビジネスアプリケーションの開発および展開に適切なプログラミングアブストラクションおよび規定されたアーキテクチャを提供する。フレームワークは、それらアブストラクションに書かれたビジネス論理を基本になる技術への変化から隔離し、ビジネスアプリケーション開発チームの重要なアセット（ａｓｓｅｔ）を保存する。本発明は、コード生成を有する設計時モデルから、実行時においてビジネスモデルを解釈することができる、真の「モデルアウェアアプリケーションサービス（ｍｏｄｅｌ ａｗａｒｅ ａｐｐｌｉｃａｔｉｏｎ ｓｅｒｖｉｃｅ）」へ移動する、モデルドリブン開発への解決方法へ拡張する。

マップに基づくモデルドリブンＵＩ
本発明の実施形態で構築された、ビジネスアプリケーションのためのＵＩを生成するとき、アプリケーションモデルを有することは重要な特徴である。ＵＩの大部分は、ビジネス論理のモデルおよびマップに基づいてだけで生成することができる。アプリケーション開発者が、新規なエンティティをモデル化したとき、ＵＩは、これから生じる。これは、ＵＩモデル３９０へマッピングされる（３８８で示される）ビジネスモデル３８０を示す図４−２に概略的に示される。矢印３８８は、マッピングプロセス、ならびにマッピングプロセスを行うためにマップを使用する適切に構成されたマッピングエンジンを示す。

このマッピングは、従来のコード化技術を使用して達成することができるが、マッピングは、ある種の挑戦課題に対処すべきなら単純ではない。挑戦課題は、新たな特性のタイプがエンティティで作られかつ使用されるとき、コード化された変換は、どのように新たなタイプを取り扱うかを知らないことがあり、したがって変換は、修正されかつ再編集されなければならないことである。他の挑戦課題は、変換に含まれる場合だけ価値がある、新たに開発された制御を取り扱うことであり、これもやはり、変換を再プログラミングすることになる。本発明のマッピング技術は、これら挑戦課題に対処することを可能にする。実行時においてＵＩの任意の修正（コードを介して）は、マッピングを考慮することもできることに留意されたい。本発明において使用されるプラットフォームは、層状にされたＵＩモデルを明らかにし、かつ１つの層から他の層にモデルを変換するためにマップを使用する。これは、より詳細に以下に記載される。

本発明の方法および装置は、どのように所定のプラットフォームでユーザにビジネス情報を示すかを計算する方法を提供する。本発明は、まさにアブストラクトモデル（対話するためにビジネスエンティティを記述する）から具体的なモデル（どのデバイスに固有の制御が、ビジネス情報をレンダリングするために使用されるべきであるかを正確に特定する）へ作用する、他のモデルへのモデルのマッピングに基づく。一般に、このマッピングは、任意の数のステップを含むことができる。

例えば、２つの明示的でありかつ宣言的なマッピングステップを使用して、マスタモデル４０５から専門（ｓｐｅｃｉａｌｉｚｅｄ）モデル４２５へのマッピングのプロセスを示す、図５−１に示されるブロック図４００を考慮する。マスタモデル４０５（すなわち、「モデルＡ」）は、例えばデータベース、テーブル、エンティティ、オブジェクト、またはユーザに固有の問題ドメインにおける他のタイプのモデルとすることができる。マスタモデル４０５は、マップ４１０を使用する４１１で示されるマッピングステップ（すなわち「Ａ−Ｂマップ」）を用いて、中間モデル４１５（すなわち「モデルＢ」）にマッピングされる。中間モデル４１５は、以下により詳細に記載されるように、論理制御を有するディスプレイターゲットから独立したモデルとすることができる。中間モデル４１５は、第２のマップ４２０を使用する４２１で示されるマッピングステップ（すなわち「Ｂ−Ｃマップ」）を用いて、専門モデル４２５（すなわち「モデルＣ」）に次にマッピングされる。専門モデル４２５は、以下により詳細に記載されるように、物理制御を有するディスプレイターゲットに固有のモデルとすることができる。マッピングステップ４１１および４２１を示すために使用される矢印は、また、マッピングステップを実施するためにマップ４１０および４２０を利用するために構成されたマッピングエンジンを表す。

本発明のいくつかの実施形態によれば、ユーザがクライアントプラットフォームでビジネス情報と対話することをどのように可能にするかを決定することを含むマッピングスキーマは、以下に記載されかつ図５−２のブロック図４５０に概略的に示されるような少なくとも３つのステップを含む。初期のモデル４５５（図５−１に示されるマスタモデル４０５も参照）は、ユーザが対話しなければならないビジネスエンティティに関する情報を含む。このアプリケーションモデルの各データは、特定のタイプである。第１のステップは、示すデータの所定のタイプ（ストリング、整数、金銭上の値を示す１０進法タイプ、他の値を含むアドレスなど）を用いるための論理制御を決定することを含む。

所与のタイプに関する使用のための論理制御は、モデル４５５におけるデータタイプからモデル４６５における論理制御へのマッピングを使用して決定される。マッピングプロセスは、４６１で示され、マップ４６０（すなわち、「論理制御マップに対するデータタイプ」）を使用する。論理制御は、いくつかの有用な特性を有する。それらは、任意の特定のディスプレイターゲットに対する従属性からは完全に自由であるが、物理制御に特定の挙動を管理する特性を保持する。論理制御のルックアップは、階層タイプを考慮して実行される。論理制御が、特定のタイプの特性を要約するために特に適していないなら、サーチは、論理制御が扱うタイプを見出すまでベースタイプで継続する。

論理制御が、示されるデータのタイプから識別されると、所定のプラットフォームにレンダリングを実際に実行するために使用される物理制御は、見出さなければならない。これらの物理制御は、時々「アダプタ」と呼ばれる。これは、論理制御およびディスプレイターゲットから物理制御を生み出す、他のマッピングを使用して行われる。マッピングプロセスは、４７１に示され、論理制御モデル４６５から物理制御モデル４７５を生成するためにマップ４７０（すなわち「物理制御に対する論理制御マップ（ｌｏｇｉｃａｌ ｃｏｎｔｒｏｌ ｔｏ ｐｈｙｓｉｃａｌ ｃｏｎｔｒｏｌ ｍａｐ）」）を使用する。

クライアントが、ユーザのディスプレイターゲットで動作するとき、物理制御は、ユーザと対話するために使用されるネーティブ制御のインスタンスを作るために使用される。これは、物理制御から一組のネーティブ制御を生じる第３のマッピングによって行われる。例えば、物理制御がアドレス制御であった場合、物理制御は、ストリート、町、国に関するネーティブ制御にマッピングされる。マッピングプロセスは、４８１に示され、物理制御モデル４７５からネーティブ制御モデル４８５を生成するためにマップ４８０（すなわち「ネーティブ制御への物理制御マップ（ｐｈｙｓｉｃａｌ ｃｏｎｔｒｏｌ ｔｏ ｎａｔｉｖｅ ｃｏｎｔｒｏｌ ｍａｐ）」）を使用する。いくつかの実施形態において、これは、必須のマップであるが、必ずしもそうである必要はない。再び、矢印４６１、４７１、および４８１は、また、マップ４６０、４７０、および４８０によって特定されるように、マッピング機能を実行するために使用されるマッピングエンジンを示す。

上述のマッピングは、所望の結果を達成するために他のマッピングで論じることができる。他の要因は、レンダリングされるフォームのタイプ（カードまたはリストビュー）、ユーザルール（恐らくユーザに提供される情報を制限する）を含む。アブストラクトモデルから具体的モデルへ達するプロセスは、純粋に規定され（含まれるマッピングを記述することによって）、柔軟性は、３つのマッピングを変更できることによってもたらされる。

他の例として、図５−３は、顧客の名前および識別ナンバ（ＩＤ）から、ブラウザにこの情報をレンダリングするために使用されるＨＴＭＬを得るためのマッピングプロセスを示すブロック図５００を示す。マスタまたは初期のビジネスモデル５０５は、エンティティ（またはオブジェクト）、または特性として顧客の名前およびＩＤを有するエンティティのクラス（またはオブジェクトのクラス）である。モデル５０５の「名前」および「ＩＤ」特性は、それぞれ「ストリング」および「ナンバ」のタイプである。モデル５０５は、規定のマップ５１０を使用してモデル５１５の論理制御層にマッピングされる。マッピングプロセスは、５１１に示される。この例において、データタイプ「ストリング」は、「ＴｅｘｔＢｏｘ」論理制御にマッピングされ、一方、データタイプ「ナンバ」は、「ＮｕｍｂｅｒＢｏｘ」論理制御にマッピングされる。

次に、論理制御モデル５１５は、マップ５２０を使用してＨＴＭＬモデル５２５にマッピングされる。マッピングプロセスは、５２１で示される。この例において、モデル５２５は、ＨＴＭＬモデルのフォームにおける物理制御モデルである。したがって、マップ５２０は、モデル５１５の論理制御をモデル５２５におけるＨＴＭＬタグまたは要素にマッピングする。ＨＴＭＬモデル５２５は、次に、ブラウザにおけるモデル５０５からの情報をレンダリングするために使用される。再び、マッピングステップ５１１および５２１を示すために使用される矢印は、また、マッピングプロセスを実施するためのマップ５１０および５２０を使用する適切に構成されたマッピングエンジンを表す。

図５−４は、いくつかの異なる特性タイプを同一の最終制御にマッピングすることができ、したがって必要な制御の数は、特性タイプの数が増加するとき必ずしも増加しない、本発明の実施形態のさらなる態様を示す。図５のブロック図５５０に示されるように、異なるタイプの特性５６１を有するビジネスモデル５６０は、マップ５５５を使用するディスプレイターゲットモデル５８０にマッピングされる。前述の例と同様に、モデル５６０は、論理制御５７１を有する論理層モデル５７０にマッピングされる。マップ５６５を使用するマッピングエンジンおよびマッピングプロセスは、５６６で示される。マップ５６５は、論理制御（「ナンバ」および「ストリング」）に、モデル５６０の特性５６１のデータタイプ（「ＩＤタイプ」、「ストリング」、および「フロート」）をマッピングする。この場合、「ＩＤタイプ」および「フロート」の両方のデータタイプは、「ナンバ」の論理制御タイプをマッピングし、一方、「ストリング」のデータタイプは、「ストリング」の論理制御タイプにマッピングする。

次に、論理層モデル５７０は、特定のディスプレイターゲットに特定の物理制御５８１を有するディスプレイターゲットモデル５８０にマッピングされる。モデル５７０は、５７６で示されるプロセスおよびマッピングエンジンで、マップ５７５を使用してモデル５８０にマッピングされる。マップ５７５は、モデル５８０の物理制御タイプ「ＴｅｘｔＢｏｘ」に、モデル５７０の論理制御タイプの「ナンバ」および「ストリング」をマッピングし、特定のモデルからいくつかの異なるタイプは、この場合も他のモデルに単一のタイプにマッピングすることができることを示す。拡張によって、ビジネスモデルからの複数の異なる特性タイプは、同一の最終（例えば「物理」）制御にマッピングすることができる。

開発者経験
開発者が、存在するタイプからだけ構築される新たなエンティティを作るとき、デフォルトＵＩもマップを介して構築される。デフォルトＵＩが、所望のユーザ経験を提供しない場合、開発者は、以下を選択することができる。

・ 要件を反映するためのビジネスモデルの修正。例えば、いくつかの実施形態において、特性のシーケンスのソートが誤っているなら、すなわちＩＤが前の名前で表示されるべきなら、エンティティを編集することができる。他の実施形態において、特性の順序付けは、外部「挙動」にある。しかしながら、オーダされた特性をグループにまとめることは、エンティティに「追加する」ことができ、これは、そうするために使用することができる。したがって、これらの実施形態において、最良のアプローチは、グループに分けることにおけるオーダを変更することになり得る。

・ 生成された論理フォームモデルの修正。名前およびＩＤを切り替えることは、フォームにおいて行うこともできる。ビジネス論理が、ビジネス論理における変更がフォームにおける変更を重ね書きするなど変更されるなら、これは、おそらくは後でいくつかの保守挑戦課題を示す。また、フォーム毎にビジネス論理を変更することが必要であり得る。

・ マップの修正。ＩＤがナンバ制御にマッピングされるが、ストリング制御がより適切であるなら、マップは、変更を行うための権利の場所である。

より多くの従来のモデルの修正の代わりに、マップを変更することは多数の利点がある。まず第１に、変更はより広い範囲を有することができる。前述の例で使用されるマップエントリが変更されるなら、「ＩＤタイプ」を使用する全てのエンティティは、自動的に更新する。これは、結果としてエンドユーザが利益を得るまさに一致するＵＩを生じる。

他の利点は、保守およびアプリケーションのさらなるバージョンを調べるときに明らかになる。モデルが生成される方法を変更するが、生成されたモデルを変更しないことにより、マスタモデルを更新することができ、以降従属するモデルは、不一致の任意のリスクなしに再生することができる。全くフォームを再生しないことは、結果としてエンティティ間の不一致、およびそれらを見てかつ編集するために使用されるフォームを生じることができる。マップは、また大きな生成タスクをいくつかの小さな宣言マップエントリに分ける。

開発者が、「金銭」などの新たな特性タイプを作る場合、ただ１つのマップエントリだけが追加されるならＵＩが効率的に生成されるので、これは、ただちに使用することができる。この例において、新たな「金銭」特性は、「ナンバ」制御にマッピングすることができる。開発者は、また追加されたメタデータ情報を利用することを選択し、かつ「金銭」制御を作り、新たな制御に対する特性マップを持つこともできる。マッピング技術は、両方のシナリオを有効にする。

マッピング言語
マッピングは、拡張可能である単純な宣言マッピング言語を使用する。マッピングは、入力として１つまたは複数のトークン（ｔｏｋｅｎ）をとり、かつ出力として１つまたは複数のトークンを戻す。入力として特性タイプを考慮すれば、１つまたは複数の論理制御は、出力として特定することができる。ゼロとして出力を特定することも可能でなければならない。例えば、「ＩＤタイプ」は、ユーザが編集または見ることができず、その場合、タイプが何にもマッピングされないコンピュータによって生成されたフィールドとすることができる。また、マッピングは、出力のパラメータを制御できる。例えば、「ストリング」特性は、フォーム上の他のＴｅｘｔＢｏｘに比べてより広いＴｅｘｔＢｏｘを結果として生じることができる。

より前に対処されたスコーピング（ｓｃｏｐｉｎｇ）の問題を取り扱うために、スコープ状態は、前述の例示的なフォームで、「ＩＤ制御」に対する「ＩＤタイプ」マップが必要であるが、全ての他のフォームで、「ナンバ」制御が使用される。他のパラメータは、ビジネスエンティティ、エンティティステレオタイプ（ｓｔｅｒｅｏｔｙｐｅ）、フォームタイプなどを含む、スコープとして使用することもできる。マップが実行されるべきであるとき、考慮することが有利である他の状態がある。一例は、ペアレント（ｐａｒｅｎｔ）制御である。ペアレント制御がリストであるなら、エニュメレータ（ｅｎｕｍｅｒａｔｏｒ）特性は、ラジオボタンではなく、ドロップダウン（ｄｒｏｐ−ｄｏｗｎ）リストへのマップを選択することがある。他の状態は、エニュメレータにおける可能な選択の数とすることができ、ラジオボタンは、２つまたは３つであれば使用することができるが、より多くの選択は、結果としてリストを生じることがあり得る。この方法が作動しないと、マッピング言語は、初期の要件に比べて非常に複雑になり、マップのトップ上の他のアブストラクションレベルは、開発者がマップを理解することを必要とする。このパターンは、いくつかのツールが複雑性を隠すために実施される、拡張可能なスタイルシート（ＳｔｙｌｅＳｈｅｅｔ）言語変換（ＸＳＬＴ）で見ることができる。

論理フォーム−ＵＩモデル
ビジネス論理のモデルからＵＩモデルのマッピングのとき、論理層とも呼ばれるレイアウトに独立な層が挿入される。ビジネス論理のモデルが、ディスプレイターゲットに関わりなく最終的なＵＩにマッピングされ得ると考えられるなら、論理層は、単純な（ｓｔｒａｉｇｈｔ ｆｏｒｗａｒｄ）アブストラクションである。いくつかのメタデータは、ビジネスエンティティ自体など全てのディスプレイターゲットに関して共通であり、いくつかの部分は、特定のディスプレイターゲットに関して特定される。論理層は、共通の部分である。

図６は、フォームを作るために使用される設計時アクティビティおよび実行時アクティビティの概略図である。設計時において、モデリングツール６０５は、前述のものなどのモデルまたはフォーム定義およびマップを作るために使用される。これらのフォーム定義およびマップは、メタデータデータベース６１０に格納することができる。

実行時において、モデルまたはフォームは、論理層モデル６２５にマッピングされる。論理層モデル６２５は、また、ビジネス論理６２０に適用されるデータベース６１５に格納される実行時データを使用して生成される。また、実行時において、論理層モデル６２５は、前述ようにディスプレイターゲットモデル６３０にマッピングされる。

フォームおよび制御を含む論理層は、ビジネス論理６２０とディスプレイターゲット６３０との間のブリッジ（ｂｒｉｄｇｅ）である。それは、限定されたレイアウトの知識および限定されたビジネス論理の知識を有する。論理層は、ビジネスエンティティに基づきフォームのコンテンツを定義し、フォームをビジネスエンティティの実行時インスタンスに結合するデータなど、共通の実行時の問題を取り扱う。さらに、論理層は、全てのディスプレイターゲットに共通のセキュリティを取り扱い、それは、各ディスプレイターゲットにメタデータを提供し、論理層は、入力妥当性を取り扱うことができる。

ビジネスアーキテクチャまたは開発者は、ドメインに特定のビジネス論理およびデータに焦点を合わせることができる。焦点がＵＩに移されるとき、レイアウト詳細、データ結合の問題、プラミング（ｐｌｕｍｂｉｎｇ）コード、入力妥当性、読み取りできない特性を隠すこと、エラー処理などは、論理層に見出されるアブストラクションの高いレベルに全て隠される。ドメインスペシャリストは、ユーザが見るために何が意味を成すかなど、ＵＩのコンテンツに焦点を合わせることができ、特定のディスプレイターゲットおよびそれらの異なるレンダリング技術に関する広範囲にわたる知識を必要としない。

上述のように、論理フォームまたは論理層モデルは、論理制御を使用して構築される。新たな制御は、容易に追加することができ、論理層を非常に柔軟かつ拡張可能にする。新たな制御が開発されたとき、それは、使用されるマップを変更することによって既存のフォームに単に追加される。各ディスプレイターゲットは、新たな制御を実施する必要なく新たな機能性から利益を得るが、それが意味を成すなら、新たな制御を導入することができる。

ディスプレイターゲット
論理フォームおよび制御は、ディスプレイターゲットによって使用される特定のレンダリング技術にマッピングされる。他の図のように、これは、論理層モデルまたはフォーム７０５がいくつかの特定のディスプレイターゲットにマッピングされる図７に示される。この特定の例において、ディスプレイターゲット７１０は、Ｗｉｎｄｏｗｓレンダリング技術を使用し、一方、ディスプレイターゲット７１５は、ウェブレンダリング技術を使用する。ディスプレイターゲットは、フォームおよび制御のレンダリング、およびユーザ入力の取り扱いを含む全てのユーザ対話を担当する。各ディスプレイターゲットは、論理層における制御が何か意味のあるものにマッピングされるように、多数の制御を必要とする。すなわち、特性は、値のタイプと両立しなければならず、その値のタイプは、制御が取り扱うことができ、かつ制御が実際的な方法でその値をレンダリングすべきである。換言すれば、マッピング技術がこれに有意な影響を有するとき、各ディスプレイターゲットで利用可能でなければならない特定の多数の制御は存在しない。

ディスプレイターゲットは、ユーザ対話を制御し、また本質的に対話パラダイムを制御する。ウェブページおよびＷｉｎｄｏｗｓ Ｆｏｒｍｓウィンドウは、同じ論理フォームに基づき生成することができるが、それらが、チャッティ（ｃｈａｔｔｙ）対話ポリシーまたはチャンキー（ｃｈｕｎｋｙ）ポストバックポリシーを使用かどうかは、ディスプレイターゲットによって当然決定される。各ディスプレイターゲットは、どれだけ多くのフォームがユーザに表示されるかを選択する。Ｗｉｎｄｏｗｓフォームは、タブウェブ上の情報を隠すことができ、一方、ウェブページは、一時に全ての情報を示すために選択することができる。これらの決定は、ディスプレイターゲットが得る、論理フォーム、したがってまたフォームタイプに基づいて行われる。異なるディスプレイターゲットは、そのようなページング決定を行うための追加の情報を必要とし、同様に論理フォームおよび制御には、ディスプレイターゲットに特定の情報で注釈を付けることができる。

挙動−宣言フォーム論理
フォームが、コンテンツを定義する論理制御を構築するので、フォームに対してダイナミックスを追加する必要がまだある。これは、コードを使用して行うことができる。しかし、フォーム上にコードをマッピングすることは容易ではなく、したがって宣言的抽象レベルは必要である。同時に、フォームに追加されるコードにおける多くのパターンが存在する。例えば、他のフィールドが満たされるなら、フィールドを使用不可にするためのコードは、多くのフォームに見出される。「Ｃａｓｈ」が、フォーム上の支払いタイプとして選択される場合、「クレジットカードナンバ」は、グレイにされまたはさらに隠される。

これらのパターンは、「挙動」と呼ばれる概念で捕捉される。挙動は、宣言的にフォームに追加され、フォームにおけるイベントを介してアクティベートされる。挙動は、制御の値および特性に応じて、他の制御に特性を設定することができるが、挙動は、この使用に限定されない。挙動は、エンティティにおける制約または他のメタデータ特性に基づき主にマッピングされる。エンティティは、ビジネス論理を取り扱うことを担当し、挙動は、ＵＩ論理を担当する。換言すれば、挙動は、これが関心事の分離を妨げるので、任意のビジネス論理を実行すべきではない。

層状にされたシステムおよび方法例
さて図８を参照して、上述の様々な概念（すなわち、論理フォームタイプ、ＵＩマップ、制御、挙動など）を組み合わせて実施する、層状にされたシステムおよび方法の概略的な図示である。図８に示されるように、システムまたは方法９００は、ビジネスアプリケーションおよびコンピューティングシステム、コアクライアントマッピングエンジンまたはコンポーネント９１０、および１つまたは複数のディスプレイターゲット９１５を含むことができる、ビジネスフレームワーク９０５を使用して実施される。例示の目的で、図８は、マップ９２０（マップ９２１および９２２を含む）、モデル９２５（アプリケーションまたはビジネスモデル９２６、論理フォームモデル９２７、および物理的モデル９２８を含む）、およびライブラリ９３０を示すためにセグメント化される。

ライブラリ９３０は、アプリケーションモデル９２６におけるデータの様々な特性タイプ９２３を定義する、ビジネスフレームワーク９０５における特性タイプライブラリ９３１を含む。コアクライアント９１０において、ライブラリ９３０は、論理制御ライブラリ９３２、挙動ライブラリ９３３、および論理フォームタイプライブラリ９３４を含む。上述されたように、論理制御ライブラリ９３２は、モデル９２６のデータまたは特性タイプ９２３をマッピングすることができる様々な論理制御９２４を定義する。アプリケーションモデル９２６と論理フォームモデル９２７との間のこのマッピングは、マップ９２１を使用するコアクライアントマッピングエンジンによって実行される。

挙動ライブラリ９３３および論理フォームタイプライブラリ９３４は、前述のように、フォームを設計および生成するプロセスにおいて、コアクライアントマッピングエンジン９１０によって使用される。ライブラリ９３０は、物理的フォームモデル９２８を生成するために、したがって物理的フォームをレンダリングするためにディスプレイターゲット９００によって使用される、スタイルライブラリ９３５、物理的またはネーティブ制御ライブラリ９３６、およびフォームタイプライブラリ９３７も含む。制御ライブラリ９３６は、マップ９２２を使用して論理制御９２４をマッピングすることができる特定のディスプレイターゲットに関する様々な物理制御９２５を定義する。

本発明は、特定の実施形態を参照して述べたが、当業者は、本発明の精神および範囲から逸脱することなく、形態および詳細に変更を加えることができることは理解されよう。

本発明を使用することができる１つの例示的な環境のブロック図である。 本発明を実施することができる一般的なモバイルコンピューティング環境のブロック図である。 論理フォームおよび物理的フォームを生成するために、本発明のフォームタイプの使用の概略的な例示の図である。 図３−１に示されるフォームタイプの使用の概略的な例示であり、フォームタイプと論理フォームおよび物理的フォームの生成との間の関係をさらに例示する図である。 ビジネスモデル例を例示するブロック図である。 フォームに対してマッピングされたエンティティビジネスモデルを例示するブロック図である。 マップを使用するモデルおよび他のモデルを生成するプロセスを例示するブロック図である。 一連のマッピングを介して初期のアプリケーションまたはビジネスモデルから、ディスプレイターゲットの特定モデルを生成するプロセスを例示するブロック図である。 一例の実施形態に関して図４−１および図４−２に示されるタイプのプロセスを例示するブロック図である。 ディスプレイターゲットから独立した論理フォームを作成するために、制御に対してマッピングされたエンティティ特性で、ビジネスモデルエンティティが、最初にディスプレイターゲットから独立したフォームにマッピングされ、次に論理フォームが、ディスプレイターゲットにマッピングされる、例示的なマッピングプロセスを例示するブロック図である。 本発明の設計時および実行時の態様を例示し、かつ論理層が、ビジネス論理とディスプレイターゲットとの間のブリッジであることを例示するブロック図である。 ディスプレイターゲットの特定のレンダリング技術にマッピングされた論理的なフォームを例示するブロック図である。 本発明の概念の概略の例示の図である。

符号の説明

１２０ プロセッシングユニット
１３０ システムメモリ
１３４ オペレーティングシステム
１３５ アプリケーションプログラム
１３６ 他のプログラムモジュール
１３７ プログラムデータ
１４０ 固定不揮発性メモリインターフェース
１４４ オペレーティングシステム
１４５ アプリケーションプログラム
１４６ 他のプログラムモジュール
１４７ プログラムデータ
１５０ 取り外し可能な不揮発性メモリインターフェース
１６０ ユーザ入力インターフェース
１６１ ポインティングデバイス
１６２ キーボード
１６３ マイクロフォン
１７０ ネットワークインターフェース
１７１ ローカルエリアネットワーク
１７２ モデム
１７３ ワイドエリアネットワーク
１８０ リモートコンピュータ
１８５ リモートアプリケーションプログラム
１９０ ビデオインターフェース
１９１ モニタ
１９５ 出力周辺インターフェース
１９６ プリンタ
１９７ スピーカ
２０２ プロセッサ
２０８ 通信インターフェース
２１６ オブジェクトストア

Claims (24)

1. アプリケーションモデルを示すために、モデルドリブンフォームユーザインターフェースを生成する方法であって、
   前記アプリケーションモデルを示す前記フォームユーザインターフェースを生成するために使用する、複数の異なる論理フォームタイプのどれかを選択するステップと、
   第１のマップを提供するステップと、
   前記アプリケーションモデル、前記選択されたフォームタイプ、および前記第１のマップを使用して、ディスプレイターゲットから独立した論理フォームを生成するステップとを備えることを特徴とする方法。
2. 前記第１のマップは、第１の宣言マップであり、前記第１の宣言マップを使用してディスプレイターゲットから独立した論理フォームを生成するステップは、前記ディスプレイターゲットから独立した論理フォーム内のディスプレイターゲットから独立した論理制御に、前記アプリケーションモデルのデータの特性タイプをマッピングするステップをさらに含むことを特徴とする請求項１に記載の方法。
3. 前記ディスプレイターゲットから独立した論理フォームを生成するステップは、ディスプレイターゲットから独立した論理フォームモデルを生成するステップを含むことを特徴とする請求項２に記載の方法。
4. 前記アプリケーションモデル、前記選択されたフォームタイプ、および前記第１の宣言マップを使用して、前記ディスプレイターゲットから独立した論理フォームを生成するステップは、前記ディスプレイターゲットから独立した論理フォームに対して宣言的に適用される挙動をさらに付けるステップをさらに含むことを特徴とする請求項２に記載の方法。
5. 前記宣言的に適用される挙動は、前記フォームにおけるイベントによってアクティベートされることを特徴とする請求項４に記載の方法。
6. 前記宣言的に適用される挙動は、前記論理制御の値および特性に応じて、他の制御に特性を設定する論理のパターンであることを特徴とする請求項５に記載の方法。
7. 前記第１の宣言マップは、前記ディスプレイターゲットから独立した論理フォームを生成するために使用されるマッピングエンジンに対して外部にあることを特徴とする請求項２に記載の方法。
8. 前記第１の宣言マップは、前記論理制御モデルを生成するために前記マッピングエンジンによって使用されるモデルであることを特徴とする請求項７に記載の方法。
9. 第２の宣言マップを使用して物理的フォームに対して前記論理フォームをマッピングするさらなるステップをさらに備えることを特徴とする請求項２に記載の方法。
10. 前記物理的フォームは、ディスプレイターゲットへの前記論理フォームのレンダリングで使用するために利用可能な複数の物理制御を有し、前記第２の宣言マップを使用して前記物理的フォームに対して前記論理フォームをマッピングするステップは、前記複数の利用可能な物理制御の１つに対して前記論理フォームにおける各前記論理制御をマッピングするために、前記第２の宣言マップを使用することをさらに含むことを特徴とする請求項９に記載の方法。
11. 前記アプリケーションモデルが、実行時に作用されるように、前記生成された論理フォームを使用して実行時に前記フォームユーザインターフェースをレンダリングするステップをさらに備えることを特徴とする請求項１０に記載の方法。
12. 実行時に前記フォームユーザインターフェースをレンダリングするステップは、前記選択された論理フォームタイプおよび前記アプリケーションモデルからのメタデータの両方を使用して、実行時に前記論理フォームを生成するステップをさらに含むことを特徴とする請求項１１に記載の方法。
13. 各前記複数の異なる論理フォームタイプは、前記生成された論理フォームに含まれるべきアプリケーションモデルデータを定義する関連スキーマを有し、実行時に前記論理フォームを生成するステップは、前記関連スキーマを使用して前記論理フォームを生成するステップをさらに含むことを特徴とする請求項１２に記載の方法。
14. 各前記複数の異なる論理フォームタイプの前記スキーマは、複数のフォームから捕捉されたパターンを示すことを特徴とする請求項１３に記載の方法。
15. 各前記複数の論理フォームタイプは、少なくとも１つの定義されたレイアウトを有し、前記方法は、前記少なくとも１つの定義されたレイアウトを使用して、実行時に前記物理的フォームを生成することをさらに含むことを特徴とする請求項１３に記載の方法。
16. フォームユーザインターフェースを生成するステップを実行するためのコンピュータ実行可能命令を有するコンピュータ可読媒体であって、フォームユーザインターフェースを生成するステップは、
    アプリケーションモデルを示すフォームユーザインターフェースを生成するために使用する、複数の異なる論理フォームタイプのどれかを選択するための選択入力を受信するステップと、
    第１のマップを提供するステップと、
    前記アプリケーションモデル、前記選択されたフォームタイプ、および前記第１のマップを使用して、ディスプレイターゲットから独立した論理フォームを生成するステップとを含むことを特徴とするコンピュータ可読媒体。
17. 前記第１のマップは、第１の宣言マップであり、前記第１の宣言マップを使用して前記ディスプレイターゲットから独立した論理フォームを生成するステップは、前記ディスプレイターゲットから独立した論理フォーム内のディスプレイターゲットから独立した論理制御に、前記アプリケーションモデルのデータの特性タイプをマッピングすることもさらに含むことを特徴とする請求項１６に記載のコンピュータ可読媒体。
18. 前記アプリケーションモデル、前記選択されたフォームタイプ、および前記第１の宣言マップを使用して、前記ディスプレイターゲットから独立した論理フォームを生成するステップは、前記ディスプレイターゲットから独立した論理フォームに対して宣言的に適用される挙動を付けるステップもさらに含むことを特徴とする請求項１７に記載のコンピュータ可読媒体。
19. 前記第１の宣言マップは、前記ディスプレイターゲットから独立した論理フォームを生成するために使用されるマッピングエンジンに対して外部にあることを特徴とする請求項１７に記載のコンピュータ可読媒体。
20. 第２の宣言マップを使用して物理的フォームに対して前記論理フォームをマッピングするさらなるステップを実行するためのコンピュータ実行可能命令をさらに有することを特徴とする請求項１７に記載のコンピュータ可読媒体。
21. 前記物理的フォームは、ディスプレイターゲットへの前記論理フォームのレンダリングで使用するために利用可能な複数の物理制御を有し、前記第２の宣言マップを使用して前記物理的フォームに対して前記論理フォームをマッピングするステップは、前記複数の利用可能な物理制御の１つに対して前記論理フォームにおける各前記論理制御をマッピングするために、前記第２の宣言マップを使用することをさらに含むことを特徴とする請求項２０に記載のコンピュータ可読媒体。
22. 各前記複数の異なる論理フォームタイプは、前記生成された論理フォームに含まれるべきアプリケーションモデルデータを定義する関連スキーマを有し、前記論理フォームを生成するステップは、前記関連スキーマを使用して前記論理フォームを生成するステップをさらに含むことを特徴とする請求項２１に記載のコンピュータ可読媒体。
23. 各前記複数の異なる論理フォームタイプの前記スキーマは、複数のフォームから捕捉されたパターンを示すことを特徴とする請求項２２に記載のコンピュータ可読媒体。
24. 各前記複数の論理フォームタイプは、少なくとも１つの定義されたレイアウトを有し、前記コンピュータ可読媒体は、前記少なくとも１つの定義されたレイアウトを使用して、実行時に前記物理的フォームを生成するさらなるステップを実行するためのコンピュータ実行可能な命令をさらに有することを特徴とする請求項２２に記載のコンピュータ可読媒体。
    

Images