JP2009534766A - アプリケーション・データ・エディタを生成するための方法及びシステム - Google Patents

Abstract

【課題】 データモデルから始まり、実行環境で用いるように適合されたデータ・エディタを生成する方法を提供すること。
【解決手段】 アプリケーションの永続データを編集するための、コンピュータのグラフィカル・ユーザ・インターフェースを介して実行されるエディタを生成する方法、コンピュータ・プログラム及びシステムであって、永続データは、クラス、それらの属性、及びクラス間の関係の階層的組織を定義するモデリング言語を用いてデータ・オブジェクト・モデル内に記述され、格納され、この方法は、ルート・クラスを検索し、ルート・クラスから開始するステップと、クラスのインスタンスを作成するためにクラス毎にページを作成するステップとを含む。現在のクラスの各ページは、クラスの属性を編集する編集セクションと、それらが作成されるときにクラスの全てのインスタンスを列挙するテーブル・セクションと、現在のクラスと関連するターゲット・クラスに対応する他のページへのポインタを列挙するハイパーリンク・セクションとを含む。
ハイパーリンク・セクションのポインタを用いてページ内をナビゲートするエディタのユーザは、モデルの全てのクラスをインスタンス化することができる。
【選択図】 図２

Description

本発明は、一般に、アプリケーションのユーザ・インターフェースの開発に関し、より特定的には、本発明は、アプリケーション・データのオブジェクト・モデルに基づいて生成されるフォームエディタ・生成プログラム（generator）に関する。

ビジネス・アプリケーションの開発サイクルの一部であるエディタの生成は、アプリケーション・データの収集を可能にするユーザ・インターフェース（ＵＩ）をエンドユーザに提供する。そのコードを容易に展開し、維持するためのＵＩコードが、オブジェクト指向技術を用いて開発されている。
アプリケーションのデータモデルから始まるこれらのエディタの生成を容易にする必要性が存在する。

オブジェクト指向ソフトウェア工学を容易にする多くのツールが存在する。統一モデリング言語（Ｕｎｉｆｉｅｄ Ｍｏｄｅｌｉｎｇ Ｌａｎｇｕａｇｅ、ＵＭＬ）のような方法は、開発アーチファクトを視覚化し、管理するためのグラフィカル言語を提供する。これらの方法は、開発者に対してコードを生成するためのツールを提供するが、それは、一般的に、細粒度コードであり、全てのユーザ・アプリケーション及び編集機能を含むものではない。特許文献１は、フレームワークのツリー表示、オブジェクトのグラフ表示、メソッドのメソッド表示及び編集表示から成るオブジェクト指向フレームワークを対話形式で生成し、フレームワーク、オブジェクト及びメソッドを変更するための解決法を提供する。実行時オブジェクトは自動的に生成することができるが、開発者は、例えば、生成されたコードが実行されるターゲット・オペレーティング・システムのグラフィカル機能に応じて編集属性の特異性を導入することによってこのコード生成をカスタマイズする可能性を有していない。この解決法を用いる場合、オブジェクトが作成されると、カスタマイズのために、各々のエディタ・コードを変更する必要がある。

Ｅｃｌｉｐｓｅ Ｍｏｄｅｌｉｎｇ Ｆｒａｍｅｗｏｒｋ（ＥＭＦ）は、構造化されたデータモデルに基づいてツール及び他のアプリケーションを構築するためのモデリング・フレームワーク及びコード生成ファシリティである。ＸＭＩ（ＸＭＬ Ｍｅｔａｄａｔａ Ｉｎｔｅｒｃｈａｎｇｅ）形式で記述されたモデル仕様から、ＥＭＦは、モデルに関するＪａｖａクラスの組、モデルの表示及びコマンド・ベースの編集を可能にするアダプタ・クラスの組、及び基本的なエディタを生成するために、ツール及び実行時支援を提供する。編集属性の何らかの特異性を導入することによって、エディタをカスタマイズすることができるが、エディタは、基本的で一般的なものである。エディタは、ツリーを表示し、そのツリーの各ノードについての属性を列挙する。従って、ＥＭＦを用いて生成されたエディタは、開発及び試験目的のために用いることができるが、データモデルの下でより詳細なデータ更新をカバーすることを必要とする現実のビジネス環境における実行のために用いることはできない。

Ｏｂｊｅｃｔ，Ｖｉｅｗ，ａｎｄ Ｉｎｔｅｒａｃｔｉｏｎ Ｄｅｓｉｇｎ（ＯＶＩＤ）は、コード設計に変換することができるソフトウェア設計方法である。ＯＶＩＤは、ＵＭＬで書かれたアプリケーションの永続データのオブジェクト・モデルから開始し、エディタのためのコード生成に終わる。編集属性の何らかの特異性を導入することによって、定義段階の際にエディタ・インターフェースをカスタマイズすることができる。しかしながら、ＯＶＩＤを用いる場合、開発者は、モデルを変更し、ターゲット・ユーザ・インターフェースの特異性を入力することによってこれに適合させなければならない。このことは、煩わしく、モデル作成者（modeler）が、エディタを生成するために、ＵＭＬモデル内のＵＩ仕様を定義することを強いる。モデル作成者は、エディタを実行するために、ターゲットと同数のモデルを生成しなければならない。

米国特許第ＵＳＰ５９８７２４７号

従って、オリジナル・データモデルから独立した方法で、かつ、効率的にデータを更新するように適合された最終的なエディタを用いて、アプリケーション・データのエディタを生成する解決法に対する必要性が存在する。

従って、本発明の目的は、データモデルから始まり、実行環境で用いるように適合されたデータ・エディタを生成する方法を提供することである。

この目的は、アプリケーションの永続データを編集するための、コンピュータのグラフィカル・ユーザ・インターフェースを介して実行されるエディタを生成するための方法、コンピュータ・プログラム及びシステムであって、永続データは、クラス、それらの属性及びクラス間の関係の階層的組織を定義するモデリング言語を用いてデータ・オブジェクト・モデル内に記述され格納される、方法、コンピュータ・プログラム及びシステムを用いる請求項１乃至請求項８によって達成され、この方法は、ルート・クラスを検索し、ルート・クラスから開始するステップと、クラスのインスタンスを作成し、更新するためにクラス毎にページを作成するステップとを含む。現在のクラスの各ページは、クラスの属性を編集する編集セクションと、それらが作成されるときにクラスの全てのインスタンスを列挙するテーブル・セクションと、現在のクラスと関連するターゲット・クラスに対応する他のページへのポインタを列挙するハイパーリンク・セクションとを含む。

ハイパーリンク・セクションのポインタを用いてページ内をナビゲートするエディタのユーザは、モデルの全てのクラスをインスタンス化することができる。エディタの一実施形態においては、モデルの他のクラスのページを指し示すスクリーンの最下行に、タブが追加される。１つの他の実施形態においては、同じ抽象ページに属する全てのクラスのために、固有のページが作成され、編集セクションは、現在のページの異なる先祖によってグループ化される属性を含む。１つの他の実施形態において、現在のクラスの先祖が、メタモデル内に見出され、現在のクラスの先祖によってグループ化された属性を編集するためのフィールドが、編集セクション内に表示される。

本発明の解決法の主な利点は、オリジナル・データモデルの如何なる変更もなしに、エディタを生成することである。データモデルの如何なる変更も要求することなく、エディタ生成段階中に、エディタのユーザ・インターフェースをカスタマイズすることができる。その結果、アプリケーション開発グループ内の異なる開発者又は試験者の責任下にあるエディタ生成段階の際に、モデル設計者が関与する必要がなくなる。

好ましい実施形態において、ページ構築コードを変更するために、生成プログラム内のフックに対応するグラフィカル・ユーザ・インターフェースであるインターフェースを開発者に提供することによって、エディタ・コードの生成中に、エディタのユーザ・インターフェースのカスタマイズが行われる。これにより、より冗長な作業である従来技術の解決法のように、一旦生成されたコードを直接変更することが回避される。

本発明の方法によって生成されたエディタは、ページの組内にあるアプリケーションの完全なデータモデルの全てのコンポーネントをカバーする。好ましい実施形態において、オブジェクト毎に１ページの、生成されたマルチページ・エディタは、概要ページを表示し、エンドユーザに、編集されたルート（又は、主、中央、．．．）オブジェクトの完全なビジョンを与えることで開始する。１つのページにおいて、ユーザは、所定のクラス及び編集セクションにおいて編集可能である、クラス階層内の上位のクラスに関するクラス属性を更新することができる。関係インスタンスが、テーブル・セクション内に列挙され、ユーザは、ハイパーリンク・セクションを用いて関係インスタンスのターゲット・クラスを指し示すことができる。
本発明の方法によって生成されたエディタを用いる場合、同じ抽象クラスに属するクラス・ページをグループ化することによって、ページ数が随意的に減少される。

図１は、好ましい実施形態に従った、本発明によって生成されるアプリケーション・エディタを構成し、使用するための環境を示す。この環境において、データのメタモデルを形成する、アプリケーションの永続データのためのエディタが生成される。

好ましい実施形態において、本発明は、コンピュータ上で実行されるソフトウェア・プログラムすなわちエディタ生成プログラム（１０３）として実施される。エディタのソース・コードを作成する方法のステップの他の可能な実施も適している。

エディタ生成プログラム（１０３）は、アプリケーションの開発者が、アプリケーション実行ファイル（１１２）と組み合わせて、アプリケーション・データ及びそれらの属性を生成し、読み取り、更新し、削除する方法をユーザ（１１１）に提供することができる、十分に使用可能なリッチアプリケーション・エディタ（１０５）のコードを生成するのを可能にする。

エディタ生成プログラム（１０３）は、「ソフトウェア開発環境」（１００）において実行され、データ・エディタのコードを生成する。次に、エディタは、「実行環境」（１１０）において実行される。「実行環境」は、データモデルの永続データが編集されるアプリケーションの試験環境としてもよい。この場合、実行環境は、開発環境であり、開発者により、同じコンピュータ上でエディタ生成プログラム及びエディタを実行することができる。実行環境はまた、ターゲット・アプリケーションのビジネス環境とすることもでき、この場合、エディタ生成プログラムは、依然として開発者によって実行され、エディタは、アプリケーションのエンドユーザによって実行される。

ソフトウェア開発環境（１００）は、アプリケーション全体を構築するために開発者のコンピュータ・ワークスペースにおいて使用可能な、エディタ、コンパイラ、リンカーのようなツールを含む、今日多くのものが存在する開発フレームワークである。ソフトウェア環境は、オペレーティング・システム上で動作するプログラムとしてインストールされ、本発明の好ましい実施形態のお気に入りの開発者インターフェースとして用いられるグラフィカル・ユーザ・インターフェースを提供する。

コア・ユニットである生成プログラム（１０３）は、プログラム入力のような情報の組を必要とする。第１の入力は、好ましい実施形態において、ＵＭＬのようなグラフィカル表示を有することができる設計言語で記述されたアプリケーションによって操作されるデータを表わすデータのメタモデル（１０２）である。エディタ生成プログラムはまた、実行環境（１１０）と両立性があると思われる開発環境内のＵＩグラフィック機能と関連するグラフィック・ライブラリ（１０４）の組にもアクセスする。生成プロセスの際の生成プログラムは、このグラフィカル・ライブラリの組に依存する。

他の機能の中でも、開発者に柔軟性を与えるために、生成プログラムは、開発者によって提供されるエディタのグラフィカル・カスタマイズ（１０６）を統合することができる。これらのカスタマイズにより、開発者に、生成されたアプリケーション・エディタの特有なグラフィカル・ルック・アンド・フィール要件を強いることが可能になる。これらのカスタマイズは、開発環境のグラフィカル・ライブラリ（１０４）と両立性がある。これらのカスタマイズは、実行環境においてエディタが実行されるときに適用される。

図２は、本発明の好ましい実施形態に関与する高レベルのコンポーネントの詳細を示す。図２は、生成プロセス中に使用されるアプリケーション・エディタ生成プログラム（２００）の論理コンテンツと、生成されたアプリケーション・エディタを定義する結果として得られるコンポーネント（２１０）との関係とを示す。

エディタ生成プログラム（２００）は、４つの主コンポーネント、すなわちモデル訪問者（Visitor）（２０１）、パッケージ訪問者（２０２）、クラス訪問者（２０４）及び関係訪問者（２０６）を含む。生成プログラムのプロセスは、開発者の要求で開始し、アプリケーション設計者によって定義されたデータ・メタモデル（１０２）を主入力として用いてエディタ生成プログラム（２００）を起動する。

生成プログラムのプロセスは、選択されたデータ・メタモデルを検査することで開始し、モデル訪問者（２０１）を用いて、モデル定義自体に訪問することで開始する。好ましい実施形態において、モデルは、ＵＭＬを用いて設計され、そこで、関連した要素が「パッケージ」の下でグループ化される。この検査中、生成プログラムは、その中に含まれる全てのパッケージを検索する。含まれるパッケージの全てについてループを作ると、次に、エディタ生成プロセスは、パッケージ訪問者（２０２）を用いて全てのパッケージをループし、検索された各パッケージ内に含まれる全てのクラスを探す。生成プロセスは、データ・メタモデル・コンテンツを検査し続け、次に関係ビジタ（２０６）を用いて、現在のところ検査されたクラスについて定義された全ての関係を探す。

データ・メタモデルの検査中、エディタ生成プロセスは、３つの主タイプ、すなわちエディタ（２１１）、ページ（２１２）及びセクション（２１３、２１４、２１５）の言語認識実行可能エディタ・コンポーネント（２１０）を生成する。

生成されたコンポーネントの関係は、次のとおりである、すなわち、エディタ（２１１）はページ（２１２）を含み、ページはセクション（２１３、２１４、２１５）を含む。各ページは１つのオブジェクトに対応し、ページのセクションは、３つのタイプ、すなわちハイパーリンク・セクション（２１３）、テーブル・セクション（２１４）及び編集セクション（２１５）からなるものとすることができる。テーブル・セクション（２１４）は、メタモデルに従った、オブジェクトと他のオブジェクトとの関係インスタンスのリストを提供する。ハイパーリンク・セクション（２１３）は、リンク・リストを提供し、エンドユーザが、モデル内で起点オブジェクトが関連する他のオブジェクト・インスタンスを指し示すことを可能にする。編集セクション（２１５）においては、モデル内の編集可能なフィールドが表示される。

図３は、好ましい実施形態の方法を用いて実施されるような、生成されたアプリケーション・エディタのページのレイアウト詳細及び構成（３００）を示す。

生成されたエディタにおいては、クラス毎に１つの編集可能なページが存在する。ページは、クラスの全てのインスタンスを作成するために、生成されたエディタのエンドユーザによって使用される。アプリケーションの全ての編集可能なデータの全てのクラスの全てのインスタンスを編集するために、生成されたエディタによって表示される標準的なページは、オブジェクト・モデル内のナビゲーションを反映する。好ましい実施形態の生成されたエディタによって表示された標準的なページは、ページの右上側の編集セクション（３０２）、左側のテーブル・セクション（３０４）及び右下側のハイパーリンク・セクション（３０３）である３つの編集可能なセクションを含む。タブの最下行は、タブの対応するインスタンスをさらに編集するために、他のページに、すなわち他のクラスにジャンプすることを可能にする。

クラスのページにおいて、編集セクション（３０２）は、クラスと、クラスの属性とを表示する。そのクラスがクラス階層内の第１のものでない場合には、編集セクション内により上位の階層のクラスも列挙される。テーブル・セクション（３０４）は、対応するクラスのページを編集するときにエンドユーザが作成する全てのインスタンスのリストを含む。ハイパーリンク・セクション（３０３）は、ページを作成するクラスと関連したターゲット・クラスのページへのポインタを含む。

その結果、１つのクラスに関するこのようなページから、エンドユーザは、テーブル・セクションの行をクリックすることによって、そのクラスの全てのインスタンスにジャンプすることができる。エンドユーザはまた、ページに対応するクラスと関連した全てのターゲット・クラスのインスタンスにジャンプすることもできる。

実行されたとき、生成されたエディタは、第１のページ、すなわち概要ページを表示する。ページの最下行は、ユーザが、エディタの他のクラス・ページを選択することを可能にするタブ（３０１）を含む。この概要ページから、エンドユーザは、クラスの全体的なビジョンをつかむ。生成されたエディタ（３００）によって表示される１つ１つのページは、選択することができ、現在のページ選択に従ってそのコンテンツを表示する。

エンドユーザが必要とし得る全てのグラフィカル・ルック・アンド・フィールに適合させるために、カスタマイズを用いて、エディタ生成プロセス中又はその後、生成されたコードにおいて直接的にセクションの全ての標準的な場所を変更することができる。

図４は、生成プロセス（１０３）中にアプリケーション・エディタ（２１０）のページを生成する（４００）方法の一般的なフローチャートである。このフローチャートは、クラス訪問者コンポーネント（２０４）において実施される。

このプロセスの第１のステップは、現在のパッケージに関するデータ・メタモデル（１０２）のルート・クラスを検索する（４０１）ことである。ルート・クラスは、メタモデル内の他のいずれのクラスにも含まれないか、又はそれによって参照されないクラスであり、このクラスは、好ましい実施形態に従った、本発明による編集のための入口として考えられる。このサブプロセスが、図５に示される。

終了するとき、ルート・クラス探索（lookup）プロセス（５００）が、クラス定義を現在のページ構成プロセス（４００）に送り返す。次に、ページ識別子及びラベルの基礎としてクラス名を用いてページを生成する（４０２）ために、クラス定義を用いる。ページ構成プロセスは、図６を参照してこの文書の後半に記載される。このページ構成プロセスが行なわれるとき、プロセスは、パッケージ内に含まれる全ての他のクラスを収集する（４０３）。

ステップ４０３の後、プロセスは、収集された全てのクラスをループし（４０４）、次いで、インターフェースを処理するかどうかをチェックする（４０５）。クラスは、それ自体がメソッドを定めるインターフェースを実装することができ、インターフェースは、通常のクラスとしてインスタンス化することができず、その結果、編集されていないために、プロセスにおいてインターフェースをフィルタ処理しなければならない。これがインターフェースである（試験４０５に対してイエスと返答する）とき、次のクラスが読み取られる（４１１）。これがインターフェース・クラスではない（試験４０５に対してノーと返答する）とき、システムは、現在のクラスの階層をチェックし（４０６）、パッケージ（４０８）内から抽象クラス（４０７）を探し、この抽象クラスに基づいて共通ページを作成する（４０９）。抽象クラスは、抽象概念を表し、インスタンス化されるべきではない。親クラスとしての抽象クラスは、その下にグループ化された子クラスを有する。抽象クラスは、子の属性内に含まれる属性を有することができる。ページの数を制限するために、エディタは、１つの抽象クラスのページ内にある同じ抽象クラスの下の全てのクラスのページをグループ化する。抽象クラス・ページの編集セクションは、属性のグループ、すなわち子の属性に共通する抽象クラスの属性のグループと、各々の子に関する属性のグループとを含む。抽象クラスが存在しない（４０７に対してノーと返答する）場合、生成プロセスは、ステップ４０２及び４０９におけるものと同じ構成及び命名法を用いてページを作成し（４１０）、１つのクラスについて１つのページを作成するステップは、図６を参照して文書の後半に記載される。全てのページを作成するステップの際、使用されるクラスと作成されるページとの間のリンクは、生成プロセスによってメモリ内に保持される。生成プロセス中にコードがメモリ内にリンクを保持する方法は、当業者によって知られており、かつ、プログラミング言語に依存するため、この文書内には記載されていない。次に、生成プロセスは、ステップ４０３において収集されたパッケージの次のクラスをチェックする。チェックするクラスがなくなったとき、ページ作成プロセスが終了する。

フローチャートのいずれのステップにおいても、開発者は、生成プログラム内のページを変更できることが留意される。より特定的には、毎回すなわちステップ４０２、４０９、４１０において、ページが作成される。その必要性に適合させるようにページ・コードを変更することができる場合、その段階で、開発者は、生成プロセス内のフックを用いて、新たに生成されたページ・コードにアクセスすることができる。開発者がコードを変更する好ましい実施形態においては、開発者によるページ内の変更の実施を容易にするより高性能のグラフィカル・ユーザ・インターフェースを用いる、他の実施形態を考慮することができる。

好ましい実施形態において、クラスは、パッケージによってグループ化されることになっていることも留意される。例えば、ＵＭＬ言語を用いてデータ・メタモデルを記述する場合、ＵＭＬパッケージは、それ自体が他のパッケージを含み得るサブモデルを含む。同様に、この実施形態において、この抽象クラスの同じページ（ステップ４０６乃至ステップ４０９）の下で抽象クラスに依存する全てのクラスをグループ化する関数は、これが生成されたエディタ内のページ数を制限し、これをより簡単にするので、生成されたエディタの最適化である。異なるクラス毎に１つのページを実装する１つの他の実施形態を考慮することもできる。

図５は、エディタ・コンポーネントの生成プロセス中、ページ構成プロセス（４００）に用いられるルート・クラスを検索する（４０１）ために用いられる方法を詳述するフローチャートである。このフローチャートは、クラス訪問者コンポーネント（２０４）において実施される。

プロセスの第１のステップは、現在のＵＭＬパッケージ内に含まれる全てのページを収集し、それらの全てをループする（５００）ことである。好ましい実施形態において、メタモデルは、ＵＭＬ言語を用いて記述され、ＵＭＬパッケージは、それ自体が他のパッケージを含み得るサブモデルを含む。

各々のクラス定義を用いる際、システムは、メタモデル内で定義された関係に基づいてクラスの特徴を取得し（５０１）、それらの全てをループし（５０２）、別のクラスを参照する関係を探す（５０３）。次に、参照されたクラス（５０４）をチェックし、もしあれば、その子を取得し（５０５）、他の場合にはそれ自体を取得する。

ステップ５０６の間、システムは、現在のクラス（５０７）をリスト内に保存する。このリストは、現在のパッケージ内の別のものによって参照される全てのクラスをメモリ内に保持するように働く。

このプロセスは、パッケージ内に分析すべきそれ以上の子（５０８）、それ以上の関係の特徴（５０９）、及びそれ以上のクラス（５１０）がなくなるまで、クラスをループし続ける。

プロセスの第２の主部分は、パッケージ内に含まれる全てのクラスを、ステップ（５０７）において以前に保存された参照リストと比較することを目的とする。

ルート・クラスを見つけるために、現在のプロセスは、全てのクラスをループし（５１２）、リスト内に存在するかどうかを確認するために、現在のところ読み取られたクラスをチェックする。リスト内に存在する場合には、プロセスは、読み取るクラスがなくなるまで続く。プロセスが、参照されたリスト内にはないクラスが見つかった場合、このクラスがルート・クラスであり（ステップ５１５）、ページ構成プロセス（４００）に送り返される。プロセスによってルート・クラスが戻されない（ステップ５１６）場合には、生成プロセス全体が停止するか、又は、パッケージ内に含まれているクラス・リストからクラスを選択するよう、開発者に要求することができ、次に、このクラスが、ルート・クラスとして働き、ページ構成プロセス（４００）に送り返される。

図６は、１つのクラスについて１つのページを作成するように実行される一般的なフローチャートである。このフローチャートは、図４に記載されたページ構成プロセス（４０２、４１０）において実行される。３つのタイプのセクションすなわち好ましい実施形態における編集セクション（２１５）、ハイパーリンク・セクション（２１３）及びテーブル・セクション（２１４）が、ページ内に作成される。このフローチャートは、関係訪問者コンポーネント（２０６）において実施される。

ページ作成の第１のステップ（６０１）は、ページ構成プロセス中に保持されたページとクラスとの間のイン・メモリ・リンクを用いて、ページと関連付けられた現在のクラスを検索する。ステップ６０２において、編集セクションが作成され、現在のページに追加される。

編集セクションは、現在のクラスの属性及びそれらのタイプに基づいた編集フィールドを含む。編集セクションを作成するとき、サブプロセスが、全ての現在のクラスの属性及びそれらのタイプを検索し、ラベルを、続いて属性タイプに基づいたグラフィカル・コンポーネントを作成し、それらのどれか１つに関するセクションにこれを追加する。

属性タイプと編集セクション内に表示されるグラフィカル・コンポーネントとの間の関連付けの一例として、ブール（Boolean）の場合のチェック・ボックス、列挙（Enumeration）の値のリストで満たされたコンボ・ボックス（列挙は、週の日又はＣＰＵタイプのような固有の要素の集まりを定義するために通常使用される名前付き定数の集まりである）及び他のタイプの単純なテキスト編集がある。これらの関連付けは、この文書内では例として提供されており、実施の文脈に従って拡張又は適合される。

現在のクラスから、プロセスは、次に、いずれかを見つけた場合、全ての継承されたクラスをループし（６０３）、インターフェースとして定義されたクラスをフィルタにかけ、試験６０４に対する返答がイエスである場合、次のクラスを読み取り（６１５）、試験６０４に対する返答がノーである場合、プロセスは、全ての見つけられた先祖に関する編集セクションを作成し、これを現在のページの編集セクションに追加する（６０５）。これにより、現在のクラスが先祖から継承した、現在のクラスの属性の現在のページ内の表示が与えられる。このことは、データ・メタモデル階層内の各クラスの位置決めについての、エディタのユーザ表示を改善する。従って、この改善（ステップ６０３、６０４、６０５）は随意的なものである。

現在のクラスから、プロセスは、その特徴の全てを読み取り、参照される（６０７）特徴だけを保持し、参照をループし（６０６）、参照されるクラスを検索する（６０８）。次に、プロセスは、インターフェースをフィルタにかけ（６０９）、参照されたクラスに対応する全てのクラス・ページへのポインタ・リストを用いてハイパーリンク・セクションを作成し（２１３）、このセクションを現在のページに追加する（６１０）。

参照されたクラスを用いて、現在のクラスと参照されたクラスとの間のターゲット・クラスの関係を検索する際に、プロセスは、テーブル・セクション（２１４）を作成し、イン・メモリ・マッピングを用いてターゲット・クラスからターゲット・ページを取得し、新しく作成されたテーブル・セクションをターゲット・ページに追加する（６１２）。最終的に、プロセスは、ターゲット・ページに関する編集セクション（２１５）を作成し、このセクションをターゲット・ページに追加し、言語がそのことを可能にする場合には、テーブル内の選択された項目をテーブル・セクション（２１４）から編集セクション（２１５）の現在の編集にリンクする。

セクション構成プロセス（６００）は、協働するそれ以上の特徴もそれ以上のクラスもなくなったときに終了する。

図７は、好ましい実施形態に従った、本発明による必要な入力として用いられるＵＭＬ言語を用いて表されたデータ・メタモデルの例（７００）を示す。

図７においては、定義されたグラフィカル属性を有さない任意のオブジェクト指向モデリング言語ツール、正しいクラス（７０１）、クラス属性及びそれらの関連したタイプ（７０３）、並びにクラス間の関係（７０２）を用いて、プログラム設計者又はアーキテクトによってモデル化される、データ・メタモデル（１０２）のインスタンスが表されている。このクラスの図の例は、Ｒａｔｉｏｎａｌ Ｒｏｓｅと名付けられたモデリング・ツールを用いてなされたものである。他の任意の高レベルのオブジェクト指向モデリング言語ツーリングを用いて、データ・メタモデルの他の表現をなすことができた。

図７のデータ・メタモデルから読み取られたナビゲーション・ツリーからのクラス、クラス属性及びクラス間の関係は、エディタ・プログラムにおいて生成プログラムが構築する編集フローの基礎であることが留意される。

図８は、エディタ生成プログラム（１０３）、好ましい実施形態においてはＥｃｌｉｐｓｅ ｆｒａｍｅｗｏｒｋである開発フレームワークによって提供されるグラフィカル・ライブラリ（１０４）、及び含まれるハイパーリンク・セクション（８０２）をページの左側に表示し、外部参照を右側に表示するように、レイアウトを変更するための生成プログラムのカスタマイズ（１０６）の入力としてデータ・メタモデルの図７のインスタンス（７００）を用いる、好ましい実施形態に従って生成されたアプリケーション・エディタの一例（８００）を示す。

全てのページは、ノートブック型の表示（８０３）を用いてエンドユーザが選択することが可能である。エディタ内に表示された第１のページは、生成プロセス中に検索されたルート・クラス（５００）に基づいて作成され、編集されることになる全てのプロジェクトのクラス属性を含む編集セクション（８０１）を表示する。

好ましい実施形態に従った、本発明によって生成されるアプリケーション・エディタを構成し、使用するための環境を示す。 生成プログラム及び生成されたエディタの高レベルのコンポーネントを示す。 好ましい実施形態の方法を用いて実施されるような、生成されたアプリケーション・エディタのページ（３００）のレイアウト詳細及び構成を示す。 好ましい実施形態に従った、アプリケーション・エディタのページを生成する方法の一般的なフローチャートである。 本発明の好ましい実施形態の生成プロセス中に、データ・メタモデルの「ルート・クラス」を検索するのに用いられる方法を詳述するフローチャートである。 好ましい実施形態に従った、３つのタイプのセクションを含むページを作成する方法の一般的なフローチャートである。 好ましい実施形態に従った、本発明による入力として用いられる統一モデリング言語（ＵＭＬ）を用いて表されたデータ・メタモデルの一例を示す。 好ましい実施形態に従って生成されたアプリケーション・データ・エディタのスクリーン・ショットの一例を示す。

Claims (8)

1. アプリケーションの永続データを編集するための、コンピュータのグラフィカル・ユーザ・インターフェースを介して実行されるエディタを生成する方法であって、前記永続データは、クラス、それらの属性、及びクラス間の関係の階層的組織を定義するモデリング言語を用いてデータ・オブジェクト・モデル内に記述されて格納され、
   前記モデルを読み取り、いずれかの他のクラスによって参照されない前記モデル内の唯一のクラスであるルート・クラスを検索するステップと、
   前記ルート・クラスから開始し、前記関係を用いて各々のクラスを読み取るステップと、
   インターフェースではない読み取られたクラスいわゆる現在のクラス毎に、前記現在のクラスの全てのインスタンスを編集するためにページを作成するステップと、
   各々の現在のクラスとその作成されたページとの間のリンクを格納するステップと、
   各々の現在のページ内に、前記現在のクラスの属性を編集するフィールドを含む第１のセクションと、それらが編集されるときに前記現在のクラスの全てのインスタンスを列挙する第２のセクションとを作成し、前記格納されたリンクを使用して、前記現在のクラスにおいて参照された前記クラスのクラス・ページ・インスタンスに向けたポインタを表示する第３のセクションを作成するステップと
   を含む方法。
2. クラス毎にページを作成する前記ステップは、エディタのユーザに、前記ページの作成のグラフィカル表示を変更する可能性を提供するステップをさらに含む、請求項１に記載の方法。
3. 前記格納されたリンクを用いて、前記モデルのいずれかのクラスの前記ページにアクセスするためのポインタを表示するためのステップをさらに含む、請求項１又は請求項２に記載の方法。
4. ポインタを表示するための前記ステップは、上にクラス名を有するタブをスクリーン上に表示するステップを含み、
   各々のタブは、対応するクラスの前記ページの方向にユーザを導く、
   請求項１乃至請求項３のいずれか１項に記載の方法。
5. 第１のセクションを作成する前記ステップは、前記モデルの前記階層内の前記現在のクラスよりも上位にある全ての先祖クラスの属性によって前記現在のクラスの属性を編集するためのフィールドをグループ化するステップを含む、請求項１乃至請求項４のいずれか１項に記載の方法。
6. ページを作成する前記ステップは、前記現在のクラスが帰属するいずれかの抽象クラスを探すステップを含み、
   抽象クラスが見つかった場合、前記抽象クラスが前記現在のクラスになり、
   前記現在のクラスの前記ページ内に第１のセクションを作成する前記ステップは、前記抽象クラスの属性及び全ての子クラスの属性を編集するためのフィールドをグループ化するステップを含む、
   請求項１乃至請求項５のいずれか１項に記載の方法。
7. コンピュータに、請求項１乃至請求項６のいずれか１項に記載の方法に係るステップを実行させるためのコンピュータ・プログラム。
8. 請求項１乃至請求項６のいずれか１項に記載の前記方法を実行するように適合された手段を含むシステム。

Images