JP2016224923A - ユーザフォームインタフェースの自動生成の方法およびシステム - Google Patents

Abstract

【課題】スクリーンフォームを動的に変更する形式でユーザインタフェースの自動生成を実行する。【解決手段】ユーザインタフェースに関するオブジェクトメタデータにアクセスし、メタデータに基づいてユーザインタフェース用の論理記述をロードし、メタデータに関する機能的オプションを検索し、機能的オプションに基づいてユーザインタフェース用の少なくとも１つの追加変更のための要件を決定し、ユーザフォームインタフェースのユーザにとって利用可能なアクセス権を検索し、既定の基準に基づいてフォーム要素を編成するためにフォームエンジンを用い、論理記述、機能的オプション、ユーザにとって利用可能なアクセス権、およびユーザ設定に基づいて視覚的記載データを自動的に生成し、クライアント装置の表示設定に基づいてユーザフォームインタフェースをカスタマイズするクライアント装置に対して視覚的記載データを提供する。【選択図】図１

Description

関連出願に対する相互参照
この出願は、一部継続出願であり、２０１５年４月２９日に出願されたロシア国特許出願第２０１５１１６１３３号に対する優先権の権利を主張し、参照によって全体として本明細書に援用される。

本開示は、概してアプリケーション用のユーザインタフェースを生成するためのシステムおよび方法に関し、特に、スクリーンフォームを動的に変更する形式でユーザインタフェースの自動生成を実行するシステムおよび方法に関する。

パーソナルコンピュータ、ならびにスマートフォン、携帯情報端末、タブレット、および同種のものなどの他のコンピューティング装置は、ユーザが装置上に提供されるアプリケーションまたはサービスと通信し対話するためのユーザインタフェースを必要とする。しかしながら、これらのインタフェースの作成および設計は、多くの場合、相当時間がかかり且つ重労働になる可能性がある。ディベロッパのユーザインタフェースの生成を容易にする、既存のいくつかのコンピュータプログラムがある。例えば、様々なタイプのプラットフォーム上で対象のスクリーンオブジェクトを視覚化する多くの技術のための、フォーム状のユーザインタフェースを生成する１つのシステムおよび方法が知られており、ディベロッパは、アプリケーションの開発モデルおよび選択されたタイプに基づいて、後にユーザインタフェースを形成する必要とされるデータオブジェクトの論理フォームを、論理的および物理的なコントロール要素のグループとともに、予め作成することができる。しかしながら、あらゆる新たなフォームをディベロッパが手作業で作成しなければならないので、この解決手段は、まさに重労働である。したがって、フォームを自動的に生成することができる改良型のユーザインタフェースをディベロッパが作成することを可能にするシステムおよび方法が必要である。

開示されるシステムおよび方法は、標準的機能を有するユーザインタフェースの品質および人間工学的な設計を失わずに、ユーザがこれらのインタフェースをフレキシブルで且つ迅速に作成することを提供する。

有利的には、開示されたシステムおよび方法は、その結果人間工学的な要件に合わせたユーザインタフェース要素の位置調整および表示を保証する、フォームの自動生成によって実現されるアプリケーションプログラムソリューションの微調整によって向上された柔軟性および開発速度を提供する。

１つの態様によれば、アプリケーション用のユーザインタフェースを動的に生成するための方法を開示する。方法は、要求されたユーザフォームインタフェースに関するオブジェクトメタデータにアクセスするステップと、アクセスされたオブジェクトメタデータに基づいて、ユーザフォームインタフェースのための論理記述であって少なくともユーザフォームインタフェースのためのフォーム要素およびコマンドの宣言を含む論理記述をデータベースからロードするステップと、アクセスされたオブジェクトメタデータに関する機能的オプションをデータベースから検索し、機能的オプションに基づいてユーザフォームインタフェースに対する少なくとも１つの追加変更のための要件を決定するステップと、ユーザフォームインタフェースのユーザにとって利用可能なアクセス権を検索するステップと、既定の基準に基づいてフォーム要素を編成するように構成されたフォーマッティングルールを含むフォームエンジンをアクティブ化するステップと、論理記述、機能的オプション、ユーザにとって利用可能なアクセス権、およびユーザ設定に基づいて、ユーザフォームインタフェース用の視覚的記載データであってデバイス固有ではない視覚的記載データをフォームエンジンによって自動的に生成するステップと、クライアント装置の表示設定に基づいてユーザフォームインタフェースをカスタマイズするクライアント装置に対して、視覚的記載データを提供するステップとを含む。

別の態様によれば、既定の基準は、論理的基準（ｌｏｇｉｃａｌ ｃｒｉｔｅｒｉａ）、人間工学的基準（ｅｒｇｏｎｏｍｉｃ ｃｒｉｔｅｒｉａ）、審美的基準（ａｅｓｔｈｅｔｉｃ ｃｒｉｔｅｒｉａ）、およびビジネス上の基準（ｂｕｓｉｎｅｓｓ ｃｒｉｔｅｒｉａ）のセットを含む。

別の態様によれば、クライアント装置の表示設定は、クライアント装置のスクリーンのサイズ、クライアント装置のスクリーンの指定解像度、クライアント装置のスクリーンの指定されたフォント、クライアント装置のオペレーティングシステム、およびクライアント装置のブラウザのうちの少なくとも１つを含む。

別の態様によれば、方法は、ユーザがフォーム要素の少なくとも１つに間違ってデータを入力している場合、フォーム要素に隣接するウィンドウ内のユーザフォームインタフェースの特定要素に関する情報メッセージをクライアント装置上に表示するステップを含む。

別の態様によれば、ユーザフォームインタフェース用の論理記述は、フォーム要素のサイズおよび順番のうちの１つ以上に関する情報をさらに含む。

別の態様によれば、論理記述は、少なくとも１つのフォーム要素またはフォーム要素のグループと、複数の関連するフォームに適用する１つ以上のグローバルコマンドとをさらに含む。

別の態様によれば、論理記述は、検索されたフォームデータをもつ新たなフォームユーザインタフェースを開くように構成された１つ以上のコマンドをさらに含む。

別の態様によれば、アプリケーションフォームを動的に生成するためのサーバシステムを開示する。この態様によれば、サーバシステムは、少なくとも１つのユーザフォームインタフェース用の論理記述であって、少なくともユーザフォームインタフェース用のフォーム要素およびコマンドの宣言を含む論理記述を格納するように構成されたデータベースと、ネットワークインタフェースであって、要求されたユーザフォームインタフェースに関するオブジェクトメタデータにアクセスし、アクセスされたオブジェクトメタデータに基づいて、ユーザフォームインタフェースのための少なくとも１つの論理記述であって少なくともユーザフォームインタフェースのためのフォーム要素およびコマンドの宣言を含む論理記述をデータベースからロードし、アクセスされたオブジェクトメタデータに関する機能的オプションをデータベースからロードし、機能的オプションに基づいてユーザフォームインタフェースに対する少なくとも１つの追加変更のための要件を決定し、ユーザフォームインタフェースのユーザにとって利用可能なアクセス権を検索するように構成されたネットワークインタフェースと、既定の基準に基づいてフォーム要素を編成し、論理記述、機能的オプション、ユーザにとって利用可能なアクセス権、およびユーザ設定に基づいてユーザフォームインタフェース用の視覚的記載データであってデバイス固有ではない視覚的記載データを自動的に生成するように構成されたフォームエンジンフォーマッティングルールとを含み、ネットワークインタフェースは、クライアント装置の表示設定に基づいてユーザフォームインタフェースをカスタマイズするクライアント装置に対して視覚的記載データを提供するように構成される。

別の態様によれば、非一時的なコンピュータ読み取り可能な記憶媒体に格納されたコンピュータプログラムプロダクトであって、アプリケーションフォームを動的に生成するためのコンピュータ実行可能命令を備え、コンピュータプログラムプロダクトは、要求されたユーザフォームインタフェースに関するオブジェクトメタデータにアクセスするための命令と、アクセスされたオブジェクトメタデータに基づいてユーザフォームインタフェースのための論理記述であって、少なくともユーザフォームインタフェースのためのフォーム要素およびコマンドの宣言を含む論理記述をデータベースからロードするための命令と、アクセスされたオブジェクトメタデータに関する機能的オプションをデータベースから検索し、機能的オプションに基づいてユーザフォームインタフェースに対する少なくとも１つの追加変更のための要件を決定するための命令と、ユーザフォームインタフェースのユーザにとって利用可能なアクセス権を検索するための命令と、既定の基準に基づいてフォーム要素を編成するように構成されたフォーマッティングルールを含むフォームエンジンをアクティブ化するための命令と、論理記述、機能的オプション、ユーザにとって利用可能なアクセス権、およびユーザ設定に基づいて、ユーザフォームインタフェース用の視覚的記載データであってデバイス固有ではない視覚的記載データをフォームエンジンによって自動的に生成するための命令と、クライアント装置の表示設定に基づいてユーザフォームインタフェースをカスタマイズするクライアント装置に対して視覚的記載データを提供するための命令とを含む。

ユーザが構成オブジェクトの各々についてすべてのフォームを開発する（すなわち、設計し、要素のツリーを描画し、それらの動作をプログラミングする）必要がないので、開示されるシステムおよび方法は、従来のユーザインタフェース生成方法ほど多くの時間と労力を要しない。したがって、開発のプロセスまたは適用されるソリューション（ａｐｐｌｉｅｄ ｓｏｌｕｔｉｏｎ）の微調整の速度を、実質的に速める。

さらに、開示されるシステムおよび方法は、同一のメタデータオブジェクトに対して自動化された方式で２つ以上のフォームを作成することができるように、技術的なリソースのツールキットを拡張する。このオブジェクトの下位のフォームのいずれかを、メインのものとして指定することができる。

例示的な態様の上記の単純化された概要は、開示されるシステムおよび方法の基本理解を提供するように機能する。この概要は、想定された態様のすべての広範囲な概要でなく、すべての態様の重要な要素や致命的な要素を識別しないし、本開示の態様のいくつかの範囲またはすべての範囲を描写しないように意図される。その唯一の目的は、後続する本開示のさらに詳細な説明に対する前置きとしての簡易的フォームにおける１つ以上の態様を提示することである。前述の目的の達成のために、本開示の１つ以上の態様は、特許請求の範囲に記載され且つ特に指摘された特徴を含む。

この明細書に組み込まれて、この明細書の一部を構成する添付の図面は、本開示の１つ以上の例示的な態様を図示し、詳細な説明とともに、それらの原理および具体化について説明するように機能する。

好ましい態様による、ユーザインタフェースを自動的に生成する方法のためのフローチャートを図示する。 好ましい態様による、ユーザインタフェースを自動的に生成するシステムのためのブロック図を図示する。 好ましい態様による、ユーザインタフェースを自動的に生成するシステムのためのブロック図を図示する。 好ましい態様による、ユーザインタフェースの自動化された生成のためのシステムおよび方法を配備することができる例示的な汎用コンピュータシステムを図示する図である。 好ましい態様による、プログラミング設計の間に実行されるソフトウェアアプリケーションのスクリーンショットを図示する。 好ましい態様による、ＸＭＬ形式記述の好ましい論理構造を図示する。 好ましい態様による、実行時（実行モード）に起動されたソフトウェアプロダクトスクリーンショットを図示する。 好ましい態様による、実行時（実行モード）に起動されたソフトウェアプロダクトスクリーンショットを図示する。 好ましい態様による、設計時（設計モード）に動作するソフトウェアアプリケーションのスクリーンショットを図示する。 好ましい態様による、ユーザ設定の構成を備えるソフトウェアアプリケーションのスクリーンショットを図示する。

例示的な態様は、スクリーンフォームを動的に変更する形式でユーザインタフェースを自動的に生成するためのシステム、方法、およびコンピュータプログラムプロダクトとのコンテキストにおいて本明細書に記載される。当業者は、ユーザインタフェースの自動的な生成のためのシステムおよび方法の例示的な態様についての以下の記載が、単に例示的なものであり、いかなる限定も意図していない、ということを理解するだろう。他の態様は、この開示の利点を有する当業者に対して、それ自体を容易に提案するだろう。添付の図面に示されるような例示的な態様の具体化が、ここで詳細に言及されることになる。同一の参照符号は、可能な限り、同一の項目を参照するために図面および以下の記述の全体を通じて用いられることになる。

具体的には、ユーザインタフェースの自動化された生成のためのシステムおよび方法は、会計業務、電子文書化、企業資源の管理、および同種のものの自動化のためのアプリケーションソリューションを提供するハードウェアおよびソフトウェアプラットフォームを含む。ハードウェアおよびソフトウェアプラットフォームは、例えば、ＰＣ互換デバイス装置を含む周辺Ｉ／Ｏ装置をもつ汎用コンピュータ、または汎用オペレーティングシステムがインストールされるローカルエリアネットワークに組み合わされて、開示される方法を実施する専門ソフトウェアを有するいくつかのコンピュータを構成する。好ましい態様によれば、専門ソフトウェアは、その環境においてユーザアプリケーションを実行することができるソフトウェアである。エンドユーザまたはエンドユーザのグループが処理する完全な機能も、また、以下で「ユーザアプリケーション」と呼ぶものとする。開示されるシステムおよび方法は、自動化された開発および／またはユーザアプリケーションのカスタマイズを容易にし且つ促進するソフトウェアプラットフォームに関する。

開示されるシステムおよび方法は、例えばディレクトリ、ドキュメント、情報レコード、勘定科目表（ｃｈａｒｔｓ ｏｆ ａｃｃｏｕｎｔｓ）、および同種のものを含むメタデータオブジェクトからのビルダーの方式でカスタマイズ可能なユーザアプリケーションをアセンブルする能力をユーザアプリケーションのディベロッパに提供する。メタデータオブジェクトのこれらのクラスが設計者用のプラットフォーム内に備えられる／記載される、ということを評価するべきである。好ましい態様によれば、図７に示されるように、例えば、メタデータオブジェクトは、それぞれ「カタログ」、「ドキュメント」「情報レジスタ」、「勘定科目表」として特徴づけることができる。１つの態様によれば、メタデータオブジェクトの各々は、他のメタデータオブジェクトとともに機能し対話するアルゴリズムをそれ自身含む。

１つの好ましい態様において、ユーザアプリケーションのユーザインタフェースは、主として、複数のフォームを備えることになる。ユーザアプリケーションのエンドユーザは、主として、これらのフォームを処理することになる。フォームは、データベース内に含まれる情報の表示および編集のために用いられる。好ましい態様によれば、特定のフォームは、オブジェクトに基づいてアクセスされる。例えば、ディベロッパは、オブジェクト（例えば図４に示すディレクトリ「カタログ車両」）またはドキュメントを第１に作成することになり、その後、フォームを作成するためにオブジェクトが用いられる。さらに特に、（詳細は以下で論じられる）図４に示すように、「構成」ツリーは、「カタログ」、「車両」およびその後「フォーム」を備える。したがって、図示するように、フォーム「ＦｏｒｍＡｕｔｏ２」４２５は、ディレクトリ「車両」４２０の子である。

１つの態様によれば、他のメタデータオブジェクトのようなフォームは、ある情報構造としてデータベース内に保存されてもよい。物理的には、メタデータオブジェクトは、エンドユーザ（ユーザデータ）によって、アセンブルされて、主題領域に関する情報とともに、同一のデータベース内にまたは個別のデータベース内に格納されてもよい。１つの態様によれば、エンドユーザは、メタデータを編集しないので、そのため、構成のディベロッパまたはシステム管理者のタスクである構成の機能を変更する能力を有しない。

詳細には以下で論じられる論理記述に基づいて、開示されるシステムおよび方法は、エンドユーザに対する表示のためのフォームの外観を作成する。このプロセスにおいて、システムは、エンドユーザのための最大限の利便性でフォームの要素を配置するために、表示されているデータの（タイプなどの）様々なプロパティを考慮に入れる。コマンドインタフェースの要素だけでなく要素のツリーを備える要素の特定の位置調整は、フォームを表示する（描く）ときに、システムによって自動的に実行される。

好ましい態様によれば、フォームの論理記述は、例えば、以下のものを含むがこれらに限定はされない、いくつかのコンポーネントのグループを含むことができる。
・要素または要素のツリー：フォームの視覚的表現を決定するように構成され、エンドユーザとの対話を提供するオブジェクトのグループ、
・詳細（属性）：データタイプおよびデータソースを含む、そのオペレーション内のフォームが用いるデータを記述するオブジェクト、
・コマンド／アクションチーム：各々の特定のフォームのための所定のアクション、
・コマンドインタフェース：特定のフォームまたはリンクされる全体のオブジェクトのいずれかに用いる（実行する）ことができるフォーム（例えば、対話型のボタン若しくはメニュー、またはその他同種のもの）に表示される１セットのコマンド、
・オプション：１つの態様において、メモリ内にそれをロードするときに、オブジェクトの値がフォームの特定のコピーの動作を条件付けるオブジェクトであり、パラメータは、フォームコピーの「寿命」の間に不変のままであり、１つのフォームから別のフォームに対する事前送信値に用いることができる、
・モジュール：要素、イベントの処理、フォームで編集されるデータの読み取りおよび書き込み、フォームのデータの対応するデータベースレコードへの変換（逆の場合も同じ）を処理するための役割を担う組込みの言語におけるプログラム。

好ましい態様によれば、フォームの機能は、要素のツリー、詳細（フォームが処理するデータ）、および実行されるアクション（コマンド）によって、決定される。したがって、特別のフォームがユーザインタフェースを生成するためにディベロッパによってアクセスされるときに、そのフォームに関連した要素、要件、およびアクションの対応するツリーは、システムによってアクセスされる。

フォームは、構成の特別のメタデータオブジェクトに属することができる、または、いずれかの特定のメタデータには関連づけることができない。上記のように、図４に関して、好ましい状況を提供することができ、ここで、メタデータを用いて最初にオブジェクトを作成することができ、その後、オブジェクト（例えば、ディレクトリ「車両」４２０の子である「ＦｏｒｍＡｕｔｏ２」４２５）に基づいてフォームを作成することができる。しかしながら、フォームがいかなるオブジェクトにも属さずに独立する場合の状況がある、ということもまた評価するべきである。例えば、フォームは、図７に示されるように、例えば、ユーザデータのパスワードを設計者が変更することを容易にする、「ＣｈａｎｇｅＰａｓｓｗｏｒｄ」７１０などの「共通フォーム」を追加することができる。

好ましい態様によれば、組み込まれた既定の規則を用いるシステムは、ディレクトリ、ドキュメント、情報レコードなどのメタデータオブジェクトのためのフォームを自動的に作成することになる。有利的には、ディベロッパは、新たなメタデータオブジェクトが追加される度に要素のツリーとともに新たなフォームを設計および「描画」する必要がない。

フォームを自動的に作成することに加えて、フォームエディタを用いるユーザアプリケーションのディベロッパは、フォームを作成／編集し、その要件、コマンドおよび表示することができる要素の構造を規定することができ、また、各種設定によって要素の配置を決定し、要素のシーケンスを決定し、所望の幅および高さを指定することができ、それによって、エンドユーザの作業のためにさらに便利な順序でフォームの要素を構成し、配置し、表示する。

エンドユーザのためにスクリーン上に表示されるフォームの外観を指定するために、記述は、入力フィールド、フラグ、スイッチ、ボタン、ボーダパネル、ページ（ブックマーク）パネル、ページそれ自体、コマンドパネル、さらに要素（カラム）を含むテーブル、その他、などのフォームの要素を含むツリーの形式で用いられる。上記のように、図４は、フォーム要素４３０のツリーの好ましいスクリーンショットを図示する。さらに、図５は、同一のツリーフォーム要素を図示するが、ＸＭＬｓｔｒｕｃｔｕｒｅｓの形式で図示される。好ましいツリーが図４および図５に示す好ましい要素および／またはスクリーン上の要素の場所の特定の位置調整によって限定されない、ということを評価するべきである。むしろ、これらの好ましい態様は、要素のシーケンスおよびグループを図示するのみである。

前述のように、フォーム要件は、フォームを必要データにリンクするために用いられる。特に、要件は、フォームによって表示されるデータのリストを示す。要件は、コマンドリスト内で編集される。ディベロッパは、フォームの詳細を追加または除去する能力を有する。

以上にさらに記述したように、フォーム内のアクションは、すべて、どのように１つのアクションまたは別のアクションを実行するべきであるかの記述として機能するコマンドによって実行される。フォームのコマンドは、コマンドリスト内で編集される。ディベロッパは、データベース内に格納された１セットのプロパティの支援によってそれらのプロパティを割り当てるだけでなく、フォームのコマンドを追加し除去する能力を有する。１つの態様によれば、各コマンドに関して、ディベロッパは、このコマンドがユーザによって呼び出される場合に実行される手続きを指定することができる。コマンドがその機能を実行し始めるためには、フォームの必要な要素（すなわち、それに関するイベント）にリンクされなければならない。

１つの態様によれば、開発される構成のフォームに関して、ディベロッパは、全体構成のコマンドインタフェースにおいて用いられるグローバルコマンドだけでなく、フォームそれ自体（すなわちローカルコマンド）の両方のコマンドを用いることができる。この態様において、現在のフォームのデータに基づくあるパラメータがコマンドと一緒に送られる（例えば、これは、支出インボイスフォーム（ｅｘｐｅｎｄｉｔｕｒｅ ｉｎｖｏｉｃｅ ｆｏｒｍ）内で現在選択されている倉庫内の手元のストックをレポートするという呼び出し（ｃａｌｌ）であり得る）ときに、グローバルコマンドは、（別のディレクトリまたはドキュメントを開くコマンドなどのように）簡素であり、パラメータ化することができる。

１つの態様において、所定のタイプのオブジェクト用に生成されるフォームは、すべて同一の動作をしてもよい。したがって、「ディレクトリ」タイプの任意のオブジェクトに関しては、その要素、その個別要素、ディレクトリグループのリストの表示を必要とし、ディレクトリから要素および要素のグループを選択することができる。このような標準的アクションの実行を可能にするために、対応する動作を実行する場合に用いられることになるオブジェクトのタイプの各々に対して１セットの従属するフォームを生成することになる。

例えば、オブジェクト「契約者ディレクトリ」に関しては、個々の選択された契約者の要件カードのいくつかまたはすべてのフィールド（例えば名称、住所、電話、納税者ＩＤ、管理者の姓名、および同種のもの）の編集のための第１のフォームと、契約者の全リストが出力される第２のフォームとが生成される。この第２のフォームを活用して、ユーザは、全グループの契約者を、リストを通じて閲覧したり分類したり、除去したりすることなどができる。

１つの実例において、新たなオブジェクトおよびそのフォームをユーザアプリケーションに追加することが必要になる場合で、且つ（異なる設計または特定の外観によるものなど）所定のオブジェクトのためのその他のフォームを作成することが必要でない場合、ディベロッパは、ユーザアプリケーションの新たなオブジェクトを単純に追加することができ、システムは、フォームのオブジェクトセットのために最低限必要なものを生成するためにシステム内に組み込まれた規則を自動的に用いることになる。

したがって、新たなオブジェクトを追加するときに、または特別のデータオブジェクトを開くときに、システムは、オブジェクトに関連するすべてのデータとともに表示され編集されることになる、以前に開発されたフォームの論理記述のオブジェクトとともに自動的にロードされる。このような記述がある場合、システムは、論理記述をロードし、それに基づいたフォームのさらなる生成がある。

対照的に、このような記述がロードされていない場合、システムは、ロードされたオブジェクトのタイプを判定することができる、すなわち、構成のどのタイプのメタデータオブジェクト（例えば、ディレクトリ、ドキュメント、情報レコード、勘定科目表、および同種のもの）に関連するかを判定する。オブジェクトのタイプを決定した後に、システムは、構成のすべての既知のタイプのメタデータオブジェクトの基本的な論理記述を含む規則のセットから所定のオブジェクトに適用される規則を選択し、論理記述を生成する。

好ましい態様によれば、エンドユーザが自身のスクリーン上のフォームを見る前に、システムは、以下のオペレーション、すなわち、フォームの生成、フォームの変換、フォームの出力（すなわち描画）を実行することになる。したがって、オブジェクトのフォームの論理記述が得られた後（ディベロッパによって自動的に生成されようが、または予め保存されようが）、システムは、それを変換し始める。変換は、機能的オプション、アクセス権、およびユーザ設定の利用に基づいてユーザインタフェースを変更するステップを含む。機能的オプションに基づくユーザインタフェースの変更は、適用されるソリューションにおいて、機能を選び出すことを可能にし、それは、それを実施するときに、適用されるソリューションそれ自体の変更を伴わずに、オン／オフすることができる。

エンドユーザのアクセス権に応じて、システムは、フォーム内の表示または編集のために、ユーザにどのデータを提示することができないかを正確に判定する。ユーザ設定の支援によって、ユーザは、自身で、表示のために必要なフォーム要素をオン／オフすることができる。したがって、記述、機能的オプション、アクセス権、およびユーザ設定に基づいて、システムは、特定ユーザのためのフォームの視覚的表現を表示（描画）することを提供する。

さらに、システムの支援によって、方法の変形を実施することができる。すなわち、フォームの視覚的表現の表示（描画）およびエンドユーザがそれを処理し始める後に、情報メッセージは、データを入力するときにユーザが誤りをしたそれらのフォーム要素の下に配置されたフォームの特別のウィンドウ内に表示される、フォームの特定要素に関連して出力される。例えば、ユーザがテキストを入力した新たなドキュメントを作成するときに日付フィールドまたは必須フィールドを埋めなかった場合に、システムは、前記の特別のウィンドウにおいて、このことをユーザ自身に伝える。

図１は、例示的な態様による、ユーザインタフェースを自動的に生成する方法１００のためのフローチャートを図示する。図示したように、初めに、ユーザがユーザインタフェースを生成する自動化された処理を始める場合、開示されるシステムは、ステップ１０５において、要求されたユーザインタフェースに関する１つ以上のオブジェクトにアクセスする。具体的には、図４を参照する例によれば、ユーザは、メインメニューにおいて、例えば特定の目的を選択することができ、その使用は「車両」ガイド（すなわち「カタログ車両」）を選択することができる。これは、ユーザがこのディレクトリに関心をもつことを示しており、したがって、システムは、このディレクトリからの情報から、適切なフォームを示すことができる。

次に、ステップ１１０において、方法は、オブジェクトのフォーム論理記述が、ディベロッパによって規定されて保存されるか否かを判定する。ＹＥＳの場合、方法１００は、論理記述の存在がロードしたオブジェクトのためのフォーム用に決定されるステップ１１５に進む。その代わりに、オブジェクトのフォーム論理記述がディベロッパによって事前に定義されない場合、方法は、フォーム論理記述が規定されるステップ１２０に進む。再び、一旦規定されると、方法は、論理記述の存在がロードしたオブジェクトのためのフォーム用に決定されるステップ１１５に進む。開示される方法を実行するために、システムは、図２（ａ）および図２（ｂ）に関してここで記述されることになる。

特に、図２（ａ）および図２（ｂ）は、例示的な態様による、ユーザインタフェースを自動的に生成するシステム２００のためのブロック図を図示する。図３に関して以下に記載されるコンピュータシステムなどのコンピュータシステムを用いて、システム２００を実施することができる、ということは評価されるべきである。図３に示すように、以下に記載される様々なデータを、システムメモリ２２上に格納することができる、ということは評価されるべきである。さらに、図２（ａ）および図２（ｂ）に関して以下に論じられるモジュール（すなわちジェネレータおよびエグゼキュータ）は、当業者に理解されるように、ソフトウェア／ハードウェアモジュールとして実施することができる。本明細書において用いられるように、用語「モジュール」は、（実行されている間に）マイクロプロセッサシステムを専用装置に変換する、例えば特定用途向け集積回路（ＡＳＩＣ）若しくはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）またはマイクロプロセッサシステムやモジュールの機能を実施する１セットの命令などのハードウェアおよびソフトウェアの組み合わせなどによる、ハードウェアを用いて実施される実在の装置、コンポーネント、またはコンポーネントの設備を指す。モジュールは、また、ハードウェア単独によって容易にされたある機能、およびハードウェアおよびソフトウェアの組み合わせによって容易にされた他の機能との、２つの組み合わせとして実施することができる。一部の実施態様において、モジュールの少なくとも一部分、およびいくつかのケースにおいて、モジュールのすべては、汎用コンピュータのプロセッサ上で実行することができる。したがって、各モジュールは、様々な適切な構成において実現することができ、本明細書に例示される、いかなる例示的な実施態様にも限定されるべきでない。

ここで図２（ａ）および図２（ｂ）を参照すると、好ましい態様は、開示されるシステムのモジュールおよびデータベースとの対話を図示する。特に、図２（ａ）に示すシステムは、対応するオブジェクト用の事前に配置され格納された論理記述フォームの欠如を暗に示す。さらに、図２（ｂ）のシステム２００は、対応するオブジェクトのフォームの（開発段階において）予め準備されて格納された論理記述の存在を暗に示す。この点に関して、（以上に記述された）図４は、形状の記述がない「カスタマ」ディレクトリ４１０のために提供されたものである簡素なテストアプリケーションの開発の例を図示する。対照的に、「車両」ディレクトリ４２０は、予め開発されており、フォーム「ＦｏｒｍＡｕｔｏ２」４２５の論理記述を維持する。しかしながら、実行の間に、フォームは、例えば、図６（ａ）に示すように、ユーザのために自動的に生成されることになる。

図２（ａ）に戻って参照すると、ユーザは、「カスタマ」ディレクトリ４１０に基づいて特別のオブジェクトをアクセスすることができる。この実例において、システムは、このオブジェクトのために事前に格納された論理記述フォームが存在するか存在しないかをチェックして確認することができる。図示するように、フォームＬｏｇＤｅｓｃｒ（すなわち論理記述）ジェネレータ２２０は、興味のあるオブジェクトのオブジェクトメタデータ２１１にアクセスし、オブジェクトのタイプおよび他の特性の情報を受信する。受信情報に基づいて、ジェネレータ２２０は、オブジェクトの記述用の論理フォームを自動的に生成し、フォーム外観ジェネレータ２８０のフォーム入力に対して論理フォームを提供する。ひいては、ジェネレータ２８０は、（例えば「ユーザ設定」２４１を用いた）但しデータを伴わずに、フォーマッティングルールに基づいた未来のフォームの外観、フォーマット、同種のものを生成するように構成される「フォームエンジン」のタイプである。その代わりに、この目的のために、論理記述に加えて、例えば、電子データベース２４０内に格納される機能的オプション（「ＦＯ」）２６０、アクセス権（「ＵＲ」）２７０、およびユーザ設定２４１を含む、３つのパラメータが入力される。好ましい態様によれば、ユーザ設定２４１は、論理的基準、人間工学的基準、審美的基準、およびビジネス上の基準の既定のセットに基づいてフォーム要素を編成するように構成されたフォーマッティングルールを含むことができる。したがって、エンドユーザは、例えば、フォーム上の異なる要素の外見および位置決めを含む、彼らのプレファレンスおよびその他同種のものにカスタマイズされるこれらのユーザ設定を規定することができる。

図８は、好ましい態様による、ユーザ設定の構成を与えるソフトウェアアプリケーションのスクリーンショットを図示する。好ましい態様によれば、ユーザは、いくつかのフィールドの外観を変更するために（必要に応じて）フィールドを再配置することができるし、必要に応じて、（もし必要とされない場合）未使用のフィールドのいくつかを、目に見えないようにすることができる。

具体的には図示するように、スクリーンショットは、図２（ａ）および図２（ｂ）対して上で述べたように、ユーザ設定２４１の準備／変更ためのインタフェースを図示する。１つの態様によれば、ユーザ設定２４１は、フィールドを交換すること（すなわち、（もし必要とされない場合）未使用のフィールドを目に見えないようにすること）、例えばフィールドの外観および場所を変更すること、絶対項の要素サイズを明示的に指定することに限定してもよい。１つの態様によれば、ユーザは、新たなフィールドを追加することができない。

したがって、ユーザ権利２７０、機能的オプション（「ＦＯ」）２６０、およびユーザ設定２４１を考慮して、論理記述は、（フォームメタデータ２１２内にどのように格納されるのか、ディベロッパと比べて）フォーム外観ジェネレータ２８０において変更されることになる。その結果、論理記述は、必要に応じて、後者がクライアント側に伝送する準備ができた後の、中景（ｉｎｔｅｒｍｅｄｉａｔｅ ｖｉｅｗ）、すなわち視覚的な記述、に変換されることになる。

クライアント側で、図２（ａ）および図２（ｂ）に示すように、フォーム外観ジェネレータ２８０によって生成された記述の結果として生じるフォームは、図形出力トランスフォーマ２９０の入力に送られることになる。図形出力トランスフォーマ２９０は、ワークステーション、スマートフォン、またはその他同種のものなどのクライアント装置の特定の特性に対して結果として生じるフォームの形状を最適化するように構成される。

例えば１つの好ましい態様において、ウェブクライアント（すなわちクライアント側）上の図形出力トランスフォーマ２９０の実施態様は、ＪａｖａＳｃｒｉｐｔ（登録商標）またはＡｃｔｉｖｅＸブラウザ環境内でダウンロード可能および実行可能として実施されてもよい。別の例として、ｉｎｓｔａｌｌａｔｉｏｎ ｐａｃｋａｇｅ．ｄｅｂからＣ＋＋内に記載されたクライアントアプリケーションの一部としてインストールされる後者を伴うＵｎｉｘシステムの下のシンクライアントの実施態様が挙げられる。

好ましい態様によれば、図形出力トランスフォーマ２９０の出力は、そのスクリーンのサイズ、指定された解像度、使用されるスクリーンフォント、オペレーティングシステム、クライアントアプリケーション（ブラウザまたはシンクライアント）などに基づいた特定のクライアント装置上の図面の構成要素を保証するために既に十分に細かい視覚的な記述を提供する。１つの態様によれば、視覚表現に関しては、図形出力トランスフォーマ２９０出力は、絶対的にはすべての視覚的要素の正確な寸法および座標を既に含んでいてもよい。

さらに、フォームの外観および形状が既に規定されている場合に、興味のあるオブジェクトに関するデータベース２４０から、入力済みフォームエグゼキュータモジュール２９５にアクセスされることができ、フォームデータ領域（すなわち「ユーザデータ」）２４２のデータコンテンツにもアクセスすることができる。その後、フォームデータは、対応するディスプレイ装置上（モニタ、スマートフォンディスプレイなど）に表示されてもよい。

上述のように、図２（ｂ）は、ディベロッパが所望のフォーマットの論理記述を開始することを可能にするシステムを図示する。ここで、システムは、また、フォームＬｏｇＤｅｓｃｒジェネレータ２２０も利用する。上述のように、ジェネレータ２２０は、オブジェクトメタデータ２１１にアクセスするように構成され、受信した情報に基づいてオブジェクトのタイプおよび他の特性のこの情報を受信する。さらに、ジェネレータ２２０は、このオブジェクトのためのいくつかの事前のフォームの論理記述を自動的に生成し、ディベロッパに対して、改善されるべき論理記述を提供する。好ましい態様によるとオプションである記述（「Ｄｅｓｃｒ」）エディタ２３０により、ディベロッパは、フォームの論理記述に変更を加えて、改善されたフォームをフォームメタデータ２１２の一部として格納することが可能になる。

図２（ｂ）に示すようにアプリケーションの第２のステージにおいて、ディベロッパが特別のオブジェクトにアクセスする場合、システムは、事前に格納された論理フォーム記述がオブジェクト用のフォームメタデータ２１２内にあるということをチェックし確認するように構成される。好ましい態様によれば、事前に格納された論理フォーム記述は、フォーム外観ジェネレータ２８０に提供される論理記述である。ひいては、ジェネレータ２８０は、未来のフォームの非装置の特定の外観およびフォーマットを、但し上記のデータを含まずに、生成する。このために、論理記述に加えて、機能的オプション（「ＦＯ」）２６０、ユーザ許可（ユーザのアクセス権「ＵＲ」）２７０、およびユーザ設定／プレファレンス２４１を含む入力の３つのパラメータとともにフォームが供給される。

さらに、フォームの外観およびフォーマットが最終のデバイス固有アウトラインに既に設定されているときに、入力済みフォームエグゼキュータモジュール２９０は、アクセスされ、興味のあるオブジェクトに関するフォームデータ領域２４２のデータコンテンツは、モジュール２９０によってさらにアクセスされる。

メタデータ２１２チャートの形式の画像、機能的特色２６０、ユーザのアクセス権２７０、およびユーザ設定２４１が、４つの分離したソース（すなわち記憶場所）として提供され、それらは好ましい態様による異なるデータベース内に物理的に格納されるように示されるが、但し代替的に単一のデータベース内に提供することもできる、ということを認識するべきである。しかしながら、個別のソースとして提供されるこれらのタイプのデータを、異なる時期に異なるユーザによって生成することができる、ということは評価されるべきである。具体的には、フォームメタデータ２１２は、ディベロッパ構成によって規定することができ、機能的オプション２６０は、例えば、特定の会社のニーズに典型的な構成を適合させる実装者によって規定することができ、（これらはその時々に修正され得るが）、会社内部のシステム管理者によってアクセス権２７０を構成することができ、最終的に、ユーザ設定２４１は、個々の最後のユーザによってそれらのプレファレンスおよびその他同種のものにカスタマイズされる設定とすることができる。

図１に戻って参照すること、ステップ１１５は、アクセスされたオブジェクトメタデータ（例えば図２のオブジェクトメタデータ２１１）に基づいてフォーム用の１つ以上の論理記述をデータベースからロードするステップを特別に必要とし、論理記述は、フォーム用のフォーム要素およびコマンドの宣言を含む。一旦論理記述がロードされると、方法は、オブジェクトに対する機能的オプションが読み取られるステップ１２５に進む。１つの態様によれば、方法は、読み取られた機能的オプション上に基づいてユーザインタフェース内の追加変更のためのニーズを決定することをさらに含む。次に、方法は、ユーザに適用されたアクセス権（ステップ１３０）およびユーザ設定（ステップ１３５）を読み取るか、または決定する。

一旦この情報が検索されれば、方法は、機能的オプション、アクセス権、およびユーザ設定によって改善された論理記述に基づいて、ステップ１４０において最終のデバイス固有ではないフォームの視覚的な記述を生成する。その後、フォームの記述を、サーバ側からクライアント側に送り出すことができる。

クライアント側においては、フォームが特定のクライアント装置のためにカスタマイズされるように、フォームの記述は、ステップ１４５においてデバイス固有に変換される。上述のように、このカスタマイズは、そのスクリーンのサイズ、指定された解像度、使用されるスクリーンフォント、クライアントアプリケーション（ブラウザまたはシンクライアント）などのオペレーティングシステムを含む設定の表示に基づくことができる。最終的に、ステップ１５０において、フォーム（すなわち、ユーザインタフェース）には、その後、生成されたフォーム内にそれらを表示するためにデータオブジェクトを埋めることができ、フォーム用の外観形状データを、ユーザに対するスクリーン上での表示のために準備することができる。

図３は、アプリケーション用のユーザインタフェースの自動化された生成のために開示されるシステムおよび方法を実施するために用いることができるコンピュータシステム５の一態様例を表す。コンピュータシステム５は、パーソナルコンピュータ、ノートブック、タブレット型コンピュータ、スマートフォン、ネットワークサーバ、ルーター、または他のタイプの処理装置を含んでもよいが、これらに限定されない。図示するように、コンピュータシステム５は、システムバス１０によって接続される、１つ以上のハードウェアプロセッサ１５、メモリ２０、１つ以上のハードディスクドライブ３０、光ドライブ３５、シリアルポート４０、グラフィックスカード４５、音声カード５０、およびネットワークカード５５を含んでもよい。システムバス１０は、様々な既知のバスアーキテクチャのいずれかを用いる、メモリバスまたはメモリコントローラ、周辺バスおよびローカルバスを含む、いくつかのタイプのバス構造のいずれかであってもよい。プロセッサ１５は、１つ以上のインテル（登録商標）コア２クアッド２．３３ＧＨｚプロセッサまたは他のタイプのマイクロプロセッサを含んでもよい。

システムメモリ２０は、読み取り専用メモリ（ＲＯＭ）２１およびランダムアクセスメモリ（ＲＡＭ）２３を含んでもよい。ＤＲＡＭ（ダイナミックＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、フラッシュ、または他のタイプのメモリアーキテクチャ内などにメモリ２０を実装してもよい。ＲＯＭ２１は、起動の間などに、コンピュータシステム５のモジュール間の情報を伝送するのを支援する基本ルーチンを含む基本入出力システム２２（ＢＩＯＳ）を格納する。ＲＡＭ２３は、Ｗｉｎｄｏｗｓ（登録商標）７プロフェショナルまたは他のタイプのオペレーティングシステムなどの（プロセスおよび割り当ての管理および協調のための役割を担い、コンピュータシステム５内のハードウェア資源を共有する）オペレーティングシステム２４（ＯＳ）を格納する。メモリ２０は、また、アプリケーションおよびプログラム２５を格納する。メモリ２０は、また、プログラム２５によって用いられる様々なランタイムデータ２６を格納する。

コンピュータシステム５は、ＳＡＴＡ ＨＤＤなどのハードディスクドライブ３０と、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、または他の光学的媒体などの着脱可能な光ディスクから読み取るための若しくはその光ディスクに書き込むための光ディスクドライブ３５とをさらに含んでもよい。ドライブ３０および３５およびそれらの関連するコンピュータ読み取り可能なメディアは、本明細書に開示されるアルゴリズムおよび方法を実装するコンピュータ読み取り可能な命令、データ構造、アプリケーション、およびプログラムモジュール／サブルーチンの不揮発性記憶装置を提供する。好ましいコンピュータシステム５は磁気光ディスクおよび光ディスクを利用するが、コンピュータシステム５によってアクセス可能なデータを格納することができるコンピュータ読み取り可能なメディアの他のタイプのものが当業者によって認識されるべきであり、磁気カセット、フラッシュメモリカード、ディジタルビデオティスク、ＲＡＭ、ＲＯＭ、ＥＰＲＯＭ、および他のタイプのメモリなども、コンピュータシステム５の代替的な態様において用いられてもよい。

コンピュータシステム５は、キーボード、マウス、タッチパッド、およびその他のものなどのデータ入力デバイス７５を接続するための、ユニバーサルシリアルバス（ＵＳＢ）などの複数のシリアルポート４０をさらに含む。外部データストレージ装置およびその他同種のものなどの他の周辺機器８５だけでなく、データ出力装置８０（プリンタ、スキャナ、およびその他のものなど）を接続するためにも、シリアルポート４０を用いてもよい。システム５は、また、タッチスクリーンディスプレイなどのディスプレイ６０または他のビデオ再生装置とのインタフェースを確立するための、ｎＶｉｄｉａ（登録商標）ＧｅＦｏｒｃｅ（登録商標）ＧＴ２４０Ｍなどのグラフィックスカード４５または他のビデオカードを含んでもよい。システム５は、また、内部スピーカ６５または外部スピーカ６５を介して音を再生するための音声カード５０を含んでもよい。さらに、システム５は、インターネットなどのネットワーク７０にコンピュータシステム５を接続するための、イーサネット（登録商標）、Ｗｉ−Ｆｉ、ＧＳＭ（登録商標）、ブルートゥース（登録商標）、または他の有線、無線若しくはセルラーネットワークインタフェースなどのネットワークカード５５を含んでもよい。

様々な態様において、本明細書に記載されるシステムおよび方法は、ハードウェア、ソフトウェア、ファームウェア、またはそのあらゆる組み合わせで実装されてもよい。もしソフトウェア内に実装されれば、方法は、非一時的なコンピュータ読み取り可能媒体上に１つ以上の命令またはコードとして格納されてもよい。コンピュータ読み取り可能媒体は、データストレージを含む。限定ではなく、例として、このようなコンピュータ読み取り可能媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭ、フラッシュメモリ、または他のタイプの電気記憶媒体、磁気記憶媒体、光記憶媒体、または、汎用コンピュータのプロセッサによってアクセスすることができる命令若しくはデータ構造の形式の所望のプログラムコードを所持若しくは格納するために用いることができる他のメディアを備えることができる。

明瞭さのために、態様の決まりきった特徴のすべてが本明細書に開示されるとは限らない。本開示のあらゆる実際の実施態様の発展において、多数の実装固有の決定がディベロッパの特定の目標を実現するために行われなければならず、これらの特定の目標が異なる具体化および異なるディベロッパのために変化するであろうことが理解される。このような開発努力は複雑で時間がかかる可能性があるが、この開示の利益を受ける当業者にとってエンジニアリングの決まりきった作業になるだろうことが理解される。

さらに、本明細書で使用される語法または専門用語は、限定ではなく記述のためのものであり、本明細書の専門用語または語法が、本明細書に提示された教示およびガイダンスに照らして、当業者の知識と組み合わせて、当業者に解釈されるものである、ということを理解されたい。また、明示的に示さない限り、明細書または特許請求の範囲内のあらゆる用語が通常でない特別の意味に帰着することは意図していない。

本明細書に開示した様々な態様は、実例として本明細書において参照する既知のモジュールに対する、現在および未来の均等物を包含する。また、態様および適用を図示し記述したが、この開示の恩恵を受ける当業者には、本明細書に開示の概念から逸脱することなく、上述のものよりもさらに多くの改善が可能である、ということは、明らかであろう。

５ コンピュータシステム
１０ システムバス
１５ ハードウェアプロセッサ
２０ メモリ
２１ 読み取り専用メモリ（ＲＯＭ）
２２ システムメモリ（基本入出力システム（ＢＩＯＳ））
２３ ランダムアクセスメモリ（ＲＡＭ）
２４ オペレーティングシステム（ＯＳ）
２５ プログラム
２６ ランタイムデータ
３０ ハードディスクドライブ
３５ 光ドライブ
４０ シリアルポート
４５ グラフィックスカード
５０ 音声カード
５５ ネットワークカード
６０ ディスプレイ
６５ スピーカ
７０ ネットワーク
７５ データ入力デバイス
８０ データ出力装置
８５ 他の周辺機器
１００ 方法
２００ システム
２１１ オブジェクトメタデータ
２１２ フォームメタデータ
２２０ フォームＬｏｇＤｅｓｃｒジェネレータ
２３０（「Ｄｅｓｃｒ」） エディタ
２４０ 電子データベース
２４１ 「ユーザ設定」
２４２ フォームデータ領域（「ユーザデータ」）
２６０ 機能的オプション（「ＦＯ」）
２７０ ユーザのアクセス権（「ＵＲ」）
２８０ フォーム外観ジェネレータ
２９０ 図形出力トランスフォーマ
２９５ 入力済みフォームエグゼキュータモジュール
４１０ 「カスタマ」ディレクトリ
４２０ ディレクトリ（ディレクトリ「車両」）
４２５ ＦｏｒｍＡｕｔｏ２
４３０ フォーム要素

Claims (20)

1. アプリケーション用のユーザフォームインタフェースを動的に生成する方法であって、
   要求されたユーザフォームインタフェースに関するオブジェクトメタデータにアクセスするステップと、
   前記アクセスされたオブジェクトメタデータに基づく前記ユーザフォームインタフェースのための論理記述であって少なくとも前記ユーザフォームインタフェースのためのフォーム要素およびコマンドの宣言を含む前記論理記述をデータベースからロードするステップと、
   前記アクセスされたオブジェクトメタデータに関する機能的オプションを前記データベースから検索し、前記機能的オプションに基づいて前記ユーザフォームインタフェースに対する少なくとも１つの追加変更のための要件を決定するステップと、
   前記ユーザフォームインタフェースのユーザにとって利用可能なアクセス権を検索するステップと、
   既定の基準に基づいて前記フォーム要素を編成するように構成されたフォーマッティングルールを含むフォームエンジンをアクティブ化するステップと、
   前記論理記述、前記機能的オプション、前記ユーザにとって利用可能な前記アクセス権、およびユーザ設定に基づいて、前記ユーザフォームインタフェース用の視覚的記載データであってデバイス固有ではない前記視覚的記載データを前記フォームエンジンによって自動的に生成するステップと、
   クライアント装置の表示設定に基づいて前記ユーザフォームインタフェースをカスタマイズする前記クライアント装置に対して、前記視覚的記載データを提供するステップと
   を備える方法。
2. 前記既定の基準は、論理的基準、人間工学的基準、審美的基準、およびビジネス上の基準のセットを含む請求項１に記載の方法。
3. 前記クライアント装置の表示設定は、前記クライアント装置のスクリーンのサイズ、前記クライアント装置の前記スクリーンの指定解像度、前記クライアント装置の前記スクリーンの指定されたフォント、前記クライアント装置のオペレーティングシステム、および前記クライアント装置のブラウザのうちの少なくとも１つを含む請求項１に記載の方法。
4. 前記ユーザが前記フォーム要素の少なくとも１つに間違ってデータを入力している場合、前記フォーム要素に隣接するウィンドウ内の前記ユーザフォームインタフェースの特定要素に関する情報メッセージを前記クライアント装置上に表示するステップをさらに備える請求項１に記載の方法。
5. 前記ユーザフォームインタフェース用の前記論理記述は、フォーム要素のサイズおよび順番のうちの１つ以上に関する情報をさらに含む請求項１に記載の方法。
6. 前記論理記述は、少なくとも１つの前記フォーム要素または前記フォーム要素のグループと、複数の関連するフォームに適用する１つ以上のグローバルコマンドとをさらに含む請求項１に記載の方法。
7. 前記論理記述は、前記検索されたフォームデータをもつ新たなフォームユーザインタフェースを開くように構成された１つ以上のコマンドをさらに含む請求項１に記載の方法。
8. アプリケーションフォームを動的に生成するためのサーバシステムであって、
   少なくとも１つのユーザフォームインタフェース用の論理記述であって少なくとも前記ユーザフォームインタフェース用のフォーム要素およびコマンドの宣言を含む前記論理記述を格納するように構成されたデータベースと、
   ネットワークインタフェースであって、
   要求されたユーザフォームインタフェースに関するオブジェクトメタデータにアクセスし、
   前記アクセスされたオブジェクトメタデータに基づいて、前記ユーザフォームインタフェースのための論理記述であって少なくとも前記ユーザフォームインタフェースのためのフォーム要素およびコマンドの宣言を含む少なくとも１つの前記論理記述を前記データベースからロードし、
   前記アクセスされたオブジェクトメタデータに関する機能的オプションを前記データベースからロードし、前記機能的オプションに基づいて前記ユーザフォームインタフェースに対する少なくとも１つの追加変更のための要件を決定し、
   前記ユーザフォームインタフェースのユーザにとって利用可能なアクセス権を検索する
   ように構成された前記ネットワークインタフェースと、
   既定の基準に基づく前記フォーム要素を編成し、前記論理記述、前記機能的オプション、前記ユーザにとって利用可能な前記アクセス権、およびユーザ設定に基づいて、前記ユーザフォームインタフェース用の視覚的記載データであってデバイス固有ではない前記視覚的記載データを自動的に生成するように構成されたフォームエンジンフォーマッティングルールと
   を備え、
   前記ネットワークインタフェースは、クライアント装置の表示設定に基づいて前記ユーザフォームインタフェースをカスタマイズする前記クライアント装置に対して前記視覚的記載データを提供するように構成される、
   サーバシステム。
9. 前記既定の基準は、論理的基準、人間工学的基準、審美的基準、およびビジネス上の基準のセットを含む請求項８に記載のサーバシステム。
10. 前記クライアント装置の表示設定は、前記クライアント装置のスクリーンのサイズ、前記クライアント装置の前記スクリーンの指定解像度、前記クライアント装置の前記スクリーンの指定されたフォント、前記クライアント装置のオペレーティングシステム、および前記クライアント装置のブラウザのうちの少なくとも１つを含む請求項１０に記載のサーバシステム。
11. 前記ネットワークインタフェースは、前記ユーザが前記フォーム要素の少なくとも１つに間違ってデータを入力している場合、前記フォーム要素に隣接するウィンドウ内の前記ユーザフォームインタフェースの特定要素に関する情報メッセージを前記クライアント装置上に表示するようにさらに構成される請求項８に記載のサーバシステム。
12. 前記ユーザフォームインタフェース用の論理記述は、フォーム要素のサイズおよび順番のうちの１つ以上に関する情報をさらに含む請求項８に記載のサーバシステム。
13. 前記論理記述は、フォーム要素の１つ以上のグループをさらに含む請求項８に記載のサーバシステム。
14. 前記論理記述は、複数の関連するフォームに適用する１つ以上のグローバルコマンドと、前記検索されたフォームデータをもつ新たなフォームユーザインタフェースを開くように構成された１つ以上のコマンドとの少なくとも１つをさらに含む請求項８に記載のサーバシステム。
15. 非一時的なコンピュータ読み取り可能記録媒体に格納されたコンピュータプログラムプロダクトであって、アプリケーションフォームを動的に生成するためのコンピュータ実行可能命令を備え、
    要求されたユーザフォームインタフェースに関するオブジェクトメタデータにアクセスするための命令と、
    前記アクセスされたオブジェクトメタデータに基づく前記ユーザフォームインタフェースのための論理記述であって少なくとも前記ユーザフォームインタフェースのためのフォーム要素およびコマンドの宣言を含む前記論理記述をデータベースからロードするための命令と、
    前記アクセスされたオブジェクトメタデータに関する機能的オプションを前記データベースから検索し、前記機能的オプションに基づいて前記ユーザフォームインタフェースに対する少なくとも１つの追加変更のための要件を決定するための命令と、
    前記ユーザフォームインタフェースのユーザにとって利用可能なアクセス権を検索するための命令と、
    既定の基準に基づいて前記フォーム要素を編成するように構成されたフォーマッティングルールを含むフォームエンジンをアクティブ化するための命令と、
    前記論理記述、前記機能的オプション、前記ユーザにとって利用可能な前記アクセス権、およびユーザ設定に基づいて、前記ユーザフォームインタフェース用の視覚的記載データであってデバイス固有ではない前記視覚的記載データを前記フォームエンジンによって自動的に生成するための命令と、
    クライアント装置の表示設定に基づいて前記ユーザフォームインタフェースをカスタマイズする前記クライアント装置に対して前記視覚的記載データを提供するための命令と
    を含むコンピュータプログラムプロダクト。
16. 前記既定の基準は、論理的基準、人間工学的基準、審美的基準、およびビジネス上の基準のセットを含む請求項１５に記載のコンピュータプログラムプロダクト。
17. 前記クライアント装置の表示設定は、前記クライアント装置のスクリーンのサイズ、前記クライアント装置の前記スクリーンの指定解像度、前記クライアント装置の前記スクリーンの指定されたフォント、前記クライアント装置のオペレーティングシステム、および前記クライアント装置のブラウザのうちの少なくとも１つを含む請求項１５に記載のコンピュータプログラムプロダクト。
18. 前記ユーザが前記フォーム要素の少なくとも１つに間違ってデータを入力している場合、前記フォーム要素に隣接するウィンドウ内の前記ユーザフォームインタフェースの特定要素に関する情報メッセージを前記クライアント装置上に表示するための命令をさらに含む請求項１５に記載のコンピュータプログラムプロダクト。
19. 前記ユーザフォームインタフェース用の前記論理記述は、フォーム要素のサイズおよび順番のうちの１つ以上に関する情報をさらに含む請求項１５に記載のコンピュータプログラムプロダクト。
20. 前記論理記述は、フォーム要素の１つ以上のグループと、複数の関連するフォームに適用する１つ以上のグローバルコマンドとの少なくとも１つをさらに含む請求項１５に記載のコンピュータプログラムプロダクト。