(57)【要約】  本発明は、計算処理システムで、構造、機能、挙動を特定する論理を持つことのできるソフトウェア・オブジェクトの動的生成と再生成の方法と装置を提供する。一実施形態は、システム論理オブジェクトを含むソフトウェア・オブジェクトの、関連するが異なるインスタンスを生成する再生成機能である。この再生成機能は、その定義とパラメータ化が生成モデルから取得され、ビルダと呼ばれるソフトウェア・オブジェクトによって実施される順序付きのタスク・シーケンスを含む。各ビルダは、１組の入力パラメータと、システム論理オブジェクトを含むゼロ個または複数の生成済みソフトウェア・オブジェクトを含むコンテナへの参照とを受け入れる。再生成機能は、各ビルダに、コンテナの内容を処理し、オブジェクトを付加、変更、削除し、コンテナを更新済みの内容と共に返すよう指図する。再生成機能の挙動は、選択されたビルダを無効にすること、およびビルダへの入力を変更することによって変更し得る。
2005510790.tif 000002
【特許請求の範囲】
【請求項１】
オブジェクトを作成する方法であって、
生成モデルを取得するステップと、
前記オブジェクトを生成するために前記生成モデルを処理するステップと
を含む方法。
【請求項２】
前記処理するステップが、
前記生成モデル中のビルダ呼び出しリストに位置する複数のビルダ呼び出しを見つけるステップと、
複数のビルダ入力からなるプロファイルを取得するステップと、
前記オブジェクトが作成された際にそれらを保持する生成コンテナを作成するステップと、
前記ビルダ呼び出しを使用して前記生成コンテナに前記オブジェクトを作成するステップと
をさらに含む請求項１に記載の方法。
【請求項３】
生成モデルを取得する前記ステップが、
生成管理プログラムを使用して前記生成モデルを取得するステップ
をさらに含む請求項２に記載の方法。
【請求項４】
前記ビルダ呼び出しを使用する前記ステップが、
前記ビルダ呼び出しを使用して第１のフェーズで前記生成管理プログラムを用いた再生成を実施するステップと、
複数のフェーズで再生成を実施する前記ステップを繰り返すステップと
をさらに含む請求項２に記載の方法。
【請求項５】
再生成を実施する前記ステップが、
生成コンテキストを使用して、前記ビルダ呼び出しリスト中の前記複数のビルダ呼び出しに関連する複数の生成ハンドラを取得するステップと、
前記複数のビルダ呼び出しを実行するステップと
をさらに含む請求項４に記載の方法。
【請求項６】
前記実行するステップが、
前記ビルダ呼び出しのサブセットが無効または有効であるとマークされるように構成するステップと、
有効であるとマークされた前記ビルダ呼び出しのサブセットを実行するステップと
をさらに含む請求項５に記載の方法。
【請求項７】
前記実行するステップが、
前記ビルダ呼び出しリストからの第１のビルダ呼び出しを処理するステップと、
前記生成コンテキストを使用して前記第１のビルダ呼び出しに関連する第１の生成ハンドラを初期設定するステップと、
前記第１のビルダ呼び出しのために第１のビルダを初期設定するステップと、
前記第１のビルダの再生成メソッドを呼び出すステップと、
前記複数のビルダ呼び出しのために、前記処理するステップ、前記生成コンテキストを使用するステップ、第１のビルダを初期設定する前記ステップ、前記再生成メソッドを呼び出すステップを繰り返すステップ
をさらに含む請求項５に記載の方法。
【請求項８】
第１のビルダを初期設定する前記ステップが、
ビルダ定義によって識別された前記第１のビルダを探し出すステップと、
前記ビルダ入力の組を使用して前記第１のビルダのインスタンスを取得するステップと、
前記現在のビルダを呼び出す準備をするステップと
をさらに含む請求項７に記載の方法。
【請求項９】
前記第１のビルダを取得する前記ステップが、前記第１のビルダの新規インスタンスをインスタンス化することを必要とする請求項８に記載の方法。
【請求項１０】
前記生成モデルを作成することをさらに含む請求項２に記載の方法。
【請求項１１】
前記作成するステップが、
デザイナ・アプリケーションを使用して前記生成モデルを作成するステップと、
前記生成モデルを用いて再生成プロセスを実施するステップと、
前記再生成プロセスの結果を見えるようにするステップと、
任意選択で前記生成モデルを編集するステップと
をさらに含む請求項１０に記載の方法。
【請求項１２】
デザイナ・アプリケーションを使用する前記ステップが、
新規ビルダ呼び出しを作成するためにビルダ・エディタをインスタンス化するステップと、
ビルダ定義オブジェクトを取得し、前記生成モデル中の第１の選択されたビルダ呼び出しのためのビルダ入力の定義を探し出すステップと、
前記ビルダ入力に対応する複数の動的ビルダ入力を構築するステップと、
前記第１の選択されたビルダ呼び出しによって識別されたビルダのコーディネータ機能をインスタンス化するステップと
をさらに含む請求項１１に記載の方法。
【請求項１３】
ビルダ・エディタをインスタンス化する前記ステップが、前記生成モデルの前記ビルダ呼び出しリスト中の第２の選択されたビルダ呼び出しを変更するために前記ビルダ・エディタをインスタンス化する請求項１２に記載の方法。
【請求項１４】
ビルダ定義を取得する前記ステップが、
前記ビルダ呼び出しリストに新規ビルダ呼び出しを構築する際に使用するビルダの種類の名前を取得するステップと、
前記名前を使用して前記ビルダ定義オブジェクトを取得するステップと
をさらに含む請求項１２に記載の方法。
【請求項１５】
１組のビルダ・ユーザ・インターフェイス・ウィジェットをインスタンス化するステップと、
前記コーディネータ機能をセットアップするステップと、
前記生成コンテナを前記コーディネータ機能が使用できるようにするステップと、
前記ビルダ呼び出しに、前記ユーザ・インターフェイス・ウィジェットを介して入力された更新済みの動的ビルダ入力値を保存するステップと
をさらに含む請求項１２に記載の方法。
【請求項１６】
前記プロファイルを作成するステップをさらに含む請求項２に記載の方法。
【請求項１７】
前記作成するステップが、
カストマイザ・アプリケーションを使用して前記プロファイルを編集するステップと、
前記プロファイルを用いて再生成を実施するステップと、
第２の生成されたオブジェクトの組を取得するステップと
をさらに含む請求項１６に記載の方法。
【請求項１８】
実行エンジンで前記第２の生成されたオブジェクトの組を実行するステップをさらに含む請求項１７に記載の方法。
【請求項１９】
カストマイザ・アプリケーションを使用して、前記プロファイル中の前記複数のビルダ入力を変更するステップをさらに含む請求項２に記載の方法。
【請求項２０】
前記オブジェクトが直列化され得る請求項１に記載の方法。
【請求項２１】
前記オブジェクトがＸＭＬで提示される請求項１に記載の方法。
【請求項２２】
前記オブジェクトがソース・オブジェクトである請求項１に記載の方法。
【請求項２３】
前記ソース・オブジェクトがプログラミング言語で表現される請求項２２に記載の方法。
【請求項２４】
前記プログラミング言語がＪａｖａである請求項２３に記載の方法。
【請求項２５】
前記ソース・オブジェクトが推論エンジン規則言語で表現される請求項２２に記載の方法。
【請求項２６】
前記推論エンジン規則言語がＩＬＯＧ規則言語である請求項２５に記載の方法。
【請求項２７】
前記ソース・オブジェクトが複数のシステム論理オブジェクトを含む請求項２２に記載の方法。
【請求項２８】
実行エンジンで前記生成されたオブジェクトを実行するステップをさらに含む請求項１に記載の方法。
【請求項２９】
生成モデルと、
プロファイルと、
再生成エンジンと、
複数のビルダと、
前記再生成エンジンが前記プロファイルと共に前記生成モデルを処理して前記複数のビルダを制御し、前記オブジェクトをそこに生成するための生成コンテナと
を含むオブジェクトを作成するシステム。
【請求項３０】
前記複数のビルダが前記生成コンテナ中の前記オブジェクトを編集する請求項２９に記載のシステム。
【請求項３１】
前記再生成エンジンが生成管理プログラムをさらに含む請求項２９に記載のシステム。
【請求項３２】
前記生成管理プログラムが再生成の複数のフェーズを実施する請求項２９に記載のシステム。
【請求項３３】
生成コンテキストと、
生成ハンドラと、
ビルダ入力オブジェクトと、
ビルダ定義オブジェクトと
をさらに含む請求項３２に記載のシステム。
【請求項３４】
前記ビルダ定義オブジェクトが、
複数のビルダ入力定義と、
複数のビルダ・グループ定義と
をさらに含む請求項３３に記載のシステム。
【請求項３５】
前記生成コンテナが複数のオブジェクトを指し示す生成要素をさらに含む請求項３２に記載のシステム。
【請求項３６】
実行エンジンと、
前記実行エンジンが前記オブジェクトを実行するための動作アプリケーションと
をさらに含む請求項２９に記載のシステム。
【請求項３７】
前記生成モデルが、複数のビルダ呼び出しを含むビルダ呼び出しリストをさらに含む請求項２９に記載のシステム。
【請求項３８】
前記生成モデルの前記複数のビルダ呼び出しを編集するためのデザイナ・アプリケーションをさらに含む請求項３７に記載のシステム。
【請求項３９】
前記デザイナ・アプリケーションが、
ビルダ呼び出しリスト・ビューと、
生成コンテナ・ビューと、
アプリケーション・ビューと
をさらに含む請求項３８に記載のシステム。
【請求項４０】
前記デザイナ・アプリケーションが、
前記複数のビルダ呼び出し中の前記１つのビルダ呼び出しによって特定されたビルダのために複数の動的ビルダ入力を生成するようにビルダ定義を処理するためのビルダ・エディタ
をさらに含む請求項３９に記載のシステム。
【請求項４１】
前記プロファイルが、
複数のビルダ入力
をさらに含む請求項２９に記載のシステム。
【請求項４２】
ユーザが前記プロファイルを編集するためのカストマイザ・アプリケーション
をさらに含む請求項４１に記載のシステム。
【請求項４３】
ユーザが前記プロファイルを作成するためのカストマイザ・アプリケーション
をさらに含む請求項４１に記載のシステム。
【請求項４４】
前記カストマイザ・アプリケーションが、
プロファイル・ビューと、
プロファイル作成済みアプリケーション・ビューと
をさらに含む請求項４３に記載のシステム。
【請求項４５】
前記オブジェクトが直列化され得る請求項２９に記載のシステム。
【請求項４６】
前記オブジェクトがＸＭＬで提示される請求項２９に記載のシステム。
【請求項４７】
前記オブジェクトがソース・オブジェクトである請求項２９に記載のシステム。
【請求項４８】
前記ソース・オブジェクトがプログラミング言語で表現される請求項４７に記載のシステム。
【請求項４９】
前記プログラミング言語がＪａｖａである請求項４８に記載のシステム。
【請求項５０】
前記ソース・オブジェクトが推論エンジン規則言語で表現される請求項４７に記載のシステム。
【請求項５１】
前記推論エンジン規則言語がＩＬＯＧ規則言語である請求項５０に記載のシステム。
【請求項５２】
前記ソース・オブジェクトが複数のシステム論理オブジェクトを含む請求項４７に記載の方法。
【請求項５３】
再生成エンジンと、
ビルダ呼び出しの生成モデルと、
入力のプロファイルと、
前記再生成エンジンが前記生成モデルを使用して前記複数のビルダを制御し、前記プロファイルからの入力を使用してシステム論理オブジェクトを動的に生成するための複数のビルダと
を含むシステム論理オブジェクトを生成するシステム。
【請求項５４】
前記複数のビルダが、
複数の規則ビルダと、
複数のアクション・ビルダと、
複数の接合ビルダと、
複数の条件ビルダと、
複数のチェーン規則ビルダと
を含む請求項５３に記載のシステム。
【請求項５５】
前記システム論理オブジェクトが、
ゼロ個または複数の規則と、
ゼロ個または複数のアクションと、
ゼロ個または複数の接合と、
ゼロ個または複数のフェーズと、
ゼロ個または複数の構造と
をさらに含む請求項５４に記載のシステム。
【請求項５６】
前記複数の規則ビルダが、複数の前記規則を作成する請求項５５に記載のシステム。
【請求項５７】
前記規則が、
複数の条件と、
前記条件が真であると評価された場合に実行するための、「ｔｈｅｎ」節に入れられた第１のゼロ個または複数のアクションの組と、
前記条件が偽であると評価された場合に実行するための、「ｅｌｓｅ」節に入れられた第２のゼロ個または複数のアクションの組と
を含む基本規則をさらに含む請求項５６に記載のシステム。
【請求項５８】
前記複数の条件が複数の前提条件をさらに含む請求項５７に記載のシステム。
【請求項５９】
前記基本規則がリセットの前に一度作動するように構成され得る請求項５７に記載のシステム。
【請求項６０】
前記基本規則が、
「ｆｒｏｍ」フェーズ条件チェックと、
前記「ｔｈｅｎ」節中の第１の「ｔｏ」フェーズと、
前記「ｅｌｓｅ」節中の第２の「ｔｏ」フェーズと
をさらに含む請求項５７に記載のシステム。
【請求項６１】
前記基本規則にチェーン規則が接続される請求項５７に記載のシステム。
【請求項６２】
前記チェーン規則が前記基本規則の前記「ｔｈｅｎ」節に接続される請求項５７に記載のシステム。
【請求項６３】
前記チェーン規則が前記基本規則の前記「ｅｌｓｅ」節に接続される請求項５７に記載のシステム。
【請求項６４】
複数のチェーン規則が前記基本規則に接続されて論理規則のチェーンが形成される請求項５７に記載のシステム。
【請求項６５】
前記複数のチェーン規則が自動参照適応を使用して接続される請求項６４に記載のシステム。
【請求項６６】
複数のチェーン規則が前記基本規則に接続されて論理規則のツリーが形成される請求項５７に記載のシステム。
【請求項６７】
前記複数のチェーン規則が自動参照適応を使用して接続される請求項６６に記載のシステム。
【請求項６８】
前記複数の条件が、前記条件を論理的に接続する複数の接合をさらに含む請求項５７に記載のシステム。
【請求項６９】
前記複数の条件が、
変数状態条件と、
アクション状態条件と、
接合状態条件と、
サービス状態条件と、
規則状態条件と
をさらに含む請求項５５に記載のシステム。
【請求項７０】
前記複数のアクションが、
サービス呼び出しアクションと、
アクション呼び出しアクションと、
メソッド呼び出しアクションと、
変数設定アクションと、
状態設定アクションと、
オブジェクト戻しアクションと、
ページ設定アクションと
をさらに含む請求項５５に記載のシステム。
【請求項７１】
前記アクション・ビルダが前記規則に前記アクションを構築する請求項５５に記載のシステム。
【請求項７２】
ゼロ個または複数の規則セット・ビルダと、
ゼロ個または複数のフェーズ・ビルダと、
ゼロ個または複数のリンクされた規則セット・ビルダと
をさらに含む請求項５５に記載のシステム。
【請求項７３】
前記ビルダが、入力の値を再生成時にリゾルブするための間接参照を入力として受け取り得る請求項５３に記載のシステム。
【請求項７４】
前記ビルダ呼び出しが、多重定義を実現するための同じ名前を持つインスタンスを持ち得る請求項５３に記載のシステム。
【請求項７５】
システム論理オブジェクトを生成する方法であって、
複数のビルダ呼び出しを用いて生成モデルを処理するステップと、
複数のビルダ入力からなるプロファイルを使用するステップと、
前記ビルダ呼び出しによって特定された複数のビルダを前記ビルダ入力と共に使用して前記システム論理オブジェクトを作成するステップと
を含む方法。
【請求項７６】
前記複数のビルダが、
複数の規則ビルダと、
複数のアクション・ビルダと、
複数の接合ビルダと、
複数の条件ビルダと、
複数のチェーン規則ビルダと
を含む請求項７５に記載の方法。
【請求項７７】
前記システム論理オブジェクトが、
ゼロ個または複数の規則と、
ゼロ個または複数のアクションと、
ゼロ個または複数の接合と、
ゼロ個または複数のフェーズと、
ゼロ個または複数の構造と
をさらに含む請求項７６に記載の方法。
【請求項７８】
前記複数の規則ビルダが複数の前記規則を作成する請求項７７に記載の方法。
【請求項７９】
複数のビルダを使用する前記ステップが、
基本規則を構築するステップ
をさらに含む請求項７８に記載の方法。
【請求項８０】
基本規則を構築する前記ステップが、
複数の条件を構築するステップと、
前記条件が真であると評価された場合に実行するための、「ｔｈｅｎ」節に入れられた第１のゼロ個または複数のアクションの組を構築するステップと、
前記条件が偽であると評価された場合に実行するための、「ｅｌｓｅ」節に入れられた第２のゼロ個または複数のアクションの組を構築するステップと
をさらに含む請求項７９に記載の方法。
【請求項８１】
前記複数の条件が複数の前提条件をさらに含む請求項８０に記載の方法。
【請求項８２】
前記基本規則がリセットの前に一度作動するように構成され得る請求項８０に記載の方法。
【請求項８３】
前記基本規則に「ｆｒｏｍ」フェーズ条件チェックを構築するステップと、
前記「ｔｈｅｎ」節に第１の「ｔｏ」フェーズを構築するステップと、
前記「ｅｌｓｅ」節に第２の「ｔｏ」フェーズを構築するステップと
をさらに含む請求項８０に記載の方法。
【請求項８４】
前記基本規則にチェーン規則を接続するステップをさらに含む請求項８０に記載の方法。
【請求項８５】
前記チェーン規則が前記基本規則の前記「ｔｈｅｎ」節に接続される請求項８４に記載の方法。
【請求項８６】
前記チェーン規則が前記基本規則の前記「ｅｌｓｅ」節に接続される請求項８４に記載の方法。
【請求項８７】
前記基本規則に複数のチェーン規則を接続して論理規則のチェーンを形成するステップをさらに含む請求項８０に記載の方法。
【請求項８８】
前記接続するステップが、自動参照適応を使用して前記チェーン規則を接続する請求項８６に記載の方法。
【請求項８９】
前記基本規則に複数のチェーン規則を接続して論理規則のツリーを形成するステップ
をさらに含む請求項８０に記載の方法。
【請求項９０】
前記接続するステップが、自動参照適応を使用して前記チェーン規則を接続する請求項８９に記載の方法。
【請求項９１】
前記複数の条件が、前記条件を論理的に接続する複数の接合をさらに含む請求項８０に記載の方法。
【請求項９２】
前記複数の条件が、
変数状態条件と、
アクション状態条件と、
接合状態条件と、
サービス状態条件と、
規則状態条件と
をさらに含む請求項７７に記載の方法。
【請求項９３】
前記複数のアクションが、
サービス呼び出しアクションと、
アクション呼び出しアクションと、
メソッド呼び出しアクションと、
変数設定アクションと、
状態設定アクションと、
オブジェクト戻しアクションと、
ページ設定アクションと
をさらに含む請求項７７に記載の方法。
【請求項９４】
前記アクション・ビルダが、前記規則に前記アクションを構築する請求項７７に記載の方法。
【請求項９５】
ゼロ個または複数の規則セット・ビルダと、
ゼロ個または複数のフェーズ・ビルダと、
ゼロ個または複数のリンクされた規則セット・ビルダと
をさらに含む請求項７７に記載の方法。
【請求項９６】
前記ビルダが、入力の値を再生成時にリゾルブするための間接参照を入力として受け取り得る請求項７５に記載の方法。
【請求項９７】
前記ビルダ呼び出しが、多重定義を実現するための同じ名前を持つインスタンスを持ち得る請求項７５に記載の方法。
【発明の詳細な説明】
【関連出願】
【０００１】
本願は、２００１年１１月２８日に出願された、「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  ｆｏｒ  Ｃｒｅａｔｉｎｇ  Ｓｙｓｔｅｍ  Ｌｏｇｉｃ」という名称の米国仮出願第６０／３３４，２０７号の優先権の特典を主張するものである。
【技術分野】
【０００２】
本発明は、一般に、コンピュータ・ソフトウェアに関し、詳細には、計算処理システムによって使用されるオブジェクトを動的に作成するソフトウェア・システムに関する。より詳細には、ただし最良の実施形態に従って以下で述べる具体的実施形態に限定されるものではないが、本発明は、計算処理システムで使用される論理の実施形態を表すソース・オブジェクトを動的に作成する方法とシステムに関する。それらの論理の実施形態をシステム論理オブジェクトと呼ぶ。
【背景技術】
【０００３】
これまでは、計算処理システムでプログラムの構造や機能、挙動を定義するソース・オブジェクトを作成する際にプログラマを支援するツールを人が提供してきた。ソース・オブジェクトの例には、Ｊａｖａ（登録商標）やＣなどのコンパイル言語で書かれたファイルとＸＭＬやＪａｖａｓｃｒｉｐｔなどのインタープリート言語で書かれたファイルが含まれる。
【０００４】
ソース・オブジェクトを作成、変更するためのツールは、プログラマにその仕事をより効率よく行わせることに重点を置いてきた。その中には、多くの意味を持ち、したがって、書く必要のあるソース・コードの量を低減させるキーワードを有する高水準ソース・コード言語を提供することに重点を置く手法もあり、プログラマが大量の低水準ソース・コードを書くタスクを支援する「ウィザード」や「マクロ」の形でツールを提供することに重点を置く手法もある。
【０００５】
オーサーがオブジェクトを作成する際に、オブジェクト・エンティティの直接操作を介して支援するツールは、「明示的」オーサリング・ツールと呼ばれている。そうしたツールは、テキスト、図形操作、その他の対話手段の形でソース・オブジェクトへの直接操作アクセスを提供する。これらのツールは、オーサーがソース・オブジェクトの諸要素を直接作成、削除、変更することを可能にする。ワード・プロセッサは文書テキストを作成するための明示的ツールの一例であり、よく知られている「ｖｉ」エディタや「ｅｍａｃｓ」エディタは、コンピュータ・プログラム用のソース・オブジェクトを作成するための明示的ツールの例である。
【０００６】
ユーザが、「明示的」オーサリング・ツールを使用してオブジェクトを変更しようとするとき、そのユーザは、適当な編集環境でそのオブジェクトを開き、そのオブジェクトのエンティティを直接操作することによって１つまたは複数の変更を加え、更新されたオブジェクトを保存する。そうしたシステムはユーザに、オブジェクトの内容への直接アクセスを提供すると共に、それらのオブジェクトで直接エンティティを追加、削除、変更するためのツールを提供する。そうした手法の例には、１）Ｃｏｂｏｌ、Ｊａｖａ、Ｃ＋＋、Ｃ＃などのコンパイル言語でプログラムを作成するためのテキストベースとグラフィカルベースのプログラミング・ツール、２）ＩＢＭのＷｅｂサービス・フロー言語（ＷＳＦＬ）や、マイクロソフトのＸＬＡＮＧ言語など言語で宣言文書を作成するテキストベースとグラフィカルベースの手法、および３）「前向きおよび逆向き連鎖」Ｒｅｔｅアルゴリズムを用いた推論エンジンを含む規則エンジンで使用される宣言規則の組を作成するテキストベースとグラフィカルベースの手法が含まれる。
【０００７】
従来、コンピュータ・プログラマは、明示的編集ツールを利用してコンピュータ・プログラムを表すソース・オブジェクトを作成し、維持してきた。プログラミング言語は、長年にわたって、Ｃなどの低水準コンパイル言語からＨＴＭＬやＸＭＬなどの高水準インタープリート言語に進化してきたが、明示的ツールの利用は続いている。さらに、強力なグラフィカル「ドラッグ・アンド・ドロップ」ツールや、手の込んだウィザードやマクロが登場しても、それらのツールの明示的性質は変わっていない。ユーザは、それが図形操作によってであれ、タイプ入力操作によってであれ、あるいはウィザードやマクロの支援を用いてであれ、結局は、直接ソース・オブジェクトでエンティティを操作することになる。結局、ソース・オブジェクトは、ユーザによって明示的に作成され、変更される。
【０００８】
エンティティの直接操作を用いる「明示的」オーサリング・ツールを使用してソース・オブジェクトを作成する手法には多数の制限事項がある。これらの制限事項のいくつかを以下に挙げる。
【０００９】
１）オブジェクトを作成するプロセスは、コンピュータベースの再実行可能形式の形では取り込まれず、保存されない。それらのツールは、１組のユーザ主導の明示的編集オペレーションを（オブジェクト・エンティティの直接作成、削除、変更によって）実施し、そのオブジェクトの最終表現だけを取り込み、記憶する。したがって、オーサーは、そのオブジェクトの別の変形形態を生成するためには、その作成プロセスや変更プロセスの様々なステップを手動で反復する必要がある。例えば、明示的編集ツールを使用して、ユーザがあるオブジェクトにエンティティＡを付加し、次いでＡの一部を変更してＡ’を生成し、次いでＢを付加した場合には、システムはＡ’Ｂを保存するはずである。ＡからＡ’を経てＡ’Ｂに至る編集プロセスは、決して取り込まれることがない。結果だけが取り込まれるはずである。したがって、ユーザがＡＢの形でそのオブジェクトの変形形態を生成しようとした場合には、そのユーザは、Ａを付加し、次いで、Ｂを付加するステップに直接進むステップを反復する必要がある。
【００１０】
２）オーサーがオブジェクトに変更を加えるときに、エラーを生じる可能性がある。オーサーが編集プロセスを手動で、オブジェクトに直接行っているからである。例えば、ユーザが元のオブジェクトにおいてＡ’にすでに変更されていたエンティティＡを削除し、再作成する場合には、そのユーザが誤りを犯し、Ａの作成に導いた同じ明示的オペレーションを実施しない可能性がある。
【００１１】
３）１組の競合する要件を満たすオブジェクトを作成するためには、オーサーは、オブジェクト・インスタンスの中から大量の複製を伴うことがあるそのオブジェクトの複数のインスタンスを作成する必要がある。例えば、ユーザは、そのオブジェクトの２つの異なる表現を持つためには、２つのオブジェクトＡＢとＡ’Ｂを生成する必要があるはずである。
【００１２】
一部の明示的オーサリング・ツールは、人間とユーザ・インターフェイスとの対話のシーケンスを取り込む機能を提供し、明示的編集環境で他のときにそれらの操作を再実行できるようにすることに留意すべきである。例をあげると、アンドゥやリドゥ機能が含まれ、さらにユーザ対話のシーケンスを別の再実行可能ファイルに取り込む「履歴」と「トレール」ファイルも含まれる。これらの「再実行」機能は、ユーザがその明示的編集ツールを用いてより速く作業するのに役立つが、それらの明示的編集ツールが、依然として、オブジェクトの最終表現だけを取り込み、記憶するという事実を変えるものではない。
【００１３】
ソース・コンパイル・ツール
明示的編集ツールを使用してソース・オブジェクトを作成、変更することによって生じる制限事項のうちのいくつかに対応するために、ソフトウェア界は、単一のソース・オブジェクトをより多用途にし、したがって、それを多種多様なニーズに役立てることのできる多種多様な技術を推進することに専心している。それらの技術は、まず第１に、作成、変更される必要のある別々のソース・オブジェクトの数を低減させる。その意図は、ユーザに、ソース・オブジェクト自体の複数の異なる変形形態を作成させるのではなく、単一のソース・オブジェクトを多くの異なる表現に後処理する手段を提供することである。この手法は、ユーザがやはり明示的編集ツールを使用してソース・オブジェクトの各インスタンスを作成するが、次いで、ソフトウェア・システムを用いてオブジェクトを様々な表現に後処理するという前提に基づくものであり、明示的編集ツールを使用してソース・オブジェクトの変形形態を手動で作成することを不要にする。
【００１４】
ソース・オブジェクトのこの種の後処理を提供するのに使用されている１つの技術がコンパイラである。コンパイラは、ソフトウェア生成プログラムの１つの形であり、その目的は、ソース・オブジェクトを１つの表現から別の表現に変換し、最終的には、コンピュータが実行できる表現に変換することである。
【００１５】
最初に広く用いられた変換エンジンは、人間が作成したソース・オブジェクトを、高水準の人間可読言語から、コンピュータで処理することのできる機械可読言語で書かれたより低水準の実行可能オブジェクトに変換するコンパイラであった。コンパイラの背後にある意図は、変換オペレーションが、事前に構築された完全なソース・オブジェクトＡを入力として取り込み、それをＡ’と呼ばれる、それ自体の別の表現に変換するというものであった。
【００１６】
やがて、コンパイラを、より大きな構造的柔軟性を持ってより包括的なタスクを実施できるようにする機能がコンパイラに付加された。その目標は、プログラマが、プログラムのソース・オブジェクトを、できるだけ少ない命令を用いて非常に高水準な形で書けるようにすると共に、コンパイラにそのプログラムを、コンピュータによって必要とされる冗長で具体的なインスタンスに変形させることであった。そうした手法は、そのプログラムを表すソース・オブジェクトを何らかの言語表現でプログラマが書き、その完全なソース・オブジェクトを変換プロセスへの初期入力として使用することが必要である。それらの手法の目標は、プログラミング・プロセス全体をより効率よくすると共に、可能な限り少ないワード数で表現された高水準の概念を、コンピュータ上で機能する具体的なものマッピングするタスクを自動化することであった。
【００１７】
コンパイラをより一層多用途にするために、入力ソース・オブジェクトのもとで動作するときにそのコンパイラの挙動を変更する構成入力を受け入れることができるコンパイラが実現された。それらは、パラメータ化コンパイラと呼ばれる。
【００１８】
プログラマとの対話の後のソース・オブジェクトを後処理する手法の例はもとより、プログラマとの対話の前にソース・オブジェクトを前処理する手法の例も多数存在する。第４世代言語（４ＧＬ）とコード生成プログラムは、ソース・オブジェクト中に詳細実装の作成を完了するために、ソース・オブジェクトを前処理し、プログラマが次いでプログラム・コードを手動で付加するスタブ、またはテンプレートを生成する手法であった。プリプロセッサは、プログラマが、自分の明示的編集ツールにおいて手動で編集することのできる１つまたは複数のソース・オブジェクトの明示的表現を生成するマクロまたはウィザードの１つの形である。コンパイラ、コード・チェッカ、オプティマイザは、手動で作成されたソース・オブジェクトを取り込み、それらを様々な表現に変換するポストプロセッサの例である。
【００１９】
プログラマがソース・オブジェクトを手動で作成する際に役立つ手法のもっと最近の例には、メタプログラミングと、アスペクト指向プログラミング（ＡＯＰ）と、インテンショナル・プログラミング（ＩＰ）が含まれる。しかし、これらの手法のどれも、それがいかに高水準であり、あるいはその細分性がいかに小さいとしても、ユーザがソース・オブジェクトの明示的表現を作成する必要をなくすものではない。反対に、これらの手法すべてが、プログラマがソース・オブジェクトの明示的表現を作成することを、後処理オペレーションを実施するための基礎として利用している。これらのプログラミング技法の詳細な説明は、Ｋｒｚｙｓｚｔｏｆ  ＣｚａｒｎｅｃｋｉおよびＵｌｒｉｃｈ  Ｅｉｓｅｎｅｃｋｅｒ著、「Ｇｅｎｅｒａｔｉｖｅ  Ｐｒｏｇｒａｍｍｉｎｇ」（Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ刊、２０００年）で見ることができる。
【００２０】
メタプログラミング
メタプログラミングは、既存のコンパイラ技術の拡張である。ユーザは、ソース・コードを明示的に書き、次いで、そのソース・コードに「メタコード」を付加する。コンパイラは、そのメタコードを命令として使用して、ソース・コード上で変換を実施する。このメタコードは、コンパイラの挙動をパラメータ化する手段として働く。メタプログラミングは、事後オペレーションのための構成パラメータをソース・オブジェクト自体に埋め込むことが関与するソース・オブジェクト後処理の１つの形である。
【００２１】
アスペクト指向プログラミング（ＡＯＰ）
ＡＯＰを用いる場合、ユーザは、やはり、プログラムを表すソース・オブジェクトを明示的に書き、次いで、ポストプロセッサによってそのソース・オブジェクトを変更するのに使用される別のオブジェクトを明示的に作成する。第２のプログラムは、ポストプロセッサがソース・プログラムに「アスペクト」をどのように適用すべきかを、コードをソース・プログラムに「編み込む」ことによって定義する。アスペクト指向プログラミングは、一部は、ソフトウェア・コンポーネントをアセンブルし、次いで、個々の事前アセンブルされたオブジェクト中では容易に表すことのできない諸機能を実装するために、それらの中にコードを編み込む必要から生じたものである。例えば、１組のコンポーネントを「スレッド・セーフ」にすることは、まず、ソフトウェア・ライブラリ中の様々なメソッドに呼び出しを行う１つまたは複数のオブジェクトをプログラマに明示的に作成させることによって実施された。次いで、プログラマは、コードの断片を全体のセットに編み込むことによって、ソース・オブジェクトをそのソース・オブジェクトの異なる、スレッド・セーフな表現に変換するポストプロセッサを実行することになる。この手法は、やはり、ユーザに、ソース・オブジェクトを明示的に作成させ、次いで、そのソース・オブジェクト上でポストプロセッサを実行させて、そのソース・オブジェクトの、異なるがやはり明示的な変形形態を生成するものである。
【００２２】
インテンショナル・プログラミング（ＩＰ）
ＩＰは、マイクロソフトで開発されたプログラミング環境であり、プログラマが明示的エディタを使用して情報の喪失を低減させる形式でソース・コードを作成できるようにするものである。ＩＰは、プログラマが特別の統合開発環境（ＩＤＥ）に拡張ライブラリをロードできるようにする。これらのライブラリ拡張は、ドメイン特有の言語拡張を、所与のアプリケーションの必要に応じて付加する。プログラマは、やはり、明示的編集ツールを使用して、ソース・ツリーの形でソース・オブジェクトを明示的に作成する。それらのソース・オブジェクトは、次いで、ソース・オブジェクトを少数の縮小コード、すなわちＲコードのセットに変形する多段変換縮小エンジンを使用して、より低水準の形式に後処理される。この縮小プロセスは、そのソース・ツリーをキーとして使用し、ソース・ツリーは、その縮小プロセスのシードまたは開始点として機能する。
【００２３】
ＩＰはＩＤＥに、ソース・ツリー・オブジェクトの縮小コードへの後処理に影響を与える拡張だけでなく、ソース・ツリーの視覚表現に影響を与える拡張やデバッギングなど、ソース・ツリー上で実施されるタスクに影響を与えるその他の拡張も提供する。
【発明の開示】
【発明が解決しようとする課題】
【００２４】
各手法の要約
本項で述べた手法はすべて、何らかの形のソース・オブジェクトの前処理、または後処理を提供することによって、ソース・オブジェクトを作成する際のユーザの生産性を向上させようとするものである。これらの手法すべての背後にある前提は、１）ユーザが、依然として、明示的編集手段によってソース・オブジェクトの何らかの表現を作成する必要があること、および２）ソース・オブジェクトのすべての処理が、ユーザによって実施される明示的編集プロセスの前または後に行われることである。
【課題をリゾルブするための手段】
【００２５】
本発明は、ＤｏｍａｉｎＯｂｊｅｃｔと呼ばれるソフトウェア・オブジェクトを動的に作成する方法と装置を提供するものである。一実施態様では、これらのソフトウェア・オブジェクトとは、コンピュータが使用可能な形の任意のデータを表す。別の実施態様では、これらのソフトウェア・オブジェクトは、（それだけを表すとは限らないが）計算処理システムで使用される論理を表すソース・オブジェクトである。ソース・オブジェクトは、特に、論理の実施態様を含み、それらの実施態様をシステム論理オブジェクトと呼ぶ。このシステム論理オブジェクト中の論理は、コンピュータのメモリ構造の仕様およびコンピュータのプロセッサの機能と挙動を含む。本発明の別の実施態様は、システム論理オブジェクトを動的に生成する１組のソフトウェア・オブジェクト・ビルダである。
【００２６】
本発明は、オブジェクトの表現を明示的に取り込むことしかできない従来技術の手法とは対照的に、ソフトウェア・オブジェクトを作成するためのプロセス定義を取り込む手法を提供する。従来技術の明示的編集手法は、ユーザが明示的編集手段によってオブジェクトを作成するためのツールを提供する。そうした手段を用いた場合、ユーザは、ソフトウェア・オブジェクト中のエンティティを直接操作し、その結果生じたオブジェクトを保存することによって、ソース・オブジェクトを作成、変更することができる。本発明は、ビルダと呼ばれる１組のソフトウェア生成プログラムを実行することによってオブジェクトを作成するためのプロセス定義を含む、生成モデルと呼ばれるオブジェクトをそれによってユーザが作成する、異なる手法を提供する。さらに、このプロセス定義は、ユーザがオブジェクト作成のプロセスを、それを再実行して多種多様なソフトウェア・オブジェクトを生成することができるような形で取り込むことを可能にする。
【００２７】
本発明によれば、ユーザが生成モデルを作成、変更する際に、本発明のシステムは、その生成モデルを同時に処理して、ソフトウェア・オブジェクトの１つまたは複数のインスタンスを自動的かつ動的に生成する。本発明は、ユーザにオブジェクト中のエンティティを明示的に作成、変更、削除させ、その結果だけを保存させるのではなく、ソフトウェア・オブジェクトを作成するための１つまたは複数のプロセス定義を取り込む手段、ならびにそれらのプロセス定義を変更、再パラメータ化し、それらを再実行して前記ソフトウェア・オブジェクトの新しい変形形態を生成する手段を提供する。本発明では、ユーザは、生成されたソフトウェア・オブジェクトを直接的にも明示的にも編集しない。
【００２８】
本発明の方法と装置は、再生成機能と呼ばれる機能を実施する。この再生成機能は、１つまたは複数の生成モデルで宣言されたプロセス定義を実行し、ソフトウェア・オブジェクトの、関連するが異なるインスタンスのファミリを生成する。これらのオブジェクトはシステム論理オブジェクトと呼ばれる計算処理システムによって実施される論理オペレーションを表すエンティティを含む。この再生成機能は、再生成エンジンと呼ばれる本発明のシステムによって実施される。
【００２９】
再生成機能は、ビルダと呼ばれるソフトウェア・オブジェクトによって実施される下位構築タスクの順序付けされたシーケンスからなる。生成モデルは、ビルダへの呼び出しのシーケンスを規定し、このシーケンスをＢｕｉｌｄｅｒＣａｌｌＬｉｓｔと呼ぶ。ＢｕｉｌｄｅｒＣａｌｌＬｉｓｔ中の各ＢｕｉｌｄｅｒＣａｌｌは、ビルダの名前、および再生成機能での処理中にそのビルダに供給される１組のパラメータ値を定義する。各ビルダは、１組の入力パラメータ、およびゼロ個または複数の構築済みオブジェクトを含むコンテナとして働くソフトウェア・オブジェクトへの参照を受け入れる。構築済みオブジェクトには、コンピュータ・システムで任意の種類のデータとプログラム機能を表すのに使用することのできる汎用オブジェクトである、ＤｏｍａｉｎＯｂｊｅｃｔが含まれる。一実施態様では、計算処理システムによって後で実行される論理オペレーションの定義を提供するために、システム論理オブジェクトと呼ばれるＤｏｍａｉｎＯｂｊｅｃｔの一種が生成される。
【００３０】
再生成機能に誘導されて、各ビルダは、コンテナの内容に関してそれ自体の構築タスクを実施する。構築タスクには、コンテナ中のオブジェクトの付加、変更、削除が含まれる。ビルダは、その構築タスクを完了すると、そのコンテナを更新された内容と共に戻す。再生成機能の全体的挙動は、生成モデルのＢｕｉｌｄｅｒＣａｌｌＬｉｓｔによって定義されたビルダのシーケンスおよびパラメータ化によって特定される。しかし、再生成機能は、シーケンス中で特定されたビルダのうち１つまたは複数の実行を無効にし、ビルダに供給される入力パラメータを変更することによって、この挙動を実質的に変更することができる。
【００３１】
本発明では、ユーザが明示的編集ツールを使用して１つまたは複数のソフトウェア・オブジェクトを作成する従来技術のプロセスが、ユーザが１つまたは複数の生成モデルを作成し、各生成モデルを再生成機能で処理して、ソフトウェア・オブジェクトの１つまたは複数の生成済みインスタンスを生成するプロセスで置き換えられる。生成モデルは、１組のパラメータ化ビルダを実行することによって、ソフトウェア・オブジェクト生成の完全なプロセスを取り込むので、ユーザは、同じ、または異なるパラメータの組を使用して、いつでも、その作成プロセスの自動再実行を簡単に呼び出して、その生成済みソフトウェア・オブジェクトの様々な変形形態を生成することができる。明示的編集手法を用いた場合、ユーザは、ソフトウェア・オブジェクト中のエンティティを直接操作する必要があった。
【００３２】
生成モデル
本発明の実施態様には、生成モデルを特定するためのテキスト言語と、その生成モデルを作成し、そのモデルを利用して再生成機能を実施するための、デザイナという名前のソフトウェア・アプリケーションと、生成モデルに関連付けられた入力パラメータの組を作成するためのカストマイザという名前のアプリケーションとが含まれる。
【００３３】
本発明の一実施態様では、再生成機能は、入力として、１）１組のビルダ、２）それらの実行順序、３）ビルダへの入力として働く１組のデフォルト入力パラメータを定義する１つまたは複数の生成モデルを受け入れることによって動作する。また、再生成機能は、入力として、デフォルトのパラメータをオーバーライドする１組のパラメータ入力と、特定されたビルダを無効にする命令も受け入れる。一実施態様では、１組のビルダ入力をオーバーライドするために使用される１組のパラメータをプロファイルと呼ぶ。これらの入力を使用して、再生成機能は、生成モデル中の各命令によって呼び出された各ビルダの実行を調整する。再生成機能は、それが受け取る入力パラメータの一部を個々のビルダに渡し、あるビルダから次のビルダへのコンテナの受け渡しを調整する。
【００３４】
本発明の一実施態様では、再生成機能は、実施すべき構築プロセスの定義を使用して、１つまたは複数のシステム論理オブジェクトを新規に作成するタスクを実施する。生成モデルはこの構築プロセスを定義し、入力パラメータの組はこの構築プロセスを構成するように働く。入力パラメータを変更し、単一の生成モデルを利用することによって、再生成機能は、その構築プロセスの様々な構成をインスタンス化することができる。構築プロセスの潜在的に固有な各構成は、異なる生成済み出力オブジェクトの組を生成することができる。
【００３５】
生成モデルを特定するための言語は、ビルダへの呼び出しを表す命令文で使用される１組のキーワードを含む。生成モデルは、ＢｕｉｌｄｅｒＣａｌｌと呼ばれる順序付けされたそれらの命令文の組を含む。ＢｕｉｌｄｅｒＣａｌｌは、呼び出される１組のビルダを指定し、それらのビルダの実行順序を指定し、さらに再生成機能に供給された新規パラメータが無い場合は、ビルダによって使用されるデフォルトの入力パラメータの組を特定する。
【００３６】
デザイナ
生成モデルを構築するためのオーサリング・アプリケーションは、ユーザが、生成モデルを見て、編集することができると同時に、個々の構成状態でその生成モデルを処理する再生成機能によって生成されたオブジェクトを見ることができるようにする。ユーザが、ＢｕｉｌｄｅｒＣａｌｌを付加、削除、変更、有効化、無効化することによってその生成モデルを変更する際に、このアプリケーションは、再生成機能を再実行することによって生成されたオブジェクトを同時に更新する。また、ユーザが、開いた生成モデルでビルダ呼び出しを付加または変更しようとすると、このアプリケーションは、そのビルダに新規の入力パラメータを供給するために、そのビルダに特有のいくつかの使用可能なユーザ・インターフェイス・ダイアログうちの１つを呼び出す。入力パラメータは、現在付加または変更されているビルダ呼び出しの前にその生成モデル中のＢｕｉｌｄｅｒＣａｌｌによってすでに特定された他のビルダによって生成されている、生成されたオブジェクト内のエンティティへの参照を含むこともできる。また、ビルダ呼び出しは、その値が、そのＢｕｉｌｄｅｒＣａｌｌシーケンス中の後の方に特定されたビルダによって作成されるエンティティへの参照を含む入力パラメータを含むこともできる。
【００３７】
ユーザがＢｕｉｌｄｅｒＣａｌｌへの入力パラメータの変更を完了し、またはＢｕｉｌｄｅｒＣａｌｌの無効化状態を変更し、あるいはＢｕｉｌｄｅｒＣａｌｌＬｉｓｔ中のＢｕｉｌｄｅｒＣａｌｌのシーケンスを並べ替えると、再生成機能はそのＢｕｉｌｄｅｒＣａｌｌのシーケンスを再実行して１組の更新された出力オブジェクトを生成する。
【００３８】
カストマイザ
本発明は、１つまたは複数の生成モデルによって定義された構築プロセスをカストム構築するために、再生成機能によって使用される入力パラメータの組を特定するためのアプリケーションも提供する。それらの入力パラメータの組をプロファイルと呼ぶ。プロファイルは生成モデルから独立して保存され、プロファイルの組を、生成モデルで特定された再生成機能を構成する複合プロファイルを生成するプロセスの一部として組み入れることもできる。
【００３９】
ビルダ
本発明の実施態様には、再生成機能の一部として下位構築タスクを実施するビルダの拡張可能ライブラリも含まれる。ビルダは、生成コンテナと呼ばれる構築コンテナの内容に関する固有の諸機能を実施する１組のソフトウェア・オブジェクトである。ビルダは、再生成機能がビルダのシーケンスの実行を調整できるようにする共通インターフェイスを実装する。各ビルダは、入力として、１）１組のパラメータと、２）再生成機能によって新規に生成される、ＤｏｍａｉｎＯｂｊｅｃｔと呼ばれるゼロ個または複数のソフトウェア・オブジェクトを保持する生成コンテナへの参照を取り込む。本発明の一実施態様では、これらのＤｏｍａｉｎＯｂｊｅｃｔは、システム論理オブジェクトと呼ばれる、計算処理システムによって実施される論理オペレーションを表すエンティティを含む。各ビルダは、生成コンテナの内容に関して、コンテナ中に新規オブジェクトを作成すること、ならびにコンテナ中の既存のオブジェクトを削除、変更することを含む構築タスクを実施し、生成モデル中のＢｕｉｌｄｅｒＣａｌｌによって特定されたすべてのビルダの実行を調整するプロセス全体を管理する再生成機能に制御を返す。
【００４０】
再生成機能の一部として実行されるビルダは、製造フロアに設置されたロボットにたとえられ、生成されたＤｏｍａｉｎＯｂｊｅｃｔは、組立てラインで１組のロボットによって製造される製品にたとえられる。したがって、本発明は、生成モデルの形で工場の総称定義を構築する方法と装置である。さらに、本発明の再生成機能は、工場の定義（すなわち生成モデル）を読み取り、ビルダの形をした複数組のロボットの中からカストム工場インスタンスを動的かつ自動的に組み立て、構成するシステムにたとえられる。
【００４１】
本発明は、ロボット工場のたとえを利用して、プロファイルで特定された入力パラメータの値に基づいて、要求時に、製造フロアを構成するソフトウェア・ロボット（すなわちビルダ）を動的に選択し、組立て、構成することによっても構築される。生成モデルが、その生成モデル中のＢｕｉｌｄｅｒＣａｌｌによって特定された、ビルダからなる工場の総称的なデフォルトの定義を表すのに対し、複合プロファイルの形で再生成機能に供給される入力パラメータは、再生成プロセス全体をカスタマイズするために、ＢｕｉｌｄｅｒＣａｌｌシーケンス中の特定のビルダがシステムによって無効にされ、有効にされ、構成させらる。
【発明を実施するための最良の形態】
【００４２】
本発明のその他の目的、ならびにそれに寄与するその他の特徴およびそれらから生じる利点は、添付の図面に示す本発明の好ましい実施形態の以下の説明を読めば明らかになるであろう。図面全体を通じて、類似の参照番号は類似の構成要素を示す。
【００４３】
本発明は、（それだけを表すとは限らないが）計算処理で使用される論理を表すために、ソフトウェア・オブジェクトを動的に作成する方法と装置を提供する。本発明の一実施形態は、１つまたは複数の生成モデルを読み取り、処理し、その情報を使用してビルダと呼ばれる１組のソフトウェア・コンポーネントをアセンブルし、構成して、１つまたは複数のソフトウェア・オブジェクトを構築するように実行される生成プロセッサにするためのシステムである。また、このシステムは、プロファイルと呼ばれるパラメータベースの入力データやその他の外部から供給されるデータを使用して、システムがビルダを選択し、アセンブルし、構成する方法を変更し、その結果、すべてが単一の生成モデルに由来する、複数の固有の生成プロセッサが作成される。
【００４４】
本発明の他の実施形態には、生成モデルを作成するためのアプリケーションや、プロファイルを作成するためのアプリケーション、生成済みのソフトウェア・オブジェクトを処理するためのシステムが含まれる。また、本発明の実施形態には、本発明により生成されるすべてのオブジェクトを管理すると共に、そのシステムを、Ｊ２ＥＥアプリケーション・サーバなどより大規模な計算処理システムの一部として実行するためのアプリケーションとシステムが含まれる。
【００４５】
１９９９年６月９日に出願された、「Ｍｅｔｈｏｄ  ａｎｄ  Ａｐｐａｒａｔｕｓ  Ｆｏｒ  Ｃｒｅａｔｉｎｇ  Ｎｅｔｗｏｒｋ  Ｓｅｒｖｉｃｅｓ」という名称の同時係属の米国特許出願第０９／３２９，６７７号は、以下の方法と装置に関する背景技術を提供しており、その全体が参照によって本明細書に組み込まれることに留意されたい。
【００４６】
本発明には、１）生成モデルを作成、編集、実行すると共に、ＤｏｍａｉｎＯｂｊｅｃｔと呼ばれるソフトウェア・オブジェクトを生成するのに使用されるシステムと、２）計算処理システムの論理挙動を符号化することのできる実行可能なシステム論理オブジェクトを作成する１組のビルダとをカバーする２つの部分がある。以下の説明の第１の主要部分では、再生成プロセスと生成モデルの機能を開示する。これに続いて、生成モデルを作成するためのアプリケーションであるデザイナ・アプリケーションの説明、および再生成プロセス用のパラメータ入力を含むプロファイルを作成するためのアプリケーションであるカストマイザ・アプリケーションの説明を行う。以下の説明の第２の主要部分では、システム論理オブジェクトが再生成機能によってどのように生成されるかを示すと共に、多種多様な計算処理環境で実行され得る主要論理コンポーネントを表すために、様々な種類のビルダを開示する。
【００４７】
Ｉ．生成プロセッサを自動的にアセンブル、構成、実行するための再生成システム（再生成）
図１に、本発明のシステム実施形態の概要の構成図を示す。図１に示すシステムのオペレーションを図２の流れ図に示す。斜線のボックスは、本発明のこのシステム実施形態でのソフトウェア・コンポーネントを示す。点を打ったボックスは、本発明のこのシステム実施形態でのデータ・オブジェクトを示す。白いボックスは、本発明の生成済みソフトウェア・コンポーネントを示す。
【００４８】
図１に、本発明の主要コンポーネントである、生成モデル（２）、プロファイル（９）、再生成エンジン（３）、ビルダ（４）、生成コンテナ（５）（ＧｅｎＣｏｎｔａｉｎｅｒ）の全体的概要を示す。「Ｇｅｎ−」という命名は、「Ｇｅｎｅｒａｔｉｖｅ（生成的）」という語の省略表記である。生成モデル（２）は、ＢｕｉｌｄｅｒＣａｌｌ（１０）の順序付きリストであるＢｕｉｌｄｅｒＣａｌｌＬｉｓｔ（１）をさらに含む。ＢｕｉｌｄｅｒＣａｌｌ（１０）は、生成コンテナ（５）中のＤｏｍａｉｎＯｂｊｅｃｔ（６）を構築する様々なビルダ（４）を選択するために、再生成エンジン（３）によって使用される。次いで、生成コンテナ（５）は、実行エンジン（７）に供給される。その後、生成されたＤｏｍａｉｎＯｂｊｅｃｔ（６）が、動作アプリケーション（８）において任意選択で実行される。
【００４９】
図２をたどっていくと、ステップ１００で再生成エンジン（３）中の再生成機能は、１つまたは複数のプロファイル（９）の形のＢｕｉｌｄｅｒＩｎｐｕｔ（１５）と呼ばれる１組の入力パラメータと共に、１つまたは複数の生成モデル（２）を処理する。次いで、ステップ１０１で、再生成機能は、その生成モデル（２）をソフトウェア・オブジェクト・モデルにインスタンス化する。次いで、再生成機能は、ステップ１０２で、このモデル内のＢｕｉｌｄｅｒＣａｌｌＬｉｓｔ（１）を調べて、ＢｕｉｌｄｅｒＣａｌｌ（１０）と呼ばれる１組のデータ・オブジェクトを見つける。ＢｕｉｌｄｅｒＣａｌｌＬｉｓｔは、１組のビルダ（４）、それらの実行順序、各ビルダごとのデフォルトの無効状態または有効状態、および各ビルダごとの１組のデフォルト・パラメータ値を規定する。ＢｕｉｌｄｅｒＣａｌｌＬｉｓｔ（１）を読み取ると、ステップ１０３で、再生成機能は、各ビルダごとに対応する１組のソフトウェア・オブジェクトを探し出してインスタンス化し、ステップ１０４で、それらを再生成エンジン（３）のセッションにロードする。
【００５０】
ビルダがロードされると、ステップ１０５で再生成機能は、それらのビルダの無効状態または有効状態を構成する。ビルダが無効状態である場合、それは実行されない。ステップ１０６で、再生成機能は、プロファイル（９）で特定された入力パラメータ（ＢｕｉｌｄｅｒＩｎｐｕｔ（１５））の組を、生成モデル（２）のＢｕｉｌｄｅｒＣａｌｌＬｉｓｔ（１）に位置するデフォルト・パラメータの組と一緒に使用して、ビルダ（４）を構成する。次に、再生成機能は、ステップ１０７で、生成コンテナ（５）（またはＧｅｎＣｏｎｔａｉｎｅｒ）を作成する。生成コンテナ（５）は、インスタンス化されたビルダ（４）によって構築、変更されるソフトウェア・オブジェクト・エンティティを保持するための設備として働く。再生成機能は、ステップ１０８で、ＢｕｉｌｄｅｒＣａｌｌＬｉｓｔでの順序に従ってビルダを実行する。場合によっては、ビルダは、生成コンテナ（５）の中のオブジェクトを削除することもできる。これまでのところ、再生成機能によって実施される、生成モデル（２）に特定された命令に従って１組のビルダ（４）をインスタンス化するこのプロセスは、ロボット（すなわちビルダ）で物理的工場を組み立てる１組の高度に自動化された機械にたとえられる。このたとえにさらに従うと、再生成エンジン（３）は、それらのカスタマイズされた工場を動的に組み立てるソフトウェアであり、その目的は、次いで、生成コンテナ（５）において（ＤｏｍａｉｎＯｂｊｅｃｔ（６）を含む）ソフトウェア・オブジェクトを生成することである。
【００５１】
再生成プロセス
図３Ａおよび３Ｂに、図１に示した本発明の実施形態の再生成オペレーションの部分を詳細に示す。図３Ａは、図３Ｂの流れ図に見られるステップ番号を付した矢印を含む構成図である。矢印は、このプロセスの各ステップに関与するコンポーネントを示すのに使用される。簡単にいうと、再生成オペレーションは、新規に１組のソフトウェア・オブジェクト（ＤｏｍａｉｎＯｂｊｅｃｔ）を作成することを含み、それによって、ＧｅｎＣｏｎｔａｉｎｅｒという名前のそれらのＤｏｍａｉｎＯｂｊｅｃｔ用のコンテナが、独立のソフトウェア生成プログラム（ビルダ）の順序に従って受け渡され、各ビルダがそのＧｅｎＣｏｎｔａｉｎｅｒとその内容を参照し、ＧｅｎＣｏｎｔａｉｎｅｒ中のＤｏｍａｉｎＯｂｊｅｃｔに付加、削除、変更を行う。さらに、再生成オペレーションには、パラメータ値を各ビルダに受け渡すことも伴う。それらの値は、そのビルダの生成挙動を構成するのに使用される。このプロセスが「再」生成と呼ばれる理由は、そのＢｕｉｌｄｅｒＣａｌｌＬｉｓｔによって規定されたビルダ・シーケンスの生成が、それらのビルダに供給された様々な入力パラメータの組によって、かつ有効化、無効化される様々なビルダの組み合わせによって、繰り返し実施されるからである。
【００５２】
再生成プロセスは、ステップ１１１で、ＧｅｎｅｒａｔｉｏｎＭａｎａｇｅｒ（１２）が生成モデル（２）とＧｅｎＣｏｎｔａｉｎｅｒ（５）を取得したときに開始する。ＧｅｎｅｒａｔｉｏｎＭａｎａｇｅｒは、図１に示した再生成エンジンの一部として、ＧｅｎＣｏｎｔａｉｎｅｒに関して生成モデルによって定義された複数の再生成オペレーションの実行を調整するソフトウェア・オブジェクトである。各再生成オペレーションは個々のフェーズに関連付けられる。これらのフェーズには、それだけに限らないが、「構築」、「事後構築」、「検証」が含まれる。ＧｅｎｅｒａｔｉｏｎＭａｎａｇｅｒは、複数の再生成オペレーションによって生成された生成済みの内容を保持するＧｅｎＣｏｎｔａｉｎｅｒ（５）を取得する。
【００５３】
ステップ１１２で、ＧｅｎｅｒａｔｉｏｎＭａｎａｇｅｒは、ＧｅｎＣｏｎｔａｉｎｅｒとその内容に関する各フェーズにおいて再生成オペレーションを実施するために、ＧｅｎＣｏｎｔｅｘｔ（１３）オブジェクトを作成し、呼び出す。ＧｅｎＣｏｎｔｅｘｔ（１２）は、生成モデル（２）中のすべてのＢｕｉｌｄｅｒＣａｌｌ（１０）の組に関して、特定されたフェーズでの再生成オペレーションを実施するソフトウェア・オブジェクトである。
【００５４】
本発明の一実施形態では、生成モデルは、まず、「構築」フェーズに対する（生成モデルの）ＢｕｉｌｄｅｒＣａｌｌＬｉｓｔ（１）に関する再生成オペレーションの実行をトリガする。このフェーズが完了すると、ＧｅｎｅｒａｔｉｏｎＭａｎａｇｅｒは、「事後構築」フェーズでの別の再生成オペレーションの実行をトリガする。第１のフェーズで使用され、このフェーズ用のＧｅｎＣｏｎｔｅｘｔにそれ自体を登録することを選択したどのビルダも、その再生成機能を、そのフェーズの再生成の一部として実行させる。最後に、ＧｅｎｅｒａｔｉｏｎＭａｎａｇｅｒは、「検証」フェーズでの再生成オペレーションの実行をトリガする。この複数フェーズ手法は、他のビルダが前の諸フェーズで実行の機会を持った後で、ビルダがＤｏｍａｉｎＯｂｊｅｃｔ（６）に関して、変換、検証、その他のオペレーションを実施することを可能にする。再生成のためのフェーズの数および名前は可変であり、生成モデルによって動的に変更される。
【００５５】
各フェーズの実行が始まる前に、ステップ１１３で、ＧｅｎＣｏｎｔｅｘｔは、生成モデル（２）のＢｕｉｌｄｅｒＣａｌｌＬｉｓｔ（１）で定義された１組のＢｕｉｌｄｅｒＣａｌｌ（１０）を取り出す。ＧｅｎＣｏｎｔｅｘｔは、ステップ１１４で、取り出したＢｕｉｌｄｅｒＣａｌｌに関連付けられた適当なＧｅｎＨａｎｄｌｅｒを取得する。ＧｅｎＣｏｎｔｅｘｔは、取得したＧｅｎＨａｎｄｌｅｒのリストを維持する。ＧｅｎＨａｎｄｌｅｒは、個々のＢｕｉｌｄｅｒＣａｌｌに関する再生成を、そのビルダ専用のやり方で調整し、呼び出すソフトウェア・オブジェクトである。ビルダの組は、共通や専用のインターフェイスとＡＰＩを持つことがある。したがって、ＧｅｎＨａｎｄｌｅｒは、これらのビルダを専用のやり方で呼び出す標準的機構を提供することができる。ＧｅｎＨａｎｄｌｅｒは、１組のビルダ全部が、通常、それ自体の再生成機能でそれぞれ実施する必要があるはずの多数のソフトウェア・オペレーションを実施することもできる。単一のＧｅｎＨａｎｄｌｅｒがビルダの再生成機能への入力を前処理できるようにすることによって、通常は、各ビルダで繰り返し実装される必要があるはずの一箇所のコンピュータ・プログラム・コードに単一のＧｅｎＨａｎｄｌｅｒを隔離することができる。
【００５６】
次に、第１フェーズの再生成が開始する。ステップ１１５は、再生成プロセスが、ＢｕｉｌｄｅｒＣａｌｌＬｉｓｔにリストされた各ＢｕｉｌｄｅｒＣａｌｌごとに実施するループを開始する任意選択のステップである。ステップ１１５で、ＧｅｎＣｏｎｔｅｘｔは、まだそのＧｅｎＨａｎｄｌｅｒのインスタンス化、初期設定が行われていない場合は、そのインスタンス化、初期設定を行い、ＧｅｎＣｏｎｔｅｘｔにＢｕｉｌｄｅｒＣａｌｌとＧｅｎＣｏｎｔｅｘｔへの参照を与える。そのＧｅｎＨａｎｄｌｅｒがすでにインスタンス化され、初期設定されている場合は、ＧｅｎＣｏｎｔｅｘｔは、既存のＧｅｎＨａｎｄｌｅｒを使用し、それにＢｕｉｌｄｅｒＣａｌｌとＧｅｎＣｏｎｔｅｘｔへの参照を渡す。
【００５７】
ステップ１１６で、ＧｅｎＨａｎｄｌｅｒは、まだそのビルダのインスタンス化、初期設定が行われていない場合は、そのビルダをインスタンス化し、初期設定する。それが、図３Ｃに示す３段階のプロセスである。ビルダがすでにインスタンス化され、初期設定されている場合は、既存のビルダが使用される。ステップ１３１で、ＧｅｎＨａｎｄｌｅｒは、ＢｕｉｌｄｅｒＤｅｆ（１６）によって識別されたビルダ（４）を探す。ＢｕｉｌｄｅｒＤｅｆは、ビルダの様々なコンポーネントを定義するソフトウェア・オブジェクトである。ＢｕｉｌｄｅｒＤｅｆは、それだけに限らないが、以下のものを含む。
【００５８】
（１）１組の入力定義オブジェクト（ＢｕｉｌｄｅｒＩｎｐｕｔＤｅｆｉｎｉｔｉｏｎ（１７））、およびそのビルダの調整機能と再生成機能を実施するのに使用されるクラスの名前。ＢｕｉｌｄｅｒＩｎｐｕｔＤｅｆｉｎｉｔｉｏｎは、ビルダに対する単一の入力に関する情報を定義するソフトウェア・オブジェクトである。これには、入力の種類、入力が持ち得る値に対する制約条件、デフォルト値、そのビルダの調整機能の間に値を取得し、設定するのに使用されるエディタ・ウィジェットの名前（ステップ１１７参照）、さらにその入力値が必要とされ、デフォルトで見えるかどうかが含まれる。大部分のＢｕｉｌｄｅｒＤｅｆオブジェクトは、ＢｕｉｌｄｅｒＩｎｐｕｔＤｅｆｉｎｉｔｉｏｎを参照することができる。ＢｕｉｌｄｅｒＩｎｐｕｔＤｅｆｉｎｉｔｉｏｎオブジェクトは、他のＢｕｉｌｄｅｒＩｎｐｕｔＤｅｆｉｎｉｔｉｏｎオブジェクトからの諸特性を継承し、それらをオーバーライドすることもできる。
【００５９】
（２）１組のＢｕｉｌｄｅｒＧｒｏｕｐＤｅｆｉｎｉｔｉｏｎ（１９）（図３Ａには１つだけを示す）。ＢｕｉｌｄｅｒＧｒｏｕｐＤｅｆｉｎｉｔｉｏｎは、ＢｕｉｌｄｅｒＩｎｐｕｔＤｅｆｉｎｉｔｉｏｎオブジェクトのグループに関する情報を定義するソフトウェア・オブジェクトである。ＢｕｉｌｄｅｒＩｎｐｕｔＤｅｆｉｎｉｔｉｏｎは、グループ定義を参照して、ビルダに、ＢｕｉｌｄｅｒＩｎｐｕｔ（１５）の組を相互に関連し合うように編成させることができる。例えば、いくつかのＢｕｉｌｄｅｒＩｎｐｕｔＤｅｆｉｎｉｔｉｏｎを、それらすべてが同時に見えるようにするために、同じＢｕｉｌｄｅｒＧｒｏｕｐＤｅｆｉｎｉｔｉｏｎの下にグループ化することができる。
【００６０】
（３）現在目的とされるビルダのためのＧｅｎＨａｎｄｌｅｒオブジェクトの名前への参照。
【００６１】
図３Ｃに戻ると、ステップ１３２で、ＧｅｎＨａｎｄｌｅｒは、ＢｕｉｌｄｅｒＤｅｆを使用してビルダをインスタンス化する。最後に、ＧｅｎＨａｎｄｌｅｒは、ステップ１３３で、そのビルダのインターフェイスに特有のやり方でビルダを呼び出す準備をする。
【００６２】
ステップ１１７で、ＧｅｎＨａｎｄｌｅｒは、ビルダの再生成メソッドを呼び出す。このステップでは、ビルダに、ＢｕｉｌｄｅｒＩｎｐｕｔ（１５）、ＧｅｎＣｏｎｔｅｘｔ（１３）、その内容を含むＧｅｎＣｏｎｔａｉｎｅｒ（５）が渡される。ビルダは、再生成メソッドで、ＢｕｉｌｄｅｒＩｎｐｕｔオブジェクトからの入力を使用する。ＢｕｉｌｄｅｒＩｎｐｕｔ（１５）は、ＢｕｉｌｄｅｒＣａｌｌでの入力値を定義する１組のＢｕｉｌｄｅｒＩｎｐｕｔオブジェクトを保持するソフトウェア・オブジェクトである。１つのＢｕｉｌｄｅｒＩｎｐｕｔは、単一の入力値を保持し、かつビルダの種類などの関連するメタデータを保持するソフトウェア・オブジェクトである。ＢｕｉｌｄｅｒＩｎｐｕｔは、その値の入力または変更に使用するユーザ・インターフェイス・ウィジェットの種類に関する情報を含む。例えば、ＢｕｉｌｄｅｒＩｎｐｕｔは、ユーザに値を入力する自由形式のテキスト領域を提供するのではなく、値を列挙された組だけに制限するために選択リストを提供するように特定することができる。
【００６３】
また、このステップでは、ビルダは、以下のタイプのオペレーションを実施することもできる。それらは、１）ＧｅｎＣｏｎｔａｉｎｅｒの内容とその参照されたオブジェクトの付加、変更、削除、２）ＧｅｎＣｏｎｔｅｘｔを介した他のビルダの呼び出し、３）他のフェーズでの再生成のための、ビルダのＧｅｎＣｏｎｔｅｘｔへの登録、さらに４）ＢｕｉｌｄｅｒＣａｌｌでのＢｕｉｌｄｅｒＩｎｐｕｔの付加または変更である。ビルダは、再生成機能と調整機能を実施するソフトウェア・オブジェクトの集合体である。再生成機能は、１つまたは複数の構築と変換オペレーションを、ビルダ間で受け渡されるＧｅｎＣｏｎｔａｉｎｅｒの内容に適用するプロセスである。調整機能は、そのビルダ用の入力値を集めるためのビルダ・エディタの呼び出しである（デザイナ・アプリケーションに関する選択も参照）。ビルダは、これらの機能を実施するための１つまたは複数のソフトウェア・オブジェクトと、そのコンポーネントやそれらのコンポーネント間の関係を記述するＢｕｉｌｄｅｒＤｅｆとを含む。ビルダの再生成機能は、任意の外部ソフトウェア・ライブラリにアクセスし、それを利用することができ、また、ファイル・システムやＵＲＬなどの外部システムにアクセスして内容を読み取り、それをその再生成機能で使用することもできる。
【００６４】
ＧｅｎＣｏｎｔａｉｎｅｒ（５）は、１組のビルダによって作成、変更、削除されるＤｏｍａｉｎＯｂｊｅｃｔ（６）への１組の参照を含むソフトウェア・オブジェクトである。各ＤｏｍａｉｎＯｂｊｅｃｔは、そのＤｏｍａｉｎＯｂｊｅｃｔの標準識別子であるＧｅｎＥｌｅｍｅｎｔ（１８）を介して、かつＤｏｍａｉｎＯｂｊｅｃｔをＧｅｎＣｏｎｔａｉｎｅｒに接続する接続機構を介してＧｅｎＣｏｎｔａｉｎｅｒに「接続」される。ＧｅｎＣｏｎｔａｉｎｅｒは１組のＧｅｎＥｌｅｍｅｎｔを維持する。
【００６５】
ＧｅｎＥｌｅｍｅｎｔは、１つまたは複数のＤｏｍａｉｎＯｂｊｅｃｔへの参照、および親、子、同位のＧｅｎＥｌｅｍｅｎｔへの１組の参照を含む。ＧｅｎＥｌｅｍｅｎｔは、ビルダとその他のソフトウェア・オブジェクトが、ＧｅｎＣｏｎｔａｉｎｅｒに関連付けられたＤｏｍａｉｎＯｂｊｅｃｔ間の構造と関係を理解する標準的方法、およびそれらのＤｏｍａｉｎＯｂｊｅｃｔの組をトラバースする標準的手段を提供する。ＧｅｎＥｌｅｍｅｎｔは、ロボット製造ライン中の設備上の１つまたは複数の部品に取り付けられた「バーコード付き」識別子にたとえられる。ビルダにたとえられるロボットは、その場合、そのバーコードの使用によって、標準的方法で各部品を識別することができる。ＧｅｎＥｌｅｍｅｎｔは、ＤｏｍａｉｎＯｂｊｅｃｔが、それらを構築するビルダの知識を持たなくてよいようにＤｏｍａｉｎＯｂｊｅｃｔを記述するメタデータの層を提供するために使用される。他方、ＤｏｍａｉｎＯｂｊｅｃｔは、再生成オペレーションの間に製造または変換されるソフトウェア・オブジェクトである。ＤｏｍａｉｎＯｂｊｅｃｔは、文字列のような単純なものから、ＸＭＬドキュメント・オブジェクト・モデルのような複雑なものまで、任意のソフトウェア・オブジェクトとすることができる。
【００６６】
ステップ１１８に進むと、処理する次のＢｕｉｌｄｅｒＣａｌｌがあるかどうかが判定される。次のＢｕｉｌｄｅｒＣａｌｌがある場合には、システムは続けて次のＢｕｉｌｄｅｒＣａｌｌを処理し、ステップ１１４から再度開始する。次のＢｕｉｌｄｅｒＣａｌｌがない場合には、そのフェーズが完了する。すべてのＢｕｉｌｄｅｒＣａｌｌが処理されると、ＧｅｎＣｏｎｔｅｘｔは、ステップ１１９で、そのＧｅｎＨａｎｄｌｅｒのリストにそのフェーズが完了したことを通知する。ステップ１２０では、残りのフェーズがあるかどうか判定される。残りのフェーズがない場合は、再生成プロセスが終了する。そうでない場合には、ＧｅｎｅｒａｔｉｏｎＭａｎａｇｅｒは、ステップ１２１で、残りのフェーズのために登録されたＢｕｉｌｄｅｒＣａｌｌでの再生成を呼び出す。
【００６７】
コンポーネント間の関係
本発明の各コンポーネント間の構造的関係のより詳細な説明を図４に示す。ボックスは、本発明の一実施形態でのソフトウェア・オブジェクトを表す。破線は参照を表す。入れ子構造のボックスは、包含関係（すなわちあるオブジェクトが別のオブジェクトに含まれること）を表す。ＧｅｎｅｒａｔｉｏｎＭａｎａｇｅｒ（１２）は再生成エンジン（３）の一部である。これは、ＧｅｎＣｏｎｔｅｘｔ（１３）、生成モデル（２）、ＧｅｎＣｏｎｔａｉｎｅｒ（５）への参照を含む。ＧｅｎＣｏｎｔｅｘｔ（１３）はＧｅｎＨａｎｄｌｅｒ（１４）への参照を含む。各ＢｕｉｌｄｅｒＣａｌｌ（１０）は中にＢｕｉｌｄｅｒＩｎｐｕｔ（１５）とＢｕｉｌｄｅｒＤｅｆ（１６）の両方への参照を含み、ＢｕｉｌｄｅｒＤｅｆ（１６）は複数のＢｕｉｌｄｅｒＩｎｐｕｔＤｅｆｉｎｉｔｉｏｎ（１７）オブジェクトを含む。ＢｕｉｌｄｅｒＤｅｆ（１６）はビルダ（４）を参照する。１組のＢｕｉｌｄｅｒＩｎｐｕｔ（１５）、ＢｕｉｌｄｅｒＤｅｆ（１６）、ビルダ（４）だけしか図示していないことに留意されたい。それらは、ＢｕｉｌｄｅｒＣａｌｌＬｉｓｔ（１）上で特定された各ＢｕｉｌｄｅｒＣａｌｌ（１０）ごとに１組ある。ＤｏｍａｉｎＯｂｊｅｃｔ（６）の構築には、普通、複数の組が使用される。さらに進むと、ＧｅｎＣｏｎｔａｉｎｅｒ（５）は複数のＧｅｎＥｌｅｍｅｎｔ（１８）を含む。各ＧｅｎＥｌｅｍｅｎｔはＤｏｍａｉｎＯｂｊｅｃｔ（６）を参照する。
【００６８】
オブジェクト生成
再生成機能は、ビルダを初期設定すると、ＢｕｉｌｄｅｒＣａｌｌＬｉｓｔ（１）によって規定された順序でビルダからビルダに生成コンテナを受け渡すことによって、規定のビルダの実行を調整する。各ビルダは、「ＯｎＲｅｇｅｎ」など、一般的な命名規約またはシグニチャ規約に従ったメソッドを実行することによってその再生成機能を実施する。このメソッドの目的は、コンテナに新規オブジェクトを作成、付加すると共に、すでにコンテナに含まれるオブジェクトを変換、削除することである。この状態では、オブジェクトは、再生成エンジンのオペレーションをホスティングする計算処理システムによってサポートされる任意のソフトウェア・コンポーネントである。例えば、ビルダは、文字列オブジェクトのインスタンスを構築し、次いで、それを生成コンテナに付加することができるはずである。また、ビルダは、ＸＭＬ  ＤＯＭ（拡張可能マーク付き言語ドキュメント・オブジェクト・モデル）などのより複雑なオブジェクトのインスタンスを作成し、次いで、ＸＭＬ要素や属性を付加することによってそのオブジェクトを取り込むこともできるであろう。その場合、他のビルダもこのＸＭＬ  ＤＯＭオブジェクトのインスタンスの各要素を付加し、変換することができるはずである。文字列やＤＯＭオブジェクトなどのオブジェクトは、ＸＭＬを含むテキスト形式への直列化をサポートすることができるが、この機能は、再生成が完了した直後に使用するためにソフトウェア・オブジェクト・インスタンスを生成することが目的である場合には、任意選択である。
【００６９】
再生成プロセスの一部として、再生成エンジンの再生成機能は、個々のビルダを動的に無効化し、プロファイル値や外部システムとの他の任意の対話に従ってビルダへの入力値を変更することができる。外部との対話の典型的な例として、再生成機能がデータベースを呼び出してある人の信用限度を受け取り、この情報を使用して、生成モデル中のＢｕｉｌｄｅｒＣａｌｌによって特定された１組のビルダを動的に無効にするかそれとも有効にするか決定する場合があげられよう。その再生成タスクが完了すると、再生成機能は１組の生成されたオブジェクトを返す。本発明では、それらのオブジェクトをＤｏｍａｉｎＯｂｊｅｃｔと呼ぶ。
【００７０】
再生成エンジンは、要求ペイロードの形で追加の入力データ・ブロックを使用して再生成機能を実施することもできる。例えば、本発明では、Ｊ２ＥＥ対応アプリケーション・サーバに入ってくる要求を処理するために、再生成エンジンをセットアップすることができる。これらの要求は、生成モデルやプロファイルの仕様にマッピングされるデータに加えて、ペイロード・データも含む。再生成機能は、それがビルダを処理する際に、その着信ペイロード・データのいずれかを使用することができる。また、個々のビルダも、それぞれの再生成機能でこのペイロード・データにアクセスすることができる。
【００７１】
パラメトリック生成ソース法
本発明によって実施される方法をパラメトリック生成ソース法と呼ぶ。この方法は、ソフトウェア工場の動的構成、アセンブリ、実行によって、ソース・オブジェクトを自動的に作成する。パラメトリック生成ソース法は、次に新規に１つまたは複数のソース・オブジェクトを作成するための生成ソフトウェア・コンポーネントのアセンブリとインスタンス化を自動化する。したがって、この方法は、その挙動が事前定義されると共に、既存のソース・オブジェクトを処理することに限定される静的生成プログラムを用いるコンパイラなどの従来技術の手法とは異なる。本発明によって実施されるパラメトリック生成ソース法は、ユーザによる、完全に自動化され、完全にパラメータ化された、複雑で、段階的な構築タスクをアセンブルし、構成するためのプロセス定義の定義を可能にする。ユーザが生成モデルを構築すると、そのユーザは、さらに、それらの構築タスクへの変更に対応する代替パラメータを定義することができる。したがって、この方法は、ユーザが、生成モデルと１組のパラメータ・プロファイルとに、関連する構築プロセスのファミリを定義できるようにする。これは、ソース・オブジェクトを同じソース・オブジェクトの変形に変換するように動作するコンパイラなどの静的コード生成プログラムを構築しようとするユーザの手法とは大きく異なる。本発明は、次にソース・オブジェクトのファミリを生成させるための（ソフトウェア工場が再生成エンジン中の１組の構成済みの実行ビルダを意味するとみなされる場合の）ソフトウェア工場のファミリの自動化された生成に中心を置くものである。
【００７２】
ＤｏｍａｉｎＯｂｊｅｃｔの実装
本発明の一実施形態では、図１のＤｏｍａｉｎＯｂｊｅｃｔ（６）は１組のソフトウェア・オブジェクトで表される。いくつかのビルダはそれらのオブジェクトの新規インスタンスを作成することができ、他のビルダは、そのオブジェクトＡＰＩとの対話によって、それらのオブジェクト・インスタンスの状態を追加、削除、変更することができる。例えば、規則セット・ビルダ（ビルダの一種）は、規則セット・クラスにアクセスすることによってＲｕｌｅＳｅｔオブジェクトの新規インスタンスを構築し、その新規オブジェクト・インスタンスを生成コンテナに付加する。次に、その規則ビルダは、規則クラスのインスタンスを構築し、ＲｕｌｅＳｅｔオブジェクトのａｄｄ（）メソッドを呼び出すことによって、それらの規則オブジェクト・インスタンスをＲｕｌｅＳｅｔオブジェクト・インスタンスに付加する。他のビルダは、ヘルパ・オブジェクトを呼び出すことによって、あるいはＲｕｌｅＳｅｔオブジェクトのメソッドの１つを呼び出すことによって、ＲｕｌｅＳｅｔオブジェクトを総称ＸＭＬ要素ツリーに変換することができる。これによって、そのビルダは、異なるＡＰＩを使用してこの同じＤｏｍａｉｎＯｂｊｅｃｔの異なる表現と対話できるようになる。この場合、そうしたビルダは、ＳＡＸ（Ｓｉｍｐｌｅ  ＡＰＬ  ｆｏｒ  ＸＭＬ）イベント生成とハンドラ・システムを呼び出すことによって、１つのオブジェクト表現から別の表現への変換を行うこともできるはずである。これは、ビルダがＤｏｍａｉｎＯｂｊｅｃｔと行うことのできる多くの対話の１つにすぎない。
【００７３】
本発明のビルダは、システム論理、またはその他任意の形の情報を表すことのできる任意の種類のオブジェクトを生成し、それと対話することができる。例えば、ビルダは、他のソースによって提供されたオブジェクトを作成し、それと対話することができる。一例が、米国特許第６，１８９，１４３号、「Ｍｅｔｈｏｄ  ａｎｄ  Ｓｙｓｔｅｍ  ｆｏｒ  Ｒｅｄｕｃｉｎｇ  ａｎ  Ｉｎｔｅｎｔｉｏｎａｌ  Ｐｒｏｇｒａｍ  Ｔｒｅｅ  Ｒｅｐｒｅｓｅｎｔｅｄ  ｂｙ  Ｈｉｇｈ−Ｌｅｖｅｌ  Ｃｏｍｐｕｔａｔｉｏｎａｌ  Ｃｏｎｓｔｒｕｃｔｓ」に記載されているマイクロソフトの、インテンショナル・プログラミング（ＩＰ）ツリー・ソフトウェア・システムである。システム論理を生成する本発明のビルダは、ビルダＯｎＲｅｇｅｎ機能に、ＪａｖａやＣ＃などの言語によって表され得る同じシステム論理を表すＩＰツリーの要素を表すオブジェクト・インスタンスを生成させる入力パラメータを受け入れることができる。ＩＰツリーは、縮小変換プロセスによって様々なプログラミング言語に変換され得るソース・データの高水準表現とするためのものであることに留意すべきである。
【００７４】
生成モデルを生成するためのシステム（デザイナ）
本発明の一実施形態は、ユーザによって生成モデル（２）の作成と編集に使用されるデザイナ・アプリケーションである。デザイナとシステムのその他の部分との関係を図５に示す。デザイナ（２０）は、ユーザが新規の生成モデルを作成し、既存の生成モデルを編集し、それらのモデルを削除することを可能にする。デザイナは、ユーザに、生成モデルの内容に対する直接操作制御を提供する「明示的」オーサリング・ツールである。本発明の別の実施形態では、再生成プロセスが生成モデルを生成できるようにする１組のビルダを提供することもできるはずである。これによって、ユーザは、システムが別の生成モデルなどを作成するための命令を含む生成モデルを作成できるようになる。デザイナが生成モデルを作成するための明示的オーサリング・ツールであるという事実を、ソフトウェア・オブジェクト・エンティティの直接操作によってソフトウェア・オブジェクトを作成するのに使用される他の「明示的」オーサリング・ツールと混同すべきではない。本発明では、ユーザは、明示的手法を使用して生成モデルを作成するが、生成されたソフトウェア・オブジェクトのインスタンスの自動生成をもたらすのは、生成モデルと再生成エンジンの再生成機能との組み合わせである。
【００７５】
ユーザがデザイナで生成モデルを開くと、デザイナはユーザにＢｕｉｌｄｅｒＣａｌｌＬｉｓｔ（１）のビューを提供する。このビューを、ＢｕｉｌｄｅｒＣａｌｌＬｉｓｔビュー（２１）と呼ぶ。このＢｕｉｌｄｅｒＣａｌｌＬｉｓｔビューは、表形式ビュー、順次リスト・ビュー、ＢｕｉｌｄｅｒＣａｌｌの属性に基づく階層ツリー・ビューを含めて、生成モデル中のＢｕｉｌｄｅｒＣａｌｌを見えるようにする多数の方法を提供する。また、デザイナ・アプリケーションは、その内容に影響を与えるようにビューに適用することのできるフィルタやソート・ユーティリティも提供する。
【００７６】
デザイナは、再生成によって生成されたＤｏｍａｉｎＯｂｊｅｃｔ（６）を含む生成されたオブジェクトを見、それと対話するための１組の拡張可能なビューも提供する。デザイナは、再生成エンジン（３）や実行エンジン（７）、さらに矢印付き点線で示す本発明のシステムの他の部分に接続される。これらの接続は、ユーザが生成モデル、プロファイルまたはその他の外部から供給されたデータを変更すると、デザイナが、生成された出力オブジェクトのビューのみならず、生成モデル・エンティティのビューも更新できることを意味する。アプリケーション・ビュー（２３）において、ユーザは、動作アプリケーション（８）を見、それと対話することができ、ＤｏｍａｉｎＯｂｊｅｃｔが、Ｗｅｂアプリケーションのオペレーションなど、実行可能なオペレーションを実施できる場合には、動作ＤｏｍａｉｎＯｂｊｅｃｔ（１１）を見、それと対話することもできる。したがって、生成モデルでユーザが行った変更の影響を直ちに表示させることができる。
【００７７】
図６に実行中のプロセスを示す。ステップ１４０で、ユーザは、デザイナに新規の生成モデルを作成し、または既存のモデルを編集する。次いで、ステップ１４１で、ユーザは、その新規または編集済み生成モデルと共に再生成機能を実行する。次いでステップ１４２で、ユーザは、生成されたＤｏｍａｉｎＯｂｊｅｃｔを見、それと対話する。次に、任意選択のステップ１４３で、ユーザは、ＤｏｍａｉｎＯｂｊｅｃｔを処理、実行するためのアプリケーションを呼び出すことができる。本発明では、これは、それらのＤｏｍａｉｎＯｂｊｅｃｔのオペレーションをテストするのに使用される規則エンジン実行環境でのＤｏｍａｉｎＯｂｊｅｃｔの実行が含まれる。さらなる変更が必要とされる場合は、ユーザは戻ってステップ１４０で生成モデルを編集することができる。
【００７８】
多くの場合、生成済みＤｏｍａｉｎＯｂｊｅｃｔが、一括して１つのアプリケーション（Ｗｅｂアプリケーションなど）を表すオブジェクトのサブセットを形成することに留意することは重要である。そうしたＷｅｂアプリケーションは、ＪＳＰ（Ｊａｖａ  Ｓｅｖｅｒ  Ｐａｇｅｓ）、Ｊａｖａクラス、その他のオブジェクトなど、多くの構造を表す文書ベースソフトウェア・エンティティやコンパイル済みのソフトウェア・エンティティを含む。本発明の一実施形態では、ＤｏｍａｉｎＯｂｊｅｃｔの実行は、Ｗｅｂアプリケーションのより大規模な実行の状態で行われる。本発明の一実施形態では、ＤｏｍａｉｎＯｂｊｅｃｔ内のシステム論理は、ページ・ナビゲーション、ユーザ・インターフェイス構成、ワークフロー・タスク、データ変換タスクなどの機能と挙動を制御する。
【００７９】
ＢｕｉｌｄｅｒＣａｌｌの編集
生成モデルを編集する際の主要タスクには、ＢｕｉｌｄｅｒＣａｌｌを付加、削除、変更すること、ならびにＢｕｉｌｄｅｒＣａｌｌを並べ替え、それらの有効状態、無効状態を設定することが関与する。ＢｕｉｌｄｅｒＣａｌｌが無効とマークされると、再生成機能はそれを飛ばして、そのビルダを生成プロセス全体に関与させないようにする。また、ユーザは、ＤｙｎａｍｉｃＢｕｉｌｄｅｒＩｎｐｕｔという名前のビルダ・ユーザ・インターフェイスと対話して、特定のＢｕｉｌｄｅｒＣａｌｌのどのビルダ入力を生成モデルの外部で公開として顕在化すべきかを特定することもできる。公開ビルダ呼び出し入力は、その値を、プロファイルを介して外部から供給された値で置き換えさせることができる（「カストマイザ」という表題の項を参照）。
【００８０】
図７Ａおよび７Ｂに、図５に示したデザイナ・アプリケーションの実施形態のオペレーションを詳細に示す。図７Ａは、図７Ｂの流れ図に見られるステップ番号付きの矢印を含む構成図である。これらは、このプロセスの各ステップに関与するコンポーネントを示すためのものである。このプロセスを、以下のように要約することができる。ユーザが、新規ＢｕｉｌｄｅｒＣａｌｌを生成モデルに付加し、あるいは既存のＢｕｉｌｄｅｒＣａｌｌを編集するようデザイナに指図すると、デザイナは、動的インスタンス化プロセスを利用して、ＤｙｎａｍｉｃＢｕｉｌｄｅｒＩｎｐｕｔ（２７および２８）を含む、そのビルダのユーザ・インターフェイスを作成する。このプロセスは以下の主要ステップを含む。
１．ＢｕｉｌｄｅｒＤｅｆ（１６）オブジェクト中のビルダ（４）に関する情報を探し、
２．ＢｕｉｌｄｅｒＤｅｆで特定されたＢｕｉｌｄｅｒＩｎｐｕｔＤｅｆｉｎｉｔｉｏｎ（１７）オブジェクトとＢｕｉｌｄｅｒＧｒｏｕｐＤｅｆｉｎｉｔｉｏｎ（１９）オブジェクトを使用して、ソフトウェアＵＩウィジェット（２５）をビルダ・エディタ（２６）にインスタンス化し、
３．ユーザ対話の間にビルダ・エディタ（２６）のイベント処理を実施するためにコーディネータ・ソフトウェア・オブジェクト（２３）をインスタンス化する。また、デザイナ（２０）は、プロファイル値と呼ばれる、その入力値の代替ソースを特定するために、各ＢｕｉｌｄｅｒＩｎｐｕｔＤｅｆｉｎｉｔｉｏｎごとに追加のユーザ・インターフェイス（２８）を構築する。
【００８１】
図７Ｂの流れ図でこのプロセスを詳細に示す。図７Ｂのステップ１５１で、ユーザが生成モデル（２）に新規ＢｕｉｌｄｅｒＣａｌｌを追加し、あるいはその中の既存のＢｕｉｌｄｅｒＣａｌｌ（１０）を編集しようとする（図示せず）と、デザイナ・アプリケーション（２０）は、そのＢｕｉｌｄｅｒＣａｌｌ（１０）のためのインターフェイス（２７および２８）を介したＢｕｉｌｄｅｒＩｎｐｕｔ値とプロファイル値の収集を処理するために、ビルダ・エディタ（２６）を動的にインスタンス化する。このデザイナ・アプリケーションの例には、Ｎ個のＤｙｎａｍｉｃＢｕｉｌｄｅｒＩｎｐｕｔインターフェイスのリストが示されている。
【００８２】
次いでステップ１５２で、デザイナ（２０）は、目的のビルダ（４）のためにＢｕｉｌｄｅｒＤｅｆオブジェクト（１６）を取得し、ビルダ・エディタ（２６）を構築するためにＢｕｉｌｄｅｒＩｎｐｕｔＤｅｆｉｎｉｔｉｏｎ（１７）とＢｕｉｌｄｅｒＧｒｏｕｐＤｅｆｉｎｉｔｉｏｎ（１９）の組を探し出す。これが新規のＢｕｉｌｄｅｒＣａｌｌである場合には、ＢｕｉｌｄｅｒＤｅｆオブジェクトは、ＢｕｉｌｄｅｒＤｅｆ（１６）ファイルで特定されるように、ＢｕｉｌｄｅｒＣａｌｌ（１０）を作成し、その値を初期設定する。一実施形態では、ビルダ定義を取得するステップは、１）ビルダ呼び出しリストに新規ビルダ呼び出しを構築する際に使用するビルダの種類の名前を取得するステップと、２）取得した名前を使用してビルダ定義オブジェクトを取得するステップとをさらに含む。
【００８３】
ステップ１５３で、デザイナは、各ＢｕｉｌｄｅｒＩｎｐｕｔＤｅｆｉｎｉｔｉｏｎごとにＤｙｎａｍｉｃＢｕｉｌｄｅｒＩｎｐｕｔを構築し、それが、ＢｕｉｌｄｅｒＣａｌｌ中でＢｕｉｌｄｅｒＩｎｐｕｔＤｅｆｉｎｉｔｉｏｎを対応するＢｕｉｌｄｅｒＩｎｐｕｔの特定の値で満たすこととみなされ得る。ＤｙｎａｍｉｃＢｕｉｌｄｅｒＩｎｐｕｔは、入力をエディタ内部で編集するためのウィジェットも含む。デザイナは、１）ユーザから各ＢｕｉｌｄｅｒＩｎｐｕｔごとの値を集め、２）ＢｕｉｌｄｅｒＩｎｐｕｔ間での制約条件を強制し、３）ユーザがＢｕｉｌｄｅｒＩｎｐｕｔプロファイル値のソースを外部ソースからのものと指定できるようにするために、ビルダ用のダイアログ・ボックスを構築する。
【００８４】
ステップ１５４で、デザイナは、ＢｕｉｌｄｅｒＤｅｆ（１６）で特定された、そのビルダのコーディネータ機能（２３）をインスタンス化する。コーディネータには、ＤｙｎａｍｉｃＢｕｉｌｄｅｒＩｎｐｕｔのリストを変更する機会が与えられ、その変更には、ＤｙｎａｍｉｃＢｕｉｌｄｅｒＩｎｐｕｔの付加または削除、およびその可視性、値、グループ割り当て、ウィジェット内の選択リストなどの変更が含まれる。
【００８５】
ステップ１５５で、デザイナは、ＤｙｎａｍｉｃＢｕｉｌｄｅｒＩｎｐｕｔオブジェクトで宣言されたビルダＵＩウィジェット（２５）の組をインスタンス化し、そのＵＩ制御をビルダ・エディタに置くべきかどうか決定する。また、デザイナは、プロファイル値（２８）を集めるために各ＤｙｎａｍｉｃＢｕｉｌｄｅｒＩｎｐｕｔごとに補助ユーザ・インターフェイスも構築する。ＢｕｉｌｄｅｒＧｒｏｕｐＤｅｆｉｎｉｔｉｏｎ（１９）は、グループ化されたＢｕｉｌｄｅｒＩｎｐｕｔＵＩ制御の組を表示したり、表示しなかったりを制御するためのＵＩ論理を作成するのに使用される。
【００８６】
デザイナは、ステップ１５６で、ビルダ・エディタでユーザによって生成された変更イベントのハンドラとしてコーディネータをセットアップする。デザイナは、ユーザとエディタとの対話に応答して変更イベントを作動させ、コーディネータにＤｙｎａｍｉｃＢｕｉｌｄｅｒＩｎｐｕｔを処理させ、更新させる。ＢｕｉｌｄｅｒＩｎｐｕｔが変更されるとコーディネータ中の一機能が呼び出され、コーディネータは、ＢｕｉｌｄｅｒＩｎｐｕｔ中の値を変更し、ビルダ・エディタで表示されるエラーや警告を生成する。
【００８７】
デザイナは、ステップ１５７で、コーディネータがＧｅｎＣｏｎｔａｉｎｅｒを使用できるようにする。これは、コーディネータが、ＧｅｎＣｏｎｔａｉｎｅｒによって参照されるＤｏｍａｉｎＯｂｊｅｃｔを取得し、参照できるようにする。コーディネータは、ＤｙｎａｍｉｃＢｕｉｌｄｅｒＩｎｐｕｔを変更することができ、その変更にはそれらを付加したり、削除すること、可視性などのそれらの値や特性を変更することが含まれる。
【００８８】
最後に、ステップ１５８で、ユーザが編集タスクを完了すると、デザイナは、更新されたＤｙｎａｍｉｃＢｕｉｌｄｅｒＩｎｐｕｔ値をＢｕｉｌｄｅｒＣａｌｌに保存する。そのＢｕｉｌｄｅｒＣａｌｌが新規である場合は、デザイナはそれをＢｕｉｌｄｅｒＣａｌｌＬｉｓｔに挿入する（図示せず）。
【００８９】
ビュー
一実施形態では、デザイナ・アプリケーションは、システム論理オブジェクトと呼ばれるＤｏｍａｉｎＯｂｊｅｃｔの一種と対話するための２つのビューも提供する。第１のビューは、規則ビューと呼ばれる（各規則の説明については表１を参照）。このビューは、各データ構造をボックスとして図示する。このビューは、各アクションを、そのアクションから他のアクションへの呼び出しを表すネストされたボックスを含むボックスとして表す。このビューは、各規則を、その規則の条件中の構造への参照を示す接続リンクと、呼び出し先のアクションへの参照を示す接続リンクを持つひし形として表す。このビューは、規則の条件とアクションのポップアップ表示も提供する。このビューは、論理記号（すなわちＡＮＤやＯＲ接合）の標準的略図を使用して各接合を表す。このビューは、フェーズと呼ばれる、外部に公開された状態もボックスとして表す。続いて、規則ビューで表されるエンティティのより詳細な説明を行う。
【００９０】
システム論理オブジェクトと対話するための第２のビューは、生成済みシステム論理オブジェクトのＸＭＬツリー表現のテキストベースのビューである。
【００９１】
デザイナは、ビューと呼ばれるソフトウェア・オブジェクトを呼び出すための機構も提供する。図８にビューの一例（３１）を示す。デザイナは、ビューにアクティブなＧｅｎＣｏｎｔａｉｎｅｒ（５）への参照を渡すことによってビューを呼び出す。ビューは、ＧｅｎＣｏｎｔａｉｎｅｒ（５）の内容の、図による、またはテキストベースの表現である。図８に矢印で示すように、ビューは、ＧｅｎＥｌｅｍｅｎｔ（１８）とＧｅｎＥｌｅｍｅｎｔ間の関係を表示することもでき、ＤｏｍａｉｎＯｂｊｅｃｔ（６）とＤｏｍａｉｎＯｂｊｅｃｔ間の関係を表示することもでき、両者の組み合わせを表示することもできる。具体的には、ビューは、ＧｅｎＥｌｅｍｅｎｔおよび／またはＤｏｍａｉｎＯｂｊｅｃｔの間の任意の親／子関係や対等の関係を示すことができる。この表示は、ＧｅｎＥｌｅｍｅｎｔ表示要素（３１）とＤｏｍａｉｎＯｂｊｅｃｔ表示要素（３２）によって行われる。アクティブなＧｅｎＣｏｎｔａｉｎｅｒとは、デザイナによって開かれている生成モデルに関連するものである。ＧｅｎＣｏｎｔａｉｎｅｒが変更されると、そのビューは、それ自体を更新できるように通知を受け取る。
【００９２】
ビューは、デザイナにＧｅｎＥｌｅｍｅｎｔの現在の状態について知らせる手段を提供する。例えば、ビューはデザイナに、あるＧｅｎＥｌｅｍｅｎｔが選択され、または強調されていることを知らせることができる。ビューは、デザイナに、生成モデルを変更するよう要求する手段を提供することもできる。例えば、ビューはデザイナに、ＢｕｉｌｄｅｒＣａｌｌＬｉｓｔ中のＢｕｉｌｄｅｒＣａｌｌを削除または無効にするよう要求することができる。
【００９３】
プロファイルを作成するためのシステム（カストマイザ）
図９は、カストマイザ（３４）と呼ばれる本発明の一実施形態と、それがその他のシステム・コンポーネントとどのように関係するかを示す構成図である。カストマイザは、プロファイル（９）を作成すると共に、それらが１つまたは複数の生成モデル（２）に関連して再生成プロセスに及ぼす影響をテストするためのアプリケーションである。カストマイザは、ユーザが生成モデルを開き、次いで、名前と値の対の形のパラメータからなる１つまたは複数のプロファイルを定義できるようにする。
【００９４】
カストマイザはプロファイル・セットを作成する機能も提供する。プロファイル・セットは、１組の名前付きパラメータとそれらの型を定義するデータの集まりである。ユーザがデザイナで作業しているとき、そのユーザは、ＢｕｉｌｄｅｒＣａｌｌ入力を公開とマークすることができ、その入力をプロファイル・セットで定義されたパラメータに関連付けることもできる。
【００９５】
カストマイザ・アプリケーション内で、ユーザが生成モデルに関連付けられたプロファイルのパラメータ値を指定したとき、そのプロファイル・セットの型定義は、このアプリケーションが入力値を得るための適当なユーザ・インターフェイス制御を生成するのに役立つ。例えば、プロファイル・セット・パラメータは、その入力が（文字列型と仮定する）ブール真／偽型であると特定することができる。その型がブール型であると知ることによって、カストマイザ・アプリケーションは、適当なユーザ・インターフェイス制御を自動的に生成することができ、それはこの場合、Ｎ個の列挙値のドロップ・ダウン選択リストである。
【００９６】
カストマイザはユーザに、プロファイルの付加、削除、変更を行うための機能を提供する。ユーザがプロファイルを作成するときに、このアプリケーションは、プロファイル・ビュー（３５）と呼ばれるビューを提供する。このビューは、そのプロファイルのパラメータを示し、ユーザが値を入力できるようにする。このビューは、生成モデルと関連付けることのできるすべてのプロファイルを処理するためのビュー機能と管理機能も提供する。
【００９７】
カストマイザ・アプリケーションは、その値を生成モデルと共に再生成エンジンに供給することによってプロファイルをテストする機能も提供する。カストマイザ内で編集とテストを同時に行うプロセスは、ユーザにとって好都合である。図１０にそのプロセスを示す。ステップ１６６で、ユーザが新規プロファイルを付加し、または既存のプロファイルを変更することによってプロセスが開始する。次いで、カストマイザ・アプリケーションは、ステップ１６７で、その値を生成モデルと共に再生成エンジンに供給することによってそのプロファイルをテストする。次いで、再生成エンジンは、ステップ１６８で再生成機能を実施し、ステップ１６９で生成済み出力オブジェクトを取得し、それらを実行エンジンに供給する。実行エンジンは、ステップ１７０で動作アプリケーション（８）を作成する。最後に、カストマイザは、ステップ１７１で、実行中のプロファイル特有のアプリケーションのプロファイル作成済みアプリケーション・ビュー（３６）と呼ばれるビューを提供する。このアプリケーションは、それが再生成エンジンによって使用されるプロファイルに特有であるという意味でプロファイル特有である。異なるプロファイルが使用された場合は、生成モデルが同じであっても、異なるアプリケーションが生成される。
【００９８】
II．ビルダとシステム論理オブジェクト
説明の第２の部分では、ビルダとシステム論理オブジェクトを含む、本発明の実施形態を開示する。ビルダはシステム論理オブジェクトを作成するための基本的な構築機構である。ビルダのオペレーションとシステム論理オブジェクトの機構を論じる前に、以下の表１に重要な用語およびそれらの定義を示す。
【００９９】
【表１】
2005510790.tif 000003
2005510790.tif 000004
2005510790.tif 000005
2005510790.tif 000006
2005510790.tif 000007
2005510790.tif 000008
【０１００】
システム論理オブジェクトを構築するビルダの説明
以下の各項では、本発明で使用される様々な種類のビルダについて述べる。それらはシステム論理ビルダ、規則セット・ビルダ、フェーズ・ビルダ、基本規則ビルダ、チェーン規則ビルダ、規則アクション・ビルダ、規則条件ビルダ、アクション・ビルダ、接合ビルダ、リンク規則ビルダである。
【０１０１】
システム論理ビルダ
システム論理ビルダは、ＤｏｍａｉｎＯｂｊｅｃｔがシステム論理オブジェクトである場合に１組のＤｏｍａｉｎＯｂｊｅｃｔで動作するビルダである。システム論理ビルダは、ＧｅｎＣｏｎｔａｉｎｅｒ内のシステム論理オブジェクトを作成、変更、削除することができる。システム論理ビルダは、このビルダの再生成機能がそれを使用して生成コンテナ中の生成済みＤｏｍａｉｎＯｂｊｅｃｔとＧｅｎＥｌｅｍｅｎｔを一意に特定することのできる名前を特定するためのＢｕｉｌｄｅｒＩｎｐｕｔを持つことができる。
【０１０２】
システム論理ビルダは、任意選択で、このビルダが動作すべき範囲を定義する規則セットの１つまたは複数の名前を取得するＢｕｉｌｄｅｒＩｎｐｕｔを持つことができる。例えば、ビルダは、そうした入力を使用して規則セットの名前を取得し、次いで、その規則セット内のシステム論理オブジェクトへの参照だけを含むようにその後のＢｕｉｌｄｅｒＩｎｐｕｔ値の範囲を限定することができるはずである。また、そうしたＢｕｉｌｄｅｒＩｎｐｕｔは、そのビルダが、その再生成オペレーションの範囲を前記規則セットの内容に限定できるようにすることも可能であろう。
【０１０３】
生成モデルは１組のシステム論理ビルダへの１組のＢｕｉｌｄｅｒＣａｌｌを含む。そうした生成モデルが再生成されると、それは１つまたは複数のシステム論理オブジェクトを、生成済みＤｏｍａｉｎＯｂｊｅｃｔとして生成することができる。
【０１０４】
規則セット・ビルダ
規則セット・ビルダは、（規則セットとも呼ばれる）名前付きシステム論理オブジェクトを構築する。これは、そのシステム論理オブジェクトにとって外部のエンティティへの参照を含む、１組の規則、アクション、接合、フェーズ、構造のためのコンテナまたはリポジトリとして働く。図１１に示すように、規則セット（４０）は、ゼロ個または複数の規則（４１）、ゼロ個または複数のアクション（４２）、ゼロ個または複数の接合（４３）、ゼロ個または複数のフェーズ（４４）、ゼロ個または複数の構造（４５）、ゼロ個または複数のその他のオブジェクトを含む。規則セット・ビルダによって構築される規則セットは、他のビルダによって構築され得る任意の種類の構造、機能、挙動、状態をサポートする開放型の構造とすることを意図するものである。
【０１０５】
規則セット・ビルダは、システム論理オブジェクトを構築する際にその挙動を構成するのに使用するための１組のＢｕｉｌｄｅｒＩｎｐｕｔを持つ。これらの入力には（それだけに限らないが）以下のものが含まれる。
【０１０６】
【表２】
2005510790.tif 000009
【０１０７】
規則セット・ビルダは上記の入力パラメータに限定されるものではない。システム論理オブジェクトの全体的動作挙動を規定するビルダに他のパラメータを付加することもできる。例えば、システム論理オブジェクトは、各規則が絶えず作動する無限ループに入ることによって動作することができ、これに対して、システム論理オブジェクトが１組の規則を実行する場合は動作挙動は停止し、次いで、それが次の規則を実行する場合は、別のフェーズに設定され、再度停止する。
【０１０８】
規則セット・ビルダは、規則セットが実行されるときに呼び出す最初のアクションの名前を特定するための任意選択のＢｕｉｌｄｅｒＩｎｐｕｔを持つことができる。これは、初期挙動と呼ばれる。そうしたＢｕｉｌｄｅｒＩｎｐｕｔが供給された場合、ビルダは、その挙動が、
ｉｆ（ＯｎＬｏａｄ（））｛  ｝，
の形での条件テストを含む単純規則を構築する。ＯｎＬｏａｄは、計算処理システムが（実行時に１度だけ実現される）初期状態にあるか否かを示す論理値を返すアクションへのメソッド呼び出しを表す。さらに、このビルダは、特定されたアクションへのアクション呼び出しを作成し、それを単純規則の挙動に挿入する。
【０１０９】
規則セットでの初期挙動の別の例が、
ｉｆ（Ｏｎｌｏａｄ（））｛ｓｅｔＰｈａｓｅ（”ｓｔａｒｔ”）；｝，
である。ｓｅｔＰｈａｓｅ（”ｓｔａｒｔ”）は規則セットのフェーズ変数を「ｓｔａｒｔ」という値に設定するアクションへのアクション呼び出しである。
【０１１０】
規則セット・ビルダがバインドされた変数、バインドされたアクション、デフォルト・アクション、あるいはＯｎＬｏａｄパラメータを特定するためにＢｕｉｌｄｅｒＩｎｐｕｔを必ずしも持たなくてもよいことに留意する必要がある。
【０１１１】
規則セット・ビルダを使用するために、本発明のユーザは、対話式オーサリング・アプリケーション（デザイナなど）を使用して生成モデルを作成し、その生成モデルに規則セット・ビルダを付加するよう選択する。このアプリケーションは、規則セット・ビルダのビルダ・エディタ・ユーザ・インターフェイスを開き、ビルダ・パラメータへの入力値の組を取得する。次いで、ユーザ・インターフェイスから「ＯＫ」信号を受け取ると、このアプリケーションは、生成モデルに新規ＢｕｉｌｄｅｒＣａｌｌを付加し、次いで、その新規ビルダの再生成機能を呼び出し、これによってその生成モデルの生成コンテナ中に１組の更新されたシステム論理オブジェクトが生成される。生成モデルは、任意の数の以前に付加されたＢｕｉｌｄｅｒＣａｌｌも含むことができる。生成コンテナは、他のシステム論理オブジェクトを含めて、任意の数の以前に構築されたエンティティを含むことができる。
【０１１２】
図１２に、単純な規則セット・ビルダによって作成された例示的システム論理オブジェクト（規則セット）の図を示す。規則セット（４８）は４つのフェーズ、すなわち開始フェーズ（４９）、実行フェーズ（５０）、完了フェーズ（５１）、リセットフェーズ（５２）を含む。また、フェーズの状態を開始に設定し、ｐａｇｅ１（５５）を作成し返送するためのページ処理を実行する開始規則（５４）の実行をトリガする、ＯｎＬｏａｄ機能（５３）もある。図示のシステム論理オブジェクトのエンティティすべては、規則セット・ビルダへの呼び出しの単一インスタンスによって作成される。
【０１１３】
フェーズ・ビルダ
フェーズ・ビルダは、規則セットのフェーズの許容された値を変更するシステム論理ビルダである。フェーズ・ビルダは、１）参照された規則セットと、２）前記フェーズの値を変更するための基準を特定するためのＢｕｉｌｄｅｒＩｎｐｕｔを持つ。第２のＢｕｉｌｄｅｒＩｎｐｕｔは、新規のフェーズ値の名前と、それを既存の列挙値の組のどこに挿入すべきかの基準とを受け入れることができる。使用法の一例では、ユーザに、ＲｕｌｅＳｅｔビルダの後の生成モデルにフェーズ・ビルダを付加させて、生成されたＲｕｌｅＳｅｔでのフェーズを変更することが考えられる。
【０１１４】
基本規則ビルダ
基本規則ビルダは、基本規則と呼ばれる規則の形のシステム論理オブジェクトに挙動を作成する。
【０１１５】
大部分のプログラミング言語では、規則は、以下のように、ｉｆ−ｔｈｅｎ式で表現される。
【０１１６】
【表３】
2005510790.tif 000010
【０１１７】
規則を表現する多くの方法がある。例えば、表を、１組の規則を間接的に定義する一方法とすることができ、その場合、ある行の第１のセルのエントリは規則のパターンであり、同じ行の次のセルはその規則のアクションである。ここで重要なことは、規則や挙動を表現するすべての異なる方法を詳述することでも、パターンやアクションを表現する様々な方法を詳述することでもない。そうではなく、重要なことは、挙動が規則の形のシステム論理オブジェクトで表現され得ることを識別することである。したがって、本発明におけるビルダは、新規の挙動の構築、既存の挙動の変更、あるいは挙動の削除を、すべてシステム論理オブジェクトの状態で行うことができる。
【０１１８】
基本規則ビルダ入力
基本規則ビルダは、１）テスト条件、２）Ｔｈｅｎ挙動に関連付けられたアクション呼び出し、３）Ｅｌｓｅ挙動に関連付けられたアクション呼び出し、４）テスト条件を評価すべきか否かを判定するのに使用される「前提条件」を特定するための１組のＢｕｉｌｄｅｒＩｎｐｕｔを持つ。ＢｕｉｌｄｅｒＩｎｐｕｔのそれぞれは、条件の場合には「真」を、アクションの場合には「ヌル」またはアクションなしを意味する縮退(degenerate)値を持つことができる。基本規則の挙動は以下の通りである。すなわち、基本規則は、そのテスト条件が「真」であると評価された場合は、そのＴｈｅｎ挙動に関連付けられたアクションを実行する。そうでない場合は、基本規則は、そのＥｌｅｓｅ挙動に関連付けられたアクションを実行する。基本規則ビルダは、その基本規則の名前（ＩＤ）のための入力も持つ。
【０１１９】
アクション呼び出しの名前を供給するためのＢｕｉｌｄｅｒＩｎｐｕｔは、単一のアクション呼び出しの仕様、またはゼロ個または複数のアクション呼び出しを含むアクション呼び出しのリストの仕様をサポートすることができる。後者の場合は、このビルダは、供給されたアクション呼び出しの組からなる新規アクションを構築する。次いで、このビルダは、その新規アクションへのアクション呼び出しを構築する。最後に、このビルダはこのアクション呼び出しを、関連するＴｈｅｎ挙動またはＥｌｓｅ挙動のどちらか関連する方に関連付ける。
【０１２０】
以下に、１組のアクション呼び出しのためのＢｕｉｌｄｅｒＩｎｐｕｔ値がリスト：ａｃｔｉｏｎ１（）、ａｃｔｉｏｎ２（）である場合に、基本規則ビルダがどのように挙動のアクション部分を構築し得るかの２つの例を示す。
【０１２１】
【表４】
2005510790.tif 000011
【０１２２】
テスト条件および前提条件を供給するためのＢｕｉｌｄｅｒＩｎｐｕｔは、単一の条件の仕様、または１つまたは複数の条件を含むことのできる条件のリストの仕様をサポートすることができる。第１の場合には、このビルダは単一の条件を評価する条件テストを構築する。第２の場合には、このビルダは、論理ＡＮＤを用いてすべての条件を評価する条件テストを構築する。
【０１２３】
以下に、１組の前提条件および／またはテスト条件に対するＢｕｌｄｅｒＩｎｐｕｔ値がリスト（ａ＞５），（ｂ＞１０）である場合に、基本規則ビルダが挙動の条件テスト部分をどのように構築し得るかの一例を示す。
【０１２４】
【表５】
2005510790.tif 000012
【０１２５】
以下に、Ｊａｖａ言語で表現された挙動の一例を示す。
【０１２６】
【表６】
2005510790.tif 000013
【０１２７】
以下は、２つの挙動の例であり、第２の挙動は、第１の挙動の条件の否定である条件を有する。これは、よく知られているｉｆ−ｔｈｅｎ−ｅｌｓｅ挙動である。
【０１２８】
【表７】
2005510790.tif 000014
【０１２９】
図１３に、規則形式で表現された事例２の図を示す。基本規則（５８）（ｒｕｌｅ１）は１つの条件（５７）と２つのアクション（５９）、（６０）を持つ。この場合もやはり、基本規則は、その前提条件とテスト条件を表す任意のパターン、および任意の２つのアクションを持つことができる。また、基本規則は、ｔｈｅｎの場合とｅｌｓｅの場合に関連付けられた１つまたは複数のアクションを持たないこともあり得る。
【０１３０】
基本規則ビルダは、挙動を、１つの「ｆｒｏｍ」状態と、「ｔｈｅｎ」の場合と「ｅｌｓｅ」の場合に関連付けられた１対の「ｔｏ」状態とに関連付けるための任意選択の入力を持つこともできる。ビルダ入力パラメータを介して「ｆｒｏｍ」状態と「ｔｏ」状態を特定することによって、ユーザはこのビルダに、ビルダが基本規則条件で追加のパターンを構築できるようにする情報を供給する。それらの追加パターンは、計算処理システムが、その挙動をアクティブ化し、「ｔｈｅｎ」アクションまたは「ｅｌｓｅ」アクションのどちらかを実行させるために、そのｆｒｏｍ状態を持つことを保証する。「ｔｈｅｎ」の場合と「ｅｌｓｅ」の場合のどちらかまたは両方に「Ｔｏ」状態を特定することによって、このビルダは、計算処理システムの状態をそれらの特定された状態によって呼び出される状態に変更するアクションへのアクション呼び出しを付加する。これらの状態を、この例示的ビルダでは「フェーズ」と呼ぶ。フェーズの実装は、基本規則ビルダで必須のものではないことに留意されたい。
【０１３１】
【表８】
2005510790.tif 000015
【０１３２】
事例３に、基本規則が、追加の挙動を提示させる追加のパターンとアクションを持つことのできる多数の方法のうちの１つを示す。ここで基本規則は、そのフェーズがＲＵＮ（実行）状態にある場合にアクティブ化することができる。その場合には、条件がチェックされ、ｔｈｅｎまたはｅｌｓｅアクションが実行される。また、この規則は、そのフェーズをＲＵＮ（実行）、またはＲＥＳＥＴ（リセット）に変更させる。図１４に、条件（６３）、（６４）を持つ、対応する基本規則６２（ｒｕｌｅ１）を示す。条件（６３）はフェーズ・チェックであることに留意されたい。条件がチェックされると、適当なフェーズ設定機構（６６）または（６８）と共に、アクション（６５）と（６７）のどちらかが実行される。
【０１３３】
基本規則ビルダは、「リセットの前に一度作動する」という任意選択の入力を持つことができる。これは真または偽に設定することができる。このビルダ入力は、システム論理オブジェクト全体の状態がリセットされる前にその規則が複数回作動できることを規定する追加の条件とアクションを規則中に構築すべきか否かをビルダに判定させる。規則が複数回作動できる場合は、計算処理システムは、パターンがマッチする間は、その規則を必要とされる回数だけ実行する。その規則が１回だけ作動するようにセットアップされた場合は、それが一度作動すると、計算処理システムは、この状態を反映するように動作システム論理オブジェクトの状態を変更する。この変更により、その規則は、その「作動済み」状態がリセットされるまで二度と作動しない。
【０１３４】
何度も作動することのできる規則の一例が、変数に値を繰り返し付加する規則である。一度作動し、システム全体のリセットまで無効にされる規則の一例が、変数によって維持される値である価格の値引きを計算する規則である。
【０１３５】
生成済み表現の実装の独立性
本発明のビルダが任意のソース表現でシステム論理オブジェクトを生成できることに留意することは重要である。上記の事例３では、基本規則ビルダでの生成済み出力のＪａｖａ表現が示されている。以下の例では、同じ挙動が２つの規則として表現され、その場合の目的計算処理システムは、ＩＬＯＧ社からのＪＲｕｌｅｓと呼ばれるＩＬＯＧ推論エンジンを動作させるソフトウェア・オブジェクトである。基本規則ビルダは、同じシステム挙動の他の表現を生成するのに使用されるのと同じパラメータ・ビルダ入力を使用してこの表現を生成する。
【０１３６】
【表９】
2005510790.tif 000016
【０１３７】
条件の種類
基本規則ビルダは、真または偽の状態であると評価される任意の種類の式の作成をサポートする、本発明における多数のビルダのうちの１つである。しかし、本発明では、基本規則ビルダ、あるいは条件の構築をサポートするその他のビルダのいずれかへの入力のための条件を構築する際にユーザが用いることのできる多数の事前構築されたテスト式がある。これらの事前構築された式は、システム論理オブジェクトにおける他のエンティティの状態の有無をテストする。以下に、そうした式のテストの一覧を示す。これは完全なリストではなく、どんな種類の条件が、条件を作成するビルダによってサポートされるかを示めそうとするためのものである。
【０１３８】
【表１０】
2005510790.tif 000017
【０１３９】
状態の値には、それだけに限らないが、ＦＩＲＥＤ、ＡＲＭＥＤ、ＡＣＴＩＶＥ、ＮＯＴＦＩＲＥＤ、ＤＩＳＡＢＬＥＤ、ＳＵＣＣＥＳＳ、ＦＡＩＬ、ＷＯＲＫＩＮＧ、ＷＡＩＴＩＮＧが含まれる。上記の各式を使用して、条件は、変数、アクション、接合、サービス、または規則の状態をチェックすることができる。したがって、それらの条件を利用するビルダによって生成されたシステム論理オブジェクトは、システム論理オブジェクトの流れをしかるべく導くことができる。
【０１４０】
アクションの種類
アクションを作成するビルダは、他のビルダによってシステム論理オブジェクトに構築されたエンティティを参照する多数の事前構築済みアクションを利用することもできる。そうしたアクションを集めたものの一例を以下のリストで示す。
【０１４１】
【表１１】
2005510790.tif 000018
【０１４２】
リストに示すように、サービス、アクション、メソッドを、事前定義アクションの一部として呼び出すことができる。また、変数、状態、ページを設定することもできる。オブジェクトをアクションの一部として取り出すこともできる。
【０１４３】
チェーン規則ビルダ
チェーン規則ビルダは、新規規則を付加すると共に、既存の規則の構造を変更するシステム論理ビルダである。既存の規則を変更する前に、チェーン規則ビルダは、まず、新規のＩｆ−Ｔｈｅｎ−Ｅｌｓｅ規則を構築する。本発明の一実施形態では、既存の規則をＲｕｌｅ１と呼び、新規のＩｆ−Ｔｈｅｎ−Ｅｌｓｅ規則をＲｕｌｅ２と呼ぶ。次に、このビルダは、参照されたのＲｕｌｅ１のＴｈｅｎまたはＥｌｓｅアクション部分のどちらか一方を新規のＲｕｌｅ２で置き換える。次に、このビルダは、参照されたのＲｕｌｅ１の元のＴｈｅｎまたはＥｌｓｅアクション部分を新規のＲｕｌｅ２のＥｌｓｅアクションに挿入する。チェーン規則ビルダは、１）ここではＲｕｌｅ１と呼ばれる参照されたの規則、２）ここではＲｕｌｅ１のＴｈｅｎまたはＥｌｓｅアクション部分と呼ばれる目的アクション、３）新規規則のテスト条件、および４）新規規則のＴｈｅｎアクション呼び出しを特定するためのＢｕｉｌｄｅｒＩｎｐｕｔを持つ。
【０１４４】
ユーザが、すでにＲｕｌｅ１を含んでいるシステム論理オブジェクト（すなわち規則セット）に関するＢｕｉｌｄｅｒＩｎｐｕｔに下記の値を特定する、以下の例を考察する。
Ｒｕｌｅ１：
ＢｕｉｌｄｅｒＩｎｐｕｔ値：
１）参照された規則          Ｒｕｌｅ１
２）目的アクション      「Ｔｈｅｎ」
３）新規条件            （ｂ＞２）
４）新規ＲｕｌｅＡｃｔｉｏｎ呼び出し      ａｃｔｉｏｎ２（）；
【０１４５】
チェーン規則の再生成の前に、システム論理オブジェクトは以下の構造を含む。
【０１４６】
【表１２】
2005510790.tif 000019
【０１４７】
チェーン規則の再生成のステップは以下の通りである。まず、チェーン規則ビルダは、以下に示すＲｕｌｅ２と呼ばれる新規規則を構築する。
【０１４８】
【表１３】
2005510790.tif 000020
【０１４９】
次に、チェーン規則ビルダは、Ｒｕｌｅ１の「Ｔｈｅｎ」アクション部分を新規Ｒｕｌｅ２で以下のように置き換える。
【０１５０】
【表１４】
2005510790.tif 000021
【０１５１】
最後に、チェーン規則ビルダは、Ｒｕｌｅ１の元のＴｈｅｎアクション部分を新規Ｒｕｌｅ２のＥｌｓｅアクションに以下のように挿入する。
【０１５２】
【表１５】
2005510790.tif 000022
【０１５３】
図１５は、事例４を図示したものである。図１５は、ｒｕｌｅ２と呼ばれるチェーン規則を示すものであり、これはｒｕｌｅ１と呼ばれる（最初に図１３で示した）参照されたの基本規則に関連付けられている。図１３と図１５の違いに注目されたい。図１５では、チェーン規則ｒｕｌｅ２（７０）が以前のａｃｔｉｏｎ１（６０）の位置に付加される。チェーン規則ｒｕｌｅ２（７０）は、変数「ｂ」（７１）をチェックし、２つのアクション、ａｃｔｉｏｎ１（６０）、ａｃｔｉｏｎ２（７２）を持つ。言い換えると、ｒｕｌｅ１（５８）の条件が満たされた場合は、ｒｕｌｅ１の「ｔｈｅｎ」アクションが実行され、それはｒｕｌｅ２（７０）がアクティブ化されることを意味する。チェーン規則がアクティブ化されると、それはその条件が満たされた場合にはその「ｔｈｅｎ」アクションを作動させることができ、その条件が満たされなかった場合にはその「ｅｌｓｅ」アクションを作動させることができる。上記の場合には、ｒｕｌｅ２（７０）の条件が満たされた場合は、ａｃｔｉｏｎ２（７２）が実行される。ｒｕｌｅ２（７０）がアクティブ化されたが、その条件が満たされなかった場合は、ｒｕｌｅ１の「ｔｈｅｎ」の場合に特定された元のアクションが実行される。そのアクションはａｃｔｉｏｎ１（６０）である。
【０１５４】
前述のチェーン規則ビルダへの第２のＢｕｉｌｄｅｒＩｎｐｕｔ（目的アクション−「Ｔｈｅｎ」）がＲｕｌｅ１の「Ｅｌｓｅ」部分を参照するように変更され、このビルダが再生成された場合には、システム論理オブジェクトは以下のように見えるように更新されることに留意する必要がある。
【０１５５】
【表１６】
2005510790.tif 000023
【０１５６】
要するに、チェーン規則は、参照された規則の元の挙動を、その参照された規則のｉｆ−ｔｈｅｎ条件が満たされた場合は、その参照された規則の「ｔｈｅｎ」アクションが実施されないように変更するという影響を与える。その代わり、参照されたの規則のアクションは、チェーン規則のアクティブ化をトリガすることになる。
【０１５７】
チェーン規則が別のオブジェクトをアクティブ化するための多種多様な方法がある。本発明の一実施形態では、参照された規則は、チェーン規則上でｓｅｔＡｃｔｉｖｅ（）メソッドを呼び出す。例えば、上記の場合には、ｒｕｌｅ１がｒｕｌｅ２上でｓｅｔＡｃｔｉｖｅ（）を呼び出すことになる。チェーン規則ビルダは、参照された規則のアクションを変更することの一部として、この既存の参照された規則へのｓｅｔＡｃｔｉｖｅ（）呼び出しを付加する。
【０１５８】
完全パス名
チェーン規則ビルダは完全パス名と呼ばれる追加のＢｕｉｌｄｅｒＩｎｐｕｔを持ち、これはユーザからは見えない。このＢｕｉｌｄｅｒＩｎｐｕｔの値は、ユーザが最初の２つのＢｕｉｌｄｅｒＩｎｐｕｔに対する値、すなわち参照された規則と目的アクションの値を指定したときはいつでも、チェーン規則ビルダのコーディネータ（図７Ａを想起されたい）論理によって自動的に供給、更新される。ユーザが参照された規則と目的アクションを特定すると、コーディネータ論理は、その参照された規則が別の規則のアクション内にネストされているかどうか判定し、ネストされている場合は、そのアクションが、さらに別の規則のアクション内にネストされている別の規則の一部であるか否かを判定する、以下同様である。この分析が完了すると、コーディネータ論理は、完全パス名ＢｕｉｌｄｅｒＩｎｐｕｔの値を構築する。この値は、分析で発見されたすべてのネストされた規則／アクション命令文の連結であり、その最後のものが先頭になる。以下は、コーディネータ論理によって完全パス名の隠されたＢｕｉｌｄｅｒＩｎｐｕｔについて導出されるはずの値の一例である。
【０１５９】
事例４の例に戻ると、以下のように示される。
【０１６０】
【表１７】
2005510790.tif 000024
【０１６１】
ユーザが以下のＢｕｉｌｄｅｒＩｎｐｕｔ値、
１）  参照された規則        Ｒｕｌｅ２
２）  目的アクション    Ｔｈｅｎ
を供給した場合、その完全パス名ＢｕｉｌｄｅｒＩｎｐｕｔ値は、
Ｒｕｌｅ１／Ｔｈｅｎ，Ｒｕｌｅ２／Ｔｈｅｎ
となるはずである。
【０１６２】
チェーン規則ビルダは、その他のＢｕｉｌｄｅｒＩｎｐｕｔ値の１つが使用できない特定の場合には、その再生成論理で完全パス名の値を使用する。これは、ビルダの再生成機能がＢｕｉｌｄｅｒＩｎｐｕｔの値をリゾルブしようとし、その値が、実際には、存在することもしないこともあるＤｏｍａｉｎＯｂｊｅｃｔ中のエンティティの名前である場合に行われる。場合によっては、再生成機能がＢｕｉｌｄｅｒＩｎｐｕｔの値を持つこともあるが、何らかの理由で、そのＤｏｍａｉｎＯｂｊｅｃｔ中の参照されたオブジェクトを見つけられないこともある。これによって、再生成機能がその再生成タスクを完了するのを妨げられることがある。チェーン規則ビルダを用いる際には、場合によっては、参照された規則ＢｕｉｌｄｅｒＩｎｐｕｔに値が存在したとしても、参照された規則が実際には存在しないこともある。これは、生成モデルが、相互によって作成された規則を参照し合う、すなわち規則チェーンを形成する複数のチェーン規則ビルダを用いて作成された場合に起こり得る。この場合、そうした生成モデルがその後に、ＢｕｉｌｄｅｒＣａｌｌＬｉｓｔ中で「無効」にされたチェーン規則ＢｕｉｌｄｅｒＣａｌｌの１つを用いて再生成されると、そのＢｕｉｌｄｅｒＣａｌｌＬｉｓｔの後の方に存在するチェーン規則ＢｕｉｌｄｅｒＣａｌｌが、それが参照する１つまたは複数の規則を見つけ出せなくなることがある。これが、チェーン規則ビルダが、完全パス名ＢｕｉｌｄｅｒＩｎｐｕｔを使用して、それが参照できるチェーンで使用可能な次の規則を見つけるという方法を取る場合である。このプロセスのより詳細な説明は「自動参照適応」の項で行う。
【０１６３】
複数チェーン規則
チェーン規則ビルダは、別のチェーン規則を参照するチェーン規則を構築することもできる。これは、基本規則ビルダと１組のチェーン規則ビルダが、システム論理オブジェクト中にＮレベルの深さでネストされた挙動のチェーンを構築することを可能にする。以下の例では、チェーン規則ビルダが生成モデルに付加され、それによってシステム論理オブジェクトにすでに存在するチェーン規則を参照するチェーン規則の付加が生じる。第２のチェーン規則を付加することの影響は、基本規則の挙動を保ちつつ、参照されたチェーン規則の挙動を変更することである。以下に一例を示す。事例４の終わりの部分から開始する。
【０１６４】
【表１８】
2005510790.tif 000025
【０１６５】
新規のチェーン規則ＢｕｉｌｄｅｒＣａｌｌが生成モデルに付加された後で、以下のＢｕｉｌｄｅｒＩｎｐｕｔ、
１）  参照された規則        Ｒｕｌｅ２
２）  目的アクション    Ｔｈｅｎ
３）  新規条件          （ｃ＞３）
４）  新規アクション呼び出し    ａｃｔｉｏｎ３（）；
５）  完全パス名        Ｒｕｌｅ１／Ｔｈｅｎ，Ｒｕｌｅ２／Ｔｈｅｎ
を用いると、以下が得られる。
【０１６６】
【表１９】
2005510790.tif 000026
【０１６７】
図１６は、第２のチェーン規則の付加後の事例５の流れを示す概略図である。図１５に比べると、ｒｕｌｅ３の付加によって論理の流れが変更されている。この場合、チェーン規則ｒｕｌｅ３（７３）が以前のａｃｔｉｏｎ２（７２）の位置にある。チェーン規則ｒｕｌｅ３は変数「ｃ」（７４）をチェックし、変数「ｃ」のチェック結果に基づく２つのアクション、ａｃｔｉｏｎ３（７５）とａｃｔｉｏｎ２（７２）を持つ。チェーン規則の進行は直線的である必要はないことに留意する必要がある。「ツリー」進行も可能である。規則は、それに関連する複数のチェーン規則を持つことができる。これにより、ユーザは、システム論理オブジェクト中にチェーン規則ツリーを構築することができる。
【０１６８】
自動参照適応
本発明は、ユーザが生成モデル中の任意のビルダを無効にできるようにする。これにより、システムは、（無効にされたビルダを飛ばして）生成モデル中のアクティブなビルダだけを再生成し、システム論理オブジェクトを含む１組の新規の生成されたオブジェクトを生成する。上記の事例５では、チェーンの完全パスは「Ｒｕｌｅ１，Ｔｈｅｎ／Ｒｕｌｅ２，Ｔｈｅｎ」である。この値に対応する規則が生成済みシステム論理オブジェクトで見つからなかった場合は、チェーン規則の再生成機能は、その完全パス名入力を調べ、生成済みシステム論理オブジェクト（規則セット）に存在するチェーンの中の「最下位」の規則を見つけ出す。例えば、ユーザがＲｕｌｅ２を構築するチェーン規則ビルダを無効にした場合、Ｒｕｌｅ３を構築するチェーン規則ビルダはその挙動を変更し、構築されたＲｕｌｅ３をＲｕｌｅ２ではなくＲｕｌｅ１に関連付けるはずである。これは、最下位の規則がＲｕｌｅ２ではなくＲｕｌｅ１である（Ｒｕｌｅ２が無効にされている）からである。事例６は、生成モデル中の第１のチェーン規則ビルダを無効にすることの影響を示すものである。
【０１６９】
【表２０】
2005510790.tif 000027
【０１７０】
図１７は事例６の流れを示す概略図である。図１６（事例５）と図１７（事例６）の違いに留意されたい。この場合、進行はｒｕｌｅ１（５８）からｒｕｌｅ３（７３）に進む。ａｃｔｉｏｎ１（６０）の位置はｒｕｌｅ３（７３）の後に移動している。
【０１７１】
事例６を構築する際に、最後のチェーン規則ビルダは、条件（ｂ＞２）で特徴付けられる、その元の参照された規則−ｒｕｌｅ２を見つけることができなかった。その結果、そのチェーン規則ビルダの再生成機能は、完全パス名に頼ってその「チェーン」中の次に使用可能な参照された規則を見つけ出した。再生成機能は、Ｒｕｌｅ１がチェーン中でＲｕｌｅ２のすぐ上に並んでいることを発見し、その結果、Ｒｕｌｅ１を参照された規則ＢｕｉｌｄｅｒＩｎｐｕｔ値として使用した。したがって、チェーン規則ビルダは、Ｒｕｌｅ１への接続を用いてＲｕｌｅ３を構築する。その結果、チェーン規則ビルダは、Ｒｕｌｅ１の「Ｔｈｅｎ」アクションに挿入されたその新規の規則、
ｉｆ（ｃ＞３）｛ａｃｔｉｏｎ３（）；｝ｅｌｓｅ｛  ｝
を構築した。次いで、チェーン規則ビルダは、Ｒｕｌｅ１の「Ｔｈｅｎ」アクションを除去し、それを新規規則の「Ｅｌｓｅ」アクションとして割り当てた。
【０１７２】
このＢｕｉｌｄｅｒＩｎｐｕｔ値再割り当て機能は、ＧｅｎＣｏｎｔａｉｎｅｒ中のＤｏｍａｉｎＯｂｊｅｃｔが生成モデルのある再生成から次の再生成までに著しく変更されている可能性のある場合に、チェーン規則ビルダなどのビルダが強力な適応能力を持つことができるようにする。この能力を自動参照適応と呼ぶ。
【０１７３】
一般に、どの種類のビルダも、その値がシステム論理オブジェクト中に見当たらないエンティティを参照する入力がフォールバック参照を特定するバックアップ入力を持つ限り、それ自体の生成挙動を自動的に適応させることができる。この手法は、チェーン規則ビルダで使用される。しかし、欠けているエンティティが参照されるときに、ビルダが再生成プロセスでエラーを知らせることが望ましい場合もある。
【０１７４】
自動適応の挙動を図１８の流れ図で要約する。ステップ１７６で、新規のチェーン規則ビルダを既存の生成モデルに付加する。次いで、ステップ１７７で、再生成機能を実行する。再生成の過程で、システムは、新規に付加されたチェーン規則ビルダによって参照される規則を見つけようとする（ステップ１７８）。そうした規則が見つかった場合は、ステップ１７９で、その新規チェーン規則を参照された規則に接続する。そうでない場合は、ステップ１８０で、既存のチェーンの完全パス上でルックアップを実施し、新規チェーン規則をそのパス中の最下位の規則に接続する。
【０１７５】
本発明では、この参照機構を規則参照以外の参照の適応に適用することもできる。これは、一般に、バックアップ参照を必要とすることのある任意の参照に適用することができる。一次参照を「強い」ビルダ入力として保持するビルダ入力と、バックアップ参照を「弱い」ビルダ入力として保持するビルダ入力とを考えることができる。
【０１７６】
規則アクション・ビルダ
規則アクション・ビルダは、参照された規則または規則セットの挙動のアクション呼び出し部分を変更するシステム論理ビルダである。このビルダは、１つまたは複数の新規のアクション呼び出しを構築し、それらを参照された規則の挙動のアクション部分に挿入する。
【０１７７】
規則アクション・ビルダは、１）１つまたは複数の参照された規則、２）新規のアクション呼び出しが挿入される参照された規則の「Ｔｈｅｎ」、「Ｅｌｓｅ」、または両方のアクション部分、３）アクション呼び出しをそのために構築し、参照された規則に挿入すべきアクションの組、を特定するためのＢｕｉｌｄｅｒＩｎｐｕｔを持つ。
【０１７８】
規則アクション・ビルダは、参照されたアクションにアクション呼び出しを付加することもできる。参照された規則の名前を供給するためのＢｕｉｌｄｅｒＩｎｐｕｔは、アクションの名前を受け入れることができる。
【０１７９】
規則アクション・ビルダは、挿入されたアクション呼び出しを、参照されたアクションの先頭に挿入すべきか、それとも末尾に挿入すべきかを特定するための任意選択のＢｕｉｌｄｅｒＩｎｐｕｔを持つことができる。
【０１８０】
以下は、規則アクション・ビルダが、下記の１組の参照された規則をどのように変更するかを示す例である。
【０１８１】
【表２１】
2005510790.tif 000028
【０１８２】
規則アクション・ビルダのＢｕｉｌｄｅｒＩｎｐｕｔ値として、
１）  参照された規則    Ｒｕｌｅ１，Ｒｕｌｅ２
２）  目的アクション    Ｔｈｅｎ
３）  新規アクション呼び出し    ａｃｔｉｏｎ３（）；
を用いる。このビルダの再生成機能適用後の規則は以下の通りである。
【０１８３】
【表２２】
2005510790.tif 000029
【０１８４】
したがって、ａｃｔｉｏｎ３（）が、参照された規則の両方、Ｒｕｌｅ１とＲｕｌｅ２に付加される。規則アクション・ビルダは、システム論理オブジェクト中の１組の規則、アクション、接合に１つまたは複数のアクションを付加する。このビルダは、それらのアクションをどのエンティティに適用すべきかを特定するための１組のパラメータ入力を提供する。このビルダの生成機能はこれらの入力値を使用して、どのようにシステム論理オブジェクトを評価すべきか判定し、その新規アクションが付加されるエンティティを選択する。規則アクション・ビルダは、目的エンティティに付加されるアクションのリストを特定するための入力も持つ。規則アクション・ビルダを使用すると、ユーザは、基本規則ビルダおよびチェーン規則ビルダで使用可能なものと同じ種類のアクションを構築することができる。
【０１８５】
間接参照
生成モデル中の規則アクション・ビルダ呼び出しを無効にすることの影響により、その規則アクション・ビルダの再生成機能が無効とされ、そのため、影響を受けた規則、アクション、接合中では特定されたアクションが構築されない。また、特定のエンティティの名前を指定せずに、規則アクション・ビルダの入力パラメータ中で目的エンティティを特定することも可能である。これを行う一方法は、規則アクション・ビルダがそのアクションを特定の「Ｆｒｏｍフェーズ」を有するすべての規則に付加するよう指定することである。「Ｆｒｏｍフェーズ」の使用は、規則アクション・ビルダに、目的エンティティ（どこにアクションを付加するか）を見つける方法での柔軟性を持たせる。この柔軟な挙動により、ユーザが生成モデル中の規則アクションＢｕｉｌｄｅｒＣａｌｌの前にＢｕｉｌｄｅｒＣａｌｌを無効にすることができるようになり、そのため、特定の規則、アクション、接合エンティティを構築することが不要となり、そのため、規則アクション・ビルダが、現在生成されているシステム論理オブジェクト中に存在する関連エンティティでアクションを構築する際にその挙動を自動的に適応させる。例えば、特定の「Ｆｒｏｍフェーズ」を有する規則にアクションを付加するために規則アクションＢｕｉｌｄｅｒＣａｌｌが特定される場合を考える。ある再生成では、３つの生成済み規則がこの基準を満たし、それら３つの規則にアクションが付加される。しかし、次の再生成では、規則ビルダの１つが無効にされており、規則アクション・ビルダは、残り２つの規則だけにアクションを付加する。
【０１８６】
間接参照は、ビルダ入力が、１組の参照されたエンティティにリゾルブされる値を持つことを可能にする本発明での一機能である。そうした値は、１組の参照されたエンティティにリゾルブされる任意の式の形とすることができる。このリゾルブ機能は、生成モデル中で呼び出されるビルダの再生成の間に実施されるので、このリゾルブ機能の結果は、再生成ごとに変化し得る。
【０１８７】
例えば、規則を参照する一方法は、ビルダ入力の値として規則名のリストを提供することである。このリストは、システム論理オブジェクト中のエンティティへの直接参照である。したがって、ビルダ入力がそうしたリストを期待するときには、それは直接参照を使用するものである。これとは異なり、ユーザが間接参照の形（例えば「Ｆｒｏｍフェーズ」など）で値を供給した場合、この参照リゾルーションは、そのビルダの再生成が行われるときに生じる再生成の時点まで延期される。ユーザが＄｛ｒｕｌｅｓＡｔＡＰｈａｓｅ（”ｐｈａｓｅＸ”）；｝の形で間接参照を供給した場合、そのビルダはこの値を取り込み、その再生成機能の一部としてその値を規則のリストにリゾルブする。この場合、「ｐｈａｓｅＸ」は再生成まで知られることがなく、そのリゾルブされた値は、ある再生成から次の再生成までに変化し得る。したがって、次回の再生成が行われると、ユーザが生成モデルでそのビルダ呼び出しを作成した時点で存在していた組とは異なる、「ｐｈａｓｅＸ」に関連付けられた１組の規則オブジェクトが存在することも考えられる。
【０１８８】
本発明における規則アクション・ビルダは、アクションを作成するための目的規則を特定する３つの異なる方法を提供する。以下に、この３つの方法を列挙する。このリストは、包括的なものではなく、ビルダが入力値を介して特定された間接参照を持つことのできる方法の多様性を示すためのものである。
規則のリスト                システム論理オブジェクト中の規則名のリスト（直接参                              照）
あるフェーズにおける規則    システム論理オブジェクト中のフェーズの名前（間接参                              照）
チェーン中の規則            システム論理オブジェクト中のチェーン規則の名前、チ                              ェーンの末尾を表す（間接参照）
【０１８９】
このリストの最初の２つの項目についてはすでに論じた。チェーン中の規則を入力として特定する第３の項目は、フェーズ入力における規則と同様に機能する間接参照である。唯一の違いは、このリゾルーションがフェーズではなく、この場合はチェーン規則値に基づくことである。規則アクション・ビルダは、その規則の「ｔｈｅｎ」、「ｅｌｓｅ」または両方の部分にアクションを適用すべきかどうか、および接合とアクションを含むべきか否かを特定するための入力も持つ。さらに、規則アクション・ビルダは、特定されたもの以外のすべての規則を目的とみなすべきであると特定するためのオプションも持つ。
【０１９０】
規則条件ビルダ
規則条件ビルダは、参照された規則または規則セットの条件テスト部分を変更するシステム論理ビルダである。このビルダは、１つまたは複数の新規の条件を構築し、それを参照された規則の挙動の条件テスト部分に挿入する。条件を挿入するのに使用される手法には、元の条件を取り込み、論理「ＡＮＤ」演算子を用いてその新規条件を連結することが関与する。これにより新規条件が生成される。
【０１９１】
規則条件ビルダは、１）１つまたは複数の参照された規則、２）参照された規則に挿入される条件の組を特定するためのＢｕｉｌｄｅｒＩｎｐｕｔを持つ。
【０１９２】
以下は、規則条件ビルダが、下記の１組の参照された規則をどのように変更するかを示す例である。
【０１９３】
【表２３】
2005510790.tif 000030
【０１９４】
以下は、規則条件ビルダでのＢｕｉｌｄｅｒＩｎｐｕｔ値である。
１）  参照された規則    Ｒｕｌｅ１，Ｒｕｌｅ２
２）  新規条件          （ｄ＜１００）
このビルダの再生成機能適用後の規則は、以下のようになるはずである。
【０１９５】
【表２４】
2005510790.tif 000031
【０１９６】
したがって、条件（ｄ＜１００）が参照された規則、Ｒｕｌｅ１とＲｕｌｅ２に挿入されている。規則条件ビルダは、このビルダが１組の目的規則中に、追加のアクションではなく追加の条件を構築するという点を除けば、規則アクション・ビルダに極めて類似している。規則アクション・ビルダと同様に、規則条件ビルダでも間接参照は入力の１つのオプションである。
【０１９７】
アクション・ビルダ
アクション・ビルダは、他のアクションを含む機能エンティティへの１組の呼び出しからなるシステム論理オブジェクト中の１つのアクションを構築する。アクション・ビルダでは、ユーザは、アクション呼び出し順序の構築をサポートする他のすべてのビルダで使用可能な機能エンティティへの同じ種類の呼び出しを構築することができる。
【０１９８】
アクション・ビルダは、アクションの名前を特定するための入力と、呼び出されるアクションの組を特定するための入力を持つ。このビルダは、個々のアクション呼び出しを非同期または同期として特定できるようにする。１組のアクション呼び出しをそれらのオプションの混合として特定することも可能である。この場合は、実行時のアクションの挙動は、アクション呼び出し順序で特定された順序でアクションを呼び出し、アクション呼び出しが同期として特定された場合は完了を待つことである。
【０１９９】
アクション・ビルダは、生成モデルでのビルダの再生成の間に、そのアクションの多くの特性を動的に生成するように設計される。アクション・ビルダの再生成挙動は、再生成の前にそのパラメータ入力値を変更することによって変更することができる。アクション・ビルダが、それが構築するアクション呼び出しの順序を変更することも、各アクション呼び出しの呼び出し特性を非同期から同期に変更することも可能である。また、アクション・ビルダは、システム論理オブジェクト中のアクションの状態を規定し、更新するそのアクションに関連付けられた挙動を構築することもできる。
【０２００】
例えば、ユーザは、アクション・ビルダの入力パラメータを介して、生成されたアクションが、最初に呼び出された下位アクションが正常に完了した状態を取得したときにそのアクションを完了とマークするための挙動を持つように特定することができる。本発明におけるアクション・ビルダは、完了状態にある少なくとも１つの正常に終了した下位アクションの有無をテストする条件を持つシステム論理オブジェクトに規則を付加することによって、この挙動を生成する。この規則でのアクションは、その場合、そのアクションが完了していることを反映するようにシステム論理オブジェクトの状態を設定することである。
【０２０１】
アクション・ビルダは、そのアクションの挙動とそのアクション呼び出しの挙動とを一括して表すいくつかの別個の挙動を構築することもできる。事例７は図１９と共に、３つの異なる表現でアクション・ビルダの一例の生成済み出力を示すものである。第１の例は、Ｊａｖａ表現である。第２の例は、概略図（図１９）を示し、第３の例は、ＩＬＯＧ規則エンジンに適した、規則言語形式での挙動を示す。アクション・ビルダが、諸挙動の式をサポートする任意の言語で書かれたシステム論理オブジェクトに挙動を生成できることに留意することは重要である。
【０２０２】
【表２５】
2005510790.tif 000032
【０２０３】
図１９に、アクション・ビルダによって作成されたシステム論理オブジェクト中のアクション（７６）の図を示す。この生成済みアクションは、他の機能単位への呼び出しからなる。この図では、各呼び出しも、そのアクションがそこで動作する、そのオブジェクトを表すオブジェクトへのリンクを持つ。
【０２０４】
接合ビルダ
接合ビルダは、システム論理オブジェクトで接合を構築する。ビルダ入力を満たすステップは、基本規則ビルダの条件入力を満たすステップに類似しているが、ユーザが、その接合がＡＮＤ、ＯＲ、ＮＡＮＤ、ＮＯＲ、ＸＯＲ型の接合のいずれであるかも特定する点で異なる。本発明の一実施形態では、接合ビルダはＡＮＤとＯＲの場合をサポートする。
【０２０５】
本発明では、接合は、接合オブジェクトで動作する、特種な規則として実装される。接合オブジェクトは接合の状態情報を維持し、接合規則の挙動は、その接合の条件が満たされたときに作動するようにセットアップされる。接合規則は、それが実行されると、接合オブジェクトの状態をアクティブな状態を反映するように設定する。システム論理オブジェクト中の他の挙動は、それらの条件中で接合の状態を参照することができる。以下のコード例は、システム論理オブジェクト中の接合論理の一実装形態を示す。このコードは、接合ビルダによって生成されたものである。
【０２０６】
【表２６】
2005510790.tif 000033
【０２０７】
代替として、接合ビルダは、この種の挙動の式をサポートする言語で接合挙動の他のソース表現を生成することもできる。例えば、接合ビルダは、以下のＪａｖａ表現を生成することもできるはずである。
【０２０８】
【表２７】
2005510790.tif 000034
【０２０９】
図２０および図２１に、事例７の論理例で接合ビルダを使用した結果を示す。接合ビルダを使用して、図２０でＡＮＤ型接合が構築される。図２１では、その接合の「型」ビルダ入力パラメータが、その後の再生成で変更されてＯＲ接合が生成される。接合ビルダはどちらの場合にも、同じ名前、ｊｕｎｃｔｉｏｎ１を持つようにその接合を構築するので、ｒｕｌｅ２を構築する基本規則ビルダは、その構築挙動を、第２のシナリオでのＯＲ接合に接続するように自動的に適応させることができる。
【０２１０】
リンクされた規則セット・ビルダ
リンクされた規則セット・ビルダは、参照された生成モデルからの生成済みシステム論理オブジェクトを、現在の生成モデルのシステム論理オブジェクトにアセンブルする。
【０２１１】
リンクされた規則セット・ビルダはいくつかの入力を持つ。第１の入力は、参照された生成モデルの名前と、その参照されたモデルに関連付けられた、その再生成に使用される１つまたは複数のプロファイルの名前を特定するためのものである。第２の入力は、現在のシステム論理オブジェクト（すなわち規則セット）の名前である。最後に、参照された生成モデルによって生成されたアセンブル済みシステム論理オブジェクトのローカル名の入力がある。このローカル名は、アセンブル済みシステム論理オブジェクトが現在のシステム論理オブジェクトに入れられたときに使用される。
【０２１２】
リンクされた規則セット・ビルダは、参照された生成モデルを呼び出し、特定されたプロファイルに従ってその出力オブジェクトを再生成し、生成済み出力オブジェクトを返す再生成エンジンでＡＰＩを呼び出すというそれ自体の再生成タスクを実施する。
【０２１３】
この時点で、リンクされた規則セット・ビルダは、返された出力オブジェクト中の名前付きシステム論理オブジェクトを発見し、それを現在の生成モデルのシステム論理オブジェクトに「アセンブル」する。このアセンブリ・プロセスには、「アセンブルされる」システム論理オブジェクトを一意の名前に関連付け、この「子」オブジェクトへの参照を宣言する現在のシステム論理オブジェクト中にデータを構築することが伴う。
【０２１４】
ユーザが生成モデルにリンクされた規則セット・ビルダ呼び出しを付加すると、後続のビルダによって作成された規則とアクションを、その子「アセンブル済み」システム論理オブジェクトのアクションを呼び出すようにセットアップさせることが可能になる。これは、その子システム論理オブジェクトのフェーズを特定の状態に設定する機能を呼び出すことを含む。例えば、ビルダによって、その子オブジェクトのフェーズを「実行」に設定するように親オブジェクトの基本規則を構築することもできるであろう。この設定のために、システム論理オブジェクトの組み合わされたアセンブリの実行中に、親オブジェクトの規則が作動し、その子オブジェクトのフェーズを「実行」に設定したときに、そのフェーズに関連付けられた子オブジェクトの規則挙動のすべてが、可能な実行の有無をテストされることになる。
【０２１５】
すべてのビルダに関する注釈
本発明で説明したすべてのビルダは、ユーザが、単一の生成モデル内で複数のシステム論理オブジェクトを作成できるようにするものである。本発明は、システム論理オブジェクトを作成するための１組の公知のビルダの機能も開示する。本発明は、さらに、ユーザが、上記その他のビルダの生成済み出力と対話する任意の数の追加ビルダを作成できるようにする機能も提供する。
【０２１６】
生成済みシステム論理オブジェクトでの言語表現の独立性
本発明では、システム論理オブジェクトを構築するビルダは、システム論理オブジェクトの表現を、Ｒｅｔｅアルゴリズムをサポートする前向き連鎖推論エンジンにおける実行のための規則セットとして作成するように構成される。一実施形態では、ビルダは、その規則の構文中にＪａｖａクラスへの参照を構築する。その推論エンジンは、それらのＪａｖａクラスをロードし、規則、接合、アクション、フェーズ、変数などのオブジェクトを表すためにそれらのインスタンスを作成する。
【０２１７】
本発明のビルダは、代替として、システム論理オブジェクトおよびそれらのエンティティを、システム論理オブジェクトで表現された挙動、機能、構造、状態データの種類をサポートすることのできる任意の言語表現で生成することもできる。これは、一括してシステム論理オブジェクトを構築するビルダ入力の１つまたは複数での単一のパラメータ入力値を変更することによって、ビルダが、全く異なる言語表現で同じシステム論理オブジェクトを生成できることを意味する。これらの言語表現には、Ｊａｖａ、Ｃ＋＋、Ｃ＃などのコンパイル言語、ＩＢＭのＷＳＦＬ（Ｗｅｂサービス・フロー言語）やマイクロソフトのＸＬＡＮＧ、ＢＥＡのＸＯＣＰなどのインタープリート言語、さらには前述したマイクロソフトのインテンショナル・プログラミング・ソース・ツリーなどの高水準言語ツリー表現が含まれる。
【０２１８】
生成モデルにおけるＢｕｉｌｄｅｒＣａｌｌの「多重定義」を伴う使用法シナリオ
生成モデルでビルダを無効、有効にできることを利用する本発明の効果的な一使用方法は、「多重定義」と呼ばれるものである。多重定義は、生成モデルに複数のＢｕｉｌｄｅｒＣａｌｌを付加し、ビルダ入力の一部を各呼び出し中でセットアップし、それによって同じ名前を持つ生成済み出力オブジェクトが生み出されるようにする実施方法である。同じ「ｒｕｌｅ２」という２つのチェーン規則ＢｕｉｌｄｅｒＣａｌｌが作成される以下の例を考察する。
【０２１９】
システムは、ユーザが生成モデルで両方のＢｕｉｌｄｅｒＣａｌｌを作成することを許容する。ユーザは、それら両方を作成すると、ＢｕｉｌｄｅｒＣａｌｌの一方を無効にし、他方を有効にする。任意の時点においては、ＢｕｉｌｄｅｒＣａｌｌの一方だけが常に有効とされており、生成されたオブジェクト中で名前の衝突は生じない。両方のＢｕｉｌｄｅｒＣａｌｌが有効に設定された場合、名前が衝突する可能性があり、ビルダはこのエラーを生じる可能性のあるシナリオを処理するはずである。
【０２２０】
この時点で、ユーザはさらに続けてＢｕｉｌｄｅｒＣａｌｌを付加する。それらのビルダは、生成済み出力オブジェクト中のエンティティへの参照を行うことができる。例えば、ｒｕｌｅ３という名前の基本規則ビルダ呼び出しを付加し、そのビルダ入力を介して、その規則が、ｒｕｌｅ２がアクティブな場合に限り作動するように特定することもできるであろう。
【０２２１】
ユーザは、戻ってその２つのｒｕｌｅ２チェーン規則の有効、無効状態を切り換えることができ、システムはこれらの規則の全く異なる実装を構築する。さらに、ｒｕｌｅ３を構築する基本規則ビルダは、その後、どちらでもその時点で存在するｒｕｌｅ２任意の実装への参照を行うように更新される。
【０２２２】
従来技術の明示的オブジェクト・モデル化手法では、ユーザは、２つのオプションの間で選択しなければならない。すなわち、所望のシステム論理オブジェクトの２つの別個の実装を作成し、一方はｒｕｌｅ２を１つの方法で実装し、他方はｒｕｌｅ２を別の方法で実装するか、あるいは第２のオプションとして、ユーザが２つのｒｕｌｅ２を含む単一オブジェクトを構築することもできる。
【０２２３】
後者のシナリオでの問題は、ユーザが、その場合、名前の衝突を防ぐために、そのｒｕｌｅ２の２つの実装に何らかの一意の命名を行う必要があることである。ユーザは、例えば、それらの規則にｒｕｌｅ２ａ、ｒｕｌｅ２ｂと命名することもできる。しかし、この手法は問題を生じる。というのは、次には、１つがｒｕｌｅ２ａを参照し、１つがｒｕｌｅ２ｂを参照する、ｒｕｌｅ３の２つの実装が必要になるからである。ユーザは、ｒｕｌｅ３ａ、ｒｕｌｅ３ｂを作成することもできる。多くの異なる実装を実装する「スーパー・オブジェクト」を作成しようとするこの構築手法は、「コード爆発」を引き起こす。
【０２２４】
本明細書で述べる「多重定義」手法は、類似の、異なるオブジェクトの複数の別個の実装を作成する必要も、内部で異なる構成を実装しようとし、結局は内部コード爆発を引き起こす大規模なパラメータ化「スーパー・オブジェクト」を構築する必要もなくする。
【０２２５】
図２２、２３、２４に、それぞれがｒｕｌｅ２と命名された、チェーン規則ビルダへの２つのＢｕｉｌｄｅｒＣａｌｌを含む生成モデルを示す。図２２には、一方はそれが有効であることを示すために強調表示され、他方はそれが無効であることを示すためにぼかし表示された、ｒｕｌｅ２の２つのインスタンスを表示する本発明の一実施形態が示されている。各ビルダ呼び出しは、全く異なる規則の作成を実施するように別個に構成される。また、生成モデルは、ｒｕｌｅ３という名前の基本規則へのビルダ呼び出しも含む。ユーザは、２つのチェーン規則ＢｕｉｌｄｅｒＣａｌｌの有効および無効状態を切り換え、しかも、生成済みシステム論理オブジェクトの有効な実装を生成することができる。図２３には、有効にされたｒｕｌｅ２の第１のインスタンスを示す。図２４には有効にされたｒｕｌｅ２の第２のインスタンスを示す。
【０２２６】
結論
したがって、以上、システム論理オブジェクトを作成する方法と装置を、１つまたは複数の実施形態と併せて説明した。本発明は添付の特許請求の範囲およびその均等物の全範囲によって定義されるものである。
【図面の簡単な説明】
【０２２７】
【図１】本発明の一実施形態による再生成システムの主要コンポーネントを示す構成図である。
【図２】再生成のプロセスを示す流れ図である。
【図３Ａ】再生成の主要コンポーネントがどのように相互に対話するかを詳細に示す構成図である。
【図３Ｂ】図３Ａに示すシステムの再生成のプロセスを詳細に示す流れ図である。
【図３Ｃ】ＧｅｎＨａｎｄｌｅｒコンポーネントによるビルダ・インスタンス化のプロセスを示す流れ図である。
【図４】本発明の一実施形態による、再生成システムの各コンポーネント間の参照関係および包含関係を示す構成図である。
【図５】本発明の一実施形態による、デザイナ・アプリケーションの主要コンポーネント、およびそれらと再生成システムの他のコンポーネントとの関係を示す構成図である。
【図６】デザイナ・アプリケーションを使用するプロセスを示す流れ図である。
【図７Ａ】デザイナ・アプリケーションの主要コンポーネントがＢｕｉｌｄｅｒＣａｌｌを処理するためにどのように機能するかを示す構成図である。
【図７Ｂ】図７Ａに示すシステムを示す流れ図である。
【図８】ＧｅｎＥｌｅｍｅｎｔおよびＤｏｍａｉｎＯｂｊｅｃｔがデザイナ・アプリケーションでどのように表示され得るかを示す図である。
【図９】本発明の一実施形態による、カストマイザ・アプリケーションの主要コンポーネント、およびそれらと再生成システムの他のコンポーネントとの関係を示す構成図である。
【図１０】カストマイザ・アプリケーションを使用するプロセスを示す流れ図である。
【図１１】本発明の一実施形態による規則セット（システム論理オブジェクト）の主要コンポーネントを示す図である。
【図１２】本発明の一実施形態において、規則セット・ビルダによって生成された例示的規則セットのビューを示す図である。
【図１３】本発明の一実施形態において、規則ビルダによって生成された別の例示的規則のビューを示す図である。
【図１４】本発明の一実施形態において、規則ビルダによって生成されたフェーズを含む例示的規則のビューを示す図である。
【図１５】図１３に示す規則を使用して、チェーン規則ビルダによって生成された例示的規則のビューを示す図である。
【図１６】図１５に示す規則を使用して、チェーン規則ビルダによって生成された例示的規則のビューを示す図である。
【図１７】本発明のチェーン規則ビルダの自動参照適合機能を示すためにチェーン規則ビルダによって生成された例示的規則のビューを示す図である。
【図１８】自動参照適合のプロセスを示す流れ図である。
【図１９】本発明のアクション・ビルダによって構築されたアクションの一例を示す図である。
【図２０】本発明の接合ビルダによって構築された「ＡＮＤ」接合を用いたアクションの一例を示す図である。
【図２０】本発明の接合ビルダによって構築された「ＯＲ」接合を用いたアクションの一例を示す図である。
【図２２】一方が無効に設定され、他方が有効に設定された、ｒｕｌｅ２という名前のチェーン規則ビルダ呼び出しの２つのインスタンスを示す、生成モデルのＢｕｉｌｄｅｒＣａｌｌＬｉｓｔを示す図である。
【図２３】有効にされたｒｕｌｅ２ビルダ呼び出しの第１のインスタンスを示す生成済みシステム論理オブジェクトの規則ビューを示す図である。
【図２４】チェーン規則ＢｕｉｌｄｅｒＣａｌｌを切り換えることによる影響を表す規則ビューを示す図である。
【図１】
2005510790.tif 000035
【図２】
2005510790.tif 000036
【図３Ａ】
2005510790.tif 000037
【図３Ｂ】
2005510790.tif 000038
【図３Ｃ】
2005510790.tif 000039
【図４】
2005510790.tif 000040
【図５】
2005510790.tif 000041
【図６】
2005510790.tif 000042
【図７Ａ】
2005510790.tif 000043
【図７Ｂ】
2005510790.tif 000044
【図８】
2005510790.tif 000045
【図９】
2005510790.tif 000046
【図１０】
2005510790.tif 000047
【図１１】
2005510790.tif 000048
【図１２】
2005510790.tif 000049
【図１３】
2005510790.tif 000050
【図１４】
2005510790.tif 000051
【図１５】
2005510790.tif 000052
【図１６】
2005510790.tif 000053
【図１７】
2005510790.tif 000054
【図１８】
2005510790.tif 000055
【図１９】
2005510790.tif 000056
【図２０】
2005510790.tif 000057
【図２１】
2005510790.tif 000058
【図２２】
2005510790.tif 000059
【図２３】
2005510790.tif 000060
【図２４】
2005510790.tif 000061
【国際調査報告】
2005510790.tif 000062