【誤訳訂正書】
【提出日】平成22年5月24日(2010.5.24)
【誤訳訂正１】
【訂正対象書類名】明細書
【訂正対象項目名】全文
【訂正方法】変更
【訂正の内容】
【書類名】          明細書
【発明の名称】      自動ソフトウェア作成システム
【特許請求の範囲】
【請求項１】
検証された形式仕様から、コンピュータプログラムを自動的に生成するためにメモリを有するコンピュータを使用するプロセスであって、前記形式仕様は、前記コンピュータプログラムの望ましい構造及び動きとそのユーザインタフェースを定義し、前記形式仕様は形式言語で書かれており、前記コンピュータプログラムの前記望ましい構造及び動きを定義している必要要件データを入力しているアナリストによって作成された前記コンピュータプログラムの概念モデルにおいて概念を表現しており、前記プロセスは、
Ａ）前記形式仕様の全てのエレメントについての適切な必要要件データで明確にされる変換構造あるいはコード生成構造を作成するために、前記概念モデルから生成された前記検証された形式仕様を保存する高レベルリポジトリから必要要件データを検索し、前記コード生成構造で前記検索された必要要件データを保存することによって、前記メモリにおいて保存された変換構造と呼ばれるコード生成構造の例を明確にすることと、なお、前記変換構造は、前記コンピュータプログラムの前記ソースコードを書き込むために必要とされたビルディングブロックであるソースコードコンポーネントを生成する方法を含むコード生成構造を備えており、メモリにおける前記変換構造あるいはコード生成構造は、前記形式仕様から引き出された必要要件データを保存し、前記必要要件データで明確にされたソースコードコンポーネントを生成する１つまたは複数のコード生成方法を含む、クラスデータ構造の形を取っており、前記コード生成構造は、コンピュータによってコンパイルされ、実行されるときに、前記コンピュータが前記検証された形式仕様で定義された前記構造及び動きを有するように制御する前記コンピュータプログラムのためのソースコードを生成するために必要とされたすべての変換構造を備えており、
Ｂ）前記必要要件データで明確にされたソースコードコンポーネントを生成するために必要とされたオーダで、前記変換構造の前記コード生成方法を呼び出すために、メモリにおいて保存された前記変換構造のうちの１つであるコード生成クラスにおいて１つまたは複数の方法を実行し、グローバルインタラクション実行コンポーネントを生成し、グローバルインタラクションサーバコンポーネントを生成し、グローバル機能コンポーネントを生成し、スタンダードコンポーネントを生成し、自動的に書き込まれるべき前記コンピュータプログラムを備えるファイルに対して前記ソースコードコンポーネントを書き込むことと、
を備えるプロセス。
【請求項２】
前記変換構造は、ソースコードを書き込むために必要とされたすべての変換構造を備えており、コンピュータによってコンパイルされ実行されるときに、実行モデルにしたがって、下記の機能、
Ａ１）ユーザがログインし、自身を識別できることによって、ダイアログを提供すること、
Ａ２）前記ログインしたユーザが見ることができるオブジェクト属性のセットのみと、ログインした前記ユーザが見るあるいは作動させることができるサービスのみと、を表示するオブジェクトシステムビューを、ログインした前記ユーザに対して提供することと、
Ａ３）ログインしたユーザがサービスを実行するオブジェクトを識別し、動作されているサービスのサービス引数を導入するために、そして、前記引数を含んでいるサービス起動メッセージを作り、前記サービスを実行する前記オブジェクトサーバに対して前記サービス起動メッセージを送信するために、情報を提供できるダイアログをディスプレイすることと、
Ａ４）前記サービスの実行によって引き起こされるいずれの状態遷移も前記形式仕様において定義されている有効な状態遷移であるということを検査するために前記オブジェクトサーバを制御することと、
Ａ５）前記形式仕様において規定されたいずれの前提条件の満足を検査するために、前記オブジェクトサーバを制御することと、前提条件が満たされず、あるいは前記サービスの実行によって引き起こされる前記状態遷移が有効ではない場合には、前記サービス起動メッセージを無視することと、
Ａ６）引き起こされる前記状態遷移が有効であり、その前提条件が、前記サービスによって必要とされるすべての評価計算を作り、前記サービスが作用するときに属性の値を変更することによって、満たされる場合には、前記サービスを実行するために前記オブジェクトサーバを制御することと、
Ａ７）ステップA６で実行された前記サービスによって引き起こされた前記オブジェクトの状態の前記変更は完全性制約に反しないということを確実にするために、完全性制約を検査するように前記オブジェクトサーバを制御することと、もし完全性制約に反している場合には、ステップA6のサービスの実行によって引き起こされた状態の変化は、前記サービスの実行前のものに前記システムの状態を変更するように逆行することと、
Ａ８）いずれのトリガー条件が満たされているかを決定するためにトリガを特定する条件−動作ルールを検査するために前記オブジェクトサーバを制御することと、満たされている場合には、前記条件−動作ルールにおいて特定されたサービスを実行させることと、
を実行させる、
請求項１に記載のプロセス。
【請求項３】
前記変換構造あるいはコード生成構造は、コンピュータのメモリにおいて保存された下記のオブジェクト、
サーバコンポーネントを生成するために必要とされた情報を保存するサーバクラス、
グローバルインタラクションのためのサーバコンポーネントを生成するために必要とされた情報を保存する、グローバルインタラクションサーバクラス、
実行コンポーネントを生成するために必要とされた情報を保存する分析クラス、
グローバルインタラクション、グローバルトランザクション式、及び引数のリストの形でのグローバルインタラクションのための実行コンポーネントを生成するために必要とされた情報を保存する、グローバルインタラクション分析クラス、
継承階層のための実行コンポーネントを生成するために必要とされた情報を保存する、継承階層分析クラス、
照会コンポーネントを生成するために必要とされた情報を保存する照会クラス、
Ｔコンポーネントを生成するために必要とされた情報を保存するＴクラス、
Ｃコンポーネントを生成するために必要とされた情報を保存するＣクラス、
ＣＣコンポーネントを生成するために必要とされた情報を保存するＣＣクラス、
Ｐコンポーネントを生成するために必要とされた情報を保存するＰクラス、
ＰＬコンポーネントを生成するために必要とされた情報を保存するＰＬクラス、
前記概念モデルにおいて全てのクラスの全てのサービスのための前記引数に関する情報を保存する、引数リストクラス、
前記概念モデルにおいて全てのクラスの前記識別機能に関する情報を保存する、分析クラスリストクラス、
イベント、共有イベント、トランザクション、及びオブジェクトインタラクション（以下イベントクラスと呼ばれる）、を履行するために実行コンポーネントにおいてサービスを解決するために必要とされた方法を生成する、１つまたは複数のクラス、
前提条件、静的制約、動的制約が前記概念モデル（以下補助方法クラスと呼ばれる）において存在する場合には、少なくとも前提条件クラス、静的制約クラス、動的制約クラスを履行するために、実行コンポーネントと、継承階層のための実行コンポーネントの両方においてサービスを解決するのに必要とされた前記補助方法を生成する１つまたは複数のクラス、
照会及びＴコンポーネントにおいて必要とされる方法を生成する、ＴおよびＱ方法クラス、
継承特有方法を生成する、継承方法クラス、
コード生成プロセスを制御し履行する、コード生成クラス、
を備えている、
請求項１に記載のプロセス。
【請求項４】
前記変換構造あるいはコード生成構造仕様を表現するために前記概念モデル及び前記形式仕様において定義される、クラス、グローバルトランザクション、及びグローバル機能、から情報を検索することを備えており、クラスから情報を検索するステップは、前記形式仕様において定義される各クラスから前記下記の情報を検索し、前記適切な変換構造クラスにおける前記適切なデータフィールドをポピュレートするためにそれを使用する、ステップをさらに備えており、情報は、
名前、
定数属性、
可変の属性、
派生属性、
識別機能、
名前を含んでいるイベント、名前とタイプを含んでいる前記イベントの引数、前提条件式、
各トランザクションについて、名前とタイプ、前提条件式、そしてトランザクション式を含んでいるトランザクションと、各引数について、名前とタイプを含んでいる引数と、
評価式、
初期状態、最終状態、サービス名、有効エージェント、そして遷移条件式を含んでいる状態遷移、
静的制約式、
動的制約式、
トリガー条件式、
アンセスタークラス名、
名前、専門化条件式、前提条件再定義、そして評価再定義を含んでいる専門化クラス、
関係するクラス、濃度、静的あるいは動的、そして役名を含んでいるアグレゲーション関係、
前記フィルタについて特定された、いずれの名前、フィルター変数、及び／または順序基準を含むいずれのフィルタを含んでいる母集団選択パターン、
を備えており、
前記検証された形式仕様において定義されたグローバルインタラクションから情報を検索するステップは、前記形式仕様において定義される各グローバルインタラクションから下記情報を検索するステップをさらに備えており、情報は、
名前、
各引数の名前及びタイプを含んでいる引数、
グローバルインタラクション式、
を備えており、
前記検証された形式仕様において定義されたグローバル機能から情報を検索するステップは、前記形式仕様において定義された各グローバル機能から下記情報を検索するステップをさらに備えており、情報は、
名前、
リターンタイプ、
各引数のための名前及びタイプを含んでいる引数、
を備えている、
請求項３に記載のプロセス。
【請求項５】
前記コード生成クラスは、前記形式仕様において定義された前記クラスの前記オブジェクトから抽出され、前記変換構造あるいはコード生成クラスを定義している適切なオブジェクトにおいて保存された、必要要件データとしてコード生成構造あるいは変換構造のリストを保存しており、ステップＢは、下記のステップ、
コンポーネントとその属性と方法を生成するために必要な情報を維持し、それぞれの要素のコード生成方法を呼び出す、前に説明されたインスタンスのリストを通してループすることと、
グローバルインタラクション実行ソースコードコンポーネントを生成することと、
グローバルインタラクションサーバーソースコードコンポーネントを生成することと、
グローバル機能ソースコードコンポーネントを生成することと、
スタンダードソースコードコンポーネントを生成することと、
を備えている、請求項４に記載のプロセス。
【請求項６】
前記形式仕様における各クラスは、変換構造クラスのいくつかの例の方法によって生成された、いくつかのソースコードコンポーネントをもたらしており、各前記クラスから生じる変換構造クラスオブジェクトの様々なインスタンスの前記コード生成方法は、下記の機能を実行するソースコードコンポーネントを生成しており、
サーバクラスオブジェクトの形での各変換構造は、サーバコンポーネントのソースコードを生成するために前記サーバクラスで保存された情報を使用するコード生成方法を有しており、
グローバルインタラクションサーバクラスオブジェクトの形での各変換構造は、前記形式仕様において定義されたグローバルインタラクションについての方法を備えるインタフェースを用いて前記概念モデルにおいて定義されるグローバルインタラクションを履行する実行コンポーネントのソースコードを生成するために、前記グローバルインタラクションサーバクラスオブジェクトにおいて保存された情報を使用するコード生成方法を有しており、
分析クラスオブジェクトの形での各変換構造は、前記クラスの前記署名のサービスについての方法を備える前記クラスについての実行コンポーネントを履行するソースコードを生成するために、前記分析クラスオブジェクトにおいて保存された情報を使用するコード生成方法を有しており、なお、各方法は、実行モデルにしたがって前記サービスを実行するソースコードを生成するように構成されており、
グローバルインタラクション分析クラスオブジェクトの形での各変換構造は、前記形式仕様において特定されたグローバルトランザクションにおいて定義されるオブジェクト間のグローバルインタラクションについての方法を提供する実行コンポーネントのソースコードを生成するために、前記グローバルインタラクション分析クラスオブジェクトにおいて保存された情報を使用するコード生成方法を有しており、
承継階層分析クラスオブジェクトの形での各変換構造は、前記継承階層のための単独で特別な実行コンポーネントにグループ化される実行コンポーネントのグループの一部である実行コンポーネントを生成するために、前記継承階層分析クラスオブジェクトにおいて保存された情報を使用するコード生成方法を有しており、
照会クラスオブジェクトの形での各変換構造は、前記コンピュータプログラムのユーザが前記クラスの前記母集団を照会することを可能にする照会コンポーネントのソースコードを生成するために、前記照会クラスオブジェクトにおいて保存された情報を使用するコード生成方法を有しており、
Tクラスオブジェクトの形での各変換構造は、その項目がTコンポーネントであるコレクションを履行する照会コンポーネントを生成する前記コード生成方法の派生属性の値を計算する方法と同様に、前記クラスの対応するクラスのインスタンスの前記定数の及び可変の属性のコピーを保存するために使用されるTコンポーネントを生成するコード生成方法を有し、
Cクラスオブジェクトの形での各変換構造は、前記初期値を用いて前記対応クラスのインスタンスの属性をポピュレートするように機能するCコンポーネントのソースコードを生成するために、対応クラスの定数の及び可変の属性の初期値に関する前記Cクラスオブジェクトにおいて保存された情報を使用する生成方法を有しており、
CCクラスオブジェクトの形での各変換構造は、そのメンバーがCコンポーネントであるコレクションを履行し、そして一対の、前記コレクションに対してアイテムを加えそして得るためにCコンポーネントに従う方法と、前記コレクションにおいて項目の数を得る方法とを提供し、CCコンポーネントの前記ソースコードを生成するために、前記形式仕様において定義される一時的あるいは永久的な条件に基づいた特殊化に関して前記CCクラスオブジェクトにおいて保存された情報を使用するコード生成方法を有しており、
Pクラスオブジェクトの形での各変換構造は、それのインスタンスを作成しているときに前記対応クラスの定数の及び可変の属性を初期化するように機能するPコンポーネントのソースコードを生成するために、前記対応クラスの定数の及び可変の属性を初期化するために必要とされる値に関する前記Pクラスオブジェクトにおいて保存された情報を使用するコード生成方法を有しており、
PLクラスオブジェクトの形をとっている各変換構造は、Pコンポーネントのコレクションを履行するように機能し、そして、前記コレクションから項目を追加しあるいは取得する、前記コレクションにおいて項目の数を得る方法を提供する、PLコンポーネントのソースコードを生成するために、Pコンポーネントのコレクションに関する前記PLクラスにおいて保存された情報を使用するコード生成コンポーネントを有しており、
引数リストクラスオブジェクトの形を取っている各変換構造は、各クラスの各サービスの引数を提供するために、前記引数リストクラスオブジェクトにおいて保存された情報を使用するコード生成コンポーネントを有しており、
分析クラスリストクラスオブジェクトの形での各変換構造は、それらが作成されるように前記クラスのインスタンスについての前記識別機能情報を提供するソースコードを生成するために、前記概念モデルにおける各クラスの前記識別機能に関する前記分析クラスリストクラスオブジェクトにおいて保存された情報を使用するコード生成方法を有しており、
１つまたは複数のイベントクラスオブジェクト、共有イベントクラスオブジェクト、トランザクションクラスオブジェクト、インタラクションクラスオブジェクト、の形をとっている各変換構造は、イベント、共有イベント、トランザクション及びオブジェクトインタラクションを履行する実行コンポーネントにおいてサービスを解決するソースコードコンポーネントを生成するために、前記クラスオブジェクトにおいて保存された情報を使用するコード生成コンポーネントを有しており、
１つまたは複数の補助方法クラスオブジェクトの形を取っている各変換構造は、前提条件、静的制約、動的制約が前記概念モデルにおいて存在している場合には、少なくとも前提条件クラス、静的制約クラス、動的制約クラスを履行するように、実行コンポーネントおよび継承階層のための実行コンポーネントの両方におけるサービスを解決するソースコードコンポーネントを生成するために、前記補助方法クラスオブジェクトにおいて情報を使用するコード生成方法を有しており、
T＆Qクラスオブジェクトの形を取っている各変換構造は、照会を履行するソースコードコンポーネントとTコンポーネントを生成するために、前記T＆Qオブジェクトに保存された情報を使用するコード生成方法を有しており、
継承方法クラスオブジェクトの形を取っている各変換構造は、前記形式仕様において対応するクラスについて特定された継承関係に対する特有の方法を履行するために、ソースコードコンポーネントを生成するために前記継承方法クラスオブジェクトにおいて保存された情報を使用するコード生成方法を有している、
請求項５に記載のプロセス。
【請求項７】
Ｃ）前記コンピュータプログラムの前記望ましい構造及び動きを定義する必要要件データを入力するために前記コンピュータプログラムの設計者が使用する図及びテキストインタラクティブダイアログをディスプレイするためにコンピュータを制御することと、なお、前記図及びテキストインタラクティブダイアログは、前記形式仕様を書き込むように使用されている前記形式言語でのクラス定義を満たすのに関係のある情報のみであり、
Ｄ）文法を定義するシンタックスとセマンティクスのルールを有する形式言語で書かれた前記形式仕様として、前記図及びテキストインタラクティブダイアログを使用して入力された前記必要要件データを保存することと、
Ｅ）それが正確で完全であるということを確実にするために前記形式仕様を検証するためにシンタックスとセマンティクスの前記ルールを使用するようにコンピュータを制御することと、
をさらに備えている請求項１に記載のプロセス。
【請求項８】
前記図及びテキストインタラクティブダイアログは、クラス、クラス間の関係、グローバルトランザクションやグローバル機能、及びビューを定義している必要要件データを前記設計者が入力することを可能にするように構成されており、前記図及びテキストインタラクティブダイアログは、
属性、
サービス、
派生、
制約、
トランザクション式、
トリガー、
ディスプレイセット、
フィルター、
母集団選択パターン、
状態遷移図、
名前、
別名、
デフォルト母集団選択インターフェースパターン、
を定義している必要要件データを前記設計者が入力することを可能にするようにさらに構成されている、請求項７に記載のプロセス。
【請求項９】
前記図及びテキストインタラクティブダイアログは、
名前、
定数、変数、派生の形式データタイプ、
データタイプ、
デフォルト値、
属性がクラスのオブジェクトを区別する識別子であるか、
長さ、
オブジェクトが形成されるとき属性が必要か否か、
ＮＵＬＬ値が属性に割り当てられることができるか、
どのように属性の値がイベントの発生によって変化するか式として定義する評価についての情報、
前記属性に関係する対応するサービス引数に適用されるユーザインタフェースパターンについてのオプション情報、
等の、各サービスについて定義している必要要件データを入力することによって、前記サービスについて前記設計者が定義することができるものである、請求項８に記載のプロセス。
【請求項１０】
前記図及びテキストインタラクティブダイアログは、
サービスがイベントあるいはトランザクションであるか、
名前、
前記サービスがイベントである場合には前記イベントが共有されるか、
前記サービスがトランザクションである場合にはサービスの構成を表現するトランザクション式、
引数のリスト、各引数について、その名前、データタイプ、ＮＵＬＬが有効な値と認められるか、引数がコレクションにおいてオブジェクトの一つのセットを表すか、デフォルト値、別名、導入パターン、母集団選択パターン、定義された選択パターンおよび依存パターンを含んでいる引数に関係するユーザインタフェースパターン、
等の各サービスについて定義している必要要件データを入力することによって、前記サービスについて前記設計者が定義することができるものである、請求項９に記載のプロセス。
【請求項１１】
前記図及びテキストインタラクティブダイアログは、設計者が派生、制約、トリガー、ディスプレイセット、フィルター、母集団選択ユーザインタフェースパターンを定義している必要要件データを入力することによって各クラスをさらに定義することができ、各派生は、条件式の組のリストを特定し、全ての条件の下で適用される式を特定し、そして各制約は、式に設計者が特定するエラーメッセージを加えたもので、それは、前記設計者によって特定された前記制約が反されるときにディスプレイされるものであり、各トリガーは、自分自身により特定されるトリガーターゲット、クラスまたはオブジェクト、トリガー条件、そして前記サービスを作動させるためにサービスと可能なエージェントのリストとから成るトリガーされた動作、および関連するサービスの引数と関連する値のリストにより構成されることができ、そして各ディスプレイセットは、どのクラスの属性がユーザにとって可視であるかを定義し、各フィルタは、前記式を定義するのに便利である補助変数のリストと式から成り、前記母集団選択ユーザインタフェースパターンは、ディスプレイセットとフィルタとによって定義されており、前記図及びテキストインタラクティブダイアログは、前記設計者が、前記クラスにおけるオブジェクトの前記状態を変更できる動作の発生のときに各遷移が生じる、クラスとクラスの間の状態と変化のセットである各クラスについての状態遷移図を入力することを可能にするためものであり、前記動作は、動作が実行されることができる前に満たされる必要がある式として前記設計者によって入力される前提条件を有することができる、請求項１０に記載のプロセス。
【請求項１２】
前記図及びテキストインタラクティブダイアログは、前記設計者が集合あるいは継承であることができるクラス間の前記関係を定義している必要要件データを入力することができるためのものであり、各集合関係は、前記集合関係においてオブジェクトの構成を特定し、そして、濃度を特定し、集合が静的であるか動的であるか（、集合が包括的であるか参照的であるか、集合が識別依存を有するか、および集合が複数の値であるときには分類項を有するか、という必要要件データによって示されており、そして各継承関係は、オブジェクトの特殊化を示し、親クラスの名前、子クラスの名前、および特殊化が一時的であるか永久的であるかを保存する前記設計者によって入力される必要要件データによって定義されており、前記特殊化が永久的である場合には、特殊化条件として定数属性に関する式を保存し、特殊化が一時的である場合には、前記必要要件データは、条件もしくは、子の役割を有効／無効にするイベントのリストを示し、そして
前記図及びテキストインタラクティブダイアログはまた、設計者がグローバルインタラクションの名前、式、および引数のリストを含んでいるグローバルトランザクションのリストを必要要件データとして入力することができ、また、名前、返還された値のデータタイプ、引数のセットを含んでいるグローバル機能のリストを入力することができるためのものである、請求項１１に記載のプロセス。
【請求項１３】
前記コンピュータプログラムの望ましいシステム論理及びユーザインタフェースを定義する必要要件データを入力するために前記コンピュータプログラムの設計者が使用する図及びテキストインタラクティブダイアログをディスプレイするためにコンピュータを制御するステップと、なお、前記図及びテキストインタラクティブダイアログは前記形式仕様を書くために使用されている前記形式言語によりクラス定義を満たすことに関する情報のみを入力することができるためのものであり、
グラマーを定義するシンタックス及びセマンティックスのルールを有する形式言語で書かれた前記形式仕様として前記図及びテキストインタラクティブダイアログを使用して入力された前記必要要件データを保存するステップと、
前記検証された形式仕様を生成するため、前記形式仕様を検証するために、シンタックス及びセマンティックスの前記ルールを使用するためにコンピュータを制御するステップと、
をさらに備えている請求項５に記載のプロセス。
【請求項１４】
前記図及びテキストインタラクティブダイアログは、クラス、クラス間の関係、グローバルトランザクション、グローバル機能、及びビューを定義している必要要件データを前記設計者が入力することを可能にするように構成されており、前記図及びテキストインタラクティブダイアログは、
属性、
サービス、
派生、
制約、
トランザクション式、
トリガー、
ディスプレイセット、
フィルター、
母集団選択パターン、
状態遷移図、
名前、
別名、
デフォルト母集団選択インターフェースパターン、
を定義している必要要件データを前記設計者が入力することを可能にするようにさらに構成されている、請求項１３に記載のプロセス。
【請求項１５】
前記図及びテキストインタラクティブダイアログは、
名前、
定数、変数、派生の形式データタイプ、
データタイプ、
デフォルト値、
属性がクラスのオブジェクトを区別する識別子であるか、
長さ、
オブジェクトが形成されるとき属性が必要か否か、
ＮＵＬＬ値が属性に割り当てられることができるか、
どのように属性の値がイベントの発生によって変化するか式として定義する評価についての情報、
前記属性に関係する対応するサービス引数に適用されるユーザインタフェースパターンについてのオプション情報、
等の各属性について定義している必要要件データを入力することによって前記設計者が前記属性を定義することができる、請求項１４に記載のプロセス。
【請求項１６】
前記図及びテキストインタラクティブダイアログは、
サービスがイベントあるいはトランザクションであるか、
名前、
前記サービスがイベントである場合には前記イベントが共有されるか、
前記サービスがトランザクションである場合にはサービスの構成を表現するトランザクション式、
引数のリスト、各引数について、その名前、データタイプ、ＮＵＬＬが有効な値と認められるか、引数がコレクションにおいてオブジェクトの一つのセットを表すか、デフォルト値、別名、導入パターン、母集団選択パターン、定義された選択パターン、および依存パターンを含んでいる引数に関係するユーザインタフェースパターン、
という各サービスについて定義している必要要件データを入力することによって、前記設計者が前記サービスを定義することを可能にする、請求項１５に記載のプロセス。
【請求項１７】
前記図及びテキストインタラクティブダイアログは、前記設計者が、派生、制約、トリガー、ディスプレイセット、フィルター、母集団選択ユーザインタフェースパターン、を定義する必要要件データを入力することによって、各クラスをさらに定義することを可能にするためのものであり、
各派生は、条件式の対のリストを特定し、そして全ての条件下においてどの式が適用されるかを特定し、
各制約は、式に、前記設計者によって特定された前記制約が破られるときに表示される、前記設計者が特定する、エラーメッセージを足したものであり、
各トリガーは、自分自身により特定されるトリガーターゲット、クラスまたはオブジェクト、トリガー条件、サービスを含むトリガーされた動作、および前記サービスを作動させることの可能なエージェントのリスト、および関連するサービスの引数と関連するデフォルト値のリストにより構成されることができ、
各ディスプレイセットは、どのクラスの属性がユーザにとって可視であるかを定義し、
各フィルタは、式および前記式を定義するのに便利である補助変数のリストと式を含み、
前記母集団選択ユーザインタフェースパターンは、ディスプレイセットとフィルタとによって定義されており、
前記図及びテキストインタラクティブダイアログは、前記設計者が、前記クラスにおけるオブジェクトの前記状態を変更できる動作の発生のときに各遷移が生じる、クラスとクラスの間の状態と変化のセットである各クラスについての状態遷移図を入力することを可能にするためものであり、前記動作は、動作が実行されることができる前に満たされる必要がある式として前記設計者によって入力される前提条件を有することができる、
請求項１６に記載のプロセス。
【請求項１８】
前記図及びテキストインタラクティブダイアログは、前記設計者が、集合あるいは継承のいずれかであることができるクラス間の関係における情報を入力することができるためのものであり、
各集合関係は、集合関係においてオブジェクトの構成を特定し、そして濃度、および集合が静的であるか動的であるか、集合が包括的であるか参照的であるか、集合が識別依存を有するか、および集合が複数の値であるときには分類項を有するかを特定する、必要要件データによって示されており、
各継承関係は、オブジェクトの特殊化を示し、親クラスの名前、子クラスの名前、および特殊化が一時的であるか永久的であるかを保存する、前記設計者によって入力される必要要件データによって定義されており、前記特殊化が永久的である場合には、特殊化条件として定数属性に関する式を保存し、特殊化が一時的である場合には、前記必要要件データは、条件もしくは、子の役割を有効／無効にするイベントのリストを示し、
前記図及びテキストインタラクティブダイアログはまた、設計者がグローバルインタラクションの名前、式、および引数のリストを含んでいるグローバルトランザクションのリストを必要要件データとして入力することができ、また、名前、返還された値のデータタイプ、引数のセットを含んでいるグローバル機能のリストを入力することができるためのものである、
請求項１７に記載のプロセス。
【請求項１９】
前記実行コンポーネントによって履行されるサービスを実行する各前記方法は、下記のステップ、
リクエストされたサーバーインスタンスの存在と有効性を確かめること、
定数のおよび可変の属性の値を取り出すために、（前述の対応する照会コンポーネントで）固定層にアクセスして、メモリにリクエストされたサーバーインスタンスのコピーを生成すること、
概念モデルにおける対応する状態遷移図で特定されたように、リクエストされたサービスの状態遷移とリクエストされたサーバーインスタンスの現状を検証すること、
リクエストされたサービス前提条件の達成度を確かめること、
前記概念モデルにおいて特定されるように、サービスにより影響されたすべての評価を行うことにより、インスタンス可変の属性の値を変更し、したがって、リクエストされたサーバーインスタンスの状態を変えること、
静的と動的制約を確かめることにで、リクエストされたサーバーインスタンスにより達成された新しい状態を検証すること、
必要なときにどの動作がトリガーされるべきかを決定するために、トリガー条件をチェックすること、
リクエストされたサーバーインスタンスのすべての固定の属性のために、固定層と通信すること、
を含んでいる、請求項６に記載のプロセス。
【請求項２０】
前記形式仕様の各前記エレメントは、自動的に書き込まれるべき前記コンピュータプログラムの、概念パターンあるいは概念モデルのビルディングブロックに対応しており、前記概念モデルの前記オブジェクトモデルにおける各クラスが作られる前記ビルディングブロックは、
名前、
前記クラスにおいてオブジェクトによって使用される名づけの仕組みを特徴づける識別機能、
別名、
定数、変数、派生された属性、
プライベート及び共有イベントと、ローカルトランザクションを含んでいる１セットのサービス、
ディスプレイセット、フィルタ、及び母集団選択パターン、
それらの間の状態と遷移のセット、
保全性制約、
派生属性の値を定義する派生表現、
集合及び継承クラスのオペレータ、
を備えており、前記概念モデルの前記動的モデルのコンポーネントを構成するために、前記アナリストによって使用されるビルディングブロックは、
動作前提条件と、
有効なオブジェクトライフを特定するクラスのプロセス仕様と、
トリガー関係と、
グローバルトランザクションと、
を備えており、
前記概念モデルの機能モデルコンポーネントを構築するために前記アナリストによって使用されるビルディングブロックは、属性の値に関するイベントの効果を特定する、評価動的式を備えており、
パターン言語を定義し、そして、自動的に書き込まれるべき前記コンピュータプログラムの望ましいユーザインタフェースを定義している前記ユーザインタフェース（表示）モデルを形成するために前記分析者によって使用される、ビルディングブロックは、
導入、
定義された選択、
母集団選択、
補助情報、
依存、
ステータス回復、
引数グループ化、
のパターンを含み、それを表現するエレメンタルパターンを有するサービスプレゼンテーションパターンと、
フィルタと、
順序基準と、
ディスプレイセットと、
を定義するためのパターンを含み、それを表現するために使用されるエレメンタルパターンを有する、クラス母集団表示パターンと、
ディスプレイセットを定義するためのパターンを含み、それを表現するために使用されるエレメンタルパターンを有するインスタンスプレゼンテーションパターンと、
インスタンス表示と、
クラス母集団表示と、
帰納的、マスター詳細表示と、
を含み、それを表現するために使用されるエレメンタルパターンを有するマスター／詳細表示パターンと、
動作選択パターンと、
を含む
請求項１に記載のプロセス。
【請求項２１】
コンピュータプログラム及びそのユーザインタフェースの望ましい構造及び動きの検証された形式仕様からコンピュータプログラムを自動的に生成するための装置であって、前記形式言語で書かれた形式仕様は、
メモリを有するコンピュータと、
実行するときに、前記コンピュータに下記のステップを実行させる、前記コンピュータに保存された１つまたは複数のコンピュータプログラムと、
を備えており、下記のステップ、
変換構造と呼ばれるコード生成構造を表現することと、そしてそれは、前記形式仕様を保存している高レベルシステムリポジトリーから抽出される必要要件データを使用して、前記メモリにおいて保存され、
前記高レベルレポジトリーにおける前記変換構造から必要要件データを用いて例示されるソースコードコンポーネントを書くために各前記変換構造の前記方法を実行し、そして
ソースコードコンポーネントのファイルにおいて結果として生じるソースコードコンポーネントを含み、グローバルインタラクション実行コンポーネントのためのソースコードと、グローバルインタラクションサーバコンポーネントのためのソースコードとを生成し、そしてグローバル機能コンポーネントのためのソースコードを生成し、標準ソースコードコンポーネントを生成し、そして前記コンピュータプログラムであるファイルにすべての前記コンポーネントを組み合わせることと、
を含む、装置。
【請求項２２】
前記コンピュータの前記メモリは、前記変換構造をクラスとして保存し、前記変換構造の各々は、前記コンピュータプログラムの前記概念モデルを形成しながら、前記コンピュータプログラムの設計者によって入力される必要要件データをそこに保存することによって表現されており、必要要件データ情報あるいは前記概念モデルにおける概念パターンの各部分は、形式言語概念として表され、そして前記変換構造の一つに保存されている、前記形式仕様における対応する形式対応相手を有しており、
前記変換構造のうちの１つまたは複数は、各クラスについてのテンプレートを定義する必要要件データを保存しており、各テンプレートは、事例としてリーダークラスを形成する必要要件データの種々のサブブロックを示すいくつかのエレメンタルビルティングブロックから成り、それらの各々はクラスの形式で変換構造において保存されており、そしてそれらは各前記クラスについての各前記テンプレートを定義するために結合し、各前記クラスについてのビルディングブロックおよび前記クラスを作る前記エレメンタルビルディングブロックは、前記概念モデルのオブジェクトモデル部分を構成するために使用されており、各クラスのビルディングブロックを作る前記エレメンタルビルティングブロックは、
名前、
前記クラスにおいてオブジェクトによって使用される前記名づけの仕組みを特徴づける識別機能、
別名、
定数、変数、派生属性、
プライベート及び共有イベントを含んでいるサービスのセットおよびローカルトランザクション、
完全性制約、
派生属性の値を定義する派生エクスプレッション、
集合及び継承クラスオペレータ、
を備えており、そして
前記概念モデルの動的モデルコンポーネントを構成するために、前記設計者によって使用されるビルディングブロックは、
動作前提条件、
有効オブジェクトライフを特定するクラスのプロセス定義、
トリガー関係、
グローバルトランザクション、
を備えており、そして
前記 概念モデルの機能モデルコンポーネントを構成するために、前記アナリストによって使用されるビルディングブロックは、属性の値に関するイベントの影響を特定する評価動的式、を備えており、そして
パターン言語を定義し、そして自動的に書き込まれるように前記コンピュータプログラムの望ましいユーザインタフェースを定義している前記プレゼンテーションモデルを作るために前記アナリストによって使用されているビルディングブロックは、
導入、
定義された選択、
補助情報、
依存、
ステータス回復、
引数グループ、
のパターンを含むそれを表現するエレメンタルパターンを有するサービス表示パターンと、
フィルタ、
要求基準、
ディスプレイセット、
を定義するためのパターンを含み、それを表現するために使用されるエレメンタルパターンを有するクラス母集団プレゼンテーションパターンと、
ディスプレイセットを定義するためのパターンを含み、それを表現するために使用されるエレメンタルパターンを有する例表示パターンと、
マスター／詳細表示パターンと、そして
動作選択パターンと、
を含む、
請求項２１に記載の装置。
【請求項２３】
前記１つまたは複数のコンピュータプログラムは、前記概念モデルにおいて必要要件データを入力するために前記設計者が使用するグラフィカルな図及びテキストインタラクティブダイアログをディスプレイし、そして、自動的に書き込まれるように前記コンピュータプログラムの望ましい構造及び動きを定義する前記形式仕様におけるその形式カウンターパートに必要要件データの各部分を変換するように前記コンピュータを制御する編集機能プログラムを含んでおり、
前記編集機能プログラムは、それが完全であり正確であることを確実にするように前記形式仕様を検証するために前記形式仕様が書かれている前記形式言語によって定義されるグラマーのルールを使用するように前記コンピュータを制御している、請求項２２に記載の装置。
【請求項２４】
コンピュータプログラムの構造、機能、ユーザインタフェースを完全に定義する形式言語で書かれた形式仕様の自動書き込みと設計を容易にするソフトウェア作成システムを備えている装置であって、そのソースコード（以後アプリケーションプログラムと呼ぶ）は自動的に書き込まれ、
メモリを有しているコンピュータと、前記メモリは変換構造を保存しており、各変換構造は、ソースコードコンポーネントを生成するために必要とされる情報を保存するクラスを備えておりそして前記変換構造において保存された前記情報を使用して前記ソースコードコンポーネントを生成する方法を有しており、前記変換構造において保存される前記情報は、概念モデルから生成される形式仕様から検索される情報を含み、
前記コンピュータによって実行されるときに、概念モデルを作るために前記アプリケーションの設計者によって使用されることができる編集機能ウィンドウにおいて図及びテキストインタラクティブダイアログをディスプレイするために前記コンピュータを制御する前記コンピュータ上にロードされた編集機能プログラム（と、前記編集機能プログラムは、前記ディスプレイされた図及びテキストインタラクティブダイアログを使用して、前記アプリケーションの設計者によって入力された必要要件データを受信し、各必要要件データ情報の部分を形式言語でその対応する形式カウンターパートに変換し、そしてシステムリポジトリーとして作用する形式仕様で前記対応する形式カウンターパートを保存するように前記コンピュータを制御するために構成されており、そして
前記コンピュータによって実行されるときに、それが完全で正しいということを確実にするため各前記対応形式カウンターパートを検証するために前記形式仕様が書かれている前記形式言語のグラマーのルールを使用するように前記コンピュータを制御する検証プログラムと、
を備えている装置。
【請求項２５】
前記システムリポジトリーにおける情報からソースコードを自動的に生成するためのシステム論理変換機と、
前記システムリポジトリーにおいて保存される前記形式仕様における情報によって定義されるユーザインタフェース機能を履行するソフトウェアコンポーネントに関するソースコードを自動的に生成するユーザインタフェース変換器と、そして
前記システムリポジトリーにおける情報を使用しているリレーショナルデータベース管理システムにおいてデータモデルを自動的に定義するデータベース生成器と、
をさらに備えている請求項２４に記載の装置。
【請求項２６】
前記概念モデルを作るために前記設計者によって入力される必要要件データを保存する前記メモリにおいて保存されるクラスデータ構造である変換構造として参照されるメモリ構造と、それらの各々は、前記変換構造において保存される前記必要要件データを使用してソースコードを生成する方法を有しており、前記変換構造クラスデータ構造のうちの１つは前記適切な順序でソースコードを生成するために必要とされる前記変換構造からすべての必要要件データを検索し、そして自動的に生成されたソースコードをファイルに書き込み、前記アプリケーションプログラムを作成するためにコンポーネントベース構造にしたがって適切に前記自動的に生成されたソースコードをファイルに配列するように機能するコード生成クラスであり、
前記必要要件データのサブセットは、前記システム論理変換機、ユーザインタフェース変換器、あるいはデータベース生成器の各々によって、前記システムリポジトリーから検索され、
前記変換機は、前記システムリポジトリーから必要要件データを自動的に検索し、そして前記変換構造においてそれを保存し、そして、前記変換構造に保存された前記必要要件データのサブセットを使用してソースコードコンポーネントを生成するように、前記コンピュータを制御し、
前記システム論理変換器は、前記システムリポジトリーから検索された必要要件データのサブセットに基づいてソースコードを生成し、前記システム論理変換器によって検索される前記必要要件データは、クラスである前記概念モデルにおける情報のメインユニットと、そしてグローバルトランザクションおよびグローバル機能である前記概念モデルにおける情報の他のユニットと、に基づいており、
前記概念モデルにおいて定義される前記クラスから検索される情報は、
名前、
識別機能、
名前、引数、前提条件式を含んでいるイベント、
名前、ローカルあるいはグローバルのタイプ、引数、前提条件式、そしてトランザクション式を含んでいるトランザクション、
定数属性、
可変の属性、
名前、タイプ、派生式を含む派生属性、
関係するクラス、濃度、静的あるいは動的そして役名を含む集合クラス関係、
クラス間のエージェント関係、
評価式、
静的制約式、
動的制約式、
トリガー条件式、
アンセスタークラス、
名前、専門化条件式、前提条件再定義、そして評価再定義を含む専門化クラス、
初期状態、最終状態、サービス名、有効エージェント、そして遷移状態式を含む状態遷移、そして
名前、
名前とタイプを含む引数、そして
グローバルインタラクション式、
を含む前記概念モデルにおいて定義されたグローバルインタラクションから検索される情報、
をさらに備えている請求項２５に記載の装置。
【請求項２７】
前記ユーザインタフェース変換器は、前記システムリポジトリーから必要要件データのサブセットを検索し、そしてそれを前記変換構造に保存し、そしてユーザインタフェース機能性を履行する前記ソースコードコンポーネントを生成するために必要とされる必要要件データのサブセットを前記変換構造から検索するために前記コード生成クラスの前記方法を呼び出し、ユーザインタフェース機能を履行する前記ソースコードコンポーネントを作る前記ソースコードファイルを生成するために必要とされる前記変換構造の方法を正しい順序で呼び出すように前記コンピュータを制御し、
前記ソースコードコンポーネントは、前記ユーザにオファされた前記ユーザインタフェースを含むフォームとして前記望ましいユーザインタフェースをディスプレイするためにそれを実行するコンピュータを制御するように構成されたユーザ機能を履行し、前記フォームは、
オブジェクト識別子とパスワードをリクエストすることによって有効サービスエージェントオブジェクトとして前記ユーザを認証するアクセスフォームと、
ユーザが自身が開始できるサービスをビューすることができるメニューのフォームにおいて、ユーザが開始できるサービスのシステムビューを提供するメインフォームと、
前記ユーザが開始できる全てのサービスについての起動サービスフォームと、なお、前記起動サービスフォームは、ユーザが提供しなくてはならない全ての引数についての導入フィールドを有しており、前記起動サービスフォームの前記ソースコードは、データタイプ、サイズ、値のレンジ、前記ユーザによって導入されたいずれのデータのＮＵＬＬ、そしてすべての引数が適切であると評価された場合にサービス起動メッセージを作りそして送信するためのコード、を有効にするように構成されており、
前記アプリケーションのユーザがデータインスタンスを照会し、与えられた情報を満たすインスタンスをサーチし、関連インスタンスを観察し、与えられた状態において与えられたオブジェクトについてどのサービスをユーザが開始できるかを知ることを可能にする形式仕様において定義される各クラスについての照会選択フォームと、なお、前記ソースコードは、サービスを開始するためにビジュアルコンポーネントをディスプレイし、サービスを開始するために与えられたユーザのコマンドを開始するのがどのオブジェクトのどのサービスかを決定するように構成され、前記ソースコードはまた、以前のオブジェクトについての情報のみをディスプレイする新しい照会／選択フォームをディスプレイするために、オブジェクトからリンクにしたがうことによってユーザがナビゲートすることを可能にする、閲覧するためのコンポーネントをディスプレイするように構成され、そして
ユーザインタフェース機能性を履行する前記ソースコードコンポーネントは、広く使用されており同じ方法で常に生成されている構造あるいは補助機能に対応する固定されたコンテンツを備えた固定ファイルと、前記システムリポジトリーにおいて保存された前記形式仕様においてエンコードされた前記概念モデルにおける前記必要要件データに強く依存するコンテンツを有するが、しかし上記で定義された様々なフォームを履行するためには、前記変数ファイルされたものはよく定義された構造を備えたソースコードのテンプレートであるという点でよく定義された構造を有し、しかし前記概念モデルを構成する前記設計者によって設計された前記実際のユーザインタフェースを履行するためには、前記概念モデルから抽出された前記必要要件データに依存している前記ソースコードの変数部分を有する、ソースコードの変数ファイルと、を備えている請求項２６に記載の装置。
【請求項２８】
前記ユーザインタフェース変換器は、下記のタスク、
前記固定されたファイルを生成することと、
制御あるいはＪＡＶＡ Ｂｅａｎｓの形で、補助ウィジットを生成することと、
各クラスに対し、照会／選択フォーム、インスタンス選択コンポーネント、クラスがその他のクラスから専門化された場合の専門化コンポーネントを生成することと、
各サービスに対し、前記起動サービスフォームを生成することと、
前記アプリケーションプログラムのユーザが彼自身を認証することを可能にするための前記アクセスフォームを生成することと、
前記アクセスフォームを通じて成功してログインしたユーザが開始することができるサービスのシステムビューを含む前記メインフォームを生成することと、
前記アプリケーションプログラムの前記システム論理において、サーバに対しサービス起動メッセージを送信するために通信機能のソースコードを生成することと、
を実行するコード生成クラスの方法を呼び出す、請求項２７に記載の装置。
【請求項２９】
前記変換構造クラスは、
サーバーコンポーネントを生成するために必要な情報を保存する、サーバークラス、
グローバルインタラクションのためのサーバーコンポーネントを生成するために必要な情報を保存する、グローバルインタラクションサーバークラス、
実行コンポーネントを生成するために必要な情報を保存する、分析クラス、
グローバルインタラクション、グローバルトランザクション、そして引数のリストの名前のフォームにおいて、グローバルインタラクションのための実行コンポーネントを生成するために必要な情報を保存する、グローバルインタラクション分析クラス、
継承階層のための実行コンポーネントを生成するために必要な情報を保存する、継承階層分析クラス、
照会コンポーネントを生成するために必要な情報を保存する、照会クラス、
Ｔコンポーネントを生成するために必要な情報を保存する、Ｔクラス、
Ｃコンポーネントを生成するために必要な情報を保存する、Ｃクラス、
ＣＣコンポーネントを生成するために必要な情報を保存する、ＣＣクラス、
Ｐコンポーネントを生成するために必要な情報を保存する、Ｐクラス、
ＰＬコンポーネントを生成するために必要な情報を保存する、ＰＬクラス、
前記概念モデルにおけるすべてのクラスのすべてのサービスのための引数についての情報を保存する、引数リストクラス、
概念モデルにおけるすべてのクラスの識別機能についての情報を保存する、分析クラスリストクラス、
イベント、共有イベント、トランザクション、そしてオブジェクトインタラクション（以下イベントクラスとして参照される）を実行するための履行コンポーネントにおけるサービスを説明するために必要な方法を生成する１つまたは複数のクラス、
前記概念モデルにおいて前提条件、静的制約、および動的制約が存在する場合、少なくとも前提条件クラス、静的制約クラス、動的制約クラスを実行するための実行コンポーネントと継承階層のための実行コンポーネントの両方におけるサービスを決定するのに必要な補助的方法を生成する１つまたは複数のクラス（以後補助的方法クラスと呼ぶ）、
照会とＴコンポーネントにおいて必要な方法を生成する、ＴおよびＱ方法クラス、
継承特定方法を生成する、継承方法クラス、
コード生成プロセスを制御しそして履行する、コード生成クラス、
を備えている、請求項２６に記載の装置。
【請求項３０】
前記アプリケーションのソースコードコンポーネントを生成するために各変換構造クラスの方法を実行するステップ、をさらに備えており、前記変換構造クラスの方法は、各々、前記アプリケーションにおいて下記の機能を実行するためにソースコードコンポーネントを生成する下記の機能を実行するものであり、
各サーバクラスインスタンスコード生成方法は、前記クラスの署名に存在している各サービスのための方法を含むサーバソースコードコンポーネントを生成するために前記サーバクラスインスタンスにおいて保存された情報を使用し、
各グローバルインタラクションサーバクラスコード生成方法は、前記形式仕様において定義されるグローバルインタラクションについての方法を含むインタフェースを使用して、前記概念モデルにおいて定義されるグローバルインタラクションを履行するソースコードコンポーネントを生成するために、前記グローバルインタラクションサーバクラスにおいて保存される情報を使用し、
各分析クラスインスタンスコード生成方法は、前記分析クラスインスタンス変換構造をもたらした前記クラスについて、実行コンポーネントを履行するソースコードコンポーネントを生成するために、前記分析クラスインスタンスにおいて保存された情報を使用し、なお、前記実行コンポーネントは、前記分析クラスインスタンスに与える前記クラスの署名のサービスについての方法を含み、各方法は、実行モデルにしたがって前記サービスを実行するように構成され、
各グローバルインタラクション分析クラスコード生成方法は、前記形式仕様において特定されたグローバルトランザクションにおいて定義されるオブジェクト間でグローバルインタラクションを履行するサービスについての方法を提供する、実行コンポーネントを履行するソースコードコンポーネントを生成するために、前記グローバルインタラクション分析クラスにおいて保存された情報を使用し、
各継承階層分析クラスコード生成方法は、継承階層のための単一の特別の実行コンポーネントにグループ化された実行コンポーネントのグループの一部分である実行コンポーネントを履行するソースコードコンポーネントを生成するために、前記継承階層分析クラスにおいて保存された情報を使用し、
各照会クラスコード生成方法は、前記コンピュータプログラムのユーザが前記クラスの前記母集団を照会することを可能にする照会コンポーネントを履行するソースコードコンポーネントを生成するために、前記照会クラスで保存された情報を使用し、
各Tクラスコード生成方法は、前記Tクラスの前記インスタンスに対して生み出した前記クラスの前記定数の及び可変の属性と、定数及び派生属性の値に照会アクセスを提供し前記クラスの派生属性の値を計算するTコンポーネントのソースコードを生成するために派生属性の値を計算する方法と、に関する前記Tクラスにおいて保存された情報を使用し、
各Cクラスコード生成方法は、前記クラスが一時的あるいは永久的な条件に基づいた特殊化クラスである場合には、前記クラスのインスタンスを創設するときに、前記初期値を使用して前記クラスの属性を読み込むように機能するCコンポーネントのソースコードを生成するために、前記クラスの定数及び可変の属性の初期値に関する前記Cクラスにおいて保存された情報を使用し、
各CCクラスコード生成方法は、Cコンポーネントのコレクションを履行し、そして前記コレクションに項目を加えたり取り出すためのＣコンポーネントについての一対の方法と、前記コレクションにおいて項目の数を得る方法とを提供する、CCコンポーネントを履行するソースコードを生成するために、前記形式仕様において定義された一時的あるいは永久的な条件に基づく特殊化に関する前記CCクラスにおいて保存された情報を使用し、
各Pクラスコード生成方法は、それのインスタンスを生成しているときに前記クラスの定数及び可変の属性の初期値をメモリに保存するように機能するPコンポーネントを履行するソースコードを生成するために、前記Pクラス変換構造に対して生み出された前記クラスの定数及び可変の属性を初期化することが必要とされる値に関する前記Pクラスにおいて保存された情報を使用し、
各PLクラスコード生成方法は、Pコンポーネントのコレクションを履行するように機能するPLコンポーネントの前記ソースコードを生成するために、Pコンポーネントのコレクションに関するPLクラスにおいて保存される情報を使用し、そして前記PLクラス変換構造に対して生ずる前記クラスが集合関係の複数値のコンポーネントであるときはいつでも、前記コレクションからの項目を加えたり取り出すためや、前記コレクションにおける項目の数を得るのに必要な方法を提供し、
各引数リストクラスコード生成方法は、引数リストコンポーネントを生成するために、前記クラスの全てのサービスの引数に関する前記引数リストクラスにおいて保存された情報を使用し、
各分析クラスリストクラスコード生成方法は、それらが生成されているように前記クラスのインスタンスについてのネーミングメカニズムを特徴づけるために前記識別機能情報を供給するコンポーネントのソースコードを生成するために、前記クラスの識別機能に関する前記分析クラスリストクラスにおいて保存される情報を使用し、
前記１つまたは複数のイベントクラスコード生成方法の各々は、イベント、共有イベント、トランザクション、そしてオブジェクトインタラクションを履行する実行コンポーネントにおけるサービスを解決するソースコードコンポーネントを生成するために前記イベントクラスにおいて保存された情報を使用し、
前記１つまたは複数の補助方法クラスの各々のコード生成方法は、実行コンポーネントと、前記概念モデルにおいて前提条件、静的制約、動的制約が存在する場合に、少なくとも前提条件クラス、静的制約クラス、動的制約クラスを履行するように実行する継承階層のための実行コンポーネントとの両方のサービスを解決するのに必要とされる補助方法を履行するソースコードコンポーネントを生成し、
各Ｔ＆Ｑクラスコード生成方法は、照会及びＴコンポーネントを履行するソースコードコンポーネントを生成するために、前記Ｔ＆Ｑクラスにおいて保存された情報を使用し、そして
各継承方法クラスコード生成方法は、前記形式仕様において前記クラスについて特定された継承関係に対する特有の方法を履行するために、ソースコードコンポーネントを生成すること、
を実行することをさらに含む請求項２９に記載のプロセス。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本願発明は、コンピュータシステムに関わり、特に、自動ソフトウェア作成システムとスタンドアロンのシステムやインターネット上のシステムに適した方法論に関わる。
【０００２】
【従来の技術】
ソフトウェアエンジニアリングとはコンピュータプログラム、アプリケーション、およびその他のソフトウェアシステムの開発と維持のために、系統的で統制の取れたアプローチを適用することである。世界経済のコンピュータ化の増加にともない、効率的なソフトウェアエンジニアリングの方法の必要性は、かつてないほど重要になっている。
【０００３】
従来のソフトウェア開発プロセスは多数の段階(phases)を含む。まず、プログラムの必要要件(requirements)は、特に顧客のニーズ(needs)に基づいた書面の仕様書というかたちで特定される。次に、ソフトウェア開発者は、たとえば、データ構造(data structures)を設計し、システム論理(system logic)を符号化することにより、その必要要件を履行するソースコードを書く。最後に、ソフトウェア開発者は、必要要件における誤りやあいまいな点が識別される徹底的なテストとデバッグ段階(an extensive testing and debugging phase)を実施し、ソフトウェアコードにおけるエラーが調整される(fixed)。起こり得るもっとも深刻な問題の一つは、システム必要要件を変更しなければならなくなることである。どのような必要要件に対する修正(modification)でも、ソースコードの再開発が必要であり、すべてのプロセスをもう一度最初からやり直さねばならないからである。したがって、テストとデバッグ段階は、ソフトウェアエンジニアリングのプロセスの中で最も長い段階であり、完成に要する時間の見積もりが最も難しい段階である。
【０００４】
この４０年の間、ソフトウェアエンジニアリングのプロセスの個別の部分を改良する多くの試みがなされてきた。たとえば、ＦＯＲＴＲＡＮ等の最初の高級言語、そしてＡＬＧＯＬ等の構造化されたプログラミング言語の誕生は、システム論理を履行する負担を軽いものとした。もう一つの例としては、オブジェクト指向の方法論の導入はデータ構造の設計や実施に役立った。これらの、ソフトウェアエンジニアリングのプロセスにおける改善は、問題の場であるアプリケーションのための概念モデル(概念モデル)と、解決の場である実際のソフトウェアコードとの間の不整合(mismatch)を減少させた。しかしながら、問題の場と解決の場の不整合はまだいくらかあるため、プログラミングエラーを起こしかねない。そのため、ソフトウェアの欠点を分離し修正するために、徹底的なテストとデバッグ段階を行う必要がある。
【０００５】
最近、必要要件の識別及び特定であるソフトウェアエンジニアリングのプロセスの第一段階を容易にする、「必要要件分析(requirements analysis)」とコンピュータ支援ソフトウェアエンジニアリング(Computer Aided Software Engineering)（ＣＡＳＥ）の使用に関心が持たれている。特に、これらのアプローチはソフトウェア技術者が形式的に必要要件を特定し、その必要要件を検証し(validate)、テストするためにプロトタイプを作ることができるようにする。必要要件がテストされた後、そのプロトタイプは破棄され(discarded)、ソフトウェア技術者はその必要要件に基づき、完全なソフトウェアアプリケーションを開発する。
【０００６】
一例として知られているのが「ＯＭＴＲＯＬＬ」で、その目的は、オブジェクトモデリングテクニック（ＯＭＴ）に準拠したグラフィック表記法を使って、ソフトウェア設計者がシステムの形式仕様を作るのを支援することである。この仕様はＴＲＯＬＬ仕様言語に基づいており、完全なシステム仕様へと改良されなければならない。また、ＯＭＴＲＯＬＬは、グラフィック概念仕様から独立的に実行可能なプロトタイプを生成することによりプロトタイプ作成機能を供給する、ＴｒｏｌｌＷｏｒｋｂｅｎｃｈと呼ばれるＣＡＳＥサポートを有する。その生成されたプロトタイプはシステムの静的／動的の態様を含むＣ＋＋プログラムであり、仕様のリポジトリーとしてＩｎｇｒｅｓｓデータベースを利用する。
【０００７】
ＯＢＬＯＧは、もう一つのオブジェクト指向のソフトウェア開発へのアプローチであり、ヨーロッパのＥＳＰＲＩＴプロジェクトであるＩＳ−ＣＯＲＥ（情報システム−正確さと再利用性）の範囲に当てはまる。ＯＢＬＯＧのセマンティックスはカテゴリーの理論に照らして形式化されている。また、ＯＢＬＯＧは仕様の導入にＣＡＳＥツールを利用し、仕様をプロトタイプ用のコードに書き換えるための再書き込みルールを供給することにより、開発者がプロトタイプを作り上げることを可能にする。その再書き込みルールは、ＯＢＬＯＧによって定められた特定の言語によって書かれてなくてはならない。
【０００８】
形式化のレベルに、より焦点を合わせたもうひとつのアプローチとしては、オブジェクトシステム分析モデル（ＯＳＡ）がある。ＯＳＡの目的は、システム設計者が、非形式なものから数学的に厳格なものに亘るまで、違ったレベルの形式化で取り組めるようにする方法を開発することである。この意味において、このような調整可能な形式化は、理論研究者と実施者の両方が同じモデルに取り組めるようにし、モデルと言語の同等化において遭遇する困難を探し、ある特定の言語のためのＯＳＡに照らしてこれらの困難を克服することを可能にする。ＯＳＡもまた、必要要件を検証するために、ＯＳＡモデルからプロトタイプを生成することができる、ＩＰＯＳＴと呼ばれるＣＡＳＥサポートツールを有する。
【０００９】
ＳＯＦＬ（体系的オブジェクトに基づいた形式言語）はまた違ったアプローチを提案し、その目的は、形式方法の統一と、体系的な分析と仕様、そしてオブジェクトに基づいた方法を使用して、形式方法を、確立されている産業ソフトウェアのプロセスへと統一することを検討することである。ＳＯＦＬは、体系的な様式の必要要件の仕様から、オブジェクトに基づいた様式の設計への変換を容易にし、また設計から適切な様式のプログラムへの変換を容易にする。先の論点のとおり、ＳＯＦＬの提案は、たとえばＶＤＭ（ウイーン開発法）様式のセマンティックス等のような形式方法を、その仕様モジュールに用いて、オブジェクト指向の方法論と体系的技術を結ぶリンクを探し出すことにより、形式方法が産業において広く使用されていないという事実を克服することを試みるものである。しかし、体系的技術とオブジェクト指向の技術を一つの方法に組み合わせることは、その方法のセマンティックスを明確にすることを困難にする。したがって、一貫性の確認には、効果的なツールのサポートが必要である。
【００１０】
さらに別のアプローチとして、ＴＲＡＤＥ（必要要件と設計エンジニアリング用のツールキット）が知られており、その概念構造は内部のコンポーネントから外部システムのインタラクションを区別する。ＴＲＡＤＥは、体系的、オブジェクト指向の両方の仕様と設計方法からの技術を含む。ＴＲＡＤＥの構造をサポートするために、ＴＣＭ（概念モデリング用のツールキット）と呼ばれるグラフィック編集機能が設けられている。
【００１１】
これらのアプローチは、第一段階、つまりコンピュータアプリケーションが符号化される前に必要要件を改良する段階においていくらかの助けになるものの、ソフトウェアエンジニアリングのプロセスの後の段階、すなわちプログラミングの段階、およびテストとデバッグの段階での生産性不足の主たる原因には対処していない。たとえば、必要要件が一度識別されると、ソフトウェア技術者は通常これらのアプローチのほとんどにより生成されたプロトタイプを破棄し、Ｃ++のような標準プログラミング言語で必要要件を設計し、履行する。問題の場と解決の場の間の不整合のため、新しく開発されたコードは一般的にコードのエラーを有し、徹底的なテストとデバッグを必要とする。
【００１２】
プロトタイプが破棄されずに最終的なアプリケーションの骨組みとして使用されたとしても、ソフトウェア開発者は、特にユーザーインターフェースとエラー処理を履行する、追加のコードを開発しなければならない。その場合、プログラマーが書いたコードはやはりテストしデバッグする必要がある。さらにＯＢＬＯＧのルール再書き込みアプローチにおいては、プログラミングに関する難点が一つ前のレベル、未知の独自の言語でルールを書き直す開発にシフトしたに過ぎず、この必要性に対処していない。
【００１３】
その他のアプローチとしてはＲａｔｉｏｎａｌ法やＳｔｅｒｌｉｎｇ法などがあるが、これらは形式言語によるものではない。
【特許文献１】米国特許第５，９６０，２００号
【非特許文献１】Letelier, P., et al., “OASIS Version 3.0: Un Enfoque Formal Para el Modelado Conceptual Orientado a Objectos” (In Spanish), ISBN: 84-7721-663-0, Legal Diposit: V-3484-1998, Servicio de Publicaciones de la UPV, SP-UPV 98-4011, Valencia, Spain, 1998.
【非特許文献２】Pelechano, V., “OO-Method: Implementacion de un Entorno Grafico para el Analisis y Diseno de Sistemas De Informacion OO” (In Spanish), Master Thesis, 1994.
【非特許文献３】Pelechano, V., et al., “CASE OO-Method: Un Entorno de Produccion Automatica de Software” (In Spanish) Actas de la Convencio Informatica Latina CIL-95, Barcelona, June, 1995.
【非特許文献４】Romero, J., “Diseno de un Entorno de Produccion de Software basado en el Lenguaje de Especificacion OASIS y en la utilizacion de PowerBuilder como Herramienta de Desarrollo Grafica y C/S” (In Spanish), Master Thesis, Valencia, March, 1996.
【非特許文献５】Pastor, O., et al., "An Object Oriented Methodological Approach for Making Automated Prototyping Feasible", Database and Expert Systems Applications. Lecture Notes in Computer Science (1134) pgs. 29-39 Springer-Verlag. 1996, ISBN: 3-540-61656-x, ISSN: 0302-9743, Zurich (Suisse) [Pastor 96aO]:
【非特許文献６】Pelechano, V., et al., “Implementacion y comprobacion de restricciones de integridad dinamicas en entornos de programacion orientados a objectos” (In Spanish), II Jornadas Nacionales de Ingenieria de Software, Universidad el Pais Vasco, San Sebastian, 3-5 Septiembre 1997, pgs. 101-117.
【非特許文献７】Pastor, O., et al., “Linking Object-Oriented Concept Modeling with Object-Oriented Implementation in Java（登録商標）”, VIII Conference on Database and Expert Systems Applications, (DEXA’1997). ISGN: 3-540-63478-9, LNCS (1308). Toulouse, France, 1997.
【非特許文献８】Pastor, O., et al., “OO-METHOD: An OO Software Production Environment Combining Conventional and Formal Methods”, 9th International Conference on Advanced Information Systems Engineering, (CaiSE’1997) ISGN: 3-540-63107-0, LNCS (1250), Barcelona, Spain, 1997.
【非特許文献９】Pastor, O., et al., “Object Oriented Concept Modeling Techniques to Design and Implement a Sound and Robust Oracle Environment” Actas de Oracle OpenWorld 97, Viena (Austria) 7-11 Abstract publicado en Oracle OpenWorld Review pg. 36, April, 1997.
【非特許文献１０】Romero, J., et al., “Una Herramienta de Generacion Automatica de Software” (In Spanish) In Procs of IDEAS-98 - I Workshop Iberoamericano en Ingenieria de Requisitos y Ambientes Software, Porto Alegre, Brasil, April, 1998.
【非特許文献１１】Gomez, J., et al., “The Execution Model: A Component-Based Arquitecture to Generate Software Components from Concept Models” In Procs of International Workshop on Component-based Information Systems Engineering, 10th International Conference on Advanced Information Systems Engineering, CAiSE-98 Pisa (Italia), pgs. 87-94, ISSN 1170-487X.
【非特許文献１２】Pastor, O., et al., “From Object Oriented Concept Modeling to Automated Programming in Java（登録商標）”, Concept Modeling . ER’98. Lecture Notes in Comptuer Science (1507), pgs. 183-197, Springer-Verlag, 1998, ISBN: 3-540-65189-6, ISSN: 0302-9743, Singapur:
【非特許文献１３】Pastor, O., et al., “Mapping Aggregation from Object-Oriented Concept Modeling to Object-Oriented Programming”, In Procs of Third International Conference on Object Oriented Technology, WOON-98, pgs. 59-70, San Petersburgo, Russia, July, 1998.
【非特許文献１４】Romero, J., et al., “Automatic Object-Oriented Visual Programming with OO-METHOD”, Software and Hardware Engineering for the 21th Century, pgs. 345-354, World Scientific and Engineering Society Press. ISBN: 960-8052-06-8.
【非特許文献１５】Gomez, J., et al., “From Object-Oriented Concept Modeling to Component-Based Development” Database and Expert Systems Applications. Lecture Notes in Computer Science (1677) pgs. 332-341 Springer-Verlag, 1999, ISBN: 3-540-66448-3; ISSN: 0302-9743, Florencia (Italia).
【非特許文献１６】Torres, I., “Disseny i Implementacio d’un Diccionari de Dades per a un Model Conceptual” (In Valenciano), Master Thesis, 2000.
【非特許文献１７】Pelechano, V., et al., “An Automatic Code Generation Process for Dynamic Specialization Based on Design Patterns and Formal Techniques”, Actas de la IFIP International Conference on Software: Theory and Practice (ICS-2000), 16th IFIP World Computer Congress, pgs. 526-539, Pekin (China), Agosto 2000; ISBN-7-5053-6100-4, Publishing House of Electronics Industry:
【非特許文献１８】Pastor, O., “The OO Method Approach for Information Systems Modeling: From Object Oriented Concept Modeling to Automatic Programming”, Information Systems Journal, Elsevier Science, October 2001, Vol. 26/7, pgs. 507-534.
【非特許文献１９】Molina, P., “Especificacion, de Interfaz de Usuario en OO-Method” (In Spanish) Master Thesis, September 1998, DSIC/UPV, Valencia, Spain.
【非特許文献２０】Insfran, E., et al., “Ingenieria de Requisitos aplicada al modelado conceptual de interfax de usuario” (In Spanish), In Procs. Of IDEAS’2001, Santo Domingo, Heredia, Costa Rica, CIT, pgs. 181-192, April, 2001.
【非特許文献２１】Molina, P., et al., “Specifying Conceptual Interface Patterns in an Object-Oriented Method with Code Generation”, In Proceedings of User Interfaces for Data Intensive Systems, UIDIS’2001, Zurich, Switzerland, IEEE Computer Society, pgs. 72-79, Mary, 2001.
【非特許文献２２】Molina, P., et al., “Prototipado rapido de interfaces de usuario”, (In Spanish), In Procs. Of IDEAS’2002, La Habana, Cuba, pgs. 78-90, April, 2002.
【非特許文献２３】Molina, P., et al., “JUST-UI: A User Interface Specification Model” In ComputerAided Design of User Interfaces III, Proceedings of the 4th International Conference on ComputerAided Design of User Interfaces CADUI’2002, Kluwer Academics Publisher, Dordrecht, pgs. 63-74, Valenciennes, France, May, 2002.
【非特許文献２４】Molina, P., et al., “User Interface Concept Models”, In Proceedings of the 4th International Workshop on Design Specification & Verification of Information Systems DSV-IS’2002, Rostock, Germany, pgs. 201-214, June, 2002.
【００１４】
【発明が解決しようとする課題】
したがって、ソフトウェアエンジニアリングのプロセスを改善する必要性、特にプログラミング段階やテスト段階に費やす時間を削減する必要性が長期にわたり切実に感じられている。また、ロバストなソフトウェアアプリケーションを開発する間のプログラミングエラーを低減する方法を探す必要がある。さらに、必要要件が変更された場合に、ソフトウェアアプリケーションの維持を容易にする必要もある。
【００１５】
【課題を解決するための手段】
本発明はこれらの必要性とまたその他の必要性に対処するものであり、そのシステム必要要件は、（たとえばグラフィックユーザーインターフェースなどを通して）取り込まれ、形式仕様に変換され、正確性と完全性を検証される。また、その検証された形式仕様に基づいて、完全でロバストなソフトウェアアプリケーションを自動的に生成する変換器が設けられている。検証された形式仕様からアプリケーションのコードを生成することにより、エラーのないソースコードのストラテジー(strategy)を利用できるようになり、開発者がマニュアルでソースコードを作成したり、不完全なプロトタイプを使用することがなくなる。したがって、従来のソフトウェアエンジニアリングプロセスにおけるエラーを起こしやすいマニュアルでのプログラミング段階が排除され、テストとデバッグの時間が大幅に削減される。ひとつの例では、あるアプリケーションのソフトウェア開発にかかった時間は本来の所要時間の２７％にまで削減された。従来の符号化、テスト、そして再検証のサイクルも排除されるため、ソフトウェア維持もまた低減される。
【００１６】
本発明の一側面は、曖昧さが、Ｃ＋＋のような従来のオブジェクト指向の高位のプログラミング言語に関係するプログラミングエラーの主な原因であるという洞察から生まれた。したがって、ユーザーがソフトウェアアプリケーションの明確な形式条件を入力できるように、グラフィックなユーザーインターフェースが掲示される、自動ソフトウェア作成ツール、ソフトウェア、および方法論が備わっている。ソフトウェアアプリケーションの形式条件の入力に基づき、ソフトウェアアプリケーションの形式仕様が作成、検証され、その仕様により、ソフトウェアアプリケーションが生成される。明確な検証済みの形式仕様から直接ソフトウェアアプリケーションを生成することにより、ソフトウェア開発者は、従来のプログラミング言語に伴うプログラミングエラーを避けることができ、かわりに問題の場で直接作業することができる。一つの実施例においては、ロバストな最終的ソフトウェアアプリケーションを作成するためにソフトウェアアプリケーションを生成する時に、エラー処理のインストラクションもまた作成される。
【００１７】
本発明のもう一つの側面は、従来のプロトタイプ作成技術の欠点の主な原因は、これらの技術がユーザーインターフェースの特徴を特定する能力に欠けることであるという認識に基づくものである。したがって、そのような従来のプロトタイプは、顧客が即使用可能な、最終的なソフトウェアアプリケーションの条件を満たさない初期のユーザーインターフェースを有する。それ故、本発明のこの側面は、ソフトウェアアプリケーションの必要要件を特定する概念モデルの形式仕様を含む、自動ソフトウェアアプリケーション作成ツール、ソフトウェア、および方法論に関する。この概念モデルはソフトウェアアプリケーションのユーザーインターフェースのパターンを特定する表示モデルを含む。その表示モデルを特定する形式仕様は検証され、その検証された形式仕様に基づき、ソフトウェアアプリケーションが生成される。結果として、生成されたソフトウェアアプリケーションは、表示モデルにおいて特定されたパターンにしたがったユーザーインターフェースの処理についてのインストラクションを含む。実際、ソフトウェアアプリケーションのために生成されたコードは、高容積かつトランザクション的な拡張可能で信頼できるシステム論理機能をサポートし、表示モデルにより、クリエイティブ設計者はユーザーインターフェースの符号化の詳細について懸念せずにすむため、ソフトウェアアプリケーションのために生成されたコードは、インターネット上の開発に非常に適している。
【００１８】
以下、本発明を最善のかたちで実施すべく意図された実例の詳細な説明により、本発明のその他の目的と効果はさらに明白になる。以下理解されるごとく、本発明はその他異なる例を実施する能力を有し、いくつかの内容は、さまざまな明白な面において、本発明から逸脱することなく変更可能である。したがって、図や説明は、本質的に解説のためのものであり、これらに限定するものではない。
【００１９】
本発明は、添付の図面の例により図解されるが、これらに限定されるものではなく、参照のように、図にある数字は類似する要素を表す。
【００２０】
【発明の実施の形態】
自動ソフトウェア作成システムを説明する。以下の説明では、本発明の徹底した理解を提供するため、説明の目的で、数々の具体的な詳細が述べられている。しかしながら、この技術に熟練した者には、本発明がこれらの具体的な詳細なしに実践されることもできるということは明らかだろう。その他の場合においては不必要に本発明を不明瞭にすることを避けるため、周知の構造やデバイスはブロック図の形で示されている。
【００２１】
（ハードウェアの概要）
図１は、本発明の一実施例を実現し得るコンピュータシステム１００を示したブロック図である。コンピュータシステム１００は、バス１０２、あるいはその他の情報を伝達するための通信メカニズムと、バス１０２と連動した、情報を処理するためのプロセッサー１０４を含む。コンピュータシステム１００はまた、プロセッサー１０４が実行する情報やインストラクションを保存するためのバス１０２と繋がれた、ランダムアクセスメモリー（ＲＡＭ）やその他の動的ストレージデバイスのようなメインメモリー１０６を有する。メインメモリー１０６はまた、プロセッサー１０４がインストラクションを実行している間の一時的な変数やその他の中間情報の保存に使用されることもある。コンピュータシステム１００はさらに、プロセッサー１０４の静的な情報とインストラクションを保存するための、バス１０２に繋がれた読み出し専用のメモリー（ＲＯＭ）１０８、あるいはその他の静的なストレージデバイスをも有する。磁気ディスクや光学ディスクのようなストレージデバイス１１０が設けられており、情報とインストラクションの保管のため、バス１０２に繋がれている。
【００２２】
コンピュータシステム１００はバス１０２経由で、コンピュータユーザーに情報を掲示するためのカソードレイチューブ（ＣＲＴ）などのディスプレイ１１２に繋がれてもよい。英数字やその他のキーを含む入力デバイス１１４は、プロセッサー１０４への情報とコマンド選択の伝達のため、バス１０２に繋がれている。ユーザー入力デバイスのもう一つの形式は、プロセッサー１０４への方向情報やコマンド選択を伝達し、ディスプレイ１１２上のカーソルの動きを制御するマウスや、トラックボールや、カーソル方向キーのようなカーソル制御１１６である。この入力デバイスは通常一つの面での位置を特定できるように、二つの軸、第一軸（たとえば、ｘ）と第二軸（たとえば、ｙ）において二つの自由度を有する。
【００２３】
本発明は、自動ソフトウェア作成用のコンピュータシステム１００の使用に関する。発明の一つの実施例によれば、自動ソフトウェア作成は、メインメモリー１０６に保存されている一つ以上のインストラクションの中の一つ以上のシーケンスを実行するプロセッサー１０４に応じて、コンピュータシステム１００により成される。そのようなインストラクションは、ストレージデバイス１１０のような、もう一つのコンピュータ可読媒体から、メインメモリー１０６に読み込まれてもよい。メインメモリー１０６に保存されているインストラクションのシーケンスが実行されることにより、プロセッサー１０４がここで説明されているプロセスのステップを遂行する。メインメモリー１０６に保存されているインストラクションのシーケンスを実行するために、マルチプロセッシング配列された一つ以上のプロセッサーを使用してもよい。別の実施例においては、本発明を実施するためのソフトウェアインストラクションの代わりか、あるいはインストラクションとの組み合わせで、配線回路を使用することもできる。したがって、本発明の実施例は、ハードウェア回路とソフトウェアの特定な組み合わせに限定されるものではない。
【００２４】
本文で使われている「コンピュータ可読媒体」という言葉は、プロセッサー１０４の実行のためのインストラクションを与えることに関与するいかなる媒体をも意味する。そのような媒体は、不揮発性媒体、揮発性媒体、及び伝達媒体を含むが、それらに限定されず、多くの形状を取ることができる。たとえば、不揮発性媒体は、たとえばストレージデバイス１１０のような、光学、あるいは磁気ディスクを含む。揮発性媒体は、メインメモリー１０６のような動的メモリーを含む。伝達媒体は、バス１０２を構成するワイヤーを含め、同軸ケーブルや銅ワイヤー、及び光ファイバーなどを含む。伝達媒体はまた、ラジオ周波数（ＲＦ）や赤外線（ＩＲ）のデータ通信の間に発生するような音波や光波の形を取ってもよい。コンピュータ可読媒体の一般的な形状は、たとえば、フロッピーディスク、フレキシブルディスク、ハードディスク、マグネティックテープ、その他の磁気媒体、ＣＤ−ＲＯＭ、ＤＶＤ，その他の光学媒体、パンチカード、ペーパーテープ、その他の穴のパターンを持つ物理的媒体、ＲＡＭ，ＰＲＯＭ，およびＥＰＲＯＭ，ＦＬＡＳＨ−ＥＰＲＯＭ、その他のメモリーチップあるいはカートリッジ、この後説明する搬送波、もしくはその他のコンピュータが読み取ることができる媒体などを含む。
【００２５】
さまざまな形状のコンピュータ可読媒体は、プロセッサー１０４が遂行するための一つ以上のインストラクションの一つ以上のシーケンスを伝達することに関与してもよい。たとえば、インストラクションは最初に、遠隔のコンピュータの磁気ディスクに在ってもよい。そして、その遠隔コンピュータはそのインストラクションを動的メモリーにロードして、モデムを使って電話線上で送ることができる。コンピュータシステム１００にローカルであるモデムは電話線上のデータを受信し、赤外線信号に変換するために赤外線送信機を使うことができる。バス１０２に繋がれた赤外線検出器は、赤外線信号によって伝達されたデータを受け取り、バス１０２上にそのデータを載せることができる。そして、バス１０２はそのデータをメインメモリー１０６に運び、そこからプロセッサー１０４がインストラクションを取り出し実行する。オプションとして、メインメモリー１０６が受け取るインストラクションは、プロセッサー１０４による実行の前か後のいずれかにストレージデバイス１１０に保存されてもよい。
【００２６】
コンピュータシステム１００はまた、バス１０２に繋がれた通信インターフェース１１８を有する。通信インターフェース１１８は、ローカルネットワーク１２２に繋がっているネットワークリンク１２０へ、双方向データ通信を提供する。たとえば、通信インターフェース１１８には、データ通信接続を対応する型の電話線に供給する統合サービス・デジタルネットワーク（ＩＳＤＮ）カード、あるいはモデムなどがある。もう一つの例としては、通信インターフェース１１８は、適したローカルネットワーク（ＬＡＮ）にデータ通信接続を提供するローカルネットワークカードでもよい。ワイヤレス接続も実施可能である。そのような実施のいずれにおいても、通信インターフェース１１８は、さまざまな情報を表すデジタルデータストリームを運ぶ電気、電磁、あるいは光学信号を送り、受け取る。
【００２７】
ネットワークリンク１２０は通常、一つ以上のネットワークを通じて、他のデータデバイスへのデータ通信を提供する。たとえば、ネットワークリンク１２０は、ローカルネットワーク１２２を通して、ホストコンピュータ１２４もしくはインターネットサービスプロバイダー（ＩＳＰ）１２６によって操作されているデータ機器への接続を提供することもできる。かわりに、ＩＳＰ１２６は、今日一般に「インターネット」１２８とよばれているワールドワイドパケットデータネットワークを通して、データ通信サービスを提供する。ローカルネットワーク１２２とインターネット１２８は共に、デジタルデータストリームを運ぶ電気、電磁、あるいは光学信号を使用する。さまざまなネットワークを通る信号や、ネットワークリンク１２０上の信号と通信インターフェース１１８を通る信号は、コンピュータシステム１００と行き来してデジタルデータを運ぶもので、情報を運ぶ搬送波の形状の例である。
【００２８】
コンピュータシステム１００は、ネットワーク、ネットワークリンク１２０、及び通信インターフェース１１８を通し、メッセージを送り、プログラムコードを含むデータを受け取ることができる。インターネットの例において、サーバー１３０は、インターネット１２８、ＩＳＰ１２６、ローカルネットワーク１２２および通信インターフェース１１８を通して、アプリケーションプログラムのための要求されたコードを伝達し得る。本発明に基づいて、そのようなダウンロードされたアプリケーションにより、本文で説明されるように、自動ソフトウェア作成が成される。受信されたコードは、受信されたままの形でプロセッサー１０４により実行されてもよいし、および／またはストレージデバイス１１０に保存されてもよいし、もしくはその他の不揮発性保存場所に保存されてもよい。この方法においては、コンピュータシステム１００が、搬送波という形でアプリケーションコードを取得してもよい。
【００２９】
（概念の概要）
図２は、本発明の一実施例に基づく自動ソフトウェア作成システム２０２の、ハイレベル構造とデータフローを図示した概略ブロック図である。自動ソフトウェア作成システム２０２は、必要要件２００を入力として受理し、完全でロバストなアプリケーション２０４（システム論理とユーザーインターフェースコードの両方を含む）とデータベーススキーマ２０６とドキュメンテーション２０８を作成するよう設定されている。実施の一例においては、自動ソフトウェア作成システム２０２は、ユーザーが必要要件を入力できるようにするコンピュータ支援ソフトウェアエンジニアリング（ＣＡＳＥ）ツール２１０フロントエンドと、入力条件２００を検証する検証器２２０、および検証された入力条件２００を完全かつロバストなアプリケーション２０４に変換するいくつかの変換器を含む。これらの変換器には、システム論理変換器２３２、ユーザーインターフェース変換器２３４、データベース生成器２３６、およびドキュメンテーション生成器２３８などを含んでもよい。
【００３０】
一つの実施例の動作の間に、アプリケーションの概念モデルを特定する必要要件２００は、ＣＡＳＥツール２１０により表示される図やテキストインタラクティブダイアログを使って集められる。好ましくは、ＣＡＳＥツール２１０は、テキストのみの形式方法の使用に通常伴う複雑さを避けるために、オブジェクト指向のモデリング技術を用いる。実施の一例において概念モデルは、オブジェクトモデル、動的モデル、機能モデル、そして表示モデルの、４つの補完的なモデルに細分される。これらのモデルについては本文で後により詳しく説明する。必要要件２００を集めた後、ＣＡＳＥツール２１０は、たとえば、スペインのヴァレンシア工科大学で開発された、情報システム用のオブジェクト指向の言語であるＯＡＳＩＳ言語のような形式仕様言語に基づき、入力条件を形式仕様２１５として保存する。その形式言語により定義された拡張文法を使用し、検証器２２０は、形式仕様２１５が正しく完全であるか、シンタックス的、セマンティックス面で検証する。形式仕様２１５が検証に合格しなかった場合、アプリケーションを生成することは許可されないので、正しく完全なアプリケーションだけが生成されることになる。
【００３１】
一方、形式仕様２１５が確かに検証に合格すると、その検証された形式仕様２１５に対応する精密な実行モデルを実施するため、「変換器」と呼ばれているいくつかの自動ソフトウェア作成プロセスシステム論理とユーザーインターフェースのもの）が用いられる。特に、変換器２３２と２３４はそれぞれ、Ｃ＋＋、Ｖｉｓｕａｌ Ｂａｓｉｃ、あるいはＪＡＶＡのような高位言語で、アプリケーションのシステム論理とユーザーインターフェースそれぞれのアプリケーションソースコード２０４を作成する。実施の一例では、データーベース生成器２３６もまた、たとえば業界標準のＡＮＳＩ−９２ＳＱＬリレーショナルデータベース管理システム(Relational Database Management System)（ＲＤＭＤＳ）のアプリケーション用のデータモデルを作成する構造化照会言語(Structure Query Language)（ＳＱＬ）スクリプト言語でインストラクションを作成する。
【００３２】
さらに、実施の一例においては、概念モデルに導入された情報からサービス可能なシステムドキュメンテーションを自動的に生成するドキュメント生成器２３８も使用される。
【００３３】
（ＣＡＳＥモデラー）
上記のとおり、ＣＡＳＥツール２１０には、テキストのみの形式方法の使用に通常伴う複雑さを避けるため、オブジェクト指向のモデリング技術を使用するのが好ましい。むしろ、設計者がシステム必要要件を特定できるよう、オブジェクトモデル、動的モデル、機能モデル、および表示モデルの４つの補完的モデルが使用される。しかし、従来の技術とは反対に、ＣＡＳＥツール２１０は実際、設計者がＣＡＳＥツール２１０でシステムを特定している最中に、設計者のシステムの形式仕様を形式仕様言語に基づき取り込む。
【００３４】
この特徴は、従来の方法論にしばしば欠けている、仕様における明確に定義された表現の導入を可能にする。特に、ＣＡＳＥツール２１０は、形式仕様言語でのクラス定義を満たすのに関係のある情報だけが導入されるような制約を強化する。ＣＡＳＥツール２１０によって入力される形式仕様の使用はしたがって、解決の場におけるシステムを検証し、検証するための環境を提供し、本文で後に説明されるように、機能的に仕様と同等なソフトウェア製品を得ることができる。それにもかかわらず、これは、前に述べられたように、常に最も広範囲のモデリング技術に対応するこの外見を保存しながら達成される。このようにして、多くの従来のアプローチの単調な形式主義的特徴は設計者の目につかなくなり、グラフィックモデリング表記の使用により設計者は快適に感じるようになる。
【００３５】
表記に関して、実施の一例における概念的モデリングは、統一モデリング言語（ＵＭＬ）に対応する図を使用する。したがって、情報システムを形作るために、システム設計者が別のグラフィック表記を学ぶ必要はない。広く受け入れられているオブジェクト指向の概念モデリングの原則に基づき、概念モデルは、オブジェクトモデル、動的モデル、そして機能モデルに細分される。しかしながら、完全なアプリケーションはまたユーザーインターフェースをも必要とするため、完全なアプリケーションを特定するために、これら３つのモデルだけでは不十分である。したがって、ＣＡＳＥツール２１０は表示モデルと呼ばれる４つ目のモデルにおいて、後にアプリケーションのためのコードに変換されるユーザーインターフェースパターンについての情報も回収する。
【００３６】
実施の一例では、ＣＡＳＥツール２１０は、異なるアプリケーションに対応するプロジェクトにそってまとめられた情報を収集する。ＣＡＳＥツール２１０によって構築されたそれぞれのプロジェクトは、クラスや、クラス間の関係、グローバルトランザクションやグローバル機能、およびビューについての情報を含むこともできる。
【００３７】
各クラスは、属性、サービス、派生、制約、トランザクション式、トリガー、ディスプレイセット、フィルター、母集団選択パターン(population patterns)、状態遷移図、および形式インターフェースからなる。これらのリストの情報に加え、クラスはまた、名前、別名、およびデフォルト母集団選択インターフェースパターンを保存することもできる。そして、余分な情報は、なぜクラスがモデル内に存在するかについての情報を設計者が入力できるコメントとして保存される。
【００３８】
各属性は、以下のような特徴を持つことができる。名前、形式データタイプ（たとえば定数、変数、派生など）、データタイプ（実数、ストリング）、デフォルト値、属性がクラスのオブジェクトを区別する識別子であるか、長さ、オブジェクトが形成されるとき属性が必要か否か、ＮＵＬＬ値が属性に割り当てられるか、そしてなぜ属性が形成されたかについてのいくつかの注意点を伝えるためのフィールド、である。各属性はまた、イベントによってどのようにオブジェクトの状態が変化するかを宣言する式である評価についての情報を含むことができる。評価式は、以下の部分により構成されている。（その効果を適用するために満たさなければならない）条件、イベント、および特定の属性へのイベントの効果である。属性は、属性に関係する対応するサービス引数に適用される表示モデルに属する、ユーザーインターフェースパターンを含んでもよい。
【００３９】
サービスには、イベントとトランザクションという２つのタイプがある。イベントとは、アトミックイベント(atomic events)であり、トランザクションは、イベントあるいはトランザクションで在り得るサービスよりなる。どのサービスも以下の特徴を持つことができる。名前、サービスの種類（イベントあるいはトランザクション）、サービス別名、注意点およびヘルプメッセージである。イベントは、新規、破壊、およびそのどちらでもない、の3タイプある。イベントはまた、プロジェクトのいくつかのクラスに共有されることも可能である。共有されたイベントはそれを共有するすべてのクラスに属する。トランザクションは、サービスの構成を表す式を有する。この情報に加え、サービスは、引数のリストを保管し、その引数の特徴は、名前、データタイプ、ＮＵＬＬが有効な値と認められるか、引数がオブジェクトの一つのセット（コレクション）を表すか、デフォルト値、別名、および注意点である。また、各引数について、引数に関係するユーザーインターフェースパターンは、導入パターン、母集団選択パターン、定義された選択パターン、および依存パターンである。クラスは、派生についての情報や制約を保存することもできる。各派生は、それぞれの条件下においてどの式が適用されるかを特定する、条件式のペアのリストを特定する。各制約は、しっかりと作られた式に加え、制約が破られたときに表示されるエラーメッセージである。動的制約に関しては、式は、式の評価のガイドをなすグラフへと内部的に変換される。
【００４０】
クラスはさらに、トリガーを保存することができる。個々のトリガーは、自分自身により特定されるトリガーターゲット、クラスまたはオブジェクト、トリガー条件、作動されるトリガーされた動作（サービスに加え、可能なエージェントのリスト）、および関連するサービスの引数と関連するデフォルト値のリストにより構成されてもよい。クラスは、ディスプレイセット、フィルター、およびクラスに影響する表示モデルのユーザーインターフェースパターンとしての母集団選択パターンも有することができる。各ディスプレイセットは、可視化要素（ユーザーに表示される属性）を保存することができる。各フィルターは、しっかりと形成された式、式を限定するのに有効な補助変数のリストより成る。母集団選択パターンは、ディスプレイセットやフィルターに関係している。クラスはまた、クラスとクラスの間の状態と変化のセットである状態遷移図をも有する。それぞれの状態遷移は、オブジェクトの状態を変えることができる動作（サービスに加え、可能なエージェントのリスト）に関係している。動作は、前提条件と対応するエラーメッセージ（前提条件が適用しないと表示される）を有してもよい。前提条件とは、対応する動作が実行されるために満たされねばならない式である。決論を生み出さないトランザクションの場合、決論はぞれぞれのトランザクションに制御条件を付けることにより達成される。制御条件は、どの状態遷移が効果を生じるか特定する式である。最後に、クラスはインターフェースのリストを保存することができる。各インターフェースは、行為者が実行できるサービス（エージェント）のリストと観測可能な属性のリストを保存する。
【００４１】
モデルはまた、クラス間の関係についての情報も維持し、その関係は、集合(aggregation)（「を持つ」または「の一部」）と継承(inheritance)（「である」）の2種類が可能である。それぞれの集合関係は、オブジェクトの構成を示し、そして濃度（その集合関係における参加者の最小と最大の数）、集合が静的であるか動的であるか、集合が包括的であるか参照的であるか、集合が識別依存を有するか、および集合が複数の値である場合の分類項についての情報を取り込む。それぞれの継承関係はオブジェクトの特殊化を示し、親クラスの名前、子クラスの名前、および特殊化が一時的であるか永久的であるかを保存する。最後に、特殊化が永久的ならば、変数属性上のしっかりと形成された式を特殊化条件として保存する。特殊化が一時的な場合は、条件もしくは、子の役割を有効／無効にするイベントのリストを保存する。
【００４２】
最後に、プロジェクトは、グローバルトランザクションのリストを取り込むこともでき、そのリストの中で、保存される関連した特徴は、グローバルインタラクション、式、および引数のリストを含む。グローバル機能のリストの取り込みも可能であり、そのリストの中で、各機能は、名前、返還された値のデータタイプ、引数のセット（サービスに類似）、および機能についてのコメントを保存する。
【００４３】
プロジェクトは、選ばれたエージェントクラスが有するシステムの具体的なビジョンから構成される一つのセットのビューを有する。つまり、ひとつのエージェントクラスに許容される形式インターフェースのセット（属性とサービス）である。それぞれのエージェントクラスは、インターフェースのリストを有する。
【００４４】
（オブジェクトモデル）
オブジェクトモデルは、特にエンティティーのクラスを定義することにより、オブジェクト指向の方法で、システム設計者がアプリケーションで使用されるエンティティーを特定することができるようにするグラフィックモデルである。したがって、クラス定義は、たとえば、属性や、サービス、およびクラス関係（集合と継承）などを含む。加えて、エージェント関係は、一つのクラスのオブジェクトが起動できるサービスを決定するために特定される。
【００４５】
図３は、図書館利用者（ｒｅａｄｅｒ）、本（ｂｏｏｋ）、および貸し出し（ｌｏａｎ）を有する図書館システム用のオブジェクトモデル３００の例を図示する。オブジェクトモデル３００におけるクラスは、３つの部分、すなわちクラスの名前、属性、およびサービスを有する長方形で表されている。この例においてオブジェクトモデル３００は、貸し出しがされた時のために貸し出しコード３１２と貸し出し日３１４を示す属性を有する、貸し出しクラス３１０を含む。貸し出しクラス３００はまた、２つのサービス（方法）を含む。一つは本の貸し出し３１６であり、もう一つは本の返却３１８である。
【００４６】
オブジェクトモデル３００はさらに本クラス３２０を含み、その本クラス３２０は、その本の著者３２２、本コード３２４、状態３２６（たとえば、予約済み、使用中、貸し出し中など）、および新しい本を創設するｎｅｗ＿ｂｏｏｋ３２８のようなサービスを特定する属性を有する。もう一つのクラスは、図書館員クラス３３０であり、その名前３３２は属性によって特定され、ｎｅｗ＿ｌｉｂｒａｒｉａｎサービス３３４により創設されたものである。
【００４７】
図書館に属する各図書館利用者は、図書館利用者クラス３４０で説明され、その属性は、年齢３４２、図書館利用者の借りた本の冊数３４４、および図書館利用者の名前３４６を含む。図書館利用者は、ｎｅｗ＿ｒｅａｄｅｒサービス３４８と創設されてもよい。信頼性のない図書館利用者クラス３５０も、（たとえば、期限を過ぎた貸し出し本の料金の未払いために）信頼することのできない図書館利用者３４０を表示するために、オブジェクトモデルの一部となっている。信頼性のない図書館利用者３５０は、図書館員３３０により免除３５２されることもある。
【００４８】
オブジェクトモデル３００において、継承関係は、クラスを結ぶ矢印によって表される。たとえば、信頼性のない図書館利用者クラス３５０は、図書館利用者クレーム３４０と矢印でつながっている。したがって、信頼性のない図書館利用者クラス３５０は、図書館利用者クレーム３４０から継承をするよう指定される。別の言い方をすれば、信頼性のない図書館利用者クラス３５０は、図書館利用者クレーム３４０のサブクラスである。サブクラスとベースクラスをつないでいる矢印は、専門条件かあるいは、子の役割を起動もしくはキャンセルするイベントで同等にすることができる。オブジェクトモデル３００の例においては、信頼性のない図書館利用者クラス３５０と図書館利用者クラス３４０の間の矢印は、「図書館利用者を罰する／免除する」サービスというラベルを貼られる。したがって、図書館利用者３４０が罰せられると、その人物は信頼性のない図書館利用者３５０になる。反対に、信頼性のない図書館利用者３５０が免除３５２されると、その人物は普通の図書館利用者３４０になる。
【００４９】
集合関係は、与えられたコンポーネントクラスとその合成クラスまでの線で、合成クラス側にダイアモンドのついた線を使うことによって、オブジェクトモデル３００の中に表される。集合は、与えられた入れ物にいくつのコンポーネントが付属できるかや、コンポーネントクラスがいくつの入れ物に関連できるかを決定する。この例においては、本３２０と図書館利用者３４０は、貸し出し３１０に集合される。なぜならば、貸し出し３１０は図書館の図書館利用者３４０に本３２０を貸し出すことに関与するからである。集合の表示(representation)は、両方向における（つまり最小数と最大数の）濃度、役割名、および関係名も含む。この例において、貸し出しから本への、貸し出し：本の関係の濃度は、この概念モデルの中では厳密に一冊の本が一回の貸し出しの対象であるため、１：１であり、本からローンへは、ある時にはちょうど本が貸し出しされているかもしれないし、貸し出されてないかもしれないため、０：１である。
【００５０】
さらに、エージェント関係は、関連するクライアントクラスとサーバークラスのサービスを結ぶ点線であらわされている。この例において、図書館員３３０は信頼性のない図書館利用者クラス３５０の免除サービス３５２のエージェントであり、したがって、免除サービス３５２と図書館員クラス３３０の間に点線がある。これは、図書館員が信頼性のない図書館利用者を免除できることを意味する。もう一つの例では、図書館利用者３４０はまた、本の貸し出し３１６と本の返却３１８のサービスのエージェントである。
【００５１】
最後に、共有されるイベントは、ふたつのクラス間の関連するイベントを結ぶ実線で表されている。この例において、貸し出し＿本のイベントは、本クラス３２０と図書館利用者クラス３４０での前記イベントが実線で結ばれているため、共有されるイベントである。共有されるイベントは、一つのオブジェクト以上に影響を及ぼし、その中で、それぞれのオブジェクトはそのローカル仕様に基づき、その状態を変化させることもある。この例において、貸し出し＿本のイベントは、本３２０の状態を「入手不可能」に変え、図書館利用者３４０の本の数を一つ増加させ、そして貸し出しクラス３１０の場合と、本３２０の集合、および図書館利用者３４０を創設する。貸し出し＿本のイベントは貸し出しクラス３１０の場合を創設するので、集合されたクラスにとって、それは「新しい」イベントとなる。
【００５２】
オブジェクトモデルにおける追加の情報は、クラスの形式説明を完成するために特定される。特に、オブジェクトモデルにおけるすべてのクラスに関して、表１に示すように、以下の情報が取り込まれる。
【００５３】
【表１】
2004506962.tif 000001
【００５４】
集合と継承に関連する追加情報もまた収集される。集められたクラス(aggregated class)については、追加情報は、集合がUML特徴化に基づいた関連か合成であるか、もしくは集合が静的か動的かであるかを特定することができる。継承階層(inheritance hierarchies)については、追加情報は、継承によって成された特殊化が永久的か一時的かを特定することができる。特殊化が永久的であれば、定数属性上の対応する条件が特殊化関係を特徴づけなければならない。一方、特殊化が一時的であれば、変数属性に基づいた条件、あるいは子の役割を有効／無効化するイベントが特定されなければならない。アプリケーションによっては、完全に特定するには多数のクラスを必要とすることもある。その場合、クラスはクラスターとして集めてもよい。クラスターは、一回に一つのクラスターずつ、設計者やシステムアナリストがアプリケーションを理解し易くする。したがって、クラスターは、オブジェクトモデルのビューの複雑さを削減する。
【００５５】
（動的モデル）
システムクラスアーキテクチャーはオブジェクトモデルで特定される。しかしながら、どのオブジェクト寿命が有効とされ得るかや、どのインターオブジェクト通信が設定され得るかなどの追加の特徴はさらに、システム仕様に入力されなければならない。この目的のために、動的モデルは設けられている。
【００５６】
動的モデルは、サービス、トリガー、およびグローバルトランザクションに応じて、オブジェクトの動きを特定する。一つの実施例において、動的モデルは、状態遷移図とオブジェクトインタラクション図という二つの図により表される。
【００５７】
状態遷移図（ＳＴＤ）は、すべてのクラスの有効なオブジェクトライフサイクルを設定することにより、正しい行動を説明するために使用される。有効なライフは、特定のクラスに属するオブジェクトの正しい行動を特徴づける、適切な一連の状態を意味する。遷移は有効な状態の変化を表す。一つの遷移は一つの動作と、オプションとして制御状態、あるいはガードを有する。一つの動作は、一つのサービスに加えて、オブジェクトモデルで定義された有効なエージェントのサブセットにより構成される。すべてのエージェントが選択されると、遷移は星印（＊）を付けられる。制御条件は、与えられた動作の何の決定も生み出さない可能性を避けるための、オブジェクト属性および／あるいはサービス引数上で定義されたしっかりと形成された式である。動作は、その実行を受け入れるために満たされなければならない一つの前提条件を有することもある。丸は、埋め込みの丸を有しており、オブジェクトの存在以前の状態を表す。この状態をソースとする遷移は、創設動作により構成されなければならない。同じように、矢の命中した的はオブジェクトの破壊後の状態を表す。この状態を目的地とした遷移は、破壊動作により構成されなければならない。中間の状態は、状態の名前の付いた丸により表される。したがって、状態遷移図は、オブジェクトのさまざまな状態と状態間の遷移のグラフィックな表現である。図４Ａは、本発明の一実施例による状態遷移図４００の例を図示する。状態は、状態名を貼られた丸により、状態図４００の例では表されている。図４Ａを参照に、「本０」状態４０４は、「本０」という名を付けられた丸により示されている。オブジェクトが生まれる前に、対応する創設動作の名の付いた初期遷移４１０のソースであるこの存在していない状態を表すために、空の丸４０２が使用される。矢の命中した的４０６は、［＊］：破壊＿本動作によって起きる遷移４１６により生じるような、オブジェクトが破壊された後の状態を表すために使用される。
【００５８】
変化は、ソースの状態から目的地の状態への実線の矢印で表されている。遷移矢印の中心には、動作、前提条件、およびガード（実行された場合）を表示するテキストが付けられている。この例において、遷移４１２は、遷移４１２と前提条件である、「もし、状態＝「利用可能であれば」に関連する、貸し出し＿本動作の名でラベルを付けられている。したがって、システムは、本の状態属性が「利用可能」である場合のみ、動作の実行を受け付ける。言い換えれば、概念モデルは、本が利用可能な場合のみ本を貸し出すことができる、ということを要求する。もう一つの例として、遷移４１４は、遷移４１４と前提条件である、「もし、状態＝「貸された」に関連する返却＿本動作の名を付けられる。言い換えれば、概念モデルは、本が貸し出された場合のみ本を返却することができる、ということを要求する。オブジェクトインタラクション図は、インターオブジェクト通信を特定する。トリガーとグローバルトランザクションの２つのインタラクションが定義される。トリガーとは、前もって特定された条件が満たされた時に自動的に作動するオブジェクトサービスで、グローバルトランザクションとは、それら自身が、異なったオブジェクトのサービスおよび／あるいはその他のグローバルトランザクションに関与するサービスである。すべてのクラスに対して、一つの状態遷移図があるが、以前のインタラクションがグラフィックに特定される場である概念モデル全体に対しては、唯一つのオブジェクトインタラクション図しかない。
【００５９】
一つの実施例においては、下線の引かれた名前の付いた箱はクラスオブジェクトを表す。トリガー仕様は、目的地：：トリガー条件であれば動作、というシンタックスに従う。トリガーの第一のコンポーネントは目的地で、つまりトリガーされたサービスが対象とするオブジェクトである。トリガーの目的地は、条件が満たされる場である同じオブジェクト（つまり自分自身）、特定のオブジェクト、もしくはサービスをブロードキャストする場合は、一つのクラス母集団全体であってもよい。最後に、トリガーされたサービスとその対応するトリガー関係が宣言される。グローバルトランザクションは、宣言されたインタラクションに関与する動作を結びつけることにより、グラフィックに特定される。これらの動作は、それらを供給するオブジェクト（箱）をつなぐ実線で表されている。
【００６０】
それゆえに、オブジェクトと活動ルール間の通信は、グラフィックの箱、グラフィックのトリガー、およびグラフィックなインタラクションを表示するオブジェクトインタラクション図に説明されている。図４Ｂは、本発明の一実施例に基づくオブジェクトインタラクション図４２０の例を図示する。
【００６１】
オブジェクトインタラクション図４２０において、グラフィックインタラクションは、グラフィックインタラクションのコンポーネントの線によって表されている。図書館利用者箱４２２のようなグラフィックな箱は、この場合、図書館利用者のようなオブジェクトを（個々にもしくは総称的に）参照する特別な箱として宣言される。グラフィックトリガーは、実行するサービスとトリガー条件を示すテキストを有する実線を使って表されている。グラフィックインタラクションのコンポーネントもまた、実線を使用している。それぞれは、インタラクションの数と実行される動作を示すテキストを有する。この例においてトリガー４２４は、一人の図書館利用者がその時に借りている本の数が１０に達すると発動する図書館利用者を罰する動作をあらわす。
【００６２】
（機能モデル）
多くの従来のシステムは、機能モデルを供給する際にショートカットを取るが、これは機能仕様の正確さを制限する。時に、使用されるモデルは、機能モデルとして構造化されたＤＦＤの使用を提案したＯＭＴの初期版で起こったように、オブジェクト指向のモデルの同次性(homogeneity)を破壊する。オブジェクトモデリングの状況におけるＤＦＤ技術の使用は、主にそれが他のモデル（オブジェクトの観点）と異なったシステムの観点（機能の観点）を提供するという理由で、不正確であると批判されてきた。その他のモデルは、システム動作の自由仕様を設計者の手に託しているが、それは不一致につながる。
【００６３】
しかしながら、本発明の一実施例では、これら従来のアプローチとはまったく異なった機能モデルを使用する。この機能モデルにおいて、オブジェクトの状態の変化に関連するセマンティックスは、イベント発生の結果として取り込まれる。これを行うために、以下の情報が、宣言的に特定される。すべてのイベントが、関与するイベントの引数によってどのようにオブジェクトの状態を変化させるかと、そのオブジェクトの最新の状態である。これは、「評価(valuation)」と呼ばれる。
【００６４】
特に、機能モデルは、評価の分類の概念を使用する。プッシュポップ、状態独立(state-independent)、および個別の領域(discrete-domain)によるという３種類の評価が定義される。それぞれの種類は、その機能性を定義するのに必要な情報のパターンを決定する。
【００６５】
プッシュポップ評価は、それらの関連するイベントが属性の値をある一定の量増加したり減少したりする、もしくは属性をある値に再設定するものである。
【００６６】
状態独立評価は関与する属性に対し、以前の属性の値とは独立的に新しい値を与える。
【００６７】
個別の領域評価は、属性の前回の値に基づき、限定された領域から、属性に対し一つの値を与える。この領域の異なった値は、属性に可能な有効な状況を作る。
【００６８】
これらの特徴を図示するため、表２は、通常の図書館を表す概念モデルにおける、図書館利用者クラス３４０の「本ナンバー」属性３４４の機能モデルを示す。
【００６９】
【表２】
2004506962.tif 000002
【００７０】
これらの評価は、これらの関係するイベントが、本＿ナンバー属性３４４の値を一定の量（１）増加したり減少したりするので、プッシュポップとして分類される（１）。この例において、その関係するイベント貸し出し（）は増加する効果を有し、返却（）は減少する効果を有する。
【００７１】
この評価の分類は、完全な形式仕様が自動的に生成されるようにし、完全にイベントの機能性を取り込む本発明の一側面の貢献である。
【００７２】
ゆえに、機能モデルは、一つのクラスの属性の、すべての状態の変化のセマンティックスを取り込む責任を担う。グラフィックな図は無い。テキストの情報は、前に説明された情報構造の対応する部分を満たすインタラクティブなダイアログを通して収集される。図５は、機能モデルの入力を受け取るダイアログの例を図示する。
【００７３】
（表示モデル）
表示モデルとは、ユーザーインターフェースの必要要件を説明するのに使用することができる、前もって定義した概念のセットである。これらの概念は、ユーザーインタフェイスを開発する際に繰り返されるシナリオを抜き出し抽象化することから生じる。これらの繰り返されるシナリオの抽象概念はパターンと呼ばれる。パターンの一つのセットは、パターン言語と呼ばれる。
【００７４】
この意味で表示モデルは、ユーザーインターフェースの必要要件を反映するために設計されたパターンを集めたものである。一つのパターンは、ある特定の限定された領域における、初期状況を与える、繰り返す問題に対して繰り返す解決の明確な説明である。ドキュメント化したパターンは問題の本質と解決の本質を抽象化し、したがって、初期状況と領域に合う問題を解決するために何度も適用されることができる。パターン言語は多数のパターンから構成される。本発明は、どのような特定のパターンのリストにも限定されることはないが、以下は、有用と判明した、いくつかのユーザーインターフェースのパターンの簡単な説明である。サービス表示パターン、例表示パターン、クラス母集団表示パターン、マスター−詳細表示パターン、および動作選択表示パターンなどである。
【００７５】
サービス表示パターンは、サービスがどのように最終的なユーザーに対してデータを要求するかを取り込む。このパターンは、サービス引数の記入を制御し、サービスを始めたり終了したりするための動作を含む。これは、導入パターン、定義選択パターン、母集団選択パターン、依存パターン、ステータス回復パターン、補助情報パターン、および引数分類表示などの、より特定化したインターフェースタスクに当てはまるような、その他の低いレベルのパターンに基づく。
【００７６】
導入パターンは、最終ユーザー（つまり、最終的なアプリケーションを使用するユーザー）によって、システムに供給されなければならないデータを入力するための制限を取り扱う。特に、編集マスクと範囲値が導入され、有効にインターフェースに入力することができる値を制約する。このパターンは、入力引数を検証することによりデータ入力過程を改善するため、サービスの中の引数、あるいはクラスの中の属性に適用することができる。
【００７７】
定義選択パターンは、引数の有効な値のセットを特定する。入力データ項目が静的で数が限られていて良く知られている場合、設計者はそのような有効な値を含むセットを計数することにより宣言することができる。このパターンは、計数したタイプや選択のデフォルト値を定義するものに類似している。したがって、最終ユーザーは前もって特定されたセットからの登録だけを選択することができ、したがってエラーのでやすい入力を減少することができる。たとえば、このパターンの一つの表現になりえるものは、コンボ箱である。このパターンは、データ入力過程を改善するために、サービスの中の引数、もしくはクラスの中の属性に適用されることができる。
【００７８】
母集団選択パターンは、ディスプレイや、複数のオブジェクトに知らせるオブジェクトの選択を取り扱う。特に、このパターンは、どのようにオブジェクトがフィルターされるか（フィルター表現）、どのデータがディスプレイされるか（ディスプレイセット）、およびオブジェクトがどのように要求されるか（要求基準）をそれぞれ決定する、フィルター、ディスプレイセット、および要求基準を含む。このパターンは、フィルター表現用のｗｈｅｒｅと要求条項用のｏｒｄｅｒ  ｂｙのコラムを有する、ＳＱＬセレクト状態メントとして考えてもよく、存在するオブジェクトのある特定の母集団からオブジェクトを選択することが可能な時はいつでも、サービスにおけるオブジェクトで評価された引数に適用することができる。
【００７９】
依存パターンは、サービスの中の引数間の依存ルールの仕様を許可する、イベント−条件−動作（ＥＣＡ）のセットである。引数が他に依存しているとき、これらの制約はこの種のルールを用いる。
【００８０】
ステータス回復パターンは、サービス引数を初期化するオブジェクト属性からデータを回復する、潜在的に作られたパターンである。これは、依存パターンの潜在的なセットとしてモデル化することもできる。たとえば、カスタマーオブジェクトに関連したデータを変えるために、変化サービスを始める形が現れる。ユーザーがカスタマーＯＩＤ（オブジェクト識別子）を用意すると、インターフェースはオブジェクトを探すためにこのＯＩＤを使用することができ、名前や電話番号、および住所などのカスタマーに関係したデータを回復することができる。
【００８１】
補助情報パターンは、最終ユーザーが、存在するオブジェクトの正しいＯＩＤ（識別されたオブジェクト）を選ぶ、もしくは入力することを確認するために、最終ユーザーに供給されるフィードバックを取り扱う。たとえば、カスタマーを選択するために、ＯＩＤが供給されなければならない。カスタマーの名前がＯＩＤ入力の答えとして自動的にディスプレイされると、ユーザーは、入力データを選択もしくは修正する際に、ユーザーを保証する価値のあるフィードバックデータを受け取る。補助情報パターンは、オブジェクト−評価された引数に適用できる。
【００８２】
引数分類表示パターンは、ユーザーの希望に基づき、要求されたサービス引数をどのように分類するかを取り込む。
【００８３】
例表示パターンは、オブジェクトの特性がどのように最終ユーザーに表示されるかを取り込む。これに関して、ユーザーはサービスを開始、もしくはその他の関連したオブジェクトにナビゲートすることができる。例表示パターンは、一つの例の詳細なビューである。
【００８４】
クラス母集団表示パターンは、一つのクラスの複数のオブジェクトの特性がどのように最終ユーザーに表示されるかを取り込む。この意味において、オブジェクトが一度選択されると、最終ユーザーはサービスを始めることができるか、もしくはその他の関連したオブジェクトにナビゲートすることができるようになる。オブジェクトはまた、フィルターすることができる。
【００８５】
マスター−詳細表示パターンは、オブジェクトの全詳細を完全にする他の関連するオブジェクトを有する一つのクラスの、ある特定の一つのオブジェクトをどのように表示するかを取り込む。このパターンを築くためには、以下のパターンが使用される。例表示、クラス母集団表示、および帰納的に、マスター−詳細表示である。このように、マルチ詳細（複数の詳細）とマルチレベルのマスター詳細（帰納的に複数レベル）をモデルすることができる。たとえば一つのシナリオは、インボイスヘッダー、つづいてそのインボイスに関連したインボイスの一組のラインに関係する。
【００８６】
動作選択パターンは、サービスが段階的なアプローチの原則に従い、どのように最終ユーザーに提供されるかを取り込む。このパターンは、たとえば、ツリー構造を使用し、アプリケーションのメニューを生成できる。最終的なツリー構造は、概念モデルのクラスで特定されたサービスのセットから得られる。ユーザーは、概念モデルで定義されたサービス、もしくは照会（観察）を開始することができる。
【００８７】
フィルター表現は、ブールタイプに対し評価するしっかりと形成された式である。この式は、以下のように解釈される。式を満たすオブジェクトはフィルターを通り抜ける。条件を満たさないものは、フィルターを通り抜けない。結果的に、このフィルターは、式を満たすオブジェクトだけを通すふるいのような役割をする。これらの式は、実行時に解決されるパラメーターを含むことができ、変数の値を供給したり、それらを直接最終ユーザーに聞くことができる。フィルターは、ＳＱＬのｗｈｅｒｅ条項の抽象概念として考えることもでき、母集団選択パターンに適用される。
【００８８】
ディスプレイセットは、オブジェクトのステータスを反映するために示されている、要求された属性のセットである。ディスプレイセットは、ＳＱＬ条項のコラムの抽象化として考えることができ、母集団選択パターンに適用される。
【００８９】
要求基準は、属性と順序（増える順／減る順）を含む、順に並んだ組のセットである。この組のセットは、フィルターされたオブジェクトに対する要求基準を決定する。要求基準パターンは、ＳＱＬ条項による要求の抽象概念として考えることもでき、母集団選択パターンに適用される。
【００９０】
（形式仕様）
ＣＡＳＥツール２１０は、システム必要要件２００を取り込むためにユーザーインターフェースを表示した後、システム必要要件を形式仕様２１５に変換する。特に、ＣＡＳＥツール２１０は、以前に説明されたモデルを開始点として構築され、対応する形式のオブジェクト指向の、高レベルのシステム保存場所の役割をする仕様２１５を自動的に生成する。好ましい実施例においては、使用される形式言語は、１９９５年１０月に、「Servicio de Publicaciones de las Universidad Politecnica de Valencia」（法的保管番号：Ｖ−１２８５−１９９５）により刊行されたオスカー  パスター  ロペスとイシドロ  ラモス  サラバートによるＯＡＳＩＳ２．２版である。
【００９１】
取り込まれたシステム必要要件２００の形式仕様２１５への変換は、本発明の一側面の主な特徴である。概念モデリングのステップで導入されたそれぞれの情報には、形式言語概念として表される、形式対応相手がある。本発明の一実施例に関連するグラフィックなモデリング環境は、したがって形式仕様の上級グラフィック編集機能としてみなされても良い。
【００９２】
したがって、ＯＡＳＩＳ仕様言語の導入の表示をここで、本発明のこの実施例のより詳細な様子として提示する。表３は、自動的に概念モデルから得られた図書館利用者クラスの形式仕様２１５を表す。
【００９３】
【表３】
2004506962.tif 000003
【００９４】
図書館利用者（reader）クラス仕様の例の形式説明を統一する異なった部分の意味を説明する。ＯＡＳＩＳにおけるクラスは、「図書館利用者」というクラス名、クラスの例（オブジェクト）の識別機能、およびすべての例が分け合うタイプもしくはテンプレートによりなる。
【００９５】
識別機能ｂｙ＿図書館利用者＿コード(by_reader_code)は、オブジェクトにより使用される名づけの仕組みを特徴づけ、すでに定義された種類もしくは、ユーザーによって定義された種類（ＯＡＳＩＳにおいてはすなわち領域と呼ばれる）に属するサロゲートを生み出す。これらの領域は、クラス定義にインポートされる。最も通常のものは、ｉｎｔ、ｎａｔ、ｒｅａｌ、ｂｏｏｌ、ｃｈａｒ、ｓｔｒｉｎｇ、およびｄａｔａと前もって定義される。これらはある特定の書式において、数、ブール値(boolean values)、文字、ストリングおよび日付を表す。新しい領域は、対応する抽象データタイプを定義することにより、仕様に導入される。
【００９６】
タイプは、考慮されているクラスの可能なオブジェクトすべてが共有するすべての特性（構造と行動）を収集するテンプレートである。シンタックス面で、タイプは、ソートを含む署名、機能、属性と使用されるイベント、動的論理においては式である公理のセット、ある特定のプロセス代数で解かれるソートプロセスの変数を有する方程式のセットとしてのプロセス照会として形式化することができる。これらの変数が例示される場合、私たちは、インスタンス（オブジェクト）の可能な寿命を表す基礎項(ground terms)を有することになる。
【００９７】
クラス署名は、部分的な要求関係を有するソートのセットを含む。このソートのセットの中に、定義されるクラスに関連する対象となるソート（クラス名）もある。クラス署名はまた、（すでに定義された）ソートの定義の機能や、クラス仕様に暗黙に供給される識別に対するＡＤＴ（抽象的なデータタイプ）であるソートが識別機能に含まれる機能を含む機能のセットも含む。識別機能は、ある特定のクラスのオブジェクトが独自の識別であることを保証するために、オブジェクトを識別するある特定のソートの値を供給する。仕様目的のため、識別は、オブジェクトを確認する別名として使用される一つ以上のキーマップの宣言からなる導入された仕組みである。キーマップは、リレーショナルモデルの候補キー観念に類似する。ある特定のキー値から、これらのマップは、関連したオブジェクト識別を返還する。キーマップは、定数属性（の組）として宣言される。
【００９８】
クラス署名はまた、属性属性のセット（定数、変数および派生）を含む。表３の定数＿属性(constant_attribute)および変数＿属性(valuable_attribute)の項を参照。これらの属性はすべて、領域としてのクラスのソートと、共同領域と考えられる属性に関連したある特定のソートを有する。
【００９９】
イベントのセットはまた、領域としてのクラスのソートに加えイベント情報を表す追加のソート、および共同領域としてのクラスのソート（関心のあるソート）とともに、クラス署名に含まれる（表３の私的イベントと共有イベントを参照）。このいわゆる関心のあるソートは、オブジェクトがプロセスとみなされた場合、全体的なソートプロセスのサブソートとしてみなされることができる。
【０１００】
それぞれのイベントの発生は、それを作動できるエージェントにより名を付ける。この行為者観念を扱う時、もしエージェントＸがイベントａを開始することがＸ：ａと記載され、これが動作と呼ばれると、Ｘは環境、もしくはシステムクラスのオブジェクトとなりえる。一つの実施例において、イベントは常にエージェントと関連している。イベントを定義する時、設計者はしたがって、どのエージェントがそれを作動できるかを決定することを余儀なくされる。結果的に、動作のセットＡはイベントの初期のセットから定義され、入手され、結び付けられる。
【０１０１】
このように、オブジェクトサービスのセットの観念は、その他のオブジェクトがその状態にアクセスできるようにするインターフェースとして表されることができる。オブジェクトサービスは、これらのサービスが提供されたか、あるいは要求されたかによって、イベント（サーバービュー）もしくは動作（クライアントビュー）であり得る。動作は一つのオブジェクトにより要求されたサービスとなり、それによりそのオブジェクトはそのほかのオブジェクトの状態（もしくはそれ自体の状態）を診察、もしくは変更できる。
【０１０２】
ＯＡＳＩＳにおいて、以下のような種類の動的式がある（クラス公理のセット）。
【０１０３】
評価はφ［ａ］φ‘の形式の式であり、このセマンティックスは、基礎動作ａから可能な世界の間の一つの機能を与えるという一つのρ機能を定義することにより、得られる。他の言葉で言えば、いかなる有効な状態のオブジェクトに対しても可能な世界であり、ρ機能は、オブジェクト状態間のどの遷移が、動作ａの実行の後に有効であるかを決定する。この例において、以下のような評価がある。[loan ()] book_count= book_count+1 ; 
[re turn ()] book_count = book_count-1
この動的な論理環境の中で、式φは、ｓ∈Ｗで評価され、φ’はρ（ａ）で評価される。ρ（ａ）は、考慮されている動作のsでの実行の後のオブジェクト状態によって表される世界である。
【０１０４】
派生は、タイプφ ―＞ φ’の式である。これは、ある特定の派生条件（φで記述された）によって派生したド属性φ’を定義する。派生は基本的に、この派生した評価が特有の状態でなされたという点で、評価式とは異なる。
【０１０５】
完全性制約(integrity constoraint)は、すべての世界において満たされなければならない式である。静的と動的な完全性制約は、区別されることができる。静的な完全性制約は、すべての可能な世界に対して定義されているものである。それらは、つねに有効でなければならない。一方、動的な完全性制約は、異なった世界を関係づけるものである。それらは、対応する時間的論理オペレーターとともに、時間的論理の使用を必要とする。
【０１０６】
前提条件は、φが動作ａの実行以前の世界で有効でなければならい式であるテンプレート、┐φ［ａ］ｆａｌｓｅを有する式である。φが有効である世界のみにおいて、ａの発生を許可される。┐φが有効なら、ａの発生は、後続としての状態を生み出さない。私たちは、図書館利用者仕様において、以下のような前提条件を持っている。
book_number=0[librarian:destroy_reader()]false;
あるいは、仕様目的のためにより便利な方法で、私たちは以下のように書くことができる。
librarian:destroy_reader() if book number=0
トリガーは、φ［┐ａ］ｆａｌｓｅの式である。ここで┐ａは動作の否定である。この式は、ａは起こらず、そして何が起こるかは特定されていない、ということを意味する。もしφが有効で、ａ以外の動作が発生すると、後続状態は存在しない。これは、ａの発生を強要するか、もしくは、システムがブロックされた状態にとどまる。たとえば、（オブジェクトインタラクション図４２０が導入されたときに提示された、トリガーエキスプレッシブネスに基づき）目的地についてのトリガーされたサービス情報を含んだ、適切な動的式を使用し、私たちは、以下のことを宣言する。
book_count=10[Self::punish()]false
このトリガーは、仕様目的において、同等ではあるが、より便利な以下の方法で記載されても良い。
Self::punish() if book_count=10
したがって、トリガーは、φに記述された条件が有効なとき作動される動作である。前提条件とトリガーの主な違いは、ある特定の条件が満たされるとすぐに動作を作動させるという義務がトリガー内にあるという事実に由来する。このように、トリガーは、モデル化されるオブジェクト社会における内部活動を導入できるようにする。
【０１０７】
これらの動的式どれにおいても、φとφ’は、考慮される状態もしくは世界において、オブジェクトの属性に付属された値のセットにより特徴ずけられる、ある特定のシステム状態を普通意味する、第一要求論理におけるしっかりと形成された式である。
【０１０８】
ＯＡＳＩＳにおいて、オブジェクトは、観測可能なプロセスと定義される。クラスのプロセス仕様は、私たちが、オブジェクト動的を特定できるようにし、インスタンスの状態間のアクセス関係を決定する。プロセスは、アトミック動作としてイベントを使用することにより、組み立てられる。しかし、設計者はまた、トランザクションとよばれる実行ユニットにイベントを分類するという選択肢を有する。トランザクションである分子ユニットは、二つの主な特性を有する。第一に、これらは、関与するイベントの実行に対して、オール−オア−ナッシングのポリシーに従う。トランザクション実行中に機能不全が起きると、結果として生じる状態は、初期のものとなる。第二に、これらは、中間状態の観察の不可能を示す。
【０１０９】
私たちは、表４の図書館利用者クラスのプロセス仕様を紹介し、このセクションを終える。
【０１１０】
【表４】
2004506962.tif 000004
【０１１１】
プロセスの実行は、プロセスの明確に定義された代数における項として表される。したがって、可能なオブジェクトライフ(object lives)は、コンポーネントがトランザクションとイベントである項として宣言される。すべてのプロセスは、・（シーケンス）と＋（オルタナティブ）プロセスオペレーションを用いて、基礎プロセス代数ＢＰＡ＿δεにおける項に書き換えられることができる。これは、任意のインターリービングに基づき、同時発生の実施を提供する。
【０１１２】
本発明の一実施例による概念モデルと、それに関連したＯＡＳＩＳ形式概念を説明したので、概念モデルで導入されたグラフィックな情報を入力として受け止め、（ＯＡＳＩＳでは仕様である）テキストのシステムリプレゼンテーション２１５を生成するマッピングの説明に入る。この形式仕様２１５は、実際ＣＡＳＥツール２１０を使用し得られたもので、ソース概念モデルで表示されたように、初期必要要件に準拠する最終ソフトウェア製品を得るためのソリッドシステムドキュメンテーションを構成する。
【０１１３】
前項で紹介されたクラス用テンプレートによると、概念パターンとそれらの対応するＯＡＳＩＳリプレゼンテーションのセット。システムクラスは、オブジェクトモデルから得られる。それぞれのクラスにおいて、定数、変数、および派生属性のセット、私的イベントと共有のイベントとローカルトランザクションを含んだサービスのセット、クラス用に特定された完全性制約、および派生属性に対応する派生エキスプレションがある。複雑なクラス（供給された集合と継承クラスオペレーターを使用して定義されたもの）に対して、オブジェクトモデルはまた、対応する複雑に集められた、もしくは特殊化されたクラス用に特定された、特定の特徴を供給する。
【０１１４】
オブジェクトモデルによって与えられた情報は基本的に、クラスの署名が正確に宣言される、システムクラスの骨組みを特定する。動的モデルは、状態遷移図とオブジェクトインタラクション図の二種類を使用する。状態遷移図から、以下のものが取得される。イベント遷移に名を付ける式であるイベント前提条件と、有効なオブジェクトライフのテンプレートが決定されるクラスのプロセス定義である。オブジェクトインタラクション図からは、ＯＡＳＩＳクラス仕様の持つ他の２つの特徴が完成される。異なったオブジェクトに関係する、トリガー関係とグローバルトランザクションである。
【０１１５】
最後に、機能モデルは、評価に関係した動的式を産出し、それで属性に対するイベントの効果を特定する。
【０１１６】
本発明の一実施例に基づき概念モデルに導入できる関連した情報のセットをかくして明確に定義すると、必要要件２００に対応する形式仕様２１５は、ＯＡＳＩＳのオブジェクト指向のモデルに基づき、システム説明が完全に取り込まれる正確なシステムリポジトリーを供給する。これは、実行プロセス（実行モデル）が、関与する情報が意味のある明確な開始点から行われること可能にする。なぜなら、ＯＡＳＩＳにおける形式相手方をさらに有する概念モデルのパターンの限られたリストから、それらが由来するからである。
【０１１７】
（モデル検証）
概念モデルから（Ｃ、Ｃ＋＋、あるいは、ＪＡＶＡのような第三生成言語のような）実施言語への、完全でロバストなアプリケーションの自動ソフトウェア作成において、概念モデルは正しく、そして完全である必要がある。このセクションにおいて、「正しい」および「完全」という言葉は、自動ソフトウェア作成プロセスシステムの特定の必要性によって、以下のような意味を持つ。
【０１１８】
概念モデルは、必要要件仕様に欠けている情報がない場合、「完全」である。つまり、概念モデルのすべての必要とされる特性が定義され、値を有する。
【０１１９】
概念モデルは、概念モデルで導入された情報が、シンタックス面でもセマンティックス面でも一貫しており明確である時、「正しい」。つまり、概念モデルで定義されるすべての特性は有効な値を有する。
【０１２０】
図２に戻ると、検証器２２０は、オブジェクト指向の形式仕様言語（ＯＡＳＩＳのような）を高レベルデータリポジトリーとして使用し、概念モデルの形式仕様２１５を入力として受け取る。形式な視点からは、仕様２１５は明確に定義され断定的で動作可能のセマンティックスを使用しており、形式に動的論理論と同等であるため、検証されたＯＡＳＩＳ仕様２１５は正しく、完全である。
【０１２１】
形式仕様２１５が有効であること、あるいは有効であることを調べることができることを形式環境が保証できるので、形式仕様言語は利益を得ている。形式言語は、言語エキスプレッシブネスを規定する文法を定義する。
【０１２２】
概念モデルの検証には、二つの手順が使用される。完全さについては、検証のルールは、直接概念モデルのために集められたデータを調べることにより執行される。つまり、クラスは名前と、その識別子であるひとつの属性、および一つのサービスを持たなければならない。正確さについては、広範囲の形式言語文法が、概念モデルのすべての式のシンタックスと意味を検証するために執行される。
【０１２３】
（正確さ）
さらに具体的には、正確さについては、形式仕様言語のすべてのコンポーネントが、存在しなければならず、有効な値を持たなければならない特性のセットを有する。特性のほとんどは、完全な定義と有効な値を持つために、厳密に執行される。しかしながら、ＣＡＳＥツール２１０は、モデル入力中の使いやすさのために、いくらか不完全である特性か、もしくは、無効な値を有する特性を残す。これらの特性は、検証器２２０により、自動ソフトウェア作成プロセスの前に、完全（そして正確）であることを調べられる。
【０１２４】
概念モデルを検証するために使用される要素を、次に説明する。それぞれの要素について、検証が厳密であるかどうか（たとえば、生成時に、すべての特性が存在し、有効な値を持たなければならない場合）、あるいはフレキシブルであるかどうか（たとえば、後に検証が達成される）、が述べられる。特性には、オプションであるものもあるが、（たとえば、存在しないかもしれない）それらが定義された場合、それらは検証されなければならない。これらのコンポーネントは、表５にまとめられている。
【０１２５】
【表５】
2004506962.tif 000005
2004506962.tif 000006
【０１２６】
（完全さ）
形式仕様言語におけるコンポーネントのいくつかの特性は、明確なシンタックスに従い精密形成された式である。したがって、概念モデルで導入されたすべての式が、シンタックス面でもセマンティックス面でも正しいことを確実にすることは、必須事項である。
【０１２７】
概念モデルで使用されるすべての式が、同じ目的を有するわけではない。したがって、いくつかのタイプの式が存在する。式のタイプにより、ある特定のオペレーターや項（定数、クラス属性、ユーザーインターフェースなどのようなオペランド）が許される。概念モデルにおける式のすべてのタイプを検証するための、プロセスとルールのセットも文法の中にまた存在する。
【０１２８】
より具体的に、概念モデルは表６に示されるように、以下のようなタイプの式を含む。
【０１２９】
【表６】
2004506962.tif 000007
【０１３０】
これらの式は、導入された時に、式がシンタックス面でもセマンティックス面でも正しくなければ、設計者がインタラクティブテキストダイアログを放置することを防ぐことにより、検証される。
【０１３１】
一般に、すべての式は、シンタックス面で正しくなくてはならない。つまり、すべてのクラスは識別機能と生成イベントを保持しなくてはならず、すべてのトリガーする式はセマンティックス面で正しくなくてはならない。（たとえば、無関係のクラスへのセルフトリガーは禁止されている。）そして、集合のすべての名前は、概念スキーマにおいて固有でなければならない。もしこれらの条件が満たされなければ、エラーが発生する。
【０１３２】
一方、以下のことが当てはまらなければ、警告が発生する。すべてのクラスが破壊イベントを有する場合、すべての派生属性が少なくとも派生式を有する場合、すべてのサービスがそれを実行すると宣言されたエージェントを有する場合、そして、すべてのサービスで宣言された引数が使用された場合である。
【０１３３】
検証プロセスもまた、設計者がひとつ以上の式を無効化し得る変化をモデルに加えるたびに、発動される。前に述べたように、使い易さのために、ある特定のタイプの式は正確でなくてもよいが、設計者が後に見直さなければならない。しかしながら、本発明の一実施例による自動ソフトウェアー作成プロセスは、すべての式が正しくないかぎり、コードの生成を続行しない。設計者が、概念モデル仕様に変更を導入するたびに、影響されるすべての式は検査される。結果として、以下のようなケースが起こりうる。
【０１３４】
１．影響された式の一つでも「厳密な」特性を参照した場合、変更は拒絶される。設計者に告知するためにエラーが表示する。
【０１３５】
２．影響された式すべてが、「厳密な」特性を参照しない場合、概念モデルへの変更は受諾される。動作をとる前に、動作確認ダイアログがディスプレイされる。
【０１３６】
３．影響された式がない場合、変更は直接行われる。ユーザーインターフェース情報を検証するために、検証器２２０は以下のようにエラーを検査する。定義されたパターンは、不可欠の情報が欠けることなくしっかりと組み立てられていなければならない。フィルターに使用される属性は、定義クラスから明らかでなければならない。要求基準で使用される属性は、定義クラスから明らかでなければならない。フィルターの式は、モデルで定義された用語を使用したしっかりと形成された式でなければならない。動作選択パターンは、概念モデルで定義された最終動作オブジェクトとして使用しなければならない。依存パターンのセットは末端となり、合流点を有さなければならない。警告は、次の条件下で生成されてもよい。一つのパターンが定義されても使用（適用）されない場合、あるいはインスタンスパターンが複製された場合である。
【０１３７】
概念モデルからの自動ソフトウェアー作成は、概念モデルが正しく完全である必要がある。形式仕様言語の特徴と特性の適用は、概念モデルを効果的に検証することを可能にする。検証プロセスは、形式仕様言語により定義された文法に基づき、そして部分的な検証は、設計者が概念モデル仕様に変更を導入したときいつでも発動されるようになっている。自動ソフトウェア作成プロセス以前に、概念モデルは前提必須条件として、完全な検証において検証される。
【０１３８】
（変換概観）
検証された形式仕様２１５は、特定の機械表現に関連した実施依存の特徴を扱う実行モデルのためのソースである。特定されたシステムを実施するため、ユーザーがシステムオブジェクトと相互作用する方法が、事前に定義される。一実施例によると、図６で表されている実行テンプレートは、この行動を達成するために使用することができる。図６は、「実行モデル」と言及されているものに従うことにより、形式仕様を完全なアプリケーションに変換する作業の高レベルなビューを図示するフロー図である。
【０１３９】
プロセスは、ユーザーがシステムへログインし、ユーザーの確認をすることにより開始する（ステップ６００）。ユーザーが見えるか作動できるオブジェクト属性とサービスにより決定されるオブジェクトシステムビューが、供給される（ステップ６０２）。ユーザーが接続し、明確なオブジェクトシステムビューを得た後、ユーザーの世界ビューにおいて利用可能なサービスであればどれでもユーザーは作動することができる。これらのサービスの中に、観察（オブジェクト照会）、ローカルサービス、あるいは他のオブジェクトによりサービス提供されたトランザクションが存在する。
【０１４０】
どのサービス起動にも２つのステップがある。メッセージを作ること、そして、もし可能であればメッセージを実行することである。メッセージを作るには、ユーザーは、オブジェクトサーバーを示す情報を供給しなくてはならない（ステップ６０４）。オブジェクトサーバーの存在は、新しいというサービス以外のサービスを実行するための絶対条件である。続いてユーザーは、メッセージを作るために、（必要ならば）作動されているサービスのサービス引数を導入する（ステップ６０６）。
【０１４１】
メッセージが一度送られると（ステップ６０８）、サービス実行は、サービスオブジェクトにおける動作の以下のシーケンスの発生により特徴付けられる。現在のオブジェクト状態で選ばれたサービスのための形式仕様に有効な遷移が存在していることを確かめるために、状態遷移を検査する（ステップ６１０）。サービスに関連した前提条件が適用しなければならないことを示すために、前提条件の達成を検査する。これらどの動作も適用されない場合は、例外となり、メッセージは無視される。
【０１４２】
そうでなければ、プロセスは、検証を満たすことを続行し（ステップ６１４）、そこで誘導されたサービス変更が、関与するオブジェクト状態において行われる。サービス実行がオブジェクトを有効な状態に導くことを確かにするために、最終状態において、完全性制約（ステップ６１６）が確かめられる。制約が適用しないと、例外となり、前回の状態の変更は無視される。状態の有効な変更の後、内部システム活動を表現する条件動作ルールのセットが確かめられる。これらのどれかが適用されると、特定されたサービスがトリガーされる（ステップ６１８）。
【０１４３】
したがって、図６に図示されたステップは、概念モデルで回収されたオブジェクトシステム仕様と、その命令型プログラミング環境における具体化が、機能的に等価であることを保証するために、プログラムの履行をガイドする。
【０１４４】
本発明の一実施例において、ＣＡＳＥツール２１０を補完し自動ソフトウェアー作成システムを構成するために、いくつかの変換器を使用してもよい。たとえば、一つの履行例において変換器は、たとえばインターネットアプリケーションに適した３層構造に基づいてアプリケーションを作成する。特に、それぞれの層に対応して３つの異なった変換器が発動する。システム論理変換器２３２、ユーザーインターフェース変換器２３４、そしてデータベース生成器２３６である。さらに、４つ目の変換器であるドキュメンテーション変換器２３８が使用される。これらの異なった変換器は、作成される出力によって特徴付けられ、潜在的には同じ出力を有するが、それぞれの変換器は、前述の高レベルリポジトリー２１５における情報内の特定のサブセットに焦点を定める。
【０１４５】
（システム論理変換）
システム論理変換器２３２は、高レベルリポジトリーの情報から第３世代プログラミング言語用のコードを自動的に生成する。システム論理変換器２３２の出力は、３層構造の真ん中の層に対応する。
【０１４６】
一実施例において、システム論理変換器２３２は、以下のことを扱うソースコードを作成する。（１）ユーザーインタフェイス機能との通信サブシステム、（２）固定層へのアクセスと固定層との通信、（３）固定層の内容を読むための標準照会サービス、そして（４）固定層とクライアント通信により作成されたエラー取り扱いである。
【０１４７】
通信サブシステムは、クライアントからのリクエストを受け取る、内部方法を発動する、リクエストした者に返答を返す、リクエストされたサービスを行うためにリクエストした者の存在と権限を確かめる、リクエストされたサーバーインスタンスの存在と有効性を確かめる、固定属性のために固定層にアクセスしながら、もしくは派生の属性の値を算出しながらメモリーにリクエストされたサーバーインスタンスのコピーを創設する、概念モデルにおける状態遷移図４００で特定されたように、リクエストされたサービスのための状態遷移を検証する、リクエストされたサービスの前提条件が適用することを確かめる、機能モデルで特定されたように、リクエストされたサービスに関係のあるすべての評価を行う、リクエストされたサーバーインスタンスにより達成された新たな状態のための制約を確かめる、対応する動作を実行するために、トリガー条件を検査する、リクエストされたサーバーインスタンスにおける変更を固定化する、といったことのために構成される。
【０１４８】
さらに、固定層へのアクセスと固定層との通信や、固定層の内容を読み取るためや、固定層により発生したエラーやクライアントとの通信を扱うためのサービス基準照会のために、コードが生成される。一つの履行例では、生成されたコードは、概念モデルの検証された仕様２１５に基づき、表や制約、そしてリレーショナルデーターベースシステム（ＲＤＢＭＳ）におけるデータモデルを定義するインデックスを創設したり、取り除いたりするためのスクリプティングを含んでもよい。
【０１４９】
一実施例において、コード生成の第一段階は、概念モデル２１５の情報の引き出しと、メモリー内のコード生成構造へのこの情報の保存である。３種類の要素が情報の引き出しをガイドする。クラス、グローバルトランザクション、そしてグローバル機能である。概念モデルのクラスから得られる関連のある情報には、名前、定数属性（名前、タイプ、創設時にリクエストされた、そして初期化値式）、変数属性（名前、タイプ、創設時にリクエストされた、初期化値式、そしてＮＵＬＬ値アドミッタンス）、派生属性（名前、タイプ、そして派生式）、識別機能、イベント（名前、引数：名前とタイプ、そして前提条件式）、トランザクション（名前、タイプ、引数：名前とタイプ、前提条件式、そしてトランザクション式）、評価式、状態遷移（初期状態、最終状態、サービス名、有効エージェント、そして遷移条件式）、静的制約式、動的制約式、トリガー条件式、アンセスタークラス（名前）、特殊化クラス（名前、特殊化条件式、前提条件再定義、そして評価再定義）、集合関係（関係するクラス、濃度、静的あるいは動的、そして役名）、そして母集団選択パターン（フィルター：名前とフィルター変数、要求基準）が含まれる。
【０１５０】
概念モデルのグローバルインタラクションから得られる、関係のある情報は、名前、引数（名前とタイプ）、そしてグローバルインタラクション式を含む。概念モデルのグローバル機能から得られる、関連のある情報は、名前、リターンタイプ、そして引数（名前とタイプ）を含む。
【０１５１】
生成されたコードは、概念モデルで見つけられた情報の主なユニット、つまりクラスに基づき、コンポーネントに基づいた構造に従う。概念モデルのそれぞれのクラスは、第一のアプローチにおいて、ソフトウェアーのコンポーネントをいくつか生み出す。たとえば、「サーバーコンポーネント」と呼ばれるコンポーネントは、対応するクラスの署名に存在するそれぞれのサービスに対しての一つの方法より成るインターフェースを有する。対応するクラスの母集団を照会するために必要な方法より成るインターフェースを有するもう一つのコンポーネントは、「照会コンポーネント」と呼ばれる。特定の種類の実行コンポーネントは、概念モデルで定義されたグローバルインタラクションに関係するコンポーネントであり、そのインターフェースは、一つのグローバルインタラクションにつき、一つの方法で構成されている。
【０１５２】
これらのコンポーネントは、第二もしくは中間層が、第一もしくは表示層に提供する二つのアクセスポイントを構成する。サーバーコンポーネントは、サービスの実行に関係する表示層からリクエストを受け取り、照会コンポーネントは、固定層を照会することに関係する表示層からリクエストを受け取る。これは、インターネットで展開するアプリーケーションに適切である。なぜならば、コンテキストフリーで、拡張可能で、トランザクション的な解決を可能なものとするからである。しかし、生成されるコンポーネントは、これだけではない。
【０１５３】
概念モデルのクラスに直接関わるもう一つの生成されるコンポーネントは、「実行コンポーネント」と呼ばれるもので、それは、対応するクラスの署名でのそれぞれのサービスの解決あるいは実行の責任を担う。このコンポーネントは、その対応するサーバーコンポーネントからか、あるいはその他の実行コンポーネントからリクエストを受け取る。
【０１５４】
実行コンポーネントの主な目的は、クラス署名で提供されたサービスを解決することであるため、実行コンポーネントがその他のコンポーネントに表示するインターフェースは、一つのサービスにつき一つの方法より成る。これらの方法のそれぞれは、本発明の一実施例に基づき、実行モデルにより、構成される。
【０１５５】
言い換えれば、実行コンポーネントは、以下の作業の責任を担う。リクエストされたサーバーインスタンスの存在と有効性を確かめること、定数と変数属性の値を取り出すために、（前述の対応する照会コンポーネントで）固定層にアクセスして、メモリにリクエストされたサーバーインスタンスのコピーを創設すること、概念モデルにおける対応する状態遷移図で特定されたように、リクエストされたサービスの状態遷移とリクエストされたサーバーインスタンスの現状を検証すること、リクエストされたサービス前提条件の達成度を確かめること、概念モデルの機能モデルで特定されたように、サービスにより影響されたすべての評価を行うことにより、インスタンス変数属性の値を変更し、したがって、リクエストされたサーバーインスタンスの状態を変えること、静的と動的制限
を確かめることにで、リクエストされたサーバーインスタンスにより達成された新しい状態を検証すること、必要なときにどの動作がトリガーされるべきかを決定するために、トリガー条件をテストすること、リクエストされたサーバーインスタンスのすべての固定属性のために、固定層と通信することである。加えて、クラスがサービスのエージェントであれば、インターフェースにもう一つの方法が加えられるが、その目的はリクエスト者の存在を検証することである。
【０１５６】
もう一つの種類の実行コンポーネントは、概念モデルで定義されたグローバルインタラクションに関係するものであり、そのインターフェースは、一つのグローバルインタラクションにつき、一つの方法で構成されている。
【０１５７】
クラスが継承階層に属する場合、同じ階層のすべての実行コンポーネントは、一つの特別な実行コンポーネントにまとめられる。しかしながら、階層にはなお、一つのクラスにつき一つのサーバーコンポーネントが存在する。
【０１５８】
概念モデルにおけるクラスが生み出すもう一つのコンポーネントは、「Ｔコンポーネント」と呼ばれるコンポーネントである。このコンポーネントは、対応するクラスのインスタンスの定数および変数属性のコピーとともに、その派生属性の値を算出する方法を保存するために使用される。対応する照会コンポーネントは、コレクションを履行し、その項目は、Ｔコンポーネントである。
【０１５９】
概念モデルにおけるクラスが生み出し得るもう一つのコンポーネントは、「Ｐコンポーネント」と呼ばれるコンポーネントである。このコンポーネントは、対応するクラスのインスタンスを創設する際にその定数と変数属性を初期化するために必要な値か、あるいはクラス識別メカニズムを構成する属性の値だけを、メモリーに保存するために使用される。そのようなコンポーネントは、対応するクラスが集合関係の複数値のコンポーネントであるときはいつでも現れる。
【０１６０】
概念モデルにおけるクラスが生み出し得るもう一つのコンポーネントは、「ＰＬコンポーネント」と呼ばれるコンポーネントである。このコンポーネントは、項目がＰコンポーネントであるコレクションを履行するとともに、コレクションからの項目を加えたり取り出すためや、コレクションにおける項目の数を得るのに必要な方法を履行する。そのようなコンポーネントは、対応するクラスが集合関係の複数値のコンポーネントであるときはいつでも現れる。
【０１６１】
概念モデルにおけるクラスが生み出し得るもう一つのコンポーネントは、「Ｃコンポーネント」と呼ばれるコンポーネントである。このコンポーネントは、対応するクラスのインスタンスを創設する際に、その定数と変数の属性を初期化するために必要な値を、メモリーに保存することに使用される。そのようなコンポーネントは、対応するクラスが一時的あるいは永続的で、条件に基づいた特殊化であるときはいつでも現れる。
【０１６２】
追加のコンポーネントは、ＣＣコンポーネント、エラーコンポーネント、トリガーコンポーネント、トリガーリストコンポーネント、インスタンスリストコンポーネント、条件コンポーネント、分離コンポーネント、そして結合コンポーネントを含む。
【０１６３】
ＣＣコンポーネントは、少なくとも一つの一時的、あるいは永続的な、条件に基づいた特殊化が概念モデルに存在するときはいつでも現れる。ＣＣコンポーネントは、項目がＣコンポーネントであるコレクションを履行し、コレクションに項目を加えたり取り出したりする一組の方法（生成された一つのＣコンポーネントにつき、一つの組）を履行し、そしてコレクションにおける項目の数を得る方法を履行する。
【０１６４】
エラーコンポーネントは常に現れ、サービス実行の成功あるいは失敗についての情報を保存することに使用される。トリガーコンポーネントは、対応する動作が後に実行されることができるように、満たされたトリガー条件についての情報を保存する。トリガーリストコンポーネントは、項目がトリガーコンポーネントであるコレクションを履行するとともに、項目をコレクションに加え、項目をコレクションから取り出し、最初の項目を取り出し、そしてコレクションにおける項目の数を得るための方法を履行する。
【０１６５】
インスタンスリストコンポーネントは、項目が与えられたサービスの実行において作動する実行コンポーネントであるコレクションを履行する。項目をコレクションに加え、項目を取り出し、そしてコレクションにおける項目の数を得るために使用される方法に加えて、このコンポーネントはその識別機能によりインスタンスを探すために、かかるコレクションともう一つコレクションを空にするための方法を履行する。
【０１６６】
条件コンポーネント、分離コンポーネントそして結合コンポーネントは、常に生成され、固定層に照会するために使用され、分離の結合として構成されている複雑なブール表現の構造をサポートする。条件コンポーネントは、単純ブール条件、つまり二つのオペランドとオペレーター（＋、−、＊、／、＝、＜＞、＜、＜＝、＞＝、＞．．．）についての情報を保存する。分離コンポーネントは、項目が条件コンポーネント（つまり条件の分離）であるコレクションを履行するとともに、条件をコレクションに加えたり取り出したりする方法と、コレクションにおける条件の数を得る方法も履行する。結合コンポーネントは、項目が分離コンポーネント（つまり分離の結合）であるコレクションを履行するとともに、分離をコレクションに加えたり取り出したりする方法と、コレクションにおける分離の数を得る方法も履行する。
【０１６７】
さらに、二つのモジュールもまた生成される。属性と、生成されたコードから共有された方法を分類するためのグローバルモジュールと、概念モデルで定義されたすべてのグローバル機能のコードを分類するグローバル機能モジュールである。
【０１６８】
（変換戦略と構成）
一実施例に基づき、コード生成は、高レベルなリポジトリー２１５から引き出された情報により行われる。変換プロセスは、４つの段階に分けることができる。概念モデルの検証（検証器２２０により行われる）、対応するデータモデルの、リレーショナルデータベース管理システムへの変換（データベース生成器２３６により行われる）、概念モデルからの情報の引き出しおよびこの情報のメモリー構造への保存、そして最後に、メモリーの保存された情報からのファイルの生成（たとえばメモリー構造内の情報を読み取り、ターゲットプログラミング言語でコードを生成する）である。
【０１６９】
概念モデルの検証は必須であるが、データモデル変換はオプションである。しかし、両方とも、コード生成に厳粛に関係した他の二つの段階に対する、前提条件として考えられることができる。変換構造は、概念モデルからの入力情報を保存するように設計され、すべての構造は、ターゲットのプログラミング言語でソースコードを生成するために、この情報を使用する方法を有する。
【０１７０】
これらの変換構造は、以下の物を含む。サーバーコンポーネントを生成するために必要な情報を保存するクラス（サーバークラス）、グローバルインタラクションのためのサーバーコンポーネントを生成するために必要な情報を保存するクラス（グローバルインタラクションサーバークラス）、実行コンポーネントを生成するために必要な情報を保存するクラス（分析クラス）、グローバルインタラクションのための実行コンポーネントを生成するために必要な情報を保存するクラス（グローバルインタラクション分析クラス）、継承階層のための実行コンポーネントを生成するために必要な情報を保存するクラス（継承階層分析クラス）、照会コンポーネントを生成するために必要な情報を保存するクラス（照会クラス）、Ｔコンポーネントを生成するために必要な情報を保存するクラス（Ｔクラス）、Ｃコンポーネントを生成するために必要な情報を保存するクラス（Ｃクラス）、ＣＣコンポーネントを生成するために必要な情報を保存するクラス（ＣＣクラス）、Ｐコンポーネントを生成するために必要な情報を保存するクラス（Ｐクラス）、ＰＬコンポーネントを生成するために必要な情報を保存するクラス（ＰＬクラス）、概念モデルにおけるすべてのクラスのすべてのサービスのための引数についての情報を保存するクラス（引数リストクラス）、概念モデルにおけるすべてのクラスの識別機能についての情報を保存するクラス（分析クラスリストクラス）、実行コンポーネントにおいてのサービスを決定するために必要な方法を生成するクラス（イベントクラス、共有イベントクラス、トランザクションクラス、インタラクションクラス）、実行コンポーネントと継承階層のための実行コンポーネント両方におけるサービスを決定するのに必要な補助の方法を生成するクラス（前提条件クラス、静的制限クラス、動的制限クラス、など）、照会とＴコンポーネントにおいて必要な方法を生成するクラス（Ｔ方法クラスとＱ方法クラス）、継承特定方法を生成するクラス（継承方法クラス）、そして生成プロセスを監視するクラス（コード生成クラス）である。
【０１７１】
コード生成クラスは、コードを生成するために必要なすべての情報を引き出し、それを適切な順序で行い、生成されたコードをファイルに書き込み、そしてコンポーネントに基づいた構造に基づき、それをきちんとファイルに整理する責任を担う。コード生成クラスは、メモリー内の前述の生成構造のリストを維持し、そしてそのメモリーには概念モデルより引き出された情報が保存され、それは後に、適切なファイルに書き込むために、これらのリストからループする。
【０１７２】
情報引出しプロセスは基本的に、必要なすべての情報を集めるために、概念モデルにおけるクラスを通る一連のループと、グローバルインタラクションを通る一つのループ、そして概念モデルのグローバル機能を通る一つのループから成る。
【０１７３】
コード生成プロセスの最後の段階は、ここで記述するコンポーネントに基づいた構造によるファイルへの書き込みを含む。このプロセスは、コンポーネントとその属性と方法を生成するために必要な情報を維持し、それぞれの要素のコード生成方法を呼び出す、前に説明されたインスタンスのリストを通してループすること、グローバルインタラクション実行コンポーネントを生成すること、グローバルインタラクションサーバーコンポーネントを生成すること、グローバル機能モジュールを生成すること、そしてスタンダードコンポーネントを生成することより成る。
【０１７４】
それぞれのグローバル機能に対して、一つの方法が生成される。その方法は、そのグローバル機能と同じ名前と、一つの変換されたリターンタイプを有する。その方法のそれぞれの引数は、グローバル機能の対応する引数と同じ名前と、一つの変換されたタイプを有する。
【０１７５】
（ユーザーインターフェース変換）
一実施例において、ユーザーインターフェース変換器２３４は、高レベルなリポジトリーにある情報から、Ｖｉｓｕａｌ ＢａｓｉｃやＪＡＶＡのような高級プログラミング言語用のソースコードを自動的に生成する。しかしながら、コードは、計算された言語のどれによってでも生成されうる。その出力は、三層構造の表示層に対応する。したがって、ユーザーインターフェース変換器２３４は、ユーザーインターフェース機能を履行するコンポーネントのソースコードを出力として供給する。このコンポーネントは人の手を借りずに、自動的に生成される。ユーザーインターフェース変換器２３４は、検証された概念モデル２１５を入力データとして使用し、そしてコンポーネントが派生された概念モデルに関係した等価の機能プロトタイプを履行する、第３世代言語で書かれたソースコードを出力データとして提供する。
【０１７６】
本発明の一実施例において、ユーザーインターフェース変換器２３４は、以下のものを行うソースコードを作成する。ビジネスコンポーネントにリクエストを送り、返答を受け取ることができる通信サブシステム、ユーザー確認のためのシステムへのログオン、そして特定の確認されたユーザーが利用できるサービスのメニューである。それぞれの利用できるサービス、フレーム、スクリーン、あるいはすべてのサービス引数のデータコレクションダイアログのために、ユーザーインターフェース変換器２３４は、引数の初期値を設定し、導入されたデータ（タイプ、範囲、オブジェクト存在など）を検証し、そしてサーバー起動を呼びかけるコードを生成する。加えて、ユーザーインターフェース変換器２３４は、一つのクラスにおけるすべてのインスタンスのステータスとエラー取り扱いを一覧表にするスタンダード照会サービスのためのコードも生成する。
【０１７７】
さらに、さらに広範囲でフレキシブルなユーザーインターフェース作業のためのコードが生成される。照会サービスフレーム、フォーム、あるいはスクリーンにおいて、ある特定のインスタンスが選ばれたとき、以下の機能が利用可能になる。それは、関係し選ばれたオブジェクトとの関係を通したナビゲーションである。このナビゲーションは、その関係するリンクに従い、関係するデーター項目の間を閲覧するのに使用される。したがって、結果として生じるコードは、インターネットアプリケーションに適している。追加機能は、選ばれたオブジェクトのサービス起動、フィルター（母集団選択）、ビュー（ステータス選択）、そしてソートのクライテリアを含む上級照会サービス、そして既知のサービス引数を記入するためのコンテクストの維持を含む。コンテキストの維持は、ユーザー設備である。コンテキストは、ユーザーが仕事をする環境に関連したデータである。このデータは、サービス引数のデフォルト値を供給するのに役立つ。
【０１７８】
その入力のために、ユーザーインターフェース変換器２３４は、概念モデルの仕様２１５を読み取り、この種の情報をメモリー内の中間構造に保存する。ユーザーインターフェース変換器２３４は、概念モデルが供給される入力媒体から独立している。このように、中間構造は、異なったデータソースからロードされることができる。このモデルは幾たびか反復され、形式仕様から変換プロセスのそれぞれの段階における、クラスや、集合関係、継承関係、エージェント関係、グローバルインタラクション、ユーザーの定義された機能、そしてインターフェースパターンについての情報などを含む、関係のある情報を引き出す。
【０１７９】
変換されたアプリケーションは、最終ユーザーに提供されるユーザーインターフェースを含むフォームにより構成される。抽象的な意味で、フォームとは最終ユーザーとのインタラクションユニットである。フォームは、たとえば、ウィンドウズ環境のウィンドウズダイアログや、ウェブプラットフォームでのＨＴＭＬページ、そしてＪＡＶＡのアプレットなどのように、必要要件を満たすために、ターゲットの環境の能力に応じて変換される。
【０１８０】
変換されたアプリケーションは、システムにユーザー接続を供給する。ユーザー接続は、エージェントを確認するためにアクセスフォームを使用して解決される。加えて、変換されたアプリケーションは、システムユーザービューを供給する。ユーザーは、ユーザーが開始できるサービスにアクセスすることができなければならない。メインフォームは、この仕事を果たすよう設計されている。ユーザーが実行できるそれぞれのサービスのために、変換されたアプリケーションは、起動サービスフォームを生成する。それぞれのクラス用には、変換されたアプリケーションは、照会／選択フォームを生成する。このフォームは、ユーザーがデータインスタンスに照会し、ある特定の条件を満たすインスタンスを探し、関連したインスタンスを観察し、そしてどのサービスが、その現在の状態におけるある特定のオブジェクトに対して、開始されることができるかを知ることができるようにする。それぞれのサービスに対し、変換されたアプリケーションは、オブジェクト評価された引数の初期化値を提供する。初期データもまた、ユーザーによって作られた閲覧(browse)から得られた情報を管理することにより供給される。
【０１８１】
ユーザーは、アプリケーションと相互作用する、異なったシナリオに遭遇する。これらのシナリオは、異なったタイプのフォームを定義するよう導く。次の項において、フォームのそれぞれの種類が説明される。
【０１８２】
概念モデル２１５において、いくつかのクラスは、サービスクラスのエージェントとして定義される（エージェントクラスと呼ばれる）。つまり、オブジェクトがサービスエージェントならば、そのサービスをリクエストすることを許可される。それぞれのエージェントオブジェクトは、サービスをリクエストしようとする前に、確認され検証されなければならない。アクセスフォームは、エージェントクラス（有効なエージェントクラスのリストより選ばれる）と、オブジェクト識別子、そしてパスワードをリクエストする。回収されたデータは、システムにアクセスすることを許可された有効なエージェントオブジェクトが存在するかどうかを確かめるために使用される。
【０１８３】
アプリケーションメインフォームは、ユーザーが、実行を許されているサービスを見ることができるメニューを含む。ユーザーにより実現されるそれぞれの動作に関連したソースコードは、自動的に生成される。
【０１８４】
少なくとも一つのエージェントのそれぞれのアクセス可能なサービスに対し、サービスフォームが一つ生成される。これらのフォームは、ユーザーが供給しなくてはならないそれぞれの引数の導入フィールドを有する。この引数のフィールドは、データタイプ、サイズ、値の範囲、NULLなどを検証するための付属のコードを有する。オブジェクト評価されたフィールドは、情報を閲覧しそれをフィルターにかけるオブジェクトを探すための設備を供給する。コードは、この仕事を達成するために生成される。
【０１８５】
それぞれのサービス引数は、この初期値を三つの異なった方法で取ることができる。
【０１８６】
１．初期値によって。概念モデルにおいて、設計者は、属性と引数のためにデフォルト値を供給することができる。そのような値が存在すると、その値を供給するために、コードが生成されなければならない。
【０１８７】
２．コンテキストによって。コンテキスト情報（たとえば最近観察されたオブジェクトのリスト）は、引数を回収した同じタイプを有する、オブジェクト評価された引数に、値を示唆することに役立つ。最近訪れたオブジェクトのリストの内から適切な値を探すための機能が生成される。
【０１８８】
３．依存パターンによって。概念モデルにおいて、システム設計者は依存パターンを定義することができる。状態回復パターンは、依存パターンの潜在的なセットでもある。両方の場合において、引数上の変化は、もう一方のパターンにおける値に影響を与えることができる。よって、ある特定の引数値は、このように最初に決定することができる。
【０１８９】
データ検証は、インタラクティブにユーザーに警告しながら、データ入力の後すぐと、システム論理にデータを送る直前に起り得る。オブジェクト評価された引数の検証は、オブジェクトの存在の検査を必要とする。検証をサポートするため、それぞれのサービス引数に対し一つの機能が生成される。この機能は、リクエストをシステム論理に送る前に発動される。
【０１９０】
ユーザーがサービスの実行をリクエストするとき、サービス引数が検証される。サービス引数が有効ならば、システム論理は、そのサービスを達成するために発動される。システム論理を発動するために作られたメッセージは、引数をソートするために形式要求を使用する。サービスを実行した後、ユーザーは、サービスが成功したかどうか告知される。このトランザクションのアプローチは、インターネットアプリケーションにとって理想的である。したがって、引数を検証するコードと、形式要求における必要な引数とともにシステム論理を発動するコードが、生成される。さらに、可能なエラーは、ユーザーに告知するために返還される。
【０１９１】
照会／選択フォームは、オブジェクト（フィルターによって制限することができる）の照会とオブジェクトの選択を許可する。オブジェクトが選択されたとき、ユーザーは、そのオブジェクトに関係するその他のデータ項目に閲覧することができる。同じように、ユーザーは、その選択されたオブジェクトのサービスを開始することができる。
【０１９２】
これらの照会／選択フォームは、フィルターを表示するグラフィック項目を含む。ビジュアルコンポーネントを、クラスの母集団をフィルターするために使用する。フィルターは、変数を含んでいてもよい。そのような場合、変数のためのフィールドが、フィルターの条件を定めるために、ユーザーにリクエストされる。たとえば、車をカラー別、タイプ別、そしてモデル別に見つける、などである。
【０１９３】
これらの照会／選択フォームはまた、オブジェクトを表すためのビジュアルコンポーネントも含む。このコンポーネントの中に、フィルター条件（あるいはフィルターが定義されていない場合は、すべてのクラス母集団）を満たすオブジェクトが現れる。このコンポーネントにおいてディスプレイされる属性は、ディスプレイセットによって設定される。
【０１９４】
これらの照会／選択フォームはさらに、サービスを開始するためのビジュアルコンポーネントを含む。たとえば車を例にすると、ユーザーはその車を借りたり、返したり、あるいは売却したりするためのサービスを開始することができる。この仕事は、どのオブジェクトの、どのサービスを開始するかを決定する機能によって達成される。対応するサービスフォームは、それぞれの明らかにされたサービスに対し発動される。これらの照会／選択フォームはまた、閲覧を開始するためのコンポーネントを含む。たとえば車を例にすると、ユーザーはそのドライバー、そのドライバーの息子などを見ることができる。ユーザーが、ナビゲートするとき（オブジェクトからのリンクを辿り）、新しい照会／選択フォームがディスプレイされる。前回のコンポーネントと同じように、そこには、ユーザーがオブジェクトを閲覧する際にディスプレイされる次のフォームを発動するコードが存在する。ナビゲーションにより照会／選択フォームに到達したとき、フォームは、その最初のオブジェクトに関係したデータだけをディスプレイするために、前のオブジェクトについての情報を受け取る。
【０１９５】
アプリケーションには、訪問されたオブジェクトと、ユーザーによって辿られたナビゲーション通路が保存される。この情報はコンテキスト情報と名づけられる。ユーザーが、照会／選択フォーム間のデータを閲覧する際、辿られた通路は保存される。最後に、ユーザーがサービスを発動しようと試み、サービスフォームが必要とされると、アプリケーションは、サービスフォームへの追加入力として、このコンテキストの情報を供給する。したがって、サービスフォームは、オブジェクト評価の引数に初期値を供給するために、このデータを使用する。
【０１９６】
（ユーザーインターフェース変換器構造）
入力として使用された概念モデル２１５を使用して、ユーザーインターフェース変換器２３４は、照会ＡＰＩあるいはその他の入力ソースを使用して、メモリー構造からの情報、リレーショナルデータベースを引き出すことができる。メモリー内の中間構造は、ユーザーインターフェースコンポーネントを変換するために関連のある概念モデルのデータで満たされている。中間構造は、特定の概念モデルのクラスやサービス、そして属性のために、照会することができる概念モデルスキーマで定義されたものへと一つの構造に従う。
【０１９７】
データが中間構造にロードされる際、真の変換の段階が始まる。生成されたアプリケーションのソースコードファイルの中において、二つのタイプのファイルを区別することができる。一つのファイルは、固定された内容が入ったファイルのセットである。これらのファイルは、常に同じように作成され、広く使用される構造、あるいは補助機能に対応する。これらのファイルは、これらを創設するためにバイトストリームを変換器から最終ファイルへ直接落とすことにより、生成される。その他のファイルは、処理されている概念モデルに大いに依存する。したがって、これらのファイルはしっかりと定義された構造を有するが（前の項で詳しく述べられている）、それらは処理されたモデルによって決まる変数部分を有する。ユーザーインターフェース変換器２３４は概念モデルを反復し、関連するデータを引き出し、これらの変数部分を生成する。
【０１９８】
ユーザーインターフェース変換器２３４の変換プロセスは、以下の作業を含む。
【０１９９】
１．固定されたファイルを生成する。たとえば、ヘッダー、定義、定数、そしてそのそれぞれのファイルへの補助機能など。
【０２００】
２．アプリケーションにより、補助ウィジット（制御あるいはＪＡＶＡ Ｂｅａｎｓ）を生成する。
【０２０１】
３．それぞれのクラスに対し、照会／選択フォーム、インスタンス選択コンポーネント、特殊化コンポーネント（クラスが、その他のクラスから特殊化されると、追加の初期化が必要とされる。）を生成する。それぞれのサービスクラスに対し、サービスフォームも生成する。
【０２０２】
４．アクセスフォームを生成する（識別）。
【０２０３】
５．メニューアプリケーションを含むメインフォームを生成する。
【０２０４】
６．システム論理サーバーと連絡を取るための通信機能を生成する。これらの機能は、プロトタイプにおいて利用可能なサービスの呼び出しをカプセル化する。
【０２０５】
アクセスフォームは、エージェントクラスのリスト（このリストから、ユーザーは一つ選択する）、ユーザーが前回に選択されたクラスに属する有効なオブジェクトインスタンスのためのＯＩＤを供給するフィールド、そしてパスワードのためのフィールドを含む、小さなダイアログボックスである。このフォームは主に固定された方法で生成される。それぞれのモデルによって異なる唯一の部分は、前述のエージェントクラスのリストである。モデルクラスのリストを反復し、どのクラスがエージェントであるかを検査することにより、そのようなエージェントクラスのリストを獲得することができる。
【０２０６】
アプリケーションの機能性にアクセスを供給するために、サービスは、メニューバー（Ｖｉｓｕａｌ Ｂａｓｉｃクライアント）、ＨＴＴＰページ（ウェブクライアント）、あるいは閲覧を許可するその他の構造に変換されるために、アクセス階層に配列される。デフォルトにより、階層は、概念モデルにおけるクラスとサービスを反復することにより作られる。階層は、アプリケーションへのアクセスツリーとして見ることができる。それぞれのクラスのために、クラス別名が付けられた一つのツリー項目が作られる。それぞれの内臓された項目のために、このモードは、降順で、以下の項目を有する。照会フォームにアクセスするための「照会」と名づけられた項目、現在のクラスで定義されサービス別名を付けられたそれぞれのサービスのための項目、そしてその他のクラスとの継承関係を持つ場合は、サブクラス別名を付けられたそれぞれの直接のサブクラスのために、一つの項目が作られる。帰納的に、継承ツリーが完全に調査されるまで、同じアルゴリズムが適用される。
【０２０７】
サービスフォームは、概念モデルから引き出された以下の入力データを必要とする。生成するサービス、サービスクラス、引数リスト、そして引数とリンクされたインターフェースパターンである。それぞれのサービスのために、グラフィックな部分と機能的な部分とを含むフォームが生成される。グラフィックな部分は、ユーザーに聞かなくてはならないそれぞれの引数に付属したウィジット一つと、サービス開始を許可したりキャンセルしたりする一対のウィジットを含む。機能的な部分は、以前のウィジットのためのイベントドライバーを履行し、デフォルト値でこれらのウィジットの特性を初期化し、導入された値を検証し、そしてシステム論理コンポーネントにおけるサービスを発動するためのコードを含む。
【０２０８】
次は、サービスフォームをどのように生成するかの詳細な説明である。最初に、二つの引数リストが得られる。一つ目は、サービス宣言で定義された引数に対応する（ＦＬ、形式リスト）。このリストにおいて、引数は、その形式宣言順序によってソートされる。二つ目は、表示順序によってソートされた、同じ引数を含む（ＰＬ、表示リスト）。二つの順序は共に、概念モデルで特定される。
【０２０９】
形式リストを通してそれぞれの引数のために反復を行う。ユーザーにリクエストされなければならないそれぞれの引数のためのウィジットを一つ作り、タイプ、サイズ、NULLでも良い、導入パターン、定義された選択パターン、あるいは母集団選択パターンのような、引数に関係した特性を設定する。ウィジットは、オーケーコマンドやりキャンセルコマンドのために加えられ、そしてウィジットのグラフィックな部分は重複しないように整理される。一履行において、フォームは縦がｎ欄で横がｎ列のロジカルな格子に分けられ、ウィジットを便利に整理するために左から右、上から下まで位置を割り当てる。ロジカルな位置は、ターゲット言語において、物理的な位置に変換され、フォームの右下の隅に動作コマンドが再整理する。最後に、このフォームは、そこで含まれるデータのサイズに調整するために、再度寸法合わせをされる。
【０２１０】
出力のために、フォームの標準ヘッダーは、ファイルに落とされる。このステップは、選択されたターゲット言語に依存する。それから、フォームのグラフィックな部分は、ベーシックフォーム特性の定義、それぞれのウィジットの定義、そしてウィジットの動作を含み、ファイルに落される。
【０２１１】
最後に、このフォームに付属するソースコードは、変換され、落される。このプロセスには、イベントの開閉や、リソースを割り当てたり取り除いたりするためのコードを作成したりなど、フォームにおけるイベントを管理するための一般的な機能を変換することを含む。また、ステータス回復パターンとウィジット間の依存性を取り扱う機能も変換される。サービスに付属したステータス回復パターンやサービスで定義された可能性のある依存性パターンにより、引数値を変更するコードと、そのような依存性をトリガーするコードを生成しなければならない。検証コードもまた、変換される。ウィジットに集められた値が正しいかを検査するための検証方法が存在する。最後に、システム論理サービスに対し、発動を呼びかけるサービスを変換する機能が生成される。形成されたこの機能は、サービスが実行されるシステム論理オブジェクトについての参照、システム論理におけるサービスを履行する方法の発動、そしてウィジットを通してユーザーから供給された値から構成された、そのような機能に必要な引数を含む。
【０２１２】
照会／選択フォームを生成するために、以下の概念モデルの情報が必要とされる。クラスとその特性（別名）、そしてそのクラスのために定義された母集団選択インターフェースパターンのリストである。それぞれのパターンは、ディスプレイセット、フィルター、そしてソート基準を含む。定義された可視化セットが無い場合、クラスに属する属性のリストを推測する。クラスに母集団選択パターンが欠けていると、以下のデフォルト値が仮定される。クラスで定義されたすべての属性は、ディスプレイセットの一部とみなされ、フィルター（この場合、クラスの全母集団は、返還される）とソート基準のどちらも付属されない。
【０２１３】
照会／選択フォームを生成するには、クラスの関係についての情報も必要とされる。すべてのクラスに対し、この情報に基づきフォームが生成され、そのフォームは、クラスのディスプレイセットの表の表示と、母集団に対するサーチを制限できるようにする、グループ化された一組のフィルター、そして最初のものに関係するクラスと、クラスのインスタンスに対して開始される利用可能なサービスへのナビゲーションリンクを含むポップアップメニューを含む。
【０２１４】
前に説明された、生成されたソフトウェアコンポーネントは、プロトタイプが引き出された概念モデルに対応するプロトタイプを検証し実行するために必要なすべての機能を含む、ユーザーインターフェースクライアント機能を供給する。コンポーネントのアプリケーションは、プロトタイピング、新しい必要要件を取り込む前の概念モデルのユーザー検証、モデルが忠実に必要要件を反映しているかを確かめる分析担当による概念モデルを検証するためのテスト、そして最終のアプリケーション作成である。必要要件の取り込みのプロセスが一度完成すれば、生成されたコンポーネントは、機能的に完全で、エルゴノミックなユーザーインターフェースを履行する最終バージョンとみなすことができる。コンポーネントは殆ど労力なくして、ユーザーの希望に沿ってアプリケーションをカスタマイズするために編集することができる。
【０２１５】
（データモデル変換）
一実施例においては、データベース生成器２３６は、高レベルのリポジトリー２１５の検証された仕様に基づき、リレーショナルデータベース管理システム（ＲＤＢＭＳ）におけるデータモデルを自動的に定義する。しかしながら、フラットファイルや、一連のファイル、あるいはオブジェクト指向のデータベースなど、その他の形態の永続性記憶装置を使用することができる。データベース生成器２３６の出力は、複数層の構造における固定層に該当する。
【０２１６】
ある特定の概念モデルについての、高レベルのリポジトリーにある情報から、表や制限（第一キーと外部キー）、そしてインデックスを創設したり削除したりするために、スクリプトが生成される。スクリプトは、前記のデータモデルを効果的に創設するために、リレーショナルデータベース管理システムにおいて、オプションとして実行することができる。
【０２１７】
リレーショナルデータベースの視点で、データは表に、表間の関係と共に保存される。しかし、オブジェクト指向のプログラミングの視点では、データはオブジェクト階層に保存される。  
本発明の一実施例による自動ソフトウェア作成システムはオブジェクト指向の方法論に基づくが、生成されたアプリケーションにより管理されるデータを、永久的に保存するための物理的なデータ保存システムを見つける必要がある。リレーショナルデータべースはデータを保存するための産業基準方法であるので好まれる。結果的に、オブジェクトの代わりに表を使用することが好まれる。しかしながら、本発明の一実施例により作成されたもののように、多くのオブジェクト指向のアプリケーションは、変換プロセスに続いて、オブジェクトの静的な面を表に保存することができるため、リレーショナルモデルと互換性を持つことができる。
【０２１８】
生成されたデータモデルは、一組の表と、対応する関係と、そして基本キーと外部キーに対する制限とインデックスから成る。生成されたデータモデルは、クラスの仕様で定義された属性と、インスタンスがエージェントならばインスタンスの状態や役割のような、その他のクラスインスタンスの特性とを有するシステムデータを反映する。
【０２１９】
高レベルのリポジトリー２１５から集められた、対応するデータモデルを作成するために必要とされる情報は、クラスに集中し、そして名前、定数属性（新しいか、あるいは受け継いだもの）、変数属性新しいか、あるいは受け継いだもの）、識別機能、受け継いだ識別機能、集合関係（新しいか、あるいは受け継いだもの）、そしてエージェント情報を含む。
【０２２０】
望ましくは、生成されたスクリプトは、標準：ＡＮＳＩ  ＳＱＬ９２に従う。この事実は、生成されたデータモデルは、ＡＮＳＩ  ＳＱＬ９２に基づいたデータベース管理システムであり、特に最も良く知られたリレーショナルデータベース管理システムであれば、どれでも適応することができるということを意味する。
【０２２１】
データモデルを得るためのプロセスは、以下のようなステップを踏む。概念モデルのそれぞれの基本クラスに対し、選ばれたリレーショナルデータベースに、表が創設される。クラス仕様におけるそれぞれの定数あるいは変数属性に対し、クラスに対応する表におけるフィールドが創設される。フィールドデータタイプは、ターゲットのリレーショナルデータベースに変換された、概念モデル属性データタイプに依存する。導出された属性は、それらの値が生成されたサーバーコードの特別な方法によりリクエストされた際に計算されるため、データベースには保存されない。
【０２２２】
基本キーは、概念モデルで識別属性であると示された属性によって決定される。したがって、これらの属性に対応する表フィールドは、表の基本キーを構成する。特別な場合として、特殊化されたクラスに対応する表は、新しい属性を表すフィールドに加えて、属性のアンセスタークラスを表す表の基本キーを構成する属性に対応するフィールドを有する。特殊化されたクラスがそれ自身の識別機能を有さなければ、アンセスタークラスからコピーされたこれらのフィールドは、特殊化された表の基本キーを構成する。同時に、それらのフィールドは、親クラス表に対し、外部キーを構成する。一方、特殊化されたクラスがそれ自身の識別機能を有する場合、これらのフィールドは、親クラス表に対する外部キーのみを構成する。
【０２２３】
集合の場合は、より多くの範囲(dimension)を有するため、より複雑である。集合関係の範囲(dimension)はその濃度を決定し、濃度はデータベースでの表現を決定する。その関係が、両方の意義で多値（Ｍに設定された最大濃度）ならば、新しい表がこの集合関係を表すために加えられる。この表は関係する表の基本キーを構成するそれぞれに対して一つのフィールドを持つ。これらすべてのフィールドのセットは基本キーを成し、フィールドは個々に、それぞれの関係する表の基本キーに由来し、それぞれの関係する表の外部キーを構成する。
【０２２４】
その関係が、一つの意義で単一の値（１に設定された最大濃度）ならば、一方の一つのみのインスタンスと関係するクラスが、その一方の基本のフィールドをコピーする。これらのフィールドは、関係するクラス表への外部キーを構成する。
【０２２５】
その関係が両方の意味で単一の値ならば、どの表も、もう一方への外部キーを有することができる。この場合採用されるオプションは、集合クラスが、コンポーネントクラスを参照することである。最小濃度に関して、最小濃度が０ならば、その対応するフィールドは、NULLを採用する。他の状態では、採用しない。識別依存が二つのクラスの間に存在すると、依存しないクラスの基本キーのフィールドが、依存するクラスに対応する表にコピーされる。それらはその基本キーの一部となり、依存していないクラスの表への外部キーとなる。
【０２２６】
サーチを最適化し応答時間を削減するために、インデックスを生成してもよい。外部キーもサーチインデックスになるように、それぞれの外部キーに対しインデックスが生成される。
【０２２７】
ここまで、オブジェクトの静的な面を取り扱ってきたが、動的な面もまたいくらか検討される必要がある。サービスの属性の値がサービスの状態を特徴付けるため、サービスが起こるたびにオブジェクトの状態が変化することから、サービスの発生はオブジェクトのライフにおける進展(evolution)を特徴付ける。状態遷移図は、オブジェクトの有効なライフを決定する。状態遷移を監視するために、新しいフィールドがクラスに対応するそれぞれの表に加えられ、オブジェクトがある特定の瞬間にある状態遷移図における状態の名前を保存する。
【０２２８】
生成されたアプリケーションは、システムにログオンしているエージェントに、識別とパスワードをリクエストすることにより、ユーザー確認を行っても良い。新しいフィールドが、システムの中のサービスのエージェントであるクラスに対応する表へ加えられ、そのエージェントのパスワードを保存する。
【０２２９】
（ドキュメンテーション変換）
ＣＡＳＥツール２１０は、システムのドキュメンテーションを生成するために使用することができる追加情報を、分析時に導入できるようにする。したがって、ドキュメンテーション生成器２３８は、形式仕様、完全な概念モデル詳細ドキュメンテーション、ユーザーへのヘルプ、そしてその他を含む一組のドキュメントを、高レベルのリポジトリー２１５の情報から自動的に作成する。
【０２３０】
それらの異なった性質のため、形式システム仕様のためには特別の生成プロセスが存在する。残りの作成されたドキュメントは、一般的なデータ処理に拠る。この処理では、同じドキュメントを異なった書式で得ることができ、どんな新しいタイプのドキュメントでも定義することができる。
【０２３１】
ＣＡＳＥツールは、前回に集められた概念モデルから自動的に生成されることができる複数のドキュメントを供給しなければならない。ドキュメンテーション生成器２３８は、概念モデルに対して行われる情報リクエストや照会のための要求に答える。ドキュメンテーション生成器２３８は、企画を適切にドキュメントするために、照会、特定の文書、あるいはしっかりと形成されたドキュメントの生成を可能にする。
【０２３２】
好ましい実施例において、概念モデルの完全な生成は、問題の分析に関係する概念モデルの部分を成すＯＡＳＩＳシンタックスのＡＳＣＩＩ書式で生成されるが、表示モデルインターフェースパターンはこのシンタックスに含まれていない。
【０２３３】
ドキュメント生成器は、デフォルトでは、一般ドキュメント、サービスドキュメント、そしてヘルプドキュメントを供給する。一般ドキュメントは、通常言語での仕様の説明を含む。サービスドキュメントは、クラスとサービスの詳細な説明を含む。ヘルプドキュメントは、生成されたプロトタイプのためのオンラインヘルプを含む。
【０２３４】
ドキュメンテーション生成器は、ターゲット言語として、認識された幾つかの標準書式をドキュメンテーションに使用する。それらは、ＡＳＣＩＩ、プレーンテキスト、複数のドキュメントを有するナビゲーションのＨＴＭＬ、一つのドキュメントを有するナビゲーションのＨＴＭＬ、ＬａＴｅＸ、そしてリッチテキストフォーマット（ＲＴＦ）である。
【０２３５】
このドキュメンテーションシステムは拡張可能で、新しい種類のドキュメントやターゲット言語を追加するために拡張することができる。新しいターゲット言語を加えることにより、すべての定義されたドキュメントが、この新しい言語で生成されることができるようにする。同じように、新しいドキュメントタイプを加えることにより、支援されるどのターゲット言語ででも生成できる。
【０２３６】
形式仕様を作成するために、一つのプロセスが情報構造上を反復し、形式言語における対応するテキストストリングを一つのファイルに書き込む。内部プロセスにおいて、構造上の反復は、（１）仕様ヘッダーを書き込む、（２）説明されるために選ばれるすべてのクラスに対し、その形式テンプレート（属性、イベント、派生、制限、前提条件、トリガー、そしてプロセス）を書き込む、（３）すべてのグローバルトランザクションに対し、その宣言と形式定義を書き込む、（４）エンド仕様書を書き込む、というように詳細であることができる。
【０２３７】
ドキュメントは、中間ブロック言語（ＩＢＬ）で生成される。そのような言語では、ドキュメントはドキュメントタイプの一つのブロックであり、ｎ個の子ブロックを含む。帰納的に自制関係とブロック分類を固定することにより、ドキュメントは、ブロックの構造に基づき定義することができる。ブロックは、以下の特性を含む構造である。名前、カテゴリー、ブロックタイプ、ブロックテキスト、そして含まれるブロックのリストである。
【０２３８】
生成は、ドキュメントにより固定された順序に従い、概念モデルを反復するループを履行するアルゴリズムによりサポートされる。これらの反復においてドキュメントは、ドキュメントを構成するブロックを創設し、そしてリンクしながら作られる。ブロック構造が作られる際、結果として生じる構造であるブロックのツリーは、それを選ばれたターゲット言語のドキュメントに変換する変換器により処理される。この再帰的下降分析を使用したアルゴリズムは、ブロックと含まれたブロックに保存された情報次第で、ターゲット言語のタグにブロックを変換する能力がある。例として、テキスト「タイトル」を含む一つのセクションブロックは、次のストリングＨＴＭＬに同等なものに変換される：＜Ｈ１＞タイトル＜／Ｈ１＞。
【０２３９】
（完全なアプリケーションの生成）
したがって、自動ソフトウェア作成ツールは、情報必要要件を取り込むと説明され、また静的、動的、そして機能の３つの観点から、「ビジネスプロセス」と呼ばれる。これによりシステム設計者とアナリストは、彼らがモデル化する現実のすべての面を完全に取り込まれることができるようになる。
【０２４０】
システム論理変換器は、したがって、正確さと完全さを確かめるために以前にすでに検証される情報のすべてを集める責任を担い、モデル化された現実のすべての面を履行するコードを自動的に作成する。このシステム論理コードは、以下のような特徴を有する。
【０２４１】
システム論理コードは、完全で正確である。システム論理変換器によって集められた情報は以前に検証されているので、作成されたコードは、供給された変換方法のセット(the set of translation recipes)のおかげで、完全且つ正確であることが保証することができる。変換方法のセットは、アナリストによってモデル化され得るすべての面を含み、したがって概念モデルで表現し取り込むことができるすべてのものは、ソースコードに変換することができる。すべての変換方法は正確な変換を保証し、かくしてソースコードにエラーがなくなる。
【０２４２】
システム論理コードはただのプロトタイプのためのものではなく、完全なアプリケーションのためのものである。生成されたコードは、（そのターゲットプログラミング言語による適切なコンパイラーで）コンパイルすることができ、概念モデルの情報入力から完全に変換されているため、「そのまま」で実行することができる。生成されたコードは、ただの方法の骨組を集めたものではなく、完全な方法である。さらに、不必要なコードは作成されず、またコードの一行として一度以上生成されることはない。これに加え、生成されたコードがしっかりと構成されており可読であるが、コメントが内部コードドキュメンテーションの手段として自動的に生成され、可読性を改善する。
【０２４３】
システム論理コードは、ロバストであり、エラーのテストと処理を含む。正確さと完全さが、ロバストなコードの作成を可能にする。概念モデルの情報に基づき、エラーは、二つのカテゴリーに分けられる。モデルエラーつまり内部エラーと外部エラーである。内部エラーは、概念モデルに基づき、ある特定の時点で、適用しなければならない特性に対応する（たとえば、適用しない前提条件、完全性制約、集合関係の最大濃度の違反など）。外部エラーは、概念モデルの一部でない原因に相当する（たとえば、システム機能不全、データベース機能不全など）。
【０２４４】
生成されたコードは、この分類に基づき、以下のようにエラーを処理する。内部エラーについては、システム論理変換器は、内部エラーが起こりえるすべての地点を確認し、エラーテストとエラー処理のコードを作成し、クライアントにそのようなエラーの発生を告知する。さらにまた、内部エラーは分類することができ、カスタマイズ可能なエラーメッセージやエラーコードのような特定の処理を加えることができる。外部エラーについては、システム論理変換器は、外部エラーが起こりえるすべての地点を確認し、エラーテストとエラー処理のコードを作成し、クライアントにそのようなエラーの発生を告知する。外部エラーはカテゴリー化されることができないため、同じ標準の方法で処理される。
【０２４５】
したがって、すべての起こりえる状況に対するエラーテストとエラー処理の自動作成は、概念モデルのどのような変換もロバストであると保証することができる。
【０２４６】
システム論理コードは、トランザクションの行動を取り扱う。生成されたコードは、コードがクライアントにシステムからサービスをリクエストできるようにする明確なインターフェースを供給するという意味で、トランザクションの行動を表示する。それらのサービスは、トランザクション的な方法で実行される。つまりすべてのサービスの入力引数はクライアントによって供給されなければならず、その後システム論理は対応する作業を行いクライアントに返答する。概念モデルにおけるサービスは、動作に分解することができる。生成されたコードは、サービスを構成するすべての動作が首尾良く達成され、さもなくば何も行われないことを保証する。加えて、サービスが分解されてできた動作によって影響されたオブジェクトに対する変化は、これらすべての動作が首尾良く終わるまで、実質的にはおこなわれない。トランザクションの行動はまた、レガシーシステムとの集積化を強化する。
【０２４７】
システム論理コードは、ユーザーインターフェースから独立している。生成されたコードは、クライアントがサービスをリクエストできるようにする、明確なインターフェースを供給する。しかし、このインターフェースは、クライアントがそれと相互作用することに依存しない。これは、異なるクライアントのグループが同じシステム論理と相互作用することを可能にする。したがって、特定のシステム論理のクライアントは、それが彼らに表示するインターフェースのみを知る必要がある。この特徴は、インターネットアプリケーションの展開を簡単にし、またレガシーシステムへの統合と、巨大な情報システム、あるいは概念モデルを、明確なインターフェースを持ちそのためにそれぞれが相互作用できるより小さなものへ分解することがよりよくできるようにする。
【０２４８】
システム論理コードは、固定層(persistence layer)から独立している。生成されたコードは、「固定サービス」とみなされるものを履行する固定層と相互作用する責任を担う。これらのサービスは、固定層における情報を加えたり、引き出したり、改定したり、そして削除したりする責任を担う。これらのサービスは、その作業を実行するシステム論理にとって必要であるが、これに加え、システム論理は、固定層に対する照会を実行するサービスを供給することにより、クライアントに対し、固定層を隠蔽する。これは、クライアントが固定層の物理的な位置を知る必要がなく、固定層に対する照会を実行するサービスを供給されているため、固定層の構造を知る必要がなく、固定層へのアクセスは完全にシステム論理が管理しているため、固定層のアクセスを許可されたユーザーである必要がなく、そして固定層が存在するこさえ知る必要がないことを示唆する。
【０２４９】
要するに、本発明の一実施例の自動ソフトウェア作成システムによって自動的に作成されたコードは、ただのプロトタイプのそれではなく、本当に最終的なソフトウェアアプリケーションのそれに相当する。この識別を維持するために、生成されたシステム論理コードとプロトタイプのそれとの違いの幾つかを説明する。
【０２５０】
（１）完全さ：プロトタイプは、情報システムの機能性を完全に含まず、すべての可能な実行の流れのために意図されている訳ではないが、我々の自動に生成された最終的なアプリケーションとなるコードは、すべての可能な実行の流れと共に、対応する概念モデルで取り込まれた機能性をも完全に含む。
【０２５１】
（２）正確さ：プロトタイプは、ユーザーのニーズと必要要件を確かめ、そして実行の正確さを確かめる目的をもつ。一方、本発明の一実施例に基づく自動的に生成されたコードは正しく生成されているため、ユーザーのニーズと必要要件を確かめる目的をもつ。
【０２５２】
（３）ロバストなこと：プロトタイプは、エラーテストとエラー処理のコードで作成されていないため、ロバストではない。むしろ、このコードは、通常は手作業あり、ユーザーのニーズと必要要件が満たされていることが証明され、したがって、最終アプリケーションが作成されることができる符号化の最終段階まで作成されない。我々の自動的に作成されたコードの場合であるような最終アプリケーションは、ロバストであることを確かめるために必要なすべてのコードを有しなければならない。これは通常、手作業で符号化されるため、プログラマーが、コードを必要な箇所の多くに加え忘れることが多々ある。これは、維持のコストを高いものとし、システム論理コードとエラーテストとエラー処理のコードの間のバランスを崩す。本文で説明されたシステム論理の変換器は、エラーテストとエラー処理に必要な（そして必要ちょうどの）すべてのコードを供給する。
【０２５３】
（４）拡張可能なこと：プロトタイプは、ユーザーのニーズと必要要件を検証するプロセスの間に破棄される傾向にあるため、拡張可能ではない。最終アプリケーションは、プロトタイプよりはるかに長く持続するよう目指しているため、拡張可能である。とはいえ、拡張可能であるということは、設計の段階の間にあるガイドラインに従わなければならないことを示唆する。本発明の実施例で、システムアナリストは拡張可能であることに気を使う必要はない。これはこのような作業が、システム論理変換器２３２の責任に含まれているためである。したがって、アナリストは結果として生じるコードが拡張可能であることを知り、分析事項に集中することができる。さらに、システム論理変換器によって変換された異なった概念モデルは、それらの明確なインターフェースを通して、お互いに相互作用することができる。
【０２５４】
本発明は、現時点で最も実用的で好ましい実施例と関連して説明されてきたが、本発明は発表された実施例に限定されるものではなく、逆に、当然のことながら、付属の請求項の精神と範囲内に含まれるさまざまな改良や等価の処置を含むように意図されていることは理解されるに及ぶものである。
【図面の簡単な説明】
【図１】
図１は、本発明の一実施態様を施行し得るコンピュータシステムを表す。
【図２】
図２は、本発明の一実施態様による、自動ソフトウェア作成システムの上位構造とデータフローを図示する概略ブロック図である。
【図３】
図３は、図書館利用者（ｒｅａｄｅｒ）と、本と、貸し出し（ｌｏａｎ）のついた図書館システム用のオブジェクトモデルの一例を示す。
【図４Ａ】
図４Ａは、本発明の一実施態様による、状態遷移の例を図示する。
【図４Ｂ】
図４Ｂは、本発明の一実施態様による、オブジェクトインタラクションの例を図示する。
【図５】
図５は、機能モデルへの入力を受け取るダイアログの例を図示する。
【図６】
図６は、「実行モデル」と呼ばれるものに従うことにより、形式仕様を完全なアプリケーションに変換する作業の上位の様子を図示するフロー図である。
【符号の説明】
１００  …  コンピュータシステム
１０２  …  バス
１０４  …  プロセッサー
１０６  …  メインメモリー
１０８  …  メモリー
１１０  …  ストレージデバイス
１１２  …  ディスプレイ
１１４  …  入力デバイス
１１６  …  カーソル制御
１１８  …  通信インターフェース
１２０  …  ネットワークリンク
１２２  …  ローカルネットワーク
１２４  …  ホストコンピュータ
１２６  …  インターネットサービスプロバイダー
１２８  …  インターネット
１３０  …  サーバー
２０２  …  自動ソフトウェア作成システム
２０４  …  アプリケーションソースコード
２０６  …  データベーススキーマ
２０８  …  ドキュメンテーション
２１０  …  コンピュータ支援ソフトウェアエンジニアリングツール
２２０  …  検証器
２３２  …  システム論理変換器
２３４  …  ユーザーインターフェース変換器
２３６  …  データベース生成器
２３８  …  ドキュメンテーション生成器