【誤訳訂正書】
【提出日】平成22年6月8日(2010.6.8)
【誤訳訂正１】
【訂正対象書類名】明細書
【訂正対象項目名】全文
【訂正方法】変更
【訂正の内容】
【発明の詳細な説明】
【発明の名称】自動ソフトウェア作成システム
【技術分野】
【０００１】
［発明の分野］
本願発明は、コンピュータシステムに関わり、特に、自動ソフトウェア作成システムとスタンドアロンのシステムやインターネット上のシステムに適した方法論に関わる。
【背景技術】
【０００２】
［発明の背景］
ソフトウェアエンジニアリングとはコンピュータプログラム、アプリケーション、およびその他のソフトウェアシステムの開発とメインテナンスのために、系統的で統制の取れたアプローチを適用することである。世界経済のコンピュータ化の増加にともない、効率的なソフトウェアエンジニアリングの方法論の必要性は、かつてないほど重要になっている。
【０００３】
従来のソフトウェア開発プロセスは多数のフェーズを必要とする。まず、プログラムの条件を、顧客の要求に基づき、通常は書面の仕様書というかたちで指定する。次に、ソフトウェア開発者が、たとえば、データ構造をデザインし、システムロジックをコード化することにより、その条件を満たすためのソースコードを書く。最後に、ソフトウェア開発者は、条件中のエラーやあいまいな点を探し、ソフトウェアコード中のエラーを修理する徹底的なテストとデバッグのフェーズを実施する。起こり得るもっとも深刻な問題の一つは、システム条件を変更しなければならなくなることである。どのような条件の変更でも、ソースコードの再開発が必要であり、すべてのプロセスをもう一度最初からやり直さねばならないからである。したがって、テストとデバッグのフェーズは、ソフトウェアエンジニアリングのプロセスの中で最も長いフェーズであり、完成に要する時間の見積もりが最も難しいフェーズである。
【０００４】
この４０年の間、ソフトウェアエンジニアリングのプロセスの個別の部分を改良する多くの試みがなされてきた。たとえば、ＦＯＲＴＲＡＮ等の最初の高級言語、そしてＡＬＧＯＬ等の構造化されたプログラミング言語の誕生は、システムロジックの構築の負担を軽いものとした。もう一つの例としては、オブジェクト指向の方法論の導入はデータ構造のデザインや実施に役立った。これらの、ソフトウェアエンジニアリングのプロセスにおける改善は、問題の場であるアプリケーションの概念モデルと、解決の場である実際のソフトウェアコードとの間の不適合を減少させた。しかしながら、問題の場と解決の場の不適合はまだいくらかあるため、プログラミングエラーを起こしかねない。そのため、ソフトウェアの欠点を見分け修正する、徹底的なテストとデバッグのフェーズを行う必要がある。
【０００５】
最近、「必要条件分析」と、必要条件の確認と必要条件の明示の段階であるソフトウェアエンジニアリングのプロセスの第一フェーズを容易にするコンピュータエイデッドソフトウェアエンジニアリング（ＣＡＳＥ）の使用に関心が持たれている。特に、これらの方法はソフトウェア技術者が形式に必要条件を指定し、その条件を検証しテストするためのプロトタイプを作ることができるようにする。必要条件がテストされた後、そのプロトタイプは破棄され、ソフトウェア技術者はその必要条件に基づき、完全なソフトウェアアプリケーションを開発する。
【０００６】
一例として知られているのが「ＯＭＴＲＯＬＬ」で、その目的は、オブジェクトモデリングテクニック（ＯＭＴ）に準拠したグラフィック表記法を使って、ソフトウェアデザイナーがシステムの形式仕様を生成するのを支援することである。この仕様はＴＲＯＬＬ仕様言語に基づき、完全なシステム仕様へと改良されなければならない。また、ＯＭＴＲＯＬＬは、グラフィックな概念仕様から独立的に実行可能なプロトタイプを生成することにより、プロトタイプ作成機能を供給するＴｒｏｌｌＷｏｒｋｂｅｎｃｈと呼ばれるＣＡＳＥサポートを有する。その生成されたプロトタイプはシステムの静的勝村勝村かつむら／動的な面を含むＣ＋＋プログラムであり、仕様のリポジトリーとしてＩｎｇｒｅｓｓデータベースを利用する。
【０００７】
ＯＢＬＯＧは、もう一つのオブジェクト指向のソフトウェア開発へのアプローチであり、ヨーロッパのＥＳＰＲＩＴプロジェクトであるＩＳ―ＣＯＲＥ（情報システム−正確さと再利用性）の範囲に当てはまる。ＯＢＬＯＧのセマンティックスはカテゴリーの理論に照らして形式化されている。また、ＯＢＬＯＧは仕様の導入にＣＡＳＥツールを利用し、仕様をプロトタイプ用のコードに書き換えるための再書き込み規則を供給することにより、開発者がプロトタイプを作り上げることを可能にする。その再書き込み規則は、ＯＢＬＯＧによって定められた指定の言語によって書かれてなくてはならない。
【０００８】
形式化のレベルに、より焦点を合わせたもうひとつのアプローチとしては、オブジェクトシステム分析モデル（ＯＳＡ）がある。ＯＳＡの目的は、システムデザイナーが、非形式なものから数学的に厳格なものに亘るまで、違ったレベルの形式化で取り組めるようにする方法を開発することである。この意味において、このような調整可能な形式化は、理論研究者と実施者の両方が同じモデルに取り組めるようにし、モデルと言語の同等化において遭遇する困難を、ある特定の言語のためのＯＳＡに照らして克服することができる。ＯＳＡもまた、ＯＳＡモデルから必要条件を検証するためのプロトタイプを生成することができるＩＰＯＳＴと呼ばれるＣＡＳＥサポートツールを有する。
【０００９】
ＳＯＦＬ（体系的オブジェクトに基づいた形式言語）はまた違ったアプローチを提案し、その目的は、形式方法の統一と、体系的な分析と仕様、そしてオブジェクトに基 づいた方法を使用して、形式方法を、確立されている産業ソフトウェアのプロセスへと統一することを検討することである。ＳＯＦＬは、体系的な様式の必要条件の仕様から、オブジェクトに基づいた様式のデザインへの変換を容易にし、またデザインから適切な様式のプログラムへの変換を容易にする。先の論点のとおり、ＳＯＦＬの提案は、たとえばＶＤＭ（ウイーン開発法）様式のセマンティックス等のような形式方法を、その仕様モジュールに用いて、オブジェクト指向の方法論と体系的技術を結ぶリンクを探し出すことにより、形式方法が産業において広く使用されていないという事実を克服することを試みるものである。しかし、体系的技術とオブジェクト指向の技術を一つの方法に組み合わせることは、その方法のセマンティックスを明確にすることを困難にする。したがって、一貫性の確認には、効果的なツールのサポートが必要である。
【００１０】
さらに別のアプローチとして、ＴＲＡＤＥ（必要条件とデザインエンジニアリング用のツールキット）が知られており、その概念構造は内部の構成要素から外部システムのインタラクションを区別する。ＴＲＡＤＥは、体系的、オブジェクト指向の両方の仕様とデザイン方法からの技術を含む。ＴＲＡＤＥの構造をサポートするために、ＴＣＭ（概念モデリング用のツールキット）と呼ばれるグラフィック編集機能が設けられている。
【００１１】
これらのアプローチは、第一フェーズ、つまりコンピュータアプリケーションがコード化される前に必要条件を改良するフェーズにおいていくらかの助けになるものの、ソフトウェアエンジニアリングのプロセスの後のフェーズ、すなわちプログラミングのフェーズ、およびテストとデバッグのフェーズでの生産性不足の主たる原因には対処していない。たとえば、必要条件が一度確認されると、ソフトウェア技術者は通常これらの方法のほとんどにより生成されたプロトタイプを破棄し、Ｃ++のような標準プログラミング言語で必要条件をデザインし、その条件を実行する。問題の場と解決の場の間の不適合のため、新しく開発されたコードは一般的にコードのエラーを有し、徹底的なテストとデバッグを必要とする。
【００１２】
プロトタイプが破棄されずに最終的なアプリケーションの骨組みとして使用されたとしても、ソフトウェア開発者は、特にユーザーインターフェースの導入とエラー処理のために、追加のコードを開発しなければならない。その場合、プログラマーが書いたコードはやはりテストしデバッグする必要がある。さらにＯＢＬＯＧの規則再書き込みアプローチにおいては、プログラミングに関する難点が一つ前のレベル、未知の独自の言語で規則を書き直す開発にシフトしたに過ぎず、この必要性に対処していない。
【００１３】
その他のアプローチとしてはＲａｔｉｏｎａｌ法やＳｔｅｒｌｉｎｇ法などがあるが、これらは形式言語によるものではない。
【００１４】
したがって、ソフトウェアエンジニアリングのプロセスを改善する必要性、特にプログラミングフェーズやテストフェーズに費やす時間を削減する必要性が長期にわたり切実に感じられている。また、ロバストなソフトウェアアプリケーションを開発する間のプログラミングエラーを低減する方法を探す必要がある。さらに、必要条件が変更された場合に、ソフトウェアアプリケーションのメインテナンスを容易にする必要もある。
【発明の概要】
【００１５】
本発明はこれらの必要性とまたその他の必要性に対処するものであり、そのシステム必要条件は、（たとえばグラフィックユーザーインターフェースなどを通して）捉えられ、形式仕様に変換され、正確性と完全性を検証される。また、その検証された形式仕様に基づいて、完全でロバストなソフトウェアアプリケーションを自動的に生成するトランスレーターが設けられている。検証された形式仕様からアプリケーションのコードを生成することにより、エラーのないソースコードのストラテジーを利用できるようになり、開発者がマニュアルでソースコードを作成したり、不完全なプロトタイプを使用することがなくなる。したがって、従来のソフトウェアエンジニアリングプロセスにおけるエラーを起こしやすいマニュアルでのプログラミングフェーズが排除され、テストとデバッグの時間が大幅に削減される。ひとつの例では、あるアプリケーションのソフトウェア開発にかかった時間は本来の所要時間の２７％にまで削減された。従来のコード化、テスト、そして再検証のサイクルも排除されるため、ソフトウェアメインテナンスもまた低減される。
【００１６】
本発明の一側面は、曖昧さが、C＋＋のような従来のオブジェクト指向の高位のプログラミング言語に関係するプログラミングエラーの主な原因であるという洞察から生まれた。したがって、ユーザーがソフトウェアアプリケーションの明確な形式条件を入力できるように、グラフィックなユーザーインターフェースが掲示される、自動ソフトウェア作成ツール、ソフトウェア、および方法論が備わっている。ソフトウェアアプリケーションの形式条件の入力に基づき、ソフトウェアアプリケーションの形式仕様が作成、検証され、その仕様により、ソフトウェアアプリケーションが生成される。明確な検証済みの形式仕様から直接ソフトウェアアプリケーションを生成することにより、ソフトウェア開発者は、従来のプログラミング言語に伴うプログラミングエラーを避けることができ、かわりに問題の場で直接作業することができる。一つの実施例においては、ロバストな最終的ソフトウェアアプリケーションを作成するためにソフトウェアアプリケーションを生成する時に、エラー処理のインストラクションもまた作成される。
【００１７】
本発明のもう一つの側面は、従来のプロトタイプ作成技術の欠点の主な原因は、これらの技術がユーザーインターフェースの特徴を指定する能力に欠けることであるという認識に基づくものである。したがって、そのような従来のプロトタイプは、顧客が即使用可能な、最終的なソフトウェアアプリケーションの条件を満たさない初期のユーザーインターフェースを有する。それ故、本発明のこの側面は、ソフトウェアアプリケーションの必要条件を指定する概念モデルの形式仕様を含む、自動ソフトウェアアプリケーション作成ツール、ソフトウェア、および方法論に関する。この概念モデルはソフトウェアアプリケーションのユーザーインターフェースのパターンを指定する表示モデルを含む。その表示モデルを指定する形式仕様は検証され、その検証された形式仕様に基づき、ソフトウェアアプリケーションが生成される。結果として、生成されたソフトウェアアプリケーションは、表示モデルが指定したパターンに基づくユーザーインターフェースの処理についてのインストラクションを含む。実際、生成されたソフトウェアアプリケーションのコードは、高容積かつトランザクションに関る拡張可能で信頼できるシステムロジック機能をサポートし、表示モデルにより、クリエイティブデザイナーはユーザーインターフェースのコード化の詳細について懸念せずにすむため、生成されたソフトウェアアプリケーションのコードは、インターネット上の開発に非常に適している。
【００１８】
以下、本発明を最善のかたちで実施すべく意図された実例の詳細な説明により、本発明のその他の目的と効果はさらに明白になる。以下理解されるごとく、本発明はその他異なる例を実施する能力を有し、いくつかの内容は、さまざまな明白な面において、本発明から逸脱することなく変更可能である。したがって、図や説明は、本質的に解説のためのものであり、これらに限定するものではない。
【００１９】
本発明は、添付の図面の例により図解されるが、これらに限定されるものではなく、参照のように、図にある数字は類似する要素を表す。
【図面の簡単な説明】
【００２０】
【図１】図１は、本発明の一実施態様を施行し得るコンピュータシステムを表す。
【図２】図２は、本発明の一実施態様による、自動ソフトウェア作成システムの上位構造とデータフローを図示する概略ブロックダイアグラムである。
【図３】図３は、図書館利用者（ｒｅａｄｅｒ）と、本と、貸し出し（ｌｏａｎ）のついた図書館システム用のオブジェクトモデルの一例を示す。
【図４Ａ】図４Ａは、本発明の一実施態様による、状態遷移の例を図示する。
【図４Ｂ】図４Ｂは、本発明の一実施態様による、オブジェクトインタラクションの例を図示する。
【図５】図５は、機能モデルへの入力を受け取るダイアログの例を図示する。
【図６】図６は、「実行モデル」と呼ばれるものに従うことにより、形式仕様を完全なアプリケーションに変換する作業の上位の様子を図示するフローダイアグラムである。
【発明を実施するための形態】
【００２１】
［望ましい実施例の記載］
自動ソフトウェア作成システムを説明する。以下の説明では、本発明の徹底した理解を提供するため、説明の目的で、数々の具体的な詳細が述べられている。しかしながら、この技術に熟練した者には、本発明がこれらの具体的な詳細なしに実践されることもできるということは明らかだろう。その他の場合においては不必要に本発明を不明瞭にすることを避けるため、周知の構造やデバイスはブロックダイアグラムの形で示されている。
【００２２】
（ハードウェアの概要）
図１は、本発明の一実施例を実現し得るコンピュータシステム１００を示したブロックダイアグラムである。コンピュータシステム１００は、バス１０２、あるいはその他の情報を伝達するための通信メカニズムと、バス１０２と連動した、情報を処理するためのプロセッサー１０４を含む。コンピュータシステム１００はまた、プロセッサー１０４が実行する情報やインストラクションを保存するためのバス１０２と繋がれた、ランダムアクセスメモリー（ＲＡＭ）やその他の動的なストーレッジデバイスのようなメインメモリー１０６を有する。メインメモリー１０６はまた、プロセッサー１０４がインストラクションを実行している間の一時的な変数やその他の中間情報の保存に使用されることもある。コンピュータシステム１００はさらに、プロセッサー１０４の静的な情報とインストラクションを保存するための、バス１０２に繋がれた読み出し専用のメモリー（ＲＯＭ）１０８、あるいはその他の静的なストーレッジデバイスをも有する。磁気ディスクや光学ディスクのようなストーレッジデバイス１１０が設けられており、情報とインストラクションの保管のため、バス１０２に繋がれている。
【００２３】
コンピュータシステム１００はバス１０２経由で、コンピュータユーザーに情報を掲示するためのカソードレイチューブ（ＣＲＴ）などのディスプレイ１１２に繋がれてもよい。英数字やその他のキーを含む入力デバイス１１４は、プロセッサー１０４への情報とコマンド選択の伝達のため、バス１０２に繋がれている。ユーザー入力デバイスのもう一つの形式は、プロセッサー１０４への方向情報やコマンド選択を伝達し、ディスプレイ１１２上のカーソルの動きをコントロールするマウスや、トラックボールや、カーソル方向キーのようなカーソルコントロール１１６である。この入力デバイスは通常一つの面での位置を指定できるように、二つの軸、第一軸（たとえば、ｘ）と第二軸（たとえば、ｙ）において二つの自由度を有する。
【００２４】
本発明は、自動ソフトウェア作成用のコンピュータシステム１００の使用に関する。発明の一つの実施例によれば、自動ソフトウェア作成は、メインメモリー１０６に保存されている一つ以上のインストラクションの中の一つ以上のシーケンスを実行するプロセッサー１０４に応じて、コンピュータシステム１００により成される。そのようなインストラクションは、ストーレッジデバイス１１０のような、もう一つのコンピュータ可読媒体から、メインメモリー１０６に読み込まれてもよい。メインメモリー１０６に保存されているインストラクションのシーケンスが実行されることにより、プロセッサー１０４がここで説明されているプロセスのステップを遂行する。メインメモリー１０６に保存されているインストラクションのシーケンスを実行するために、マルチプロセッシング配列された一つ以上のプロセッサーを使用してもよい。別の実施例においては、本発明を実施するためのソフトウェアインストラクションの代わりか、あるいはインストラクションとの組み合わせで、配線回路を使用することもできる。したがって、本発明の実施例は、ハードウェア回路とソフトウェアの特定な組み合わせに限定されるものではない。
【００２５】
本文で使われている「コンピュータ可読媒体」という言葉は、プロセッサー１０４の実行のためのインストラクションを与えることに関与するいかなる媒体をも意味する。そのような媒体は、不揮発性媒体、揮発性媒体、及び伝達媒体を含むが、それらに限定されず、多くの形状を取ることができる。たとえば、不揮発性媒体は、たとえばストーレッジデバイス１１０のような、光学、あるいは磁気ディスクを含む。揮発性媒体は、メインメモリー１０６のようなダイナミックメモリーを含む。伝達媒体は、バス１０２を構成するワイヤーを含め、同軸ケーブルや銅ワイヤー、及び光ファイバーなどを含む。伝達媒体はまた、ラジオ周波数（ＲＦ）や赤外線（ＩＲ）のデータ通信の間に発生するような音波や光波の形を取ってもよい。コンピュータ可読媒体の一般的な形状は、たとえば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、マグネティックテープ、その他の磁気媒体、ＣＤ−ＲＯＭ、ＤＶＤ，その他の光学媒体、パンチカード、ペーパーテープ、その他の穴のパターンを持つ物理的媒体、ＲＡＭ，ＰＲＯＭ，およびＥＰＲＯＭ，ＦＬＡＳＨ−ＥＰＲＯＭ、その他のメモリーチップあるいはカートリッジ、この後説明する搬送波、もしくはその他のコンピュータが読み取ることができる媒体などを含む。
【００２６】
さまざまな形状のコンピュータ可読媒体は、プロセッサー１０４が遂行するための一つ以上のインストラクションの一つ以上のシーケンスを伝達することに関与してもよい。たとえば、インストラクションは最初に、遠隔のコンピュータの磁気ディスクに在ってもよい。そして、その遠隔コンピュータはそのインストラクションをダイナミックメモリーにロードして、モデムを使って電話線上で送ることができる。コンピュータシステム１００にローカルであるモデムは電話線上のデータを受信し、赤外線信号に変換するために赤外線送信機を使うことができる。バス１０２に繋がれた赤外線検出器は、赤外線信号によって伝達されたデータを受け取り、バス１０２上にそのデータを載せることができる。そして、バス１０２はそのデータをメインメモリー１０６に運び、そこからプロセッサー１０４がインストラクションを取り出し実行する。オプションとして、メインメモリー１０６が受け取るインストラクションは、プロセッサー１０４による実行の前か後のいずれかにストーレッジデバイス１１０に保存されてもよい。
【００２７】
コンピュータシステム１００はまた、バス１０２に繋がれた通信インターフェース１１８を有する。通信インターフェース１１８は、ローカルネットワーク１２２に繋がっているネットワークリンク１２０へ、双方向データ通信を提供する。たとえば、通信インターフェース１１８には、データ通信接続を対応する型の電話線に供給する統合サービス・デジタルネットワーク（ＩＳＤＮ）カード、あるいはモデムなどがある。もう一つの例としては、通信インターフェース１１８は、適したローカルネットワーク（ＬＡＮ）にデータ通信接続を提供するローカルネットワークカードでもよい。ワイヤレス接続も実施可能である。そのような実施のいずれにおいても、通信インターフェース１１８は、さまざまな情報を表すデジタルデータストリームを運ぶ電気、電磁、あるいは光学信号を送り、受け取る。
【００２８】
ネットワークリンク１２０は通常、一つ以上のネットワークを通じて、他のデータデバイスへのデータ通信を提供する。たとえば、ネットワークリンク１２０は、ローカルネットワーク１２２を通して、ホストコンピュータ１２４もしくはインターネットサービスプロバイダー（ＩＳＰ）１２６によって操作されているデータ機器への接続を提供することもできる。かわりに、ＩＳＰ１２６は、今日一般に「インターネット」１２８とよばれているワールドワイドパケットデータネットワークを通して、データ通信サービスを提供する。ローカルネットワーク１２２とインターネット１２８は共に、デジタルデータストリームを運ぶ電気、電磁、あるいは光学信号を使用する。さまざまなネットワークを通る信号や、ネットワークリンク１２０上の信号と通信インターフェース１１８を通る信号は、コンピュータシステム１００と行き来してデジタルデータを運ぶもので、情報を運ぶ搬送波の形状の例である。
【００２９】
コンピュータシステム１００は、ネットワーク、ネットワークリンク１２０、及び通信インターフェース１１８を通し、メッセージを送り、プログラムコードを含むデータを受け取ることができる。インターネットの例において、サーバー１３０は、インターネット１２８、ＩＳＰ１２６、ローカルネットワーク１２２および通信インターフェース１１８を通して、アプリケーションプログラムのための要求されたコードを伝達し得る。本発明に基づいて、そのようなダウンロードされたアプリケーションにより、本文で説明されるように、自動ソフトウェア作成が成される。受信されたコードは、受信されたままの形でプロセッサー１０４により実行されてもよいし、および／またはストーレッジデバイス１１０に保存されてもよいし、もしくはその他の不揮発性保存場所に保存されてもよい。この方法においては、コンピュータシステム１００が、搬送波という形でアプリケーションコードを取得してもよい。
【００３０】
（概念の概要）
図２は、本発明の一実施例に基づく自動ソフトウェア作成システム２０２の、ハイレベル構造とデータフローを図示した概略ブロックダイアグラムである。自動ソフトウェア作成システム２０２は、必要条件２００を入力として受理し、完全でロバストなアプリケーション２０４（システムロジックとユーザーインターフェースコードの両方を含む）とデータベーススキーマ２０６とドキュメンテーション２０８を作成するよう設定されている。実施の一例においては、自動ソフトウェア作成システム２０２は、ユーザーが必要条件を入力できるようにするコンピュータエイデッドソフトウェアエンジニアリング（ＣＡＳＥ）ツール２１０フロントエンドと、入力条件２００を検証するヴァリデーター２２０、および検証された入力条件２００を完全かつロバストなアプリケーション２０４に変換するいくつかのトランスレーターを含む。これらのトランスレーターには、システムロジックトランスレーター２３２、ユーザーインターフェーストランスレーター２３４、データベースジェネレーター２３６、およびドキュメンテーションジェネレーター２３８などを含んでもよい。
【００３１】
一つの実施例の動作の間に、アプリケーションの概念モデルを指定する必要条件２００は、ＣＡＳＥツール２１０により表示される図やテキスト対話型ダイアログを使って集められる。好ましくは、ＣＡＳＥツール２１０は、テキストのみの形式方法の使用に通常伴う複雑さを避けるために、オブジェクト指向のモデリング技術を用いる。実施の一例において概念モデルは、オブジェクトモデル、動的なモデル、機能モデル、そして表示モデルの、４つの補完的なモデルに細分される。これらのモデルについては本文で後により詳しく説明する。必要条件２００を集めた後、ＣＡＳＥツール２１０は、たとえば、スペインのヴァレンシア工科大学で開発された、情報システム用のオブジェクト指向の言語であるＯＡＳＩＳランゲージのような形式仕様言語に基づき、入力条件を形式仕様２１５として保存する。その形式言語により定義された拡張文法を使用し、ヴァリデーター２２０は、形式仕様２１５が正しく完全であるか、シンタックス的、セマンティックス面で検証する。形式仕様２１５が検証に合格しなかった場合、アプリケーションを生成することは許可されないので、正しく完全なアプリケーションだけが生成されることになる。
【００３２】
一方、形式仕様２１５が確かに検証に合格すると、その検証された形式仕様２１５に対応する精密な実行モデルを実施するため、「トランスレーター」と呼ばれているいくつかの自動ソフトウェア作成プロセス（システムロジックとユーザーインターフェースのもの）が用いられる。特に、トランスレーター２３２と２３４はそれぞれ、Ｃ＋＋、ビジュアルベイシック、あるいはＪＡＶＡ（登録商標）のような高位言語で、アプリケーションのシステムロジックとユーザーインターフェースそれぞれのアプリケーションソースコード２０４を作成する。実施の一例では、データーベースジェネレーター２３６もまた、たとえば業界標準のＡＮＳＩ−９２ＳＱＬリレーショナルデータベース管理システム（ＲＤＭＤＳ）のアプリケーション用のデータモデルを作成するストラクチャー質問ランゲージ（ＳＱＬ）スクリプティング言語でインストラクションを作成する。
【００３３】
さらに、実施の一例においては、概念モデルに導入された情報からサービス可能なシステムドキュメンテーションを自動的に生成するドキュメントジェネレーター２３８も使用される。
【００３４】
（CASEモデラー）
上記のとおり、ＣＡＳＥツール２１０には、テキストのみの形式方法の使用に通常伴う複雑さを避けるため、オブジェクト指向のモデリング技術を使用するのが好ましい。むしろ、デザイナーがシステム必要条件を指定できるよう、オブジェクトモデル、動的なモデル、機能モデル、および表示モデルの４つの補完的モデルが使用される。しかし、従来の技術とは反対に、ＣＡＳＥツール２１０は実際、デザイナーがＣＡＳＥツール２１０でシステムを指定している最中に、デザイナーのシステムの形式仕様を形式仕様言語に基づき取り込む。
【００３５】
この特徴は、従来の方法論にしばしば欠けている、仕様における明確に定義された表現の導入を可能にする。特に、ＣＡＳＥツール２１０は、形式仕様言語でのクラス定義を満たすのに関係のある情報だけが導入されるような制約を強化する。ＣＡＳＥツール２１０によって入力される形式仕様の使用はしたがって、解決の場におけるシステムを検証し、検証するための環境を提供し、本文で後に説明されるように、機能的に仕様と同等なソフトウェア製品を得ることができる。それにもかかわらず、これは、前に述べられたように、常に最も広範囲のモデリング技術に対応するこの外見を保存しながら達成される。このようにして、多くの従来のアプローチの単調な形式主義的特徴はデザイナーの目につかなくなり、グラフィックモデリング表記の使用によりデザイナーは快適に感じるようになる。
【００３６】
表記に関して、実施の一例における概念的モデリングは、統一モデリング言語（ＵＭＬ）に対応するダイアグラムを使用する。したがって、情報システムを形作るために、システムデザイナーが別のグラフィック表記を学ぶ必要はない。広く受け入れられているオブジェクト指向の概念モデリングの原則に基づき、概念モデルは、オブジェクトモデル、動的なモデル、そして機能モデルに細分される。しかしながら、完全なアプリケーションはまたユーザーインターフェースをも必要とするため、完全なアプリケーションを指定するために、これら３つのモデルだけでは不十分である。したがって、ＣＡＳＥツール２１０は表示モデルと呼ばれる4つ目のモデルにおいて、後にアプリケーションのためのコードに変換されるユーザーインターフェースパターンについての情報も回収する。
【００３７】
実施の一例では、ＣＡＳＥツール２１０は、異なるアプリケーションに対応するプロジェクトにそってまとめられた情報を収集する。ＣＡＳＥツール２１０によって構築されたそれぞれのプロジェクトは、クラスや、クラス間の関係、グローバルトランザクションやグローバル機能、およびビューについての情報を含むこともできる。
【００３８】
各クラスは、属性、サービス、派生、制約、トランザクション式、トリガー、ディスプレイセット、フィルター、母集団選択パターン、状態遷移図、および形式インターフェースからなる。これらのリストの情報に加え、クラスはまた、名前、エイリアス、およびデフォルト母集団選択インターフェースパターンを保存することもできる。そして、余分な情報は、なぜクラスがモデル内に存在するかについての情報をデザイナーが入力できるとコメントとして保存される。
【００３９】
各属性は、以下のような特徴を持つことができる。名前、形式データタイプ（たとえば定数、変数、派生など）、データタイプ（実数、ストリング）、デフォルト値、属性がクラスのオブジェクトを区別する識別子であるか、長さ、オブジェクトが形成されるとき属性が必要か否か、ＮＵＬＬ値が属性に割り当てられるか、そしてなぜ属性が形成されたかについてのいくつかの注意点を伝えるためのフィールド、である。各属性はまた、イベントによってどのようにオブジェクトの状態が変化するかを宣言する式である評価についての情報を含むことができる。評価式は、以下の部分により構成されている。（その効果を適用するために満たさなければならない）条件、イベント、および特定の属性へのイベントの効果である。属性は、属性に関係する対応するサービス引数に適用される表示モデルに属する、ユーザーインターフェースパターンを含んでもよい。
【００４０】
サービスには、イベントとトランザクションという２つのタイプがある。イベントとは、アトミックな動作であり、トランザクションは、イベントあるいはトランザクションで在り得るサービスよりなる。どのサービスも以下の特徴を持つことができる。名前、サービスの種類（イベントあるいはトランザクション）、サービスエイリアス、注意点およびヘルプメッセージである。イベントは、新規、破壊、およびそのどちらでもない、の3タイプある。イベントはまた、プロジェクトのいくつかのクラスに共有されることも可能である。共有されたイベントはそれを共有するすべてのクラスに属する。トランザクションは、サービスの構成を表す式を有する。この情報に加え、サービスは、引数のリストを保管し、その引数の特徴は、名前、データタイプ、ＮＵＬＬが有効な値と認められるか、引数がオブジェクトの一つのセット（コレクション）を表すか、デフォルト値、エイリアス、および注意点である。また、各引数について、引数に関係するユーザーインターフェースパターンは、導入パターン、母集団選択パターン、定義された選択パターン、および依存パターンである。クラスは、派生についての情報や制約を保存することもできる。各派生は、それぞれの条件下においてどの式が適用されるかを指定する、条件式のペアのリストを指定する。各制約は、しっかりと作られた式に加え、制約が破られたときに表示されるエラーメッセージである。動的な制約に関しては、式は、式の評価のガイドをなすグラフへと内部的に変換される。
【００４１】
クラスはさらに、トリガーを保存することができる。個々のトリガーは、自分自身により指定されるトリガーターゲット、クラスまたはオブジェクト、トリガー条件、起動されるトリガードアクション（サービスに加え、可能なエージェントのリスト）、および関連するサービスの引数と関連するデフォルト値のリストにより構成されてもよい。クラスは、ディスプレイセット、フィルター、およびクラスに影響する表示モデルのユーザーインターフェースパターンとしての母集団選択パターンも有することができる。各ディスプレイセットは、可視化の要素（ユーザーに表示される属性）を保存することができる。各フィルターは、しっかりと形成された式、式を限定するのに有効な補助変数のリストより成る。母集団選択パターンは、ディスプレイセットやフィルターに関係している。クラスはまた、クラスとクラスの間の状態と変化のセットである状態遷移ダイアグラムをも有する。それぞれの状態遷移は、オブジェクトの状態を変えることができるアクション（サービスに加え、可能なエージェントのリスト）に関係している。アクションは、前提条件と対応するエラーメッセージ（前提条件が適用しないと表示される）を有してもよい。前提条件とは、対応するアクションが実行されるために満たされねばならない式である。決論を生み出さないトランザクションの場合、決論はぞれぞれのトランザクションにコントロール条件を付けることにより達成される。コントロール条件は、どの状態遷移が効果を生じるか指定する式である。最後に、クラスはインターフェースのリストを保存することができる。各インターフェースは、アクターが実行できるサービス（エージェント）のリストと観測可能な属性のリストを保存する。
【００４２】
モデルはまた、クラス間の関係についての情報も維持し、その関係は、集合（「を持つ」または「の一部」）と継承（「である」）の2種類が可能である。それぞれの集合関係は、オブジェクトの構成を示し、そして濃度（その集合関係における参加者の最小と最大の数）、集合が静的であるか動的であるか、集合が包括的であるか参照的であるか、集合がアイデンティフィケーション依存を有するか、および集合が複数の値である場合の分類項についての情報を取り込む。それぞれの継承関係はオブジェクトの特殊化を示し、親クラスの名前、子クラスの名前、および特殊化が一時的であるか永久的であるかを保存する。最後に、特殊化が永久的ならば、変数属性上のしっかりと形成された式を特殊化条件として保存する。特殊化が一時的な場合は、条件もしくは、子の役割を有効／無効にするイベントのリストを保存する。
【００４３】
最後に、プロジェクトは、グローバルトランザクションのリストを取り込むこともでき、そのリストの中で、保存される関連した特徴は、グローバルインタラクション、式、および引数のリストを含む。グローバル機能のリストの取り込みも可能であり、そのリストの中で、各機能は、名前、返還された値のデータタイプ、引数のセット（サービスに類似）、および機能についてのコメントを保存する。
【００４４】
プロジェクトは、選ばれたエージェントクラスが有するシステムの具体的なビジョンから構成される一つのセットのヴューを有する。つまり、ひとつのエージェントクラスに許容される形式インターフェースのセット（属性とサービス）である。それぞれのエージェントクラスは、インターフェースのリストを有する。
【００４５】
（オブジェクトモデル）
オブジェクトモデルは、特にエンティティーのクラスを定義することにより、オブジェクト指向の方法で、システムデザイナーがアプリケーションで使用されるエンティティーを指定することができるようにするグラフィックモデルである。したがって、クラス定義は、たとえば、属性や、サービス、およびクラス関係（集合と継承）などを含む。加えて、エージェント関係は、一つのクラスのオブジェクトが起動できるサービスを決定するために指定される。
【００４６】
図３は、図書館利用者（ｒｅａｄｅｒ）、本（ｂｏｏｋ）、および貸し出し（ｌｏａｎ）を有する図書館システム用のオブジェクトモデル３００の例を図示する。オブジェクトモデル３００におけるクラスは、３つの部分、すなわちクラスの名前、属性、およびサービスを有する長方形で表されている。この例においてオブジェクトモデル３００は、貸し出しがされた時のために貸し出しコード３１２と貸し出し日３１４を示す属性を有する、貸し出しクラス３１０を含む。貸し出しクラス３００はまた、２つのサービス（方法）を含む。一つは本の貸し出し３１６であり、もう一つは本の返却３１８である。
【００４７】
オブジェクトモデル３００はさらに本クラス３２０を含み、その本クラス３２０は、その本の著者３２２、本コード３２４、状態３２６（たとえば、予約済み、使用中、貸し出し中など）、および新しい本を創設するｎｅｗ＿ｂｏｏｋ３２８のようなサービスを指定する属性を有する。もう一つのクラスは、図書館員クラス３３０であり、その名前３３２は属性によって指定され、ｎｅｗ＿ｌｉｂｒａｒｉａｎサービス３３４により創設されたものである。
【００４８】
図書館に属する各図書館利用者は、図書館利用者クラス３４０で説明され、その属性は、年齢３４２、図書館利用者の借りた本の冊数３４４、および図書館利用者の名前３４６を含む。図書館利用者は、ｎｅｗ＿ｒｅａｄｅｒサービス３４８と創設されてもよい。信頼性のない図書館利用者クラス３５０も、（たとえば、期限を過ぎた貸し出し本の料金の未払いために）信頼することのできない図書館利用者３４０を表示するために、オブジェクトモデルの一部となっている。信頼性のない図書館利用者３５０は、図書館員３３０により免除３５２されることもある。
【００４９】
オブジェクトモデル３００において、継承関係は、クラスを結ぶ矢印によって表される。たとえば、信頼性のない図書館利用者クラス３５０は、図書館利用者クレーム３４０と矢印でつながっている。したがって、信頼性のない図書館利用者クラス３５０は、図書館利用者クレーム３４０から継承をするよう指定される。別の言い方をすれば、信頼性のない図書館利用者クラス３５０は、図書館利用者クレーム３４０のサブクラスである。サブクラスとベースクラスをつないでいる矢印は、専門条件かあるいは、子の役割を起動もしくはキャンセルするイベントで同等にすることができる。オブジェクトモデル３００の例においては、信頼性のない図書館利用者クラス３５０と図書館利用者クラス３４０の間の矢印は、「図書館利用者を罰する／免除する」サービスというラベルを貼られる。したがって、図書館利用者３４０が罰せられると、その人物は信頼性のない図書館利用者３５０になる。反対に、信頼性のない図書館利用者３５０が免除３５２されると、その人物は普通の図書館利用者３４０になる。
【００５０】
集合関係は、与えられた構成クラスとその合成クラスまでの線で、合成クラス側にダイアモンドのついた線を使うことによって、オブジェクトモデル３００の中に表される。集合は、与えられた入れ物にいくつの構成要素が付属できるかや、構成クラスがいくつの入れ物に関連できるかを決定する。この例においては、本３２０と図書館利用者３４０は、貸し出し３１０に集合される。なぜならば、貸し出し３１０は図書館の図書館利用者３４０に本３２０を貸し出すことに関与するからである。集合のリプレゼンテーションは、両方向における（つまり最小数と最大数の）濃度、役割名、および関係名も含む。この例において、貸し出しから本への、貸し出し：本の関係の濃度は、この概念モデルの中では厳密に一冊の本が一回の貸し出しの対象であるため、１：１であり、本からローンへは、ある時にはちょうど本が貸し出しされているかもしれないし、貸し出されてないかもしれないため、０：１である。
【００５１】
さらに、エージェント関係は、関連するクライアントクラスとサーバークラスのサービスを結ぶ点線であらわされている。この例において、図書館員３３０は信頼性のない図書館利用者クラス３５０の免除サービス３５２のエージェントであり、したがって、免除サービス３５２と図書館員クラス３３０の間に点線がある。これは、図書館員が信頼性のない図書館利用者を免除できることを意味する。もう一つの例では、図書館利用者３４０はまた、本の貸し出し３１６と本の返却３１８のサービスのエージェントである。
【００５２】
最後に、共有されるイベントは、ふたつのクラス間の関連するイベントを結ぶ実線で表されている。この例において、貸し出し＿本のイベントは、本クラス３２０と図書館利用者クラス３４０での前記イベントが実線で結ばれているため、共有されるイベントである。共有されるイベントは、一つのオブジェクト以上に影響を及ぼし、その中で、それぞれのオブジェクトはそのローカル仕様に基づき、その状態を変化させることもある。この例において、貸し出し＿本のイベントは、本３２０の状態を「入手不可能」に変え、図書館利用者３４０の本の数を一つ増加させ、そして貸し出しクラス３１０の場合と、本３２０の集合、および図書館利用者３４０を創設する。貸し出し＿本のイベントは貸し出しクラス３１０の場合を創設するので、集合されたクラスにとって、それは「新しい」イベントとなる。
【００５３】
オブジェクトモデルにおける追加の情報は、クラスの形式説明を完成するために指定される。特に、オブジェクトモデルにおけるすべてのクラスに関して、表１に示すように、以下の情報が取り込まれる。
【００５４】
[表１]
項目                  説明
属性            ：  前記の特性または／あるいは特徴の全て
サービス        ：  前記の特性または／あるいは特徴の全て
派生              ：  派生された属性の派生
表現（その値がそれらの属性に依存
するもの）
制限            ：  あるクラスのオブジェクトが満たさなければ
ならない条件を記述する厳密に形成された
式
複雑な関係      ：  集合と継承の
階層に関連する特定の情報
エージェント    ：  このクラスにより起動されることができる
サービス。
【００５５】
集合と継承に関連する追加情報もまた収集される。集合されたクラスについては、追加情報は、アグリケーションがUML特徴化に基づいた関連か合成であるか、もしくは集合が静的か動的であるかを指定することができる。継承階層については、追加情報は、継承によって成された専門化が永久的か一時的かを指定することができる。専門化が永久的であれば、定数属性上の対応する条件が専門化関係を特徴づけなければならない。一方、専門化が一時的であれば、変数属性に基づいた条件、あるいは子の役割を有効／無効化するイベントが指定されなければならない。
【００５６】
アプリケーションによっては、完全に指定するには多数のクラスを必要とすることもある。その場合、クラスはクラスターとして集めてもよい。クラスターは、一回に一つのクラスターずつ、デザイナーやシステムアナリストがアプリケーションを理解し易くする。したがって、クラスターは、オブジェクトモデルのビューの複雑さを削減する。
【００５７】
（動的なモデル）
システムクラスアーキテクチャーはオブジェクトモデルで指定される。しかしながら、どのオブジェクト寿命が有効とされ得るかや、どのインターオブジェクト通信が設定され得るかなどの追加の特徴はさらに、システム仕様に入力されなければならない。この目的のために、動的なモデルは設けられている。
【００５８】
動的なモデルは、サービス、トリガー、およびグローバルトランザクションに応じて、オブジェクトの動きを指定する。一つの実施例において、動的なモデルは、状態遷移ダイアグラムとオブジェクトインタラクション図という二つの図により表される。
【００５９】
状態遷移ダイアグラム（ＳＴＤ）は、すべてのクラスの有効なオブジェクトライフサイクルを設定することにより、正しい行動を説明するために使用される。有効なライフは、特定のクラスに属するオブジェクトの正しい行動を特徴づける、適切な一連の状態を意味する。遷移は有効な状態の変化を表す。一つの遷移は一つのアクションと、オプションとしてコントロール状態、あるいはガードを有する。一つのアクションは、一つのサービスに加えて、オブジェクトモデルで定義された有効なエージェントのサブセットにより構成される。すべてのエージェントが選択されると、遷移は星印（＊）を付けられる。コントロール条件は、与えられたアクションの何の決定も生み出さない可能性を避けるための、オブジェクト属性および／あるいはサービス引数上で定義されたしっかりと形成された式である。アクションは、その実行を受け入れるために満たされなければならない一つの前提条件を有することもある。埋め込まれた丸を持つ丸は、オブジェクトの存在以前の状態を表す。この状態をソースとする遷移は、創設アクションにより構成されなければならない。同じように、矢の命中した的はオブジェクトの破壊後の状態を表す。この状態を目的地とした遷移は、破壊アクションにより構成されなければならない。中間の状態は、状態の名前の付いた丸により表される。したがって、状態遷移ダイアグラムは、オブジェクトのさまざまな状態と状態間の遷移のグラフィックな表現である。図４Ａは、本発明の一実施例による状態遷移ダイアグラム４００の例を図示する。状態は、状態名を貼られた丸により、状態図４００の例では表されている。図４Ａを参照に、「本０」状態４０４は、「本０」という名を付けられた丸により示されている。オブジェクトが生まれる前に、対応する創設アクションの名の付いた初期遷移４１０のソースであるこの存在していない状態を表すために、空の丸４０２が使用される。矢の命中した的４０６は、［＊］：破壊＿本アクションによって起きる遷移４１６により生じるような、オブジェクトが破壊された後の状態を表すために使用される。
【００６０】
変化は、ソースの状態から目的地の状態への実線の矢印で表されている。遷移矢印の中心には、アクション、前提条件、およびガード（実行された場合）を表示するテキストが付けられている。この例において、遷移４１２は、遷移４１２と前提条件である、「もし、状態＝「利用可能であれば」に関連する、貸し出し＿本アクションの名でラベルを付けられている。したがって、システムは、本の状態属性が「利用可能」である場合のみ、アクションの実行を受け付ける。言い換えれば、概念モデルは、本が利用可能な場合のみ本を貸し出すことができる、ということを要求する。もう一つの例として、遷移４１４は、遷移４１４と前提条件である、「もし、状態＝「貸された」に関連する返却＿本アクションの名を付けられる。言い換えれば、概念モデルは、本が貸し出された場合のみ本を返却することができる、ということを要求する。
【００６１】
オブジェクトインタラクション図は、インターオブジェクト通信を指定する。トリガーとグローバルトランザクションの２つのインタラクションが定義される。トリガーとは、前もって指定された条件が満たされた時に自動的に作動するオブジェクトサービスで、グローバルトランザクションとは、それら自身が、異なったオブジェクトのサービスおよび／あるいはその他のグローバルトランザクションに関与するサービスである。すべてのクラスに対して、一つの状態遷移ダイアグラムがあるが、以前のインタラクションがグラフィックに指定される場である概念モデル全体に対しては、唯一つのオブジェクトインタラクション図しかない。
【００６２】
一つの実施例においては、下線の引かれた名前の付いた箱はクラスオブジェクトを表す。トリガー仕様は、目的地：：トリガー条件であればアクション、というシンタックスに従う。トリガーの第一の構成要素は目的地で、つまりトリガーされたサービスが対象とするオブジェクトである。トリガーの目的地は、条件が満たされる場である同じオブジェクト（つまり自分自身）、指定のオブジェクト、もしくはサービスをブロードキャストする場合は、一つのクラス母集団全体であってもよい。最後に、トリガーされたサービスとその対応するトリガー関係が宣言される。グローバルトランザクションは、宣言されたインタラクションに関与するアクションを結びつけることにより、グラフィックに指定される。これらのアクションは、それらを供給するオブジェクト（箱）をつなぐ実線で表されている。
【００６３】
それゆえに、オブジェクトと活動ルール間の通信は、グラフィックの箱、グラフィックのトリガー、およびグラフィックなインタラクションを表示するオブジェクトインタラクション図に説明されている。図４Ｂは、本発明の一実施例に基づくオブジェクトインタラクション図４２０の例を図示する。
【００６４】
オブジェクトインタラクション図４２０において、グラフィックインタラクションは、グラフィックインタラクションの構成要素の線によって表されている。図書館利用者箱４２２のようなグラフィックな箱は、この場合、図書館利用者のようなオブジェクトを（個々にもしくは総称的に）参照する特別な箱として宣言される。グラフィックトリガーは、実行するサービスとトリガー条件を示すテキストを有する実線を使って表されている。グラフィックインタラクションの構成要素もまた、実線を使用している。それぞれは、インタラクションの数と実行されるアクションを示すテキストを有する。この例においてトリガー４２４は、一人の図書館利用者がその時に借りている本の数が１０に達すると発動する図書館利用者を罰するアクションをあらわす。
【００６５】
（機能モデル）
多くの従来のシステムは、機能モデルを供給する際にショートカットを取るが、これは機能仕様の正確さを制限する。時に、使用されるモデルは、機能モデルとして構造化されたＤＦＤの使用を提案したＯＭＴの初期版で起こったように、オブジェクト指向のモデルの同次性を破壊する。オブジェクトモデリングの状況におけるＤＦＤ技術の使用は、主にそれが他のモデル（オブジェクトの観点）と異なったシステムの観点（機能の観点）を提供するという理由で、不正確であると批判されてきた。その他のモデルは、システム動作の自由仕様をデザイナーの手に託しているが、それは不一致につながる。
【００６６】
しかしながら、本発明の一実施例では、これら従来のアプローチとはまったく異なった機能モデルを使用する。この機能モデルにおいて、オブジェクトの状態の変化に関連するセマンティックスは、イベント発生の結果として取り込まれる。これを行うために、以下の情報が、宣言的に指定される。すべてのイベントが、関与するイベントの引数によってどのようにオブジェクトの状態を変化させるかと、そのオブジェクトの最新の状態である。これは、「評価」と呼ばれる。
【００６７】
特に、機能モデルは、評価の分類の概念を使用する。プッシュポップ、状態−独立、および個別の領域によるという３種類の評価が定義される。それぞれの種類は、その機能性を定義するのに必要な情報のパターンを決定する。
【００６８】
プッシュポップ評価は、それらの関連するイベントが属性の値をある一定の量増加したり減少したりする、もしくは属性をある値に再設定するものである。
【００６９】
状態−独立評価は関与する属性に対し、以前の属性の値とは独立的に新しい値を与える。
【００７０】
個別の領域評価は、属性の前回の値に基づき、限定された領域から、属性に対し一つの値を与える。この領域の異なった値は、属性に可能な有効な状況を作る。
【００７１】
これらの特徴を図示するため、表２は、通常の図書館を表す概念モデルにおける、図書館利用者クラス３４０の「本ナンバー」属性３４４の機能モデルを示す。
【００７２】
[表２]
クラス：図書館利用者属性：本＿ナンバーカテゴリー：プッシュポップ
イベント                  数                    効果
貸し出し（）              １                    増加
返却（）                  １                    減少。
【００７３】
これらの評価は、これらの関係するイベントが、本＿ナンバー属性３４４の値を一定の量（１）増加したり減少したりするので、プッシュポップとして分類される（１）。この例において、その関係するイベント貸し出し（）は増加する効果を有し、返却（）は減少する効果を有する。
【００７４】
この評価の分類は、完全な形式仕様が自動的に生成されるようにし、完全にイベントの機能性を取り込む本発明の一側面の貢献である。
【００７５】
ゆえに、機能モデルは、一つのクラスの属性の、すべての状態の変化のセマンティックスを取り込む責任を担う。グラフィックな図は無い。テキストの情報は、前に説明された情報構造の対応する部分を満たすインターアクティブなダイアログを通して収集される。図５は、機能モデルの入力を受け取るダイアログの例を図示する。
【００７６】
（表示モデル）
表示モデルとは、ユーザーインターフェースの必要条件を説明するのに使用することができる、前もって定義した概念のセットである。これらの概念は、ユーザーインタフェイスを開発する際に繰り返されるシナリオを抜き出し抽象化することから生じる。これらの繰り返されるシナリオの抽象概念はパターンと呼ばれる。パターンの一つのセットは、パターン言語と呼ばれる。
【００７７】
この意味で表示モデルは、ユーザーインターフェースの必要条件を反映するためにデザインされたパターンを集めたものである。一つのパターンは、ある特定の限定された領域における、初期状況を与える、繰り返す問題に対して繰り返す解決の明確な説明である。ドキュメント化したパターンは問題の本質と解決の本質を抽象化し、したがって、初期状況と領域に合う問題を解決するために何度も適用されることができる。パターン言語は多数のパターンから構成される。本発明は、どのような特定のパターンのリストにも限定されることはないが、以下は、有用と判明した、いくつかのユーザーインターフェースのパターンの簡単な説明である。サービス表示パターン、例表示パターン、クラス母集団表示パターン、マスター−詳細表示パターン、およびアクション選択表示パターンなどである。
【００７８】
サービス表示パターンは、サービスがどのように最終的なユーザーに対してデータを要求するかを取り込む。このパターンは、サービス引数の記入をコントロールし、サービスを始めたり終了したりするためのアクションを含む。これは、導入パターン、定義選択パターン、母集団選択パターン、依存パターン、ステイタス回復パターン、補助情報パターン、および引数分類表示などの、より特定化したインターフェースタスクに当てはまるような、その他の低いレベルのパターンに基づく。
【００７９】
導入パターンは、最終ユーザー（つまり、最終的なアプリケーションを使用するユーザー）によって、システムに供給されなければならないデータを入力するための制限を取り扱う。特に、編集マスクと範囲値が導入され、有効にインターフェースに入力することができる値を制限する。このパターンは、入力ア引数を検証することによりデータ入力過程を改善するため、サービスの中の引数、あるいはクラスの中の属性に適用することができる。
【００８０】
定義選択パターンは、引数の有効な値のセットを指定する。入力データー項目が静的で数が限られていて良く知られている場合、デザイナーはそのような有効な値を含むセットを計数することにより宣言することができる。このパターンは、計数したタイプや選択のデフォルト値を定義するものに類似している。したがって、最終ユーザーは前もって指定されたセットからの登録だけを選択することができ、したがってエラーのでやすい入力を減少することができる。たとえば、このパターンの一つの表現になりえるものは、コンボ箱である。このパターンは、データー入力過程を改善するために、サービスの中の引数、もしくはクラスの中の属性に適用されることができる。
【００８１】
母集団選択パターンは、ディスプレイや、複数のオブジェクトに知らせるオブジェクトの選択を取り扱う。特に、このパターンは、どのようにオブジェクトがフィルターされるか（フィルター表現）、どのデータがディスプレイされるか（ディスプレイセット）、およびオブジェクトがどのようにオーダーされるか（オーダー基準）をそれぞれ決定する、フィルター、ディスプレイセット、およびオーダー基準を含む。このパターンは、フィルター表現用のｗｈｅｒｅとオーダー条項用のｏｒｄｅｒ  ｂｙのコラムを有する、ＳＱＬセレクトステートメントとして考えてもよく、存在するオブジェクトのある特定の母集団からオブジェクトを選択することが可能な時はいつでも、サービスにおけるオブジェクトで評価された引数に適用することができる。
【００８２】
依存パターンは、サービスの中の引数間の依存ルールの仕様を許可する、イベント−条件−アクション（ＥＣＡ）のセットである。引数が他に依存しているとき、これらの制限はこの種のルールを用いる。
【００８３】
ステイタス回復パターンは、サービス引数を初期化するオブジェクト属性からデータを回復する、潜在的に作られたパターンである。これは、依存パターンの潜在的なセットとしてモデル化することもできる。たとえば、カスタマーオブジェクトに関連したデータを変えるために、変化サービスを始める形が現れる。ユーザーがカスタマーＯＩＤ（オブジェクトアイデンディファイアー）を用意すると、インターフェースはオブジェクトを探すためにこのＯＩＤを使用することができ、名前や電話番号、および住所などのカスタマーに関係したデータを回復することができる。
【００８４】
補助情報パターンは、最終ユーザーが、存在するオブジェクトの正しいＯＩＤ（アイデンディファイされたオブジェクト）を選ぶ、もしくは入力することを確認するために、最終ユーザーに供給されるフィードバックを取り扱う。たとえば、カスタマーを選択するために、ＯＩＤが供給されなければならない。カスタマーの名前がＯＩＤ入力の答えとして自動的にディスプレイされると、ユーザーは、入力データを選択もしくは修正する際に、ユーザーを保証する価値のあるフィードバックデータを受け取る。補助情報パターンは、オブジェクト−ヴァリュエーテッドの引数に適用できる。
【００８５】
引数分類表示パターンは、ユーザーの希望に基づき、要求されたサービス引数をどのように分類するかを取り込む。
【００８６】
例表示パターンは、オブジェクトの特性がどのように最終ユーザーに表示されるかを取り込む。これに関して、ユーザーはサービスを開始、もしくはその他の関連したオブジェクトにナビゲートすることができる。例表示パターンは、一つの例の詳細なビューである。
【００８７】
クラス母集団表示パターンは、一つのクラスの複数のオブジェクトの特性がどのように最終ユーザーに表示されるかを取り込む。この意味において、オブジェクトが一度選択されると、最終ユーザーはサービスを始めることができるか、もしくはその他の関連したオブジェクトにナビゲートすることができるようになる。オブジェクトはまた、フィルターすることができる。
【００８８】
マスター−詳細表示パターンは、オブジェクトの全詳細を完全にする他の関連するオブジェクトを有する一つのクラスの、ある特定の一つのオブジェクトをどのように表示するかを取り込む。このパターンを築くためには、以下のパターンが使用される。例表示、クラス母集団表示、および帰納的に、マスター−詳細表示である。このように、マルチ詳細（複数の詳細）とマルチレベルのマスター詳細（帰納的に複数レベル）をモデルすることができる。たとえば一つのシナリオは、インボイスヘッダー、つづいてそのインボイスに関連したインボイスの一組のラインに関係する。
【００８９】
アクション選択パターンは、サービスが段階的なアプローチの原則に従い、どのように最終ユーザーに提供されるかを取り込む。このパターンは、たとえば、ツリー構造を使用し、アプリケーションのメニューを生成できる。最終的なツリー構造は、概念モデルのクラスで指定されたサービスのセットから得られる。ユーザーは、概念モデルで定義されたサービス、もしくは質問（観察）を開始することができる。
【００９０】
フィルター表現は、ブールタイプに対し評価するしっかりと形成された式である。この式は、以下のように解釈される。式を満たすオブジェクトはフィルターを通り抜ける。条件を満たさないものは、フィルターを通り抜けない。結果的に、このフィルターは、式を満たすオブジェクトだけを通すふるいのような役割をする。これらの式は、実行時に解決されるパラメーターを含むことができ、変数の値を供給したり、それらを直接最終ユーザーに聞くことができる。フィルターは、ＳＱＬのｗｈｅｒｅ条項の抽象概念して考えることもでき、母集団選択パターンに適用される。
【００９１】
ディスプレイセットは、オブジェクトのステータスを反映するために示されている、オーダーされた属性のセットである。ディスプレイセットは、ＳＱＬ条項のコラムの抽象化として考えることができ、母集団選択パターンに適用される。
【００９２】
オーダー基準は、属性と順序（増える順／減る順）を含む、順に並んだ組のセットである。この組のセットは、フィルターされたオブジェクトに対するオーダー基準を決定する。オーダー基準パターンは、ＳＱＬ条項によるオーダーの抽象概念として考えることもでき、母集団選択パターンに適用される。
【００９３】
（形式仕様）
ＣＡＳＥツール２１０は、システム必要条件２００を取り込むためにユーザーインターフェースを表示した後、システム必要条件を形式仕様２１５に変換する。特に、ＣＡＳＥツール２１０は、以前に説明されたモデルを開始点として構築され、対応する形式のオブジェクト指向の、高レベルのシステム保存場所の役割をする仕様２１５を自動的に生成する。好ましい実施例においては、使用される形式言語は、１９９５年１０月に、「Ｓｅｒｖｉｃｉｏ  ｄｅ  Ｐｕｂｌｉｃａｃｉｏｎｅｓ  ｄｅ  ｌａｓ  Ｕｎｉｖｅｒｓｉｄａｄ  Ｐｏｌｉｔｅｃｎｉｃａ  ｄｅ  Ｖａｌｅｎｃｉａ」 (法的保管番号：Ｖ−１２８５−１９９５）により刊行されたオスカー  パスター  ロペスとイシドロ  ラモス  サラバートによるＯＡＳＩＳ２．２版である。
【００９４】
取り込まれたシステム必要条件２００の形式仕様２１５への変換は、本発明の一側面の主な特徴である。概念モデリングのステップで導入されたそれぞれの情報には、形式言語概念として表される、形式対応相手がある。本発明の一実施例に関連するグラフィックなモデリング環境は、したがって形式仕様の上級グラフィック編集機能としてみなされても良い。
【００９５】
したがって、ＯＡＳＩＳ仕様言語の導入の表示をここで、本発明のこの実施例のより詳細な様子として提示する。表３は、自動的に概念モデルから得られた図書館利用者クラスの形式仕様２１５を表す。
【００９６】
［表３］
概念  スキーマ  図書館〔ＣＯＮＣＥＰＴＵＡＬ  ＳＣＨＥＭＡ  ｌｉｂｒａｒｙ〕
領域  ｎａｔ，ｂｏｏｌ，  ｉｎｔ，  ｄａｔｅ，  ｓｔｒｉｎｇ
〔ｄｏｍａｉｎｓ  ｎａｔ，ｂｏｏｌ，  ｉｎｔ，  ｄａｔｅ，  ｓｔｒｉｎｇ〕
クラス  図書館利用者〔ｃｌａｓｓ  ｒｅａｄｅｒ〕
アイデンティフィケーション〔ｉｄｅｎｔｉｆｉｃａｔｉｏｎ〕
ｂｙ＿図書館利用者＿コード：（図書館利用者＿コード）
〔ｂｙ＿ｒｅａｄｅｒ＿ｃｏｄｅ：（ｒｅａｄｅｒ＿ｃｏｄｅ）；〕
定数＿属性〔ｃｏｎｓｔａｎｔ＿ａｔｔｒｉｂｕｔｅｓ〕
歳：ストリング；〔ａｇｅ：Ｓｔｒｉｎｇ；〕
変数＿属性〔ｖａｒｉａｂｌｅ＿ａｔｔｒｉｂｕｔｅｓ〕
本＿カウント：Ｉｎｔ；〔ｂｏｏｋ＿ｃｏｕｎｔ：Ｉｎｔ；〕
私的＿イベント〔ｐｒｉｖａｔｅ＿ｅｖｅｎｔｓ〕
新しい＿図書館利用者（）新しい；〔ｎｅｗ＿ｒｅａｄｅｒ（）ｎｅｗ；〕
破壊＿図書館利用者（）破壊；〔ｄｅｓｔｒｏｙ＿ｒｅａｄｅｒ（）ｄｅｓｔｒｏｙ；〕罰（）；〔ｐｕｎｉｓｈ（）；〕
共有＿イベント〔ｓｈａｒｅｄ＿ｅｖｅｎｔｓ〕
貸し出し（）ｗｉｔｈ本；〔ｌｏａｎ（）ｗｉｔｈ  ｂｏｏｋ；〕
制限〔ｃｏｎｓｔｒａｉｎｔｓ〕
静的本＿カウント＜１０；〔ｓｔａｔｉｃ  ｂｏｏｋ＿ｃｏｕｎｔ＜１０；〕
評価〔ｖａｌｕａｔｉｏｎ〕
［貸し出し（）］本＿カウント＝本＿カウント＋１；〔［ｌｏａｎ（）］ｂｏｏｋ＿ｃｏｕｎｔ＝ｂｏｏｋ＿ｃｏｕｎｔ＋１；〕
［返却（）］本＿カウント＝本＿カウント−１；〔［ｒｅｔｕｒｎ（）］ｂｏｏｋ＿ｃｏｕｎｔ＝ｂｏｏｋ＿ｃｏｕｎｔ−１；〕
前提条件〔ｐｒｅｃｏｎｄｉｔｉｏｎｓ〕
図書館員：破壊＿図書館利用者（）もし〔ｌｉｂｒａｒｉａｎ：ｄｅｓｔｒｏｙ＿ｒｅａｄｅｒ（）ｉｆ〕
本＿ナンバー＝０；〔ｂｏｏｋ＿ｎｕｍｂｅｒ＝０；〕
トリガー〔ｔｒｉｇｇｅｒｓ〕
自分自身：：罰（）もし本＿カウント＝１０；〔Ｓｅｌｆ：：ｐｕｎｉｓｈ（）ｉｆ  ｂｏｏｋ＿ｃｏｕｎｔ＝１０；〕
プロセス〔ｐｒｏｃｅｓｓ〕
図書館利用者＝図書館員：新しい＿図書館利用者（）図書館利用者０；〔ｒｅａｄｅｒ＝ｌｉｂｒａｒｉａｎ：ｎｅｗ＿ｒｅａｄｅｒ（）ｒｅａｄｅｒ０；〕
図書館利用者０＝図書館員：破壊＿図書館利用者（）＋〔ｒｅａｄｅｒ０＝ｌｉｂｒａｒｉａｎ：ｄｅｓｔｒｏｙ＿ｒｅａｄｅｒ（）＋〕
貸し出し（）図書館利用者１；〔ｌｏａｎ（）ｒｅａｄｅｒ１；〕
図書館員１＝もし本＿カウント＝１返却（）図書館利用者０〔ｒｅａｄｅｒ１＝ｉｆ  ｂｏｏｋ＿ｃｏｕｎｔ＝１ｒｅｔｕｒｎ（）ｒｅａｄｅｒ０〕
＋（もし本＿カウント＞１返却（）〔＋（ｉｆ  ｂｏｏｋ＿ｃｏｕｎｔ＞１ｒｅｔｕｒｎ（））〕
＋もし本＿カウント＜１０貸し出し（））読者利用者１；〔＋ｉｆｂｏｏｋ＿ｃｏｕｎｔ＜１０ｌｏａｎ（））ｒｅａｄｅｒ１；〕
エンド＿クラス〔ｅｎｄ＿ｃｌａｓｓ〕
エンド  概念  スキーマ〔ＥＮＤ  ＣＯＮＣＥＰＴＵＡＬ  ＳＣＨＥＭＡ〕。
【００９７】
図書館利用者（ｒｅａｄｅｒ）クラス仕様の例の形式説明を統一する異なった部分の意味を説明する。ＯＡＳＩＳにおけるクラスは、「図書館利用者」というクラス名、クラスの例（オブジェクト）のアイデンティフィケーション機能、およびすべての例が分け合うタイプもしくはテンプレートによりなる。
【００９８】
アイデンティフィケーション機能ｂｙ＿図書館利用者＿コード（ｂｙ＿ｒｅａｄｅｒ＿ｃｏｄｅ）は、オブジェクトにより使用される名づけの仕組みを特徴づけ、すでに定義された種類もしくは、ユーザーによって定義された種類（ＯＡＳＩＳにおいてはすなわち領域と呼ばれる）に属するサロゲートを生み出す。これらの領域は、クラス定義にインポートされる。最も通常のものは、ｉｎｔ、ｎａｔ、ｒｅａｌ、ｂｏｏｌ、ｃｈａｒ、ｓｔｒｉｎｇ、およびｄａｔａと前もって定義される。これらはある特定の書式において、数、ブール値、文字、ストリングおよび日付を表す。新しい領域は、対応する抽象データタイプを定義することにより、仕様に導入される。
【００９９】
タイプは、考慮されているクラスの可能なオブジェクトすべてが共有するすべての特性（構造と行動）を収集するテンプレートである。シンタックス面で、タイプは、ソートを含む署名、機能、属性と使用されるイベント、動的なロジックにおいては式である公理のセット、ある特定のプロセス代数で解かれるソートプロセスの変数を有する方程式のセットとしてのプロセス質問として形式化することができる。これらの変数が例示される場合、私たちは、インスタンス（オブジェクト）の可能な寿命を表す基礎項を有することになる。
【０１００】
クラス署名は、部分的なオーダー関係を有するソートのセットを含む。このソートのセットの中に、定義されるクラスに関連する対象となるソート（クラス名）もある。クラス署名はまた、（すでに定義された）ソートの定義の機能や、クラス仕様に暗黙に供給されるアイデンティティーに対するＡＤＴ（抽象的なデータタイプ）であるソートがアイデンティフィケーション機能に含まれる機能を含む機能のセットも含む。アイデンティフィケーション機能は、ある特定のクラスのオブジェクトが独自のアイデンティティーであることを保証するために、オブジェクトをアイデンティファイするある特定のソートの値を供給する。仕様目的のため、アイデンティフィケーションは、オブジェクトを確認するエイリアスとして使用される一つ以上のキーマップの宣言からなる導入された仕組みである。キーマップは、リレーショナルモデルの候補キー観念に類似する。ある特定のキー値から、これらのマップは、関連したオブジェクトアイデンティティーを返還する。キーマップは、定数属性（の組）として宣言される。
【０１０１】
クラス署名はまた、属性のセット（定数、変数および派生）を含む。表３の定数＿属性（ｃｏｎｓｔａｎｔ＿ａｔｔｒｉｂｕｔｅ）およびヴァリアブ＿属性（ｖａｌｕａｂｌｅ＿ａｔｔｒｉｂｕｔｅ）の項を参照。これらの属性はすべて、領域としてのクラスのソートと、共同領域と考えられる属性に関連したある特定のソートを有する。
【０１０２】
イベントのセットはまた、領域としてのクラスのソートに加えイベント情報を表す追加のソート、および共同領域としてのクラスのソート（関心のあるソート）とともに、クラス署名に含まれる（表３の私的イベントと共有イベントを参照）。このいわゆる関心のあるソートは、オブジェクトがプロセスとみなされた場合、全体的なソートプロセスのサブソートとしてみなされることができる。
【０１０３】
それぞれのイベントの発生は、それを起動できるエージェントにより名を付ける。このアクター観念を扱う時、もしエージェントＸがイベントａを開始することがＸ：ａと記載され、これがアクションと呼ばれると、Ｘは環境、もしくはシステムクラスのオブジェクトとなりえる。一つの実施例において、イベントは常にエージェントと関連している。イベントを定義する時、デザイナーはしたがって、どのエージェントがそれを起動できるかを決定することを余儀なくされる。結果的に、アクションのセットＡはイベントの初期のセットから定義され、入手され、結び付けられる。
【０１０４】
このように、オブジェクトサービスのセットの観念は、その他のオブジェクトがその状態にアクセスできるようにするインターフェースとして表されることができる。オブジェクトサービスは、これらのサービスが提供されたか、あるいは要求されたかによって、イベント（サーバービュー）もしくはアクション（クライアントビュー）であり得る。アクションは一つのオブジェクトにより要求されたサービスとなり、それによりそのオブジェクトはそのほかのオブジェクトの状態（もしくはそれ自体の状態）を診察、もしくは変更できる。
【０１０５】
ＯＡＳＩＳにおいて、以下のような種類の動的な式がある（クラス公理のセット）。
【０１０６】
評価はφ［ａ］φ‘の形式の式であり、このセマンティックスは、基礎アクションａから可能な世界の間の一つの機能を与えるという一つのρ機能を定義することにより、得られる。他の言葉で言えば、いかなる有効な状態のオブジェクトに対しても可能な世界であり、ρ機能は、オブジェクト状態間のどの遷移が、アクションａの実行の後に有効であるかを決定する。この例において、以下のような評価がある。
【０１０７】
［貸し出し（）］本＿カウント＝本＿カウント＋１；
〔［ｌｏａｎ（）］ｂｏｏｋ＿ｃｏｕｎｔ＝ｂｏｏｋ＿ｃｏｕｎｔ＋１；〕
［返却（）］本＿カウント＝本＿カウント−１；
〔［ｒｅｔｕｒｎ（）］ｂｏｏｋ＿ｃｏｕｎｔ＝ｂｏｏｋ＿ｃｏｕｎｔ−１；〕。
【０１０８】
この動的なロジック環境の中で、式φは、ｓ∈Ｗで評価され、φ’はρ（ａ）で評価される。ρ（ａ）は、考慮されているアクションのsでの実行の後のオブジェクト状態によって表される世界である。
【０１０９】
派生は、タイプφ ―＞ φ’の式である。これは、ある特定の派生条件（φで記述された）によって派生された属性φ’を定義する。派生は基本的に、この派生された評価が特有の状態でなされたという点で、評価式とは異なる。
【０１１０】
完全性制約は、すべての世界において満たされなければならない式である。静的と動的な完全性制約は、区別されてもよい。静的な完全性制約は、すべての可能な世界に対して定義されているものである。それらは、つねに有効でなければならない。一方、動的な完全性制約は、異なった世界を関係づけるものである。それらは、対応する時間的ロジックオペレーターとともに、時間的ロジックの使用を必要とする。
【０１１１】
前提条件は、φがアクションａの実行以前の世界で有効でなければならい式であるテンプレート、┐φ［ａ］ｆａｌｓｅを有する式である。φが有効である世界のみにおいて、ａの発生を許可される。┐φが有効なら、ａの発生は、相続者としての状態を生み出さない。私たちは、図書館利用者仕様において、以下のような前提条件を持っている。
【０１１２】
本＿ナンバー＝０[図書館員：破壊＿図書館利用者（）]ｆａｌｓｅ；
〔ｂｏｏｋ＿ｎｕｍｂｅｒ＝０［ｌｉｂｒａｒｉａｎ：ｄｅｓｔｒｏｙ＿ｒｅａｄｅｒ（）]ｆａｌｓｅ；］
あるいは、仕様目的のためにより便利な方法で、私たちは以下のように書くことができる。
【０１１３】
図書館員：破壊＿図書館利用者（）もし本ナンバー＝０
〔ｌｉｂｒａｒｉａｎ：ｄｅｓｔｒｏｙ＿ｒｅａｄｅｒ（）  ｉｆ  ｂｏｏｋ  ｎｕｍｂｅｒ＝０〕
トリガーは、φ［┐ａ］ｆａｌｓｅの式である。ここで┐ａはアクションの否定である。この式は、ａは起こらず、そして何が起こるかは指定されていない、ということを意味する。もしφが有効で、ａ以外のアクションが発生すると、相続状態は存在しない。これは、ａの発生を強要するか、もしくは、システムがブロックされた状態にとどまる。たとえば、（オブジェクトインタラクションダイアグラム４２０が導入されたときに提示された、トリガー表現に基づき）目的地についてのトリガーされたサービス情報を含んだ、適切な動的な式を使用し、私たちは、以下のことを宣言する。
【０１１４】
本＿カウント＝１０［自分自身：：罰（）］ｆａｌｓｅ
〔ｂｏｏｋ＿ｃｏｕｎｔ＝１０［Ｓｅｌｆ：：ｐｕｎｉｓｈ（）］ｆａｌｓｅ〕
このトリガーは、仕様目的において、同等ではあるが、より便利な以下の方法で記載されても良い。
【０１１５】
自分自身：：罰（）もし本＿カウント＝１０
〔Ｓｅｌｆ：：ｐｕｎｉｓｈ（）  ｉｆ  ｂｏｏｋ＿ｃｏｕｎｔ＝１０〕
したがって、トリガーは、φに記述された条件が有効なとき起動されるアクションである。前提条件とトリガーの主な違いは、ある特定の条件が満たされるとすぐにアクションを起動させるという義務がトリガー内にあるという事実に由来する。このように、トリガーは、モデル化されるオブジェクト社会における内部活動を導入できるようにする。
【０１１６】
これらの動的な式どれにおいても、φとφ’は、考慮される状態もしくは世界において、オブジェクトの属性に付属された値のセットにより特徴ずけられる、ある特定のシステム状態を普通意味する、第一オーダーロジックにおけるしっかりと形成された式である。
【０１１７】
ＯＡＳＩＳにおいて、オブジェクトは、観測可能なプロセスと定義される。クラスのプロセス仕様は、私たちが、オブジェクトダイナミックを指定できるようにし、インスタンスの状態間のアクセス関係を決定する。プロセスは、アトミックアクションとしてイベントを使用することにより、組み立てられる。しかし、デザイナーはまた、トランザクションとよばれる実行ユニットにイベントを分類するという選択肢を有する。
【０１１８】
トランザクションであるモレキュラーユニットは、二つの主な特性を有する。第一に、これらは、関与するイベントの実行に対して、オール−オア−ナッシングのポリシーに従う。トランザクション実行中に機能不全が起きると、結果として生じる状態は、初期のものとなる。第二に、これらは、中間状態の観察の不可能を示す。
【０１１９】
私たちは、表４の図書館利用者クラスのプロセス仕様を紹介し、このセクションを終える。
【０１２０】
［表４］
図書館利用者＝図書館員：新しい＿図書館利用者（）○図書館利用者＿０；
〔ｒｅａｄｅｒ＝ｌｉｂｒａｒｉａｎ：ｎｅｗ＿ｒｅａｄｅｒ（）○ｒｅａｄｅｒ＿０；〕
図書館利用者＿０＝図書館員：破壊＿図書館利用者（）＋貸し出し（）
〔ｒｅａｄｅｒ＿０＝ｌｉｂｒａｒｉａｎ：ｄｅｓｔｒｏｙ＿ｒｅａｄｅｒ（）＋ｌｏａｎ（）〕
○図書館利用者＿１；
〔○ｒｅａｄｅｒ＿１；〕
図書館＿１＝もし本＿カウント＝１返却（）○図書館＿（）
〔ｒｅａｄｅｒ＿１＝ｉｆ  ｂｏｏｋ＿ｃｏｕｎｔ＝１  ｒｅｔｕｒｎ（）○ｒｅａｄｅｒ＿（）〕
＋（もし本＿カウント＞１返却（）
〔＋（ｉｆ  ｂｏｏｋ＿ｃｏｕｎｔ＞１  ｒｅｔｕｒｎ（））
＋もし本＿カウント＜１０貸し出し（））○図書館利用者＿１；
〔＋ｉｆ  ｂｏｏｋ＿ｃｏｕｎｔ＜１０  ｌｏａｎ（）〕○ｒｅａｄｅｒ＿１；〕。
【０１２１】
プロセスの実行は、プロセスの明確に定義された代数における項として表される。したがって、可能なオブジェクトライフは、構成要素がトランザクションとイベントである項として宣言される。すべてのプロセスは、○（シーケンス）と＋（オルタナティブ）プロセスオペレーションを用いて、基礎プロセス代数ＢＰＡ＿δεにおける項に書き換えられることができる。これは、任意のインターリービングに基づき、同時発生の実施を提供する。
【０１２２】
本発明の一実施例による概念モデルと、それに関連したＯＡＳＩＳ形式概念を説明したので、概念モデルで導入されたグラフィックな情報を入力として受け止め、（ＯＡＳＩＳでは仕様である）テキストのシステムリプレゼンテーション２１５を生成するマッピングの説明に入る。この形式仕様２１５は、実際ＣＡＳＥツール２１０を使用し得られれたもので、ソース概念モデルで表示されたように、初期必要条件に準拠する最終ソフトウェアー製品を得るためのソリッドシステムドキュメンテーションを構成する。
【０１２３】
前項で紹介されたクラス用テンプレートによると、概念パターンとそれらの対応するＯＡＳＩＳリプレゼンテーションのセット。
【０１２４】
システムクラスは、オブジェクトモデルから得られる。それぞれのクラスにおいて、定数、変数、および派生属性のセット、私的イベントと共有のイベントとローカルトランザクションを含んだサービスのセット、クラス用に指定された完全性制約、および派生属性に対応する派生エキスプレションがある。複雑なクラス（供給された集合と継承クラスオペレーターを使用して定義されたもの）に対して、オブジェクトモデルはまた、対応する複雑なアグリゲートされた、もしくは専門化されたクラス用に指定された、特定の特徴を供給する。
【０１２５】
オブジェクトモデルによって与えられた情報は基本的に、クラスのシグニチャーが正確に宣言される、システムクラスの骨組みを指定する。動的なモデルは、状態遷移ダイアグラムとオブジェクトインタラクションダイアグラムの二種類を使用する。状態遷移ダイアグラムから、以下のものが取得される。イベント遷移に名を付ける式であるエヴェント前提条件と、有効なオブジェクトライフのテンプレートが決定されるクラスのプロセス定義である。オブジェクトインタラクションダイアグラムからは、ＯＡＳＩＳクラス仕様の持つ他の２つの特徴が完成される。異なったオブジェクトに関係する、トリガー関係とグローバルトランザクションである。
【０１２６】
最後に、機能モデルは、評価に関係した動的な式を産出し、それで属性に対するイベントの効果を指定する。
【０１２７】
本発明の一実施例に基づき概念モデルに導入できる関連した情報のセットをかくして明確に定義すると、必要条件２００に対応する形式仕様２１５は、ＯＡＳＩＳのオブジェクト指向のモデルに基づき、システム説明が完全に取り込まれる正確なシステムリポジトリーを供給する。これは、実行プロセス（実行モデル）が、関与する情報が意味のある明確な開始点から行われること可能にする。なぜなら、ＯＡＳＩＳにおける形式な相手方をさらに有する概念モデルのパターンの限られたリストから、それらが由来するからである。
【０１２８】
（モデル検証）
概念モデルから（Ｃ、Ｃ＋＋、あるいは、ジャバのような第三ジェネレーション言語のような）実施言語への、完全でロバストなアプリケーションの自動ソフトウェアー作成において、概念モデルは正しく、そして完全である必要がある。このセクションにおいて、「正しい」および「完全」という言葉は、自動ソフトウェアー作成プロセスシステムの特定の必要性によって、以下のような意味を持つ。
【０１２９】
概念モデルは、必要条件仕様に欠けている情報がない場合、「完全」である。つまり、概念モデルのすべての必要とされる特性が定義され、値を有する。
【０１３０】
概念モデルは、概念モデルで導入された情報が、シンタックス面でもセマンティックス面でも一貫しており明確である時、「正しい」。つまり、概念モデルで定義されるすべての特性は有効な値を有する。
【０１３１】
図２に戻ると、ヴァリデーター２２０は、オブジェクト指向の形式仕様言語（ＯＡＳＩＳのような）を高レベルデータリポジトリーとして使用し、概念モデルの形式仕様２１５を入力として受け取る。形式な視点からは、仕様２１５は明確に定義され断定的で動作可能のセマンティックスを使用しており、形式に動的なロジック論と同等であるため、検証されたＯＡＳＩＳ仕様２１５は正しく、完全である。
【０１３２】
形式仕様２１５が有効であること、あるいは有効であることを調べることができることを形式環境が保証できるので、形式仕様言語は利益を得ている。形式言語は、言語表現を規定する文法を定義する。
【０１３３】
概念モデルの検証には、二つの手順が使用される。完全さについては、検証の規則は、直接概念モデルのために集められたデータを調べることにより執行される。つまり、クラスは名前と、そのアイデンティファイヤーであるひとつの属性、および一つのサービスを持たなければならない。正確さについては、広範囲の形式言語文法が、概念モデルのすべての式のシンタックスと意味を検証するために執行される。
【０１３４】
（正確さ）
さらに具体的には、正確さについては、形式仕様言語のすべての構成要素が、存在しなければならず、有効な値を持たなければならない特性のセットを有する。特性のほとんどは、完全な定義と有効な値を持つために、厳密に執行される。しかしながら、ＣＡＳＥツール２１０は、モデル入力中の使いやすさのために、いくらか不完全である特性か、もしくは、無効な値を有する特性を残す。これらの特性は、ヴァリデーター２２０により、自動ソフトウェアー作成プロセスの前に、完全（そして正確）であることを調べられる。
【０１３５】
概念モデルを検証するために使用される要素を、次に説明する。それぞれの要素について、検証が厳密であるかどうか（たとえば、生成時に、すべての特性が存在し、有効な値を持たなければならない場合）、あるいはフレキシブルであるかどうか（たとえば、後に検証が達成される）、が述べれる。特性には、オプションであるものもあるが、（たとえば、存在しないかもしれない）それらが定義された場合、それらは検証されなければならない。これらの構成要素は、表５にまとめられている。
【０１３６】
［表５］
−  クラス
○  名前                                        厳密
○  ＩＤ機能                                    フレキシブル
○  属性（少なくとも一つ）                      フレキシブル
○  サービス（少なくともクリエイトサービス）    フレキシブル
○  静的および動的な完全性制約（オプション）
□    それらの式                          厳密
−  属性
○  名前                                        厳密
○  タイプ（定数、変数、派生）
厳密
○  データタイプ（実数、整数など）              厳密
○  デフォルト値                                厳密
○  サイズ（もし、生じれば）                    厳密
○  創設サービスでの要求                        厳密
○  ＮＵＬＬ値許可                              厳密
○  評価（変数属性）
フレキシブル
○  派生式（派生属性）
フレキシブル
−  評価
○  クラスの一つの変数属性                      厳密
○  同じクラスの一つのサービス                  厳密
○  条件（オプション）                          厳密
○  評価の式                                    厳密
−  派生
○  式                                          厳密
○  条件（オプション）                          厳密
−  サービス
○  名前                                        厳密
○  引数
□  引数の名前                            厳密
□  データタイプ                          厳密
□  デフォルト値（オプション）            厳密
□  ＮＵＬＬ値                            厳密
□      サイズ（もし、生じれば）          厳密
○  トランザクションのための式                  フレキシブル
−  アクションの前提条件
○  式                                          厳密
□  条件に影響されるエージェント          厳密
−    関係：集合
○  関係するクラス（構成要素と合成）            厳密
○  関係名                                      厳密
○  両方向役割名                                厳密
○  濃度                                        厳密
○  包括的か参考的                              厳密
○  動的                                        厳密
○  条項  「Ｇｒｏｕｐ  ｂｙ」(オプション)      厳密
○  挿入と削除イベント（もし、生じれば）        厳密
−  関係：継承
○  関係するクラス（親と子）                    厳密
○  一時的（対永久的）                          厳密
○  特別化条件あるいはイベント                  厳密
−  関係：エージェント
○  エージェントクラスと起動を許可されるサービス
厳密
−  状態遷移ダイアグラム（ＳＴＤ）
○  クラスのすべての状態（少なくとも３つ）      フレキシブル
−  ＳＴＤにおいての状態
○  名前                                        厳密
−  ＳＴＤにおいての遷移
○  起源のエステート                            厳密
○  目的地のエステート                          厳密
○  クラスのサービス                            厳密
□  コントロール条件（オプション）        厳密
−  トリガー
○  条件                                        厳密
○  目的地のクラスまたはインスタンス            厳密
○  ターゲット（自分自身、オブジェクト、クラス）  厳密
○  起動されたサービス                厳密
○  サービス引数の初期化（オプション）
□  引数の値                              厳密
−  グローバルのトランザクション
○  名前                                        厳密
○  式                                          厳密
−  ユーザーイグジット機能
○  名前                                        厳密
○  返却データタイプ                            厳密
○  引数（オプション）
□  引数名前                              厳密
□  引数のデータタイプ                    厳密。
【０１３７】
（完全さ）
形式仕様言語における構成要素のいくつかの特性は、明確なシンタックスに従い精密形成された式である。したがって、概念モデルで導入されたすべての式が、シンタックス面でもセマンティックス面でも正しいことを確実にすることは、必須事項である。
【０１３８】
概念モデルで使用されるすべての式が、同じ目的を有するわけではない。したがって、いくつかのタイプの式が存在する。式のタイプにより、ある特定のオペレーターや項（定数、クラス属性、ユーザーインターフェースなどのようなオペランド）が許るされる。概念モデルにおける式のすべてのタイプを検証するための、プロセスとルールのセットも文法の中にまた存在する。
【０１３９】
より具体的に、概念モデルは表６に示されるように、以下のようなタイプの式を含む。
【０１４０】
［表６］
−  のデフォルト値計算
○    クラス属性（定数と変数）
○    サービスとトランザクション引数
−  継承：専門化条件
−  静的と動的な完全性制約
−  派生と評価
○    計算式（それぞれ派生あるいは変数属性）
○    条件（オプション）
−  アクションのための前提条件（サービスもしくはトランザクション）
−  状態遷移ダイアグラムにおける遷移のためのコントロール条件
−  トリガーする条件
−  ローカルとグローバルトランザクションの式。
【０１４１】
これらの式は、導入された時に、式がシンタックス面でもセマンティックス面でも正しくなければ、デザイナーがインターアクティブテキストダイアログを去ることを防ぐことにより、検証される。
【０１４２】
一般に、すべての式は、シンタックス面で正しくなくてはならない。つまり、すべてのクラスはアイデンティフィケーション機能と生成イベントを保持しなくてはならず、すべてのトリガーする式はセマンティックス面で正しくなくてはならない。（たとえば、無関係のクラスへのセルフトリガーは禁止されている。）そして、集合のすべての名前は、概念スキーマにおいてユニークでなければならない。もしこれらの条件が満たされなければ、エラーが発生する。
【０１４３】
一方、以下のことが当てはまらなければ、警告が発生する。すべてのクラスが破壊イベントを有する場合、すべての派生属性が少なくとも派生式を有する場合、すべてのサービスがそれを実行すると宣言されたエージェントを有する場合、そして、すべてのサービスで宣言された引数が使用された場合である。
【０１４４】
検証プロセスもまた、デザイナーがひとつ以上の式を無効化し得る変化をモデルに加えるたびに、発動される。前に述べたように、使い易さのために、ある特定のタイプの式は正確でなくてもよいが、デザイナーが後に見直さなければならない。しかしながら、本発明の一実施例による自動ソフトウェアー作成プロセスは、すべての式が正しくないかぎり、コードのジェネレーションを続行しない。デザイナーが、概念モデル仕様に変更を導入するたびに、影響されるすべての式は検査される。結果として、以下のようなケースが起こりうる。
【０１４５】
１．影響された式の一つでも「厳密な」特性を参照した場合、変更は拒絶される。デザイナーに告知するためにエラーが表示する。
【０１４６】
２．影響された式すべてが、「厳密な」特性を参照しない場合、概念モデルへの変更は受諾される。アクションをとる前に、アクション確認ダイアログがディスプレイされる。
【０１４７】
３．影響された式がない場合、変更は直接行われる。ユーザーインターフェース情報を検証するために、ヴァリデーター２２０は以下のようにエラーを検査する。定義されたパターンは、不可欠の情報が欠けることなくしっかりと組み立てられていなければならない。フィルターに使用される属性は、定義クラスから明らかでなければならない。要求基準で使用される属性は、定義クラスから明らかでなければならない。フィルターの式は、モデルで定義された用語を使用したしっかりと形成された式でなければならない。アクション選択パターンは、概念モデルで定義された最終アクションオブジェクトとして使用しなければならない。依存パターンのセットは末端となり、合流点を有さなければならない。警告は、次の条件下で生成されてもよい。一つのパターンが定義されても使用（適用）されない場合、あるいはインスタンスパターンが複製された場合である。
【０１４８】
概念モデルからの自動ソフトウェアー作成は、概念モデルが正しく完全である必要がある。形式仕様言語の特徴と特性の適用は、概念モデルを効果的に検証することを可能にする。検証プロセスは、形式仕様言語により定義された文法に基づき、そして部分的な検証は、デザイナーが概念モデル仕様に変更を導入したときいつでも発動されるようになっている。自動ソフトウェア作成プロセス以前に、概念モデルは前提必須条件として、完全な検証において検証される。
【０１４９】
（変換概観）
検証された形式仕様２１５は、特定の機械表現に関連した実施依存の特徴を扱う実行モデルのためのソースである。指定されたシステムを実施するため、ユーザーがシステムオブジェクトとインターアクトする方法が、事前に定義される。一実施例によると、図６で表されている実行テンプレートは、この行動を達成するために使用することができる。図６は、「実行モデル」と言及されているものに従うことにより、形式仕様を完全なアプリケーションに変換する作業の高レベルなビューを図示するフローダイアグラムである。
【０１５０】
プロセスは、ユーザーがシステムへログインし、ユーザーの確認をすることにより開始する（ステップ６００）。ユーザーが見えるか起動できるオブジェクト属性とサービスにより決定されるオブジェクトシステムビューが、供給される（ステップ６０２）。ユーザーが接続し、明確なオブジェクトシステムビューを得た後、ユーザーの世界ビューにおいて利用可能なサービスであればどれでもユーザーは起動することができる。これらのサービスの中に、観察（オブジェクト質問）、ローカルサービス、あるいは他のオブジェクトによりサーブされたトランザクションが存在する。
【０１５１】
どのサービス活性化にも２つのステップがある。メッセージを作ること、そして、もし可能であればメッセージを実行することである。メッセージを作るには、ユーザーは、オブジェクトサーバーを示す情報を供給しなくてはならない（ステップ６０４）。オブジェクトサーバーの存在は、新しいというサービス以外のサービスを実行するための絶対条件である。続いてユーザーは、メッセージを作るために、（必要ならば）起動されているサービスのサービス引数を導入する（ステップ６０６）。
【０１５２】
メッセージが一度送られると（ステップ６０８）、サービス実行は、サービスオブジェクトにおけるアクションの以下のシーケンスの発生により特徴付けられる。現在のオブジェクト状態で選ばれたサービスのための形式仕様に有効な遷移が存在していることを確かめるために、状態遷移を検査する（ステップ６１０）。サービスに関連した前提条件が適用しなければならないことを示すために、前提条件の達成を検査する。これらどのアクションも適用されない場合は、例外となり、メッセージは無視される。
【０１５３】
そうでなければ、プロセスは、検証を満たすことを続行し（ステップ６１４）、そこで誘導されたサービス変更が、関与するオブジェクト状態において行われる。サービス実行がオブジェクトを有効な状態に導くことを確かにするために、最終状態において、完全性制約（ステップ６１６）が確かめられる。制限が適用しないと、例外となり、前回の状態の変更は無視される。状態の有効な変更の後、内部システム活動を表現する条件アクションルールのセットが確かめられる。これらのどれかが適用されると、指定されたサービスがトリガーされる（ステップ６１８）。
【０１５４】
したがって、図６に図示されたステップは、概念モデルで回収されたオブジェクトシステム仕様と、その命令的ななプログラミング環境における具体化が、機能的に等価であることを保証するために、プログラムの履行をガイドする。
【０１５５】
本発明の一実施例において、ＣＡＳＥツール２１０を補完し自動ソフトウェアー作成システムを構成するために、いくつかのトランスレーターを使用してもよい。たとえば、一つの履行例においてトランスレーターは、たとえばインターネットアプリケーションに適した３層構造に基づいてアプリケーションを作成する。特に、それぞれの層に対応して３つの異なったトランスレーターが発動する。システムロジックトランスレーター２３２、ユーザーインターフェーストランスレーター２３４、そしてデータベースジェネレーター２３６である。さらに、４つ目のトランスレーターであるドキュメンテーショントランスレーター２３８が使用される。これらの異なったトランスレーターは、作成される出力によって特徴付けられ、潜在的には同じ出力を有するが、それぞれのトランスレーターは、前述の高レベルリポジトリー２１５における情報内の特定のサブセットに焦点を定める。
【０１５６】
（システムロジック変換）
システムロジックトランスレーター２３２は、高レベルリポジトリーの情報から第３ジェネレーションプログラミング言語用のコードを自動的に生成する。システムロジックトランスレーター２３２の出力は、３層構造の真ん中の層に対応する。
【０１５７】
一実施例において、システムロジックトランスレーター２３２は、以下のことを扱うソースコードを作成する。（１）ユーザーインタフェイス機能との通信サブシステム、（２）固定層へのアクセスと固定層との通信、（３）固定層の内容を読むための標準質問サービス、そして（４）固定層とクライアント通信により作成されたエラー取り扱いである。
【０１５８】
通信サブシステムは、クライアントからのリクエストを受け取る、内部方法を発動する、リクエストした者に返答を返す、リクエストされたサービスを行うためにリクエストした者の存在と権限を確かめる、リクエストされたサーバーインスタンスの存在と有効性を確かめる、固定属性のために固定層にアクセスしながら、もしくは派生の属性の値を算出しながらメモリーにリクエストされたサーバーインスタンスのコピーを創設する、概念モデルにおける状態遷移ダイアグラム４００で指定されたように、リクエストされたサービスのための状態遷移を検証する、リクエストされたサービスの前提条件が適用することを確かめる、機能モデルで指定されたように、リクエストされたサービスに関係のあるすべての評価を行う、リクエストされたサーバーインスタンスにより達成された新たな状態のための制限を確かめる、対応するアクションを実行するために、トリガー条件を検査する、リクエストされたサーバーインスタンスにおける変更を固定化する、といったことのために構成される。
【０１５９】
さらに、固定層へのアクセスと固定層との通信や、固定層の内容を読み取るためや、固定層により発生したエラーやクライアントとの通信を扱うためのサービス基準質問のために、コードが生成される。一つの履行例では、生成されたコードは、概念モデルの検証された仕様２１５に基づき、テーブルや制限、そしてリレーショナルデーターベースシステム（ＲＤＢＭＳ）におけるデータモデルを定義するインデックスを創設したり、取り除いたりするためのスクリプティングを含んでもよい。
【０１６０】
一実施例において、コードジェネレーションの第一フェーズは、概念モデル２１５の情報の引き出しと、メモリー内のコードジェネレーション構造へのこの情報の保存である。３種類の要素が情報の引き出しをガイドする。クラス、グローバルトランザクション、そしてグローバル機能である。概念モデルのクラスから得られる関連のある情報には、名前、定数属性（名前、タイプ、創設時にリクエストされた、そして初期化値式）、変数属性（名前、タイプ、創設時にリクエストされた、初期化値式、そしてＮＵＬＬ値アドミッタンス）、派生属性（名前、タイプ、そして派生式）、アイデンティフィケーション機能、イベント（名前、引数：名前とタイプ、そして前提条件式）、トランザクション（名前、タイプ、引数：名前とタイプ、前提条件式、そしてトランザクション式）、評価式、状態遷移（初期状態、最終状態、サービス名、有効エージェント、そして遷移条件式）、静的な制限式、動的な制限式、トリガー条件式、アンセスタークラス（名前）、専門化クラス（名前、専門化条件式、前提条件再定義、そして評価再定義）、アグレゲーション関係（関係するクラス、濃度、静的あるいは動的、そして役名）、そして母集団選択パターン（フィルター：名前とフィルター変数、要求基準）が含まれる。
【０１６１】
概念モデルのグローバルインタラクションから得られる、関係のある情報は、名前、引数（名前とタイプ）、そしてグローバルインタラクション式を含む。概念モデルのグローバル機能から得られる、関連のある情報は、名前、リターンタイプ、そして引数（名前とタイプ）を含む。
【０１６２】
生成されたコードは、概念モデルで見つけられた情報の主なユニット、つまりクラスに基づき、コンポーネントに基づいた構造に従う。概念モデルのそれぞれのクラスは、第一のアプローチにおいて、ソフトウェアーのコンポーネントをいくつか生み出す。たとえば、「サーバーコンポーネント」と呼ばれるコンポーネントは、対応するクラスのシグニチャーに存在するそれぞれのサービスに対しての一つの方法より成るインターフェースを有する。対応するクラスの母集団を質問するために必要な方法より成るインターフェースを有するもう一つのコンポーネントは、「質問コンポーネント」と呼ばれる。特定の種類の実行コンポーネントは、概念モデルで定義されたグローバルインタラクションに関係するコンポーネントであり、そのインターフェースは、一つのグローバルインタラクションにつき、一つの方法で構成されている。
【０１６３】
これらのコンポーネントは、第二もしくは中間層が、第一もしくは表示層に提供する二つのアクセスポイントを構成する。サーバーコンポーネントは、サービスの実行に関係する表示層からリクエストを受け取り、質問コンポーネントは、固定層を質問することに関係する表示層からリクエストを受け取る。これは、インターネットで展開するアプリーケーションに適切である。なぜならば、コンテキストフリーで、スケーラブルで、トランザクション的な解決を可能なものとするからである。しかし、生成されるコンポーネントは、これだけではない。
【０１６４】
概念モデルのクラスに直接関わるもう一つの生成されるコンポーネントは、「実行コンポーネント」と呼ばれるもので、それは、対応するクラスのシグニチャーでのそれぞれのサービスの解決あるいは実行の責任を担う。このコンポーネントは、その対応するサーバーコンポーネントからか、あるいはその他の実行コンポーネントからリクエストを受け取る。
【０１６５】
実行コンポーネントの主な目的は、クラスシグニチャーで提供されたサービスを解決することであるため、エキュゼキテイブコンポーネントがその他のコンポーネントに表示するインターフェースは、一つのサービスにつき一つの方法より成る。これらの方法のそれぞれは、本発明の一実施例に基づき、エグゼキューションモデルにより、構成される。
【０１６６】
言い換えれば、実行コンポーネントは、以下の作業の責任を担う。リクエストされたサーバーインスタンスの存在と有効性を確かめること、定数と変数属性の値を取り出すために、（前述の対応する質問コンポーネントで）固定層にアクセスして、メモリにリクエストされたサーバーインスタンスのコピーを創設すること、概念モデルにおける対応する状態遷移ダイアグラムで指定されたように、リクエストされたサービスの状態遷移とリクエストされたサーバーインスタンスの現状を検証すること、リクエストされたサービス前提条件の達成度を確かめること、概念モデルの機能モデルで指定されたように、サービスにより影響されたすべての評価を行うことにより、インスタンス変数属性の値を変更し、したがって、リクエストされたサーバーインスタンスの状態を変えること、静的と動的な制限を確かめることにで、リクエストされたサーバーインスタンスにより達成された新しい状態を検証すること、必要なときにどのアクションがトリガーされるべきかを決定するために、トリガー条件をテストすること、リクエストされたサーバーインスタンスのすべての固定属性のために、固定層と通信することである。加えて、クラスがサービスのエージェントであれば、インターフェースにもう一つの方法が加えられるが、その目的はリクエスト者の存在を検証することである。
【０１６７】
もう一つの種類の実行コンポーネントは、概念モデルで定義されたグローバルインタラクションに関係するものであり、そのインターフェースは、一つのグローバルインタラクションにつき、一つの方法で構成されている。
【０１６８】
クラスが継承階層に属する場合、同じ階層のすべての実行コンポーネントは、一つの特別な実行コンポーネントにまとめられる。しかしながら、階層にはなお、一つのクラスにつき一つのサーバーコンポーネントが存在する。
【０１６９】
概念モデルにおけるクラスが生み出すもう一つのコンポーネントは、「Ｔコンポーネント」と呼ばれるコンポーネントである。このコンポーネントは、対応するクラスのインスタンスの定数および変数属性のコピーとともに、その派生属性の値を算出する方法を保存するために使用される。対応する質問コンポーネントは、コレクションを履行し、そのアイテムは、Ｔコンポーネントである。
【０１７０】
概念モデルにおけるクラスが生み出し得るもう一つのコンポーネントは、「Ｐコンポーネント」と呼ばれるコンポーネントである。このコンポーネントは、対応するクラスのインスタンスを創設する際にその定数と変数属性を初期化するために必要な値か、あるいはクラスアイデンティフィケーションメカニズムを構成する属性の値だけを、メモリーに保存するために使用される。そのようなコンポーネントは、対応するクラスがアグレゲーション関係の複数値のコンポーネントであるときはいつでも現れる。
【０１７１】
概念モデルにおけるクラスが生み出し得るもう一つのコンポーネントは、「ＰＬコンポーネント」と呼ばれるコンポーネントである。このコンポーネントは、アイテムがＰコンポーネントであるコレクションを履行するとともに、コレクションからのアイテムを加えたり取り出すためや、コレクションにおけるアイテムの数を得るのに必要な方法を履行する。そのようなコンポーネントは、対応するクラスがアグレゲーション関係の複数値のコンポーネントであるときはいつでも現れる。
【０１７２】
概念モデルにおけるクラスが生み出し得るもう一つのコンポーネントは、「Ｃコンポーネント」と呼ばれるコンポーネントである。このコンポーネントは、対応するクラスのインスタンスを創設する際に、その定数と変数の属性を初期化するために必要な値を、メモリーに保存することに使用される。そのようなコンポーネントは、対応するクラスが一時的あるいは永続的で、条件に基づいた専門化であるときはいつでも現れる。
【０１７３】
追加のコンポーネントは、ＣＣコンポーネント、エラーコンポーネント、トリガーコンポーネント、トリガーリストコンポーネント、インスタンスリストコンポーネント、条件コンポーネント、分離コンポーネント、そして結合コンポーネントを含む。
【０１７４】
ＣＣコンポーネントは、少なくとも一つの一時的、あるいは永続的な、条件に基づいた専門化が概念モデルに存在するときはいつでも現れる。ＣＣコンポーネントは、アイテムがＣコンポーネントであるコレクションを履行し、コレクションにアイテムを加えたり取り出したりする一組の方法（生成された一つのＣコンポーネントにつき、一つの組）を履行し、そしてコレクションにおけるアイテムの数を得る方法を履行する。
【０１７５】
エラーコンポーネントは常に現れ、サービス実行の成功あるいは失敗についての情報を保存することに使用される。トリガーコンポーネントは、対応するアクションが後に実行されることができるように、満たされたトリガー条件についての情報を保存する。トリガーリストコンポーネントは、アイテムがトリガーコンポーネントであるコレクションを履行するとともに、アイテムをコレクションに加え、アイテムをコレクションから取り出し、最初のアイテムを取り出し、そしてコレクションにおけるアイテムの数を得るための方法を履行する。
【０１７６】
インスタンスリストコンポーネントは、アイテムが与えられたサービスの実行において作動する実行コンポーネントであるコレクションを履行する。アイテムをコレクションに加え、アイテムを取り出し、そしてコレクションにおけるアイテムの数を得るために使用される方法に加えて、このコンポーネントはそのアイデンティフィケーション機能によりインスタンスを探すために、かかるコレクションともう一つコレクションを空にするための方法を履行する。
【０１７７】
条件コンポーネント、分離コンポーネントそして結合コンポーネントは、常に生成され、固定層に質問するために使用され、分離の結合として構成されている複雑なブール表現の構造をサポートする。条件コンポーネントは、単純ブール条件、つまり二つのオペランドとオペレーター（＋、−、＊、／、＝、＜＞、＜、＜＝、＞＝、＞．．．）についての情報を保存する。分離コンポーネントは、アイテムが条件コンポーネント（つまり条件の分離）であるコレクションを履行するとともに、条件をコレクションに加えたり取り出したりする方法と、コレクションにおける条件の数を得る方法も履行する。結合コンポーネントは、アイテムが分離コンポーネント（つまり分離の結合）であるコレクションを履行するとともに、分離をコレクションに加えたり取り出したりする方法と、コレクションにおける分離の数を得る方法も履行する。
【０１７８】
さらに、二つのモジュールもまた生成される。属性と、生成されたコードから共有された方法を分類するためのグローバルモジュールと、概念モデルで定義されたすべてのグローバル機能のコードを分類するグローバル機能モジュールである。
【０１７９】
（変換戦略と構成）
一実施例に基づき、コードジェネレーションは、高レベルなリポジトリー２１５から引き出された情報により行われる。変換プロセスは、４つのフェーズに分けることができる。概念モデルの検証（ヴァリデーター２２０により行われる）、対応するデータモデルの、リレーショナルデータベース管理システムへの変換（データベースジェネレーター２３６により行われる）、概念モデルからの情報の引き出しおよびこの情報のメモリー構造への保存、そして最後に、メモリーの保存された情報からのファイルのジェネレーション（たとえばメモリー構造内の情報を読み取り、ターゲットプログラミング言語でコードを生成する）である。
【０１８０】
概念モデルの検証は必須であるが、データモデル変換はオプションである。しかし、両方とも、コードジェネレーションに厳粛に関係した他の二つのフェーズに対する、前提条件として考えられることができる。変換構造は、概念モデルからの入力情報を保存するようにデザインされ、すべての構造は、ターゲットのプログラミング言語でソースコードを生成するために、この情報を使用する方法を有する。
【０１８１】
これらの変換構造は、以下の物を含む。サーバーコンポーネントを生成するために必要な情報を保存するクラス（サーバークラス）、グローバルインタラクションのためのサーバーコンポーネントを生成するために必要な情報を保存するクラス（グローバルインタラクションサーバークラス）、実行コンポーネントを生成するために必要な情報を保存するクラス（分析クラス）、グローバルインタラクションのための実行コンポーネントを生成するために必要な情報を保存するクラス（グローバルインタラクション分析クラス）、継承階層のための実行コンポーネントを生成するために必要な情報を保存するクラス（継承階層分析クラス）、質問コンポーネントを生成するために必要な情報を保存するクラス（質問クラス）、Ｔコンポーネントを生成するために必要な情報を保存するクラス（Ｔクラス）、Ｃコンポーネントを生成するために必要な情報を保存するクラス（Ｃクラス）、ＣＣコンポーネントを生成するために必要な情報を保存するクラス（ＣＣクラス）、Ｐコンポーネントを生成するために必要な情報を保存するクラス（Ｐクラス）、ＰＬコンポーネントを生成するために必要な情報を保存するクラス（ＰＬクラス）、概念モデルにおけるすべてのクラスのすべてのサービスのための引数についての情報を保存するクラス（引数リストクラス）、概念モデルにおけるすべてのクラスのアイデンティフィケーション機能についての情報を保存するクラス（分析クラスリストクラス）、実行コンポーネントにおいてのサービスを決定するために必要な方法を生成するクラス（イベントクラス、共有イベントクラス、トランザクションクラス、インタラクションクラス）、実行コンポーネントとインヘリタンス階層のための実行コンポーネント両方におけるサービスを決定するのに必要な補助の方法を生成するクラス（前提条件クラス、静的な制限クラス、動的な制限クラス、など）、質問とＴコンポーネントにおいて必要な方法を生成するクラス（Ｔ方法クラスとＱ方法クラス）、継承指定方法を生成するクラス（継承方法クラス）、そしてジェネレーションプロセスを監視するクラス（コードジェネレーションクラス）である。
【０１８２】
コードジェネレーションクラスは、コードを生成するために必要なすべての情報を引き出し、それを適切な順序で行い、生成されたコードをファイルに書き込み、そしてコンポーネントに基づいた構造に基づき、それをきちんとファイルに整理する責任を担う。コードジェネレーションクラスは、メモリー内の前述のジェネレーション構造のリストを維持し、そしてそのメモリーには概念モデルより引き出された情報が保存され、それは後に、適切なファイルに書き込むために、これらのリストからループする。
【０１８３】
情報引出しプロセスは基本的に、必要なすべての情報を集めるために、概念モデルにおけるクラスを通る一連のループと、グローバルインタラクションを通る一つのループ、そして概念モデルのグローバル機能を通る一つのループから成る。
【０１８４】
コードジェネレーションプロセスの最後のフェーズは、ここで記述するコンポーネントに基づいた構造によるファイルへの書き込みを含む。このプロセスは、コンポーネントとその属性と方法を生成するために必要な情報を維持し、それぞれの要素のコードジェネレーション方法を呼び出す、前に説明されたインスタンスのリストを通してループすること、グローバルインタラクション実行コンポーネントを生成すること、グローバルインタラクションサーバーコンポーネントを生成すること、グローバル機能モジュールを生成すること、そしてスタンダードコンポーネントを生成することより成る。
【０１８５】
それぞれのグローバル機能に対して、一つの方法が生成される。その方法は、そのグローバル機能と同じ名前と、一つの変換されたリターンタイプを有する。その方法のそれぞれの引数は、グローバル機能の対応する引数と同じ名前と、一つの変換されたタイプを有する。
【０１８６】
（ユーザーインターフェース変換）
一実施例において、ユーザーインターフェーストランスレーター２３４は、高レベルなリポジトリーにある情報から、ビジュアルベーシックやジャバのような高級プログラミング言語用のソースコードを自動的に生成する。しかしながら、コードは、計算された言語のどれによってでも生成されてよい。その出力は、三層構造の表示層に対応する。したがって、ユーザーインターフェーストランスレーター２３４は、ユーザーインターフェース機能を履行するコンポーネントのソースコードを出力として供給する。このコンポーネントは人の手を借りずに、自動的に生成される。ユーザーインターフェーストランスレーター２３４は、検証された概念モデル２１５を入力データとして使用し、そしてコンポーネントが派生された概念モデルに関係した等価の機能プロトタイプを履行する、第３ジェネレーション言語で書かれたソースコードを出力データとして提供する。
【０１８７】
本発明の一実施例において、ユーザーインターフェーストランスレーター２３４は、以下のものを行うソースコードを作成する。ビジネスコンポーネントにリクエストを送り、返答を受け取ることができる通信サブシステム、ユーザー確認のためのシステムへのログオン、そして特定の確認されたユーザーが利用できるサービスのメニューである。それぞれの利用できるサービス、フレーム、スクリーン、あるいはすべてのサービス引数のデータコレクションダイアログのために、ユーザーインターフェーストランスレーター２３４は、引数の初期値を設定し、導入されたデータ（タイプ、範囲、オブジェクト存在など）を検証し、そしてサーバー活性化を呼びかけるコードを生成する。加えて、ユーザーインターフェーストランスレーター２３４は、一つのクラスにおけるすべてのインスタンスのステータスとエラー取り扱いを一覧表にするスタンダード質問サービスのためのコードも生成する。
【０１８８】
さらに、さらに広範囲でフレキシブルなユーザーインターフェース作業のためのコードが生成される。質問サービスフレーム、フォーム、あるいはスクリーンにおいて、ある特定のインスタンスが選ばれたとき、以下の機能が利用可能になる。それは、関係し選ばれたオブジェクトとの関係を通したナビゲーションである。このナビゲーションは、その関係するリンクに従い、関係するデーターアイテムの間を閲覧するのに使用される。したがって、結果として生じるコードは、インターネットアプリケーションに適している。追加機能は、選ばれたオブジェクトのサービス活性化、フィルター（母集団選択）、ビュー（ステータス選択）、そしてソートのクライテリアを含む上級質問サービス、そして既知のサービス引数を記入するためのコンテクストの維持を含む。コンテキストの維持は、ユーザー設備である。コンテキストは、ユーザーが仕事をする環境に関連したデータである。このデータは、サービス引数のデフォルト値を供給するのに役立つ。
【０１８９】
その入力のために、ユーザーインターフェーストランスレーター２３４は、概念モデルの仕様２１５を読み取り、この種の情報をメモリー内の中間構造に保存する。ユーザーインターフェーストランスレーター２３４は、概念モデルが供給される入力媒体から独立している。このように、中間構造は、異なったデータソースからロードされることができる。このモデルは幾たびかイテレーションされ、形式仕様から変換プロセスのそれぞれのフェーズにおける、クラスや、アグレゲーション関係、継承関係、エージェント関係、グローバルインタラクション、ユーザーの定義された機能、そしてインターフェースパターンについての情報などを含む、関係のある情報を引き出す。
【０１９０】
変換されたアプリケーションは、最終ユーザーに提供されるユーザーインターフェースを含むフォームにより構成される。抽象的な意味で、フォームとは最終ユーザーとのインタラクションユニットである。フォームは、たとえば、ウィンドウズ（登録商標）環境のウィンドウズダイアログや、ウェッブプラットフォームでのＨＴＭＬページ、そしてジャバのアプレットなどのように、必要条件を満たすために、ターゲットの環境の能力に応じて変換される。
【０１９１】
トンランスレートされたアプリケーションは、システムにユーザー接続を供給する。ユーザー接続は、エージェントを確認するためにアクセスフォームを使用して解決される。加えて、変換されたアプリケーションは、システムユーザービューを供給する。ユーザーは、ユーザーが開始できるサービスにアクセスすることができなければならない。主要フォームは、この仕事を果たすようデザインされている。
【０１９２】
ユーザーが実行できるそれぞれのサービスのために、変換されたアプリケーションは、活性化サービスフォームを生成する。それぞれのクラス用には、変換されたアプリケーションは、質問／選択フォームを生成する。このフォームは、ユーザーがデータインスタンスに質問し、ある特定の条件を満たすインスタンスを探し、関連したインスタンスを観察し、そしてどのサービスが、その現在の状態におけるある特定のオブジェクトに対して、開始されることができるかを知ることができるようにする。それぞれのサービスに対し、変換されたアプリケーションは、オブジェクト評価された引数のために初期化値を提供する。初期データもまた、ユーザーによって作られた閲覧から得られた情報を管理することにより供給される。
【０１９３】
ユーザーは、アプリケーションとインターアクトする、異なったシナリオに遭遇する。これらのシナリオは、異なったタイプのフォームを定義するよう導く。次の項において、フォームのそれぞれの種類が説明される。
【０１９４】
概念モデル２１５において、いくつかのクラスは、サービスクラスのエージェントとして定義される（エージェントクラスと呼ばれる）。つまり、オブジェクトがサービスエージェントならば、そのサービスをリクエストすることを許可される。それぞれのエージェントオブジェクトは、サービスをリクエストしようとする前に、確認され検証されなければならない。アクセスフォームは、エージェントクラス（有効なエージェントクラスのリストより選ばれる）と、オブジェクトアイデンティファイヤー、そしてパスワードをリクエストする。回収されたデータは、システムにアクセスすることを許可された有効なエージェントオブジェクトが存在するかどうかを確かめるために使用される。
【０１９５】
アプリケーションメインフォームは、ユーザーが、実行を許されているサービスを見ることができるメニューを含む。ユーザーにより実現されるそれぞれのアクションに関連したソースコードは、自動的に生成される。
【０１９６】
少なくとも一つのエージェントのそれぞれのアクセス可能なサービスに対し、サービスフォームが一つ生成される。これらのフォームは、ユーザーが供給しなくてはならないそれぞれの引数の導入フィールドを有する。この引数のフィールドは、データタイプ、サイズ、値の範囲、NULLなどを検証するための付属のコードを有する。オブジェクト評価されたフィールドは、情報を閲覧しそれをフィルターにかけるオブジェクトを探すための設備を供給する。コードは、この仕事を達成するために生成される。
【０１９７】
それぞれのサービス引数は、この初期値を三つの異なった方法で取ることができる。
【０１９８】
１．初期値によって。概念モデルにおいて、デザイナーは、属性と引数のためにデフォルト値を供給することができる。そのような値が存在すると、その値を供給するために、コードが生成されなければならない。
【０１９９】
２．コンテキストによって。コンテキスト情報（たとえば最近観察されたオブジェクトのリスト）は、引数を回収した同じタイプを有する、オブジェクト評価された引数に、値を示唆することに役立つ。最近訪れたオブジェクトのリストの内から適切な値を探すための機能が生成される。
【０２００】
３．依存パターンによって。概念モデルにおいて、システムデザイナーは依存パターンを定義することができる。状態回復パターンは、依存パターンの潜在的なセットでもある。両方の場合において、引数上の変化は、もう一方のパターンにおける値に影響を与えることができる。よって、ある特定の引数値は、このように最初に決定することができる。
【０２０１】
データ検証は、インターアクティブにユーザーに警告しながら、データ入力の後すぐと、システムロジックにデータを送る直前に起り得る。オブジェクト評価された引数の検証は、オブジェクトの存在の検査を必要とする。検証をサポートするため、それぞれのサービス引数に対し一つの機能が生成される。この機能は、リクエストをシステムロジックに送る前に発動される。
【０２０２】
ユーザーがサービスの実行をリクエストするとき、サービス引数が検証される。サービス引数が有効ならば、システムロジックは、そのサービスを達成するために発動される。システムロジックを発動するために作られたメッセージは、引数をソートするために形式オーダーを使用する。サービスを実行した後、ユーザーは、サービスが成功したかどうか告知される。このトランザクションのアプローチは、インターネットアプリケーションにとって理想的である。したがって、引数を検証するコードと、形式オーダーにおける必要な引数とともにシステムロジックを発動するコードが、生成される。さらに、可能なエラーは、ユーザーに告知するために返還される。
【０２０３】
質問／選択フォームは、オブジェクト（フィルターによって制限することができる）の質問とオブジェクトの選択を許可する。オブジェクトが選択されたとき、ユーザーは、そのオブジェクトに関係するその他のデータアイテムに閲覧することができる。同じように、ユーザーは、その選択されたオブジェクトのサービスを開始することができる。
【０２０４】
これらの質問／選択フォームは、フィルターを表示するグラフィックアイテムを含む。ビジュアルコンポーネントを、クラスの母集団をフィルターするために使用する。フィルターは、変数を含んでいてもよい。そのような場合、変数のためのフィールドが、フィルターの条件を定めるために、ユーザーにリクエストされる。たとえば、車をカラー別、タイプ別、そしてモデル別に見つける、などである。
【０２０５】
これらの質問／選択フォームはまた、オブジェクトを表すためのビジュアルコンポーネントも含む。このコンポーネントの中に、フィルター条件（あるいはフィルターが定義されていない場合は、すべてのクラス母集団）を満たすオブジェクトが現れる。このコンポーネントにおいてディスプレイされる属性は、ディスプレイセットによって設定される。
【０２０６】
これらの質問／選択フォームはさらに、サービスを開始するためのビジュアルコンポーネントを含む。たとえば車を例にすると、ユーザーはその車を借りたり、返したり、あるいは売却したりするためのサービスを開始することができる。この仕事は、どのオブジェクトの、どのサービスを開始するかを決定する機能によって達成される。対応するサービスフォームは、それぞれの明らかにされたサービスに対し発動される。これらの質問／選択フォームはまた、ブラウジングを開始するためのコンポーネントを含む。たとえば車を例にすると、ユーザーはそのドライバー、そのドライバーの息子などを見ることができる。ユーザーが、ナビゲートするとき（オブジェクトからのリンクを辿り）、新しい質問／選択フォームがディスプレイされる。前回のコンポーネントと同じように、そこには、ユーザーがオブジェクトを閲覧する際にディスプレイされる次のフォームを発動するコードが存在する。ナビゲーションにより質問／選択フォームに到達したとき、フォームは、その最初のオブジェクトに関係したデータだけをディスプレイするために、前のオブジェクトについての情報を受け取る。
【０２０７】
アプリケーションには、訪問されたオブジェクトと、ユーザーによって辿られたナビゲーション通路が保存される。この情報はコンテキスト情報と名づけられる。ユーザーが、質問／選択フォーム間のデータを閲覧する際、辿られた通路は保存される。最後に、ユーザーがサービスを発動しようと試み、サービスフォームが必要とされると、アプリケーションは、サービスフォームへの追加入力として、このコンテキストの情報を供給する。したがって、サービスフォームは、オブジェクト評価の引数に初期値を供給するために、このデータを使用する。
【０２０８】
（ユーザーインターフェーストランスレーター構造）
入力として使用された概念モデル２１５を使用して、ユーザーインターフェーストランスレーター２３４は、質問ＡＰＩあるいは、その他の入力ソースを使用して、メモリー構造からの情報、関係のあるデータベースを引き出すことができる。メモリー内の中間構造は、ユーザーインターフェースコンポーネントを変換するために関連のある概念モデルのデータで満たされている。中間構造は、指定の概念モデルのクラスやサービス、そして属性のために、質問することができる概念モデルスキーマで定義されたものへと一つの構造に従う。
【０２０９】
データが中間構造にロードされる際、真の変換のフェーズが始まる。生成されたアプリケーションのソースコードファイルの中において、二つのタイプのファイルを区別することができる。一つのファイルは、固定された内容が入ったファイルのセットである。これらのファイルは、常に同じように作成され、広く使用される構造、あるいは補助機能に対応する。これらのファイルは、これらを創設するためにバイトストリームをトランスレーターから最終ファイルへ直接落とすことにより、生成される。その他のファイルは、処理されている概念モデルに大いに依存する。したがって、これらのファイルはしっかりと定義された構造を有するが（前の項で詳しく述べれている）、それらは処理されたモデルによって決まる可変な部分を有する。ユーザーインターフェーストランスレーター２３４は概念モデルをイテレーションし、関連するデータを引き出し、これらの可変な部分を生成する。
【０２１０】
ユーザーインターフェーストランスレーター２３４の変換プロセスは、以下の作業を含む。
【０２１１】
１．固定されたファイルを生成する。たとえば、ヘッダー、定義、定数、そしてそのそれぞれのファイルへの補助機能など。
【０２１２】
２．アプリケーションにより、補助ウイジット（コントロールあるいはジャバビーン）を生成する。
【０２１３】
３．それぞれのクラスに対し、質問／選択フォーム、インスタンス選択コンポーネント、専門化コンポーネント（クラスが、その他のクラスから専門化されると、追加の初期化が必要とされる。）を生成する。それぞれのサービスクラスに対し、サービスフォームも生成する。
【０２１４】
４．アクセスフォームを生成する（アイデンティフィケーション）。
【０２１５】
５．メニューアプリケーションを含むメインフォームを生成する。
【０２１６】
６．システムロジックサーバーと連絡を取るための通信機能を生成する。これらの機能は、プロトタイプにおいて利用可能なサービスの開始をインキャプシュレートする。
【０２１７】
アクセスフォームは、エージェントクラスのリスト（このリストから、ユーザーは一つ選択する）、ユーザーが前回に選択されたクラスに属する有効なオブジェクトインスタンスのためのＯＩＤを供給するフィールド、そしてパスワードのためのフィールドを含む、小さなダイアログボックスである。このフォームは主に固定された方法で生成される。それぞれのモデルによって異なる唯一の部分は、前述のエージェントクラスのリストである。モデルクラスのリストをイテレーションし、どのクラスがエージェントであるかを検査することにより、そのようなエージェントクラスのリストを獲得することができる。
【０２１８】
アプリケーションの機能性にアクセスを供給するために、サービスは、メニューバー（ビジュアルベーシッククライアント）、ＨＴＴＰページ（ウェッブクライアント）、あるいはブラウジングを許可するその他の構造に変換されるために、アクセス階層に配列される。デフォルトにより、階層は、概念モデルにおけるクラスとサービスをイテレーションすることにより作られる。階層は、アプリケーションへのアクセスツリーとして見ることができる。それぞれのクラスのために、クラスエイリアスが付けられた一つのツリーアイテムが作られる。それぞれの内臓されたアイテムのために、このモードは子孫アイテムとして、以下のアイテムを有する。質問フォームにアクセスするための「質問」と名づけられたアイテム、現在のクラスで定義されサービスエイリアスを付けられたそれぞれのサービスのためのアイテム、そしてその他のクラスとの継承関係を持つ場合は、サブクラスエイリアスを付けられたそれぞれの直接のサブクラスのために、一つのアイテムが作られる。帰納的に、継承ツリーが完全に調査されるまで、同じアルゴリズムが適用される。
【０２１９】
サービスフォームは、概念モデルから引き出された以下の入力データを必要とする。生成するサービス、サービスクラス、引数リスト、そして引数とリンクされたインターフェースパターンである。それぞれのサービスのために、グラフィックな部分と機能的な部分とを含むフォームが生成される。グラフィックな部分は、ユーザーに聞かなくてはならないそれぞれの引数に付属したウイジット一つと、サービス開始を許可したりキャンセルしたりする一対のウイジットを含む。機能的な部分は、以前のウイジットのためのイベントドライバーを履行し、デフォルト値でこれらのウイジットの特性を初期化し、導入された値を検証し、そしてシステムロジックコンポーネントにおけるサービスを発動するためのコードを含む。
【０２２０】
次は、サービスフォームをどのように生成するかの詳細な説明である。最初に、二つの引数リストが得られる。一つ目は、サービス宣言で定義された引数に対応する（ＦＬ、形式リスト）。このリストにおいて、引数は、その形式宣言順序によってソートされる。二つ目は、表示順序によってソートされた、同じ引数を含む（ＰＬ、表示リスト）。二つの順序は共に、概念モデルで指定される。
【０２２１】
形式リストを通してそれぞれの引数のためにイテレーションを行う。ユーザーにリクエストされなければならないそれぞれの引数のためのウイジットを一つ作り、タイプ、サイズ、NULLでも良い、導入パターン、定義された選択パターン、あるいは母集団選択パターンのような、引数に関係した特性を設定する。
【０２２２】
ウイジットは、オーケーコマンドやりキャンセルコマンドのために加えられ、そしてウイジットのグラフィックな部分は重複しないように整理される。一履行において、フォームは縦がｎ欄で横がｎ列のロジカルな格子に分けられ、ウイジットを便利に整理するために左から右、上から下まで位置を割り当てる。ロジカルな位置は、ターゲット言語において、物理的な位置に変換され、フォームの右下の隅にアクションコマンドが再整理する。最後に、このフォームは、そこで含まれるデータのサイズに調整するために、再度寸法合わせをされる。
【０２２３】
出力のために、フォームの標準ヘッダーは、ファイルに落とされる。このステップは、選択されたターゲット言語に依存する。それから、フォームのグラフィックな部分は、べーシックフォーム特性の定義、それぞれのウイジットの定義、そしてウイジットのアクションを含み、ファイルに落される。
【０２２４】
最後に、このフォームに付属するソースコードは、変換され、落される。このプロセスには、イベントの開閉や、リソースを割り当てたり取り除いたりするためのコードを作成したりなど、フォームにおけるイベントを管理するための一般的な機能を変換することを含む。また、ステータス回復パターンとウイジット間の依存性を取り扱う機能も変換される。サービスに付属したステータス回復パターンやサービスで定義された可能性のある依存性パターンにより、引数値を変更するコードと、そのような依存性をトリガーするコードを生成しなければならない。検証コードもまた、変換される。ウイジットに集められた値が正しいかを検査するための検証方法が存在する。最後に、システムロジックサービスに対し、発動を呼びかけるサービスを変換する機能が生成される。形成されたこの機能は、サービスが実行されるシステムロジックオブジェクトについての参照、システムロジックにおけるサービスを履行する方法の発動、そしてウイジットを通してユーザーから供給された値から構成された、そのような機能に必要な引数を含む。
【０２２５】
質問／選択フォームを生成するために、以下の概念モデルの情報が必要とされる。クラスとその特性（エイリアス）、そしてそのクラスのために定義された母集団選択インターフェースパターンのリストである。それぞれのパターンは、ディスプレイセット、フィルター、そしてソート基準を含む。定義された可視化セットが無い場合、クラスに属する属性のリストを推測する。クラスに母集団選択パターンが欠けていると、以下のデフォルト値が仮定される。クラスで定義されたすべての属性は、ディスプレイセットの一部とみなされ、フィルター（この場合、クラスの全母集団は、返還される）とソート基準のどちらも付属されない。
【０２２６】
質問／選択フォームを生成するには、クラスの関係についての情報も必要とされる。すべてのクラスに対し、この情報に基づきフォームが生成され、そのフォームは、クラスのディスプレイセットの表の表示と、母集団に対するサーチを制限できるようにする、グループ化された一組のフィルター、そして最初のものに関係するクラスと、クラスのインスタンスに対して開始される利用可能なサービスへのナビゲーションリンクを含むポップアップメニューを含む。
【０２２７】
前に説明された、生成されたソフトウェアコンポーネントは、プロトタイプが引き出された概念モデルに対応するプロトタイプを検証し実行するために必要なすべての機能を含む、ユーザーインターフェースクライアント機能を供給する。コンポーネントのアプリケーションは、プロトタイピング、新しい必要条件を取り込む前の概念モデルのユーザー検証、モデルが忠実に必要条件を反映しているかを確かめる分析担当による概念モデルを検証するためのテスト、そして最終のアプリケーション作成である。必要条件の取り込みのプロセスが一度完成すれば、生成されたコンポーネントは、機能的に完全で、エルゴノミックなユーザーインターフェースを履行する最終バージョンとみなすことができる。コンポーネントは殆ど労力なくして、ユーザーの希望に沿ってアプリケーションをカスタマイズするために編集することができる。
【０２２８】
（データモデル変換）
一実施例においては、データベースジェネレーター２３６は、高レベルのリポジトリー２１５の検証された仕様に基づき、リレーショナルデータベース管理システム（ＲＤＢＭＳ）におけるデータモデルを自動的に定義する。しかしながら、フラットファイルや、一連のファイル、あるいはオブジェクト指向のデータベースなど、その他の形態の永続的な保存を使用してもよい。データベースジェネレーター２３６の出力は、複数層の構造における固定層に該当する。
【０２２９】
ある特定の概念モデルについての、高レベルのリポジトリーにある情報から、テーブルや制限（第一キーと外部キー）、そしてインデックスを創設したり削除したりするために、スクリプトが生成される。スクリプトは、前記のデータモデルを効果的に創設するために、リレーショナルデータベース管理システムにおいて、オプションとして実行することができる。
【０２３０】
リレーショナルデータベースの視点で、データはテーブルに、テーブル間の関係と共に保存される。しかし、オブジェクト指向のプログラミングの視点では、データはオブジェクト階層に保存される。
【０２３１】
本発明の一実施例による自動ソフトウェア作成システムはオブジェクト指向の方法論に基づくが、生成されたアプリケーションにより管理されるデータを、永久的に保存するための物理的なデータ保存システムを見つける必要がある。リレーショナルデータべースはデータを保存するための産業基準方法であるので好まれる。結果的に、オブジェクトの代わりにテーブルを使用することが好まれる。しかしながら、本発明の一実施例により作成されたもののように、多くのオブジェクト指向のアプリケーションは、変換プロセスに続いて、オブジェクトの静的な面をテーブルに保存することができるため、リレーショナルモデルと互換性を持つことができる。
【０２３２】
生成されたデータモデルは、一組のテーブルと、対応する関係と、そして基本キーと外部キーに対する制限とインデックスから成る。生成されたデータモデルは、クラスの仕様で定義された属性と、インスタンスがエージェントならばインスタンスの状態や役割のような、その他のクラスインスタンスの特性とを有するシステムデータを反映する。
【０２３３】
高レベルのリポジトリー２１５から集められた、対応するデータモデルを作成するために必要とされる情報は、クラスに集中し、そして名前、定数属性（新しいか、あるいはインヘリットしたもの）、変数属性（新しいか、あるいはインヘリットしたもの）、アイデンティフィケーション機能、インヘリットしたアイデンティフィケーション機能、集合関係（新しいか、あるいはインヘリットしたもの）、そしてエージェント情報を含む。
【０２３４】
望ましくは、生成されたスクリプトは、標準：ＡＮＳＩ  ＳＱＬ９２に従う。この事実は、生成されたデータモデルは、ＡＮＳＩ  ＳＱＬ９２に基づいたデータベース管理システムであり、特に最も良く知られたリレーショナルデータベース管理システムであれば、どれでも適応することができるということを意味する。
【０２３５】
データモデルを得るためのプロセスは、以下のようなステップを踏む。概念モデルのそれぞれの基本クラスに対し、選ばれたリレーショナルデータベースに、テーブルが創設される。クラス仕様におけるそれぞれの定数あるいは変数属性に対し、クラスに対応するテーブルにおけるフィールドが創設される。フィールドデータタイプは、ターゲットのリレーショナルデータベースに変換された、概念モデル属性データタイプに依存する。導出された属性は、それらの値が生成されたサーバーコードの特別な方法によりリクエストされた際に計算されるため、データベースには保存されない。
【０２３６】
基本キーは、概念モデルでアイデンティフィケーション属性であると示された属性によって決定される。したがって、これらの属性に対応するテーブルフィールドは、テーブルの基本キーを構成する。特別な場合として、専門化されたクラスに対応するテーブルは、新しい属性を表すフィールドに加えて、属性の先祖クラスを表すテーブルの基本キーを構成する属性に対応するフィールドを有する。専門化されたクラスがそれ自身のアイデンティフィケーション機能を有さなければ、先祖クラスからコピーされたこれらのフィールドは、専門化されたテービルの基本キーを構成する。同時に、それらのフィールドは、親クラステーブルに対し、外部キーを構成する。一方、専門化されたクラスがそれ自身のアイデンティフィケーション機能を有する場合、これらのフィールドは、親クラステーブルに対する外部キーのみを構成する。
【０２３７】
集合の場合は、より多くのディメンションを有するため、より複雑である。集合関係のディメンションはその濃度を決定し、濃度はデータベースでの表現を決定する。その関係が、両方の意味で複数値（Ｍに設定された最大濃度）ならば、新しいテーブルがこの集合関係を表すために加えられる。このテーブルは関係するテーブルの基本キーを構成するそれぞれに対して一つのフィールドを持つ。これらすべてのフィールドのセットは基本キーを成し、フィールドは個々に、それぞれの関係するテーブルの基本キーに由来し、それぞれの関係するテーブルの外部キーを構成する。
【０２３８】
その関係が、一つの意味で単一の値（１に設定された最大濃度）ならば、一方の一つのみのインスタンスと関係するクラスが、その一方の基本のフィールドをコピーする。これらのフィールドは、関係するクラステーブルへの外部キーを構成する。
【０２３９】
その関係が両方の意味で単一の値ならば、どのテーブルも、もう一方への外部キーを有することができる。この場合採用されるオプションは、集合クラスが、コンポーネントクラスを参照することである。最小濃度に関して、最小濃度が０ならば、その対応するフィールドは、NULLを採用する。他の状態では、採用しない。アイデンティフィケーション依存が二つのクラスの間に存在すると、依存しないクラスの基本キーのフィールドが、依存するクラスに対応するテーブルにコピーされる。それらはその基本キーの一部となり、依存していないクラスのテーブルへの外部キーとなる。
【０２４０】
サーチを最適化し応答時間を削減するために、インデックスを生成してもよい。外部キーもサーチインデックスになるように、それぞれの外部キーに対しインデックスが生成される。
【０２４１】
ここまで、オブジェクトの静的な面を取り扱ってきたが、動的な面もまたいくらか検討される必要がある。サービスの属性の値がサービスの状態を特徴付けるため、サービスが起こるたびにオブジェクトの状態が変化することから、サービスの発生はオブジェクトのライフにおける進化を特徴付ける。状態遷移ダイアグラムは、オブジェクトの有効なライフを決定する。状態遷移を監視するために、新しいフィールドがクラスに対応するそれぞれのテーブルに加えられ、オブジェクトがある特定の瞬間にある状態遷移ダイアグラムにおける状態の名前を保存する。
【０２４２】
生成されたアプリケーションは、システムにログオンしているエージェントに、アイデンティフィケーションとパスワードをリクエストすることにより、ユーザー確認を行っても良い。新しいフィールドが、システムの中のサービスのエージェントであるクラスに対応するテーブルへ加えられ、そのエージェントのパスワードを保存する。
【０２４３】
（ドキュメンテーション変換）
ＣＡＳＥツール２１０は、システムのドキュメンテーションを生成するために使用することができる追加情報を、分析時に導入できるようにする。したがって、ドキュメンテーションジェネレーター２３８は、形式仕様、完全な概念モデル詳細ドキュメンテーション、ユーザーへのヘルプ、そしてその他を含む一組のドキュメントを、高レベルのリポジトリー２１５の情報から自動的に作成する。
【０２４４】
それらの異なった性質のため、形式システム仕様のためには特別のジェネレーションプロセスが存在する。残りの作成されたドキュメントは、一般的なデータ処理に拠る。この処理では、同じドキュメントを異なった書式で得ることができ、どんな新しいタイプのドキュメントでも定義することができる。
【０２４５】
ＣＡＳＥツールは、前回に集められた概念モデルから自動的に生成されることができる複数のドキュメントを供給しなければならない。ドキュメンテーションジェネレーター２３８は、概念モデルに対して行われる情報リクエストや質問のための要求に答える。ドキュメンテーションジェネレーター２３８は、企画を適切にドキュメントするために、質問、特定の文書、あるいはしっかりと形成されたドキュメントのジェネレーションを可能にする。
【０２４６】
好ましい実施例において、概念モデルの完全なジェネレーションは、問題の分析に関係する概念モデルの部分を成すＯＡＳＩＳシンタックスのＡＳＣＩＩ書式で生成されるが、表示モデルインターフェースパターンはこのシンタックスに含まれていない。
【０２４７】
ドキュメントジェネレーターは、デフォルトでは、一般ドキュメント、サービスドキュメント、そしてヘルプドキュメントを供給する。一般ドキュメントは、通常言語での仕様の説明を含む。サービスドキュメントは、クラスとサービスの詳細な説明を含む。ヘルプドキュメントは、生成されたプロトタイプのためのオンラインヘルプを含む。
【０２４８】
ドキュメンテーションジェネレーターは、ターゲット言語として、認識された幾つかの標準書式をドキュメンテーションに使用する。それらは、ＡＳＣＩＩ、プレーンテキスト、複数のドキュメントを有するナビゲーションのＨＴＭＬ、一つのドキュメントを有するナビゲーションのＨＴＭＬ、ＬａＴｅＸ、そしてリッチテキストフォーマット（ＲＴＦ）である。
【０２４９】
このドキュメンテーションシステムはスケーラブルで、新しい種類のドキュメントやターゲット言語を追加するために拡張することができる。新しいターゲット言語を加えることにより、すべての定義されたドキュメントが、この新しい言語で生成されることができるようにする。同じように、新しいドキュメントタイプを加えることにより、支援されるどのターゲット言語ででも生成できる。
【０２５０】
ＯＡＳＩＳ仕様を作成するために、一つのプロセスが情報構造上をイテレーションし、ＯＡＳＩＳ言語における対応するテキストストリングを一つのファイルに書き込む。内部プロセスにおいて、構造上のイテレーションは、（１）仕様ヘッダーを書き込む、（２）説明されるために選ばれるすべてのクラスに対し、そのＯＡＳＩＳテンプレート（属性、イベント、派生、制限、前提条件、トリガー、そしてプロセス）を書き込む、（３）すべてのグローバルトランザクションに対し、その宣言と形式定義を書き込む、（４）エンド仕様書を書き込む、というように詳細であることができる。
【０２５１】
ドキュメントは、中間ブロック言語（ＩＢＬ）で生成される。そのような言語では、ドキュメントはドキュメントタイプの一つのブロックであり、ｎ個の子ブロックを含む。帰納的に自制関係とブロック分類を固定することにより、ドキュメントは、ブロックの構造に基づき定義することができる。ブロックは、以下の特性を含む構造である。名前、カテゴリー、ブロックタイプ、ブロックテキスト、そして含まれるブロックのリストである。
【０２５２】
ジェネレーションは、ドキュメントにより固定された順序に従い、概念モデルをイテレーションするループを履行するアルゴリズムによりサポートされる。これらのイテレーションにおいてドキュメントは、ドキュメントを構成するブロックを創設し、そしてリンクしながら作られる。
【０２５３】
ブロック構造が作られる際、結果として生じる構造であるブロックのツリーは、それを選ばれたターゲット言語のドキュメントに変換するトランスレーターにより処理される。この帰納的ディセント分析を使用したアルゴリズムは、ブロックと含まれたブロックに保存された情報次第で、ターゲット言語のタグにブロックを変換する能力がある。
【０２５４】
例として、テキスト「タイトル」を含む一つのセクションブロックは、次のストリングＨＴＭＬに同等なものに変換される：＜Ｈ１＞タイトル＜／Ｈ１＞。
【０２５５】
（完全なアプリケーションの生成）
したがって、自動ソフトウェア作成ツールは、情報必要条件を取り込むと説明され、また静的、動的、そして機能の３つの観点から、「ビジネスプロセス」と呼ばれる。これによりシステムデザイナーと分析者は、彼らがモデルする現実のすべての面を完全に取り込むことができるようになる。
【０２５６】
システムロジックトランスレーターは、したがって、正確さと完全さを確かめるために以前にすでに検証される情報のすべてを集める責任を担い、モデルされた現実のすべての面を履行するコードを自動的に作成する。このシステムロジックコードは、以下のような特徴を有する。
【０２５７】
システムロジックコードは、完全で正確である。システムロジックトランスレーターによって集められた情報は以前に検証されているので、作成されたコードは、供給された変換レシピのセットのおかげで、完全且つ正確であることが保証することができる。変換レシピのセットは、分析者によってモデルされ得るすべての面を含み、したがって概念モデルで表現し取り込むことができるすべてのものは、ソースコードに変換することができる。すべての変換レシピは正確な変換を保証し、かくしてソースコードにエラーがなくなる。
【０２５８】
システムロジックコードはただのプロトタイプのためのものではなく、完全なアプリケーションのためのものである。生成されたコードは、（そのターゲットプログラミング言語による適切なコンパイラーで）コンパイルすることができ、概念モデルの情報入力から完全に変換されているため、「そのまま」で実行することができる。生成されたコードは、ただの方法の骨組を集めたものではなく、完全な方法である。さらに、不必要なコードは作成されず、またコードの一行として一度以上生成されることはない。これに加え、生成されたコードがしっかりと構成されており可読であるが、コメントが内部コードドキュメンテーションの手段として自動的に生成され、可読性を改善する。
【０２５９】
システムロジックコードは、ロバストであり、エラーのテストと処理を含む。正確さと完全さが、ロバストなコードの作成を可能にする。概念モデルの情報に基づき、エラーは、二つのカテゴリーに分けられる。モデルエラーつまり内部エラーと外部エラーである。内部エラーは、概念モデルに基づき、ある特定の時点で、適用しなければならない特性に対応する（たとえば、適用しない前提条件、完全性制約、集合関係の最大濃度の違反など）。外部エラーは、概念モデルの一部でない原因に相当する（たとえば、システム機能不全、データベース機能不全など）。
【０２６０】
生成されたコードは、この分類に基づき、以下のようにエラーを処理する。内部エラーについては、システムロジックトランスレーターは、内部エラーが起こりえるすべての地点を確認し、エラーテストとエラー処理のコードを作成し、クライアントにそのようなエラーの発生を告知する。さらにまた、内部エラーは分類することができ、カスタマイズ可能なエラーメッセージやエラーコードのような特定の処理を加えることができる。外部エラーについては、システムロジックトランスレーターは、外部エラーが起こりえるすべての地点を確認し、エラーテストとエラー処理のコードを作成し、クライアントにそのようなエラーの発生を告知する。外部エラーはカテゴリー化されることができないため、同じ標準の方法で処理される。
【０２６１】
したがって、すべての起こりえる状況に対するエラーテストとエラー処理の自動作成は、概念モデルのどのような変換もロバストであると保証することができる。
【０２６２】
システムロジックコードは、トランザクションの行動を取り扱う。生成されたコードは、コードがクライアントにシステムからサービスをリクエストできるようにする明確なインターフェースを供給するという意味で、トランザクションの行動を表示する。それらのサービスは、トランザクション的な方法で実行される。つまりすべてのサービスの入力引数はクライアントによって供給されなければならず、その後システムロジックは対応する作業を行いクライアントに返答する。概念モデルにおけるサービスは、アクションに分解することができる。生成されたコードは、サービスを構成するすべてのアクションが首尾良く達成され、さもなくば何も行われないことを保証する。加えて、サービスが分解されてできたアクションによって影響されたオブジェクトに対する変化は、これらすべてのアクションが首尾良く終わるまで、実質的には行なわれない。トランザクションの行動はまた、レガシーシステムとのインテグレーションを強化する。
【０２６３】
システムロジックコードは、ユーザーインターフェースから独立している。生成されたコードは、クライアントがサービスをリクエストできるようにする、明確なインターフェースを供給する。しかし、このインターフェースは、クライアントがそれとインターアクトすることに依存しない。これは、異なるクライアントのグループが同じシステムロジックとインターアクトすることを可能にする。したがって、特定のシステムロジックのクライアントは、それが彼らに表示するインターフェースのみを知る必要がある。この特徴は、インターネットアプリケーションの展開を簡単にし、またレガシーシステムへの統合と、巨大な情報システム、あるいは概念モデルを、明確なインターフェースを持ちそのためにそれぞれがインターアクトできるより小さなものへ分解することがよりよくできるようにする。
【０２６４】
システムロジックコードは、固定層から独立している。生成されたコードは、「固定サービス」とみなされるものを履行する固定層と相互作用する責任を担う。これらのサービスは、固定層における情報を加えたり、引き出したり、改定したり、そして削除したりする責任を担う。これらのサービスは、その作業を実行するシステムロジックにとって必要であるが、これに加え、システムロジックは、固定層に対する質問を実行するサービスを供給することにより、クライアントに対し、固定層を隠蔽する。これは、クライアントが固定層の物理的な位置を知る必要がなく、固定層に対する質問を実行するサービスを供給されているため、固定層の構造を知る必要がなく、固定層へのアクセスは完全にシステムロジックが管理しているため、固定層のアクセスを許可されたユーザーである必要がなく、そして固定層が存在するこさえ知る必要がないことを示唆する。
【０２６５】
要するに、本発明の一実施例の自動ソフトウェア作成システムによって自動的に作成されたコードは、ただのプロトタイプのそれではなく、本当に最終的なソフトウェアアプリケーションのそれに相当する。この識別を維持するために、生成されたシステムロジックコードとプロトタイプのそれとの違いの幾つかを説明する。
【０２６６】
（１）完全さ：プロトタイプは、情報システムの機能性を完全に含まず、すべての可能な実行の流れのために意図されている訳ではないが、我々の自動に生成された最終的なアプリケーションとなるコードは、すべての可能な実行の流れと共に、対応する概念モデルで取り込まれた機能性をも完全に含む。
【０２６７】
（２）正確さ：プロトタイプは、ユーザーのニーズと必要条件を確かめ、そして実行の正確さを確かめる目的をもつ。一方、本発明の一実施例に基づく自動的に生成されたコードは正しく生成されているため、ユーザーのニーズと必要条件を確かめる目的をもつ。
【０２６８】
（３）ロバストなこと：プロトタイプは、エラーテストとエラー処理のコードで作成されていないため、ロバストではない。むしろ、このコードは、通常は手作業あり、ユーザーのニーズと必要条件が満たされていることが証明され、したがって、最終アプリケーションが作成されることができるコード化の最終フェーズまで作成されない。我々の自動的に作成されたコードの場合であるような最終アプリケーションは、ロバストであることを確かめるために必要なすべてのコードを有しなければならない。これは通常、手作業でコード化されるため、プログラマーが、コードを必要な箇所の多くに加え忘れることが多々ある。これは、維持のコストを高いものとし、システムロジックコードとエラーテストとエラー処理のコードの間のバランスを崩す。本文で説明されたシステムロジックのトランスレーターは、エラーテストとエラー処理に必要な（そして必要ちょうどの）すべてのコードを供給する。
【０２６９】
（４）スケーラブルなこと：プロトタイプは、ユーザーのニーズと必要条件を検証するプロセスの間に破棄される傾向にあるため、スケーラブルではない。最終アプリケーションは、プロトタイプよりはるかに長く持続するよう目指しているため、スケーラブルである。とはいえ、スケーラブルであるということは、デザインのフェーズの間にあるガイドラインに従わなければならないことを示唆する。本発明の実施例で、システムアナリストはスケーラブルであることに気を使う必要はない。これはこのような作業が、システムロジックトランスレーター２３２の責任に含まれているためである。したがって、アナリストは結果として生じるコードがスケーラブルであることを知り、分析事項に集中することができる。さらに、システムロジックトランスレーターによって変換された異なった概念モデルは、それらの明確なインターフェースを通して、お互いにインターアクトすることができる。
【０２７０】
本発明は、現時点で最も実用的で好ましい実施例と関連して説明されてきたが、本発明は発表された実施例に限定されるものではなく、逆に、当然のことながら、付属の請求項の精神と範囲内に含まれるさまざまな改良や等価の処置を含むように意図されていることは理解されるに及ぶものである。
【誤訳訂正２】
【訂正対象書類名】特許請求の範囲
【訂正対象項目名】全文
【訂正方法】変更
【訂正の内容】
【特許請求の範囲】
【請求項１】
コンピュータにおいて実行される方法であって、前記コンピュータはメインメモリー、ディスプレイ、そして入力デバイス、そしてカーソルコントロール装置およびコンピューター読取り可能インストラクションを記憶する記憶装置にバスによって結合されたプロセッサーを有し、前記方法は
プロセスを実行するために、前記記憶装置から前記コンピューターの前記メインメモリーへ、コンピュータエイデッドソフトウェアエンジニアリング（ＣＡＳＥ）ツールの前記コンピューター読取り可能インストラクションを実行させるために前記コンピュータの前記プロセッサーを使用することを含み、前記方法は、
デザイナーによってデザインされているソフトウェアアプリケーション（以下、「アプリケーション」）に関する要求を収集するために、前記コンピュータの前記ディスプレイに状態遷移及びオブジェクトダイアグラム、クラスダイアグラム、およびテキスト対話型ダイアログ（以下「ダイアグラムおよびテキスト対話型ダイアログ」）を表示し、そして前記アプリケーションの要求を入力するために前記入力デバイスおよび前記カーソルコントロール装置を介して前記ダイアグラムおよびテキスト対話型ダイアログと対話する前記アプリケーションのデザイナーからの入力データを受信し、前記入力データは前記アプリケーションの概念モデルを定義し、前記コンピュータにおいてクラスデータ構造で保存されており、前記概念モデルは、前記アプリケーションによって実行されるシステム内のオブジェクトのクラスを定義するオブジェクトモデル、動的なモデル、機能モデル、そして表示モデルを含み、これらは、共に、前記アプリケーションの要求を定義し、前記入力データは属性および引数を有するサービスを有するオブジェクトのクラスを定義する前記オブジェクトモデルを定義するために前記デザイナーによって入力されるものであり、
前記オブジェクトモデルを定義するために前記デザイナーによって入力された前記入力データが、属性を有するオブジェクトのクラスおよび引数を有するサービスを定義し、各サービスはイベントまたはトランザクションであり、各イベントは単一のサービスであり、そして各トランザクションはサービスのシーケンスであり、該シーケンスは前記コンピュータダイアグラムおよびテキスト対話型ダイアログを使用する前記アプリケーションのデザイナーにより入力される式により設定され、
前記オブジェクトモデルを定義するために前記デザイナーによって入力された前記入力データが、さらにサービスに関する前提条件、クラスに関する完全性制約、およびクラスに起因する各派生属性に関する派生を定義し、
前記派生が、前記派生属性の各々の値が、前記クラスの他の属性の値に基づき、どのように計算されるべきかについて指定し、
前記動的なモデルを定義するために前記デザイナーにより入力された前記入力データが、前記オブジェクトモデルにより定義された各オブジェクトに関する有効なオブジェクトライフサイクルを指定し、
前記機能モデルを定義するために前記デザイナーにより入力された前記入力データが、クラス、前記クラスの変数属性および前記クラスのイベントを選択し、そして、デザイナー選択イベントが生じた場合に、前記選択された変数属性についての評価の効果を指定することにより、前記クラスに関する状態の変化を指定し、
前記機能モデルを定義するために前記デザイナーにより入力された前記入力データが、前記選択されたイベントの発生が前記選択された変数属性の値をどのように変化させるかを定義する数学的式により前記評価を指定し、そして、評価条件が前記入力データにより指定された場合には、前記評価条件が満たされた場合のみ前記評価が実行され、
前記表示モデルを定義するために前記デザイナーにより入力される前記入力データが、前記オブジェクトモデルの要素と、前記アプリケーションの所望のユーザーインターフェースパターンとの間の関係を定義するパターン言語による、ユーザーインターフェースパターンを選択し、前記パターンは、前記アプリケーションと相互作用する前記アプリケーションによってコントロールされるコンピュータによって表示されるインターフェースメカニズムを定義するために、サービス表示パターン、導入パターン、定義選択パターン、母集団選択パターン、依存パターン、例表示パターン、クラス母集団表示パターン、マスター−詳細表示パターン、およびアクション選択パターンを含み、そして
前記概念モデルを定義するために前記メインメモリに入力された前記入力データを前記メインメモリに記憶するためにそして前記入力データとして導入されたそれぞれの要求データあるいは情報を、形式言語で書かれた形式仕様の一部として対応する形式対応相手に変換するために前記プロセッサーを使用し、前記形式仕様は、シンタックスとセマンティックスのルールを有する形式言語文法に従って構成される上記方法を実行し、
前記形式仕様が欠落している情報がないという点で完全であり、前記概念モデルを定義するためにデザイナーによって導入された前記情報がシンタックス的にもセマンティックス的にも一貫しているという点で正確であり、前記概念モデルにおいて定義されたすべての特性が有効な値を有するように曖昧ではないということを確実にするために、前記形式仕様を検証するため、シンタックスおよびセマンティックスの前記ルールを使用するように前記プロセッサをコントロールする、
動作を含む方法。
【請求項２】
前記概念モデルから情報を引き出し、変換構造と呼ばれるメモリー構造において前記情報を保存するように前記コンピューターをコントロールするインストラクションを実行するため前記プロセッサーを使用することと、それらのそれぞれは、ターゲットプログラミング言語でソースコードを生成するために前記保存された情報を使用する方法を有しており、そして、前記アプリケーションを実行するソースコードを生成するために前記変換構造において前記方法を実行することと、をさらに含む請求項１の方法。
【請求項３】
前記変換構造は、
サーバコンポーネントを生成するために必要とされた情報を保存するクラス（サーバクラス）と、
グローバルインタラクションのためのサーバコンポーネントを生成するために必要とされた情報を保存するクラス（グローバルインタラクションサーバクラス）と、
実行コンポーネントを生成するために必要とされた情報を保存するクラス（分析クラス）と、
グローバルインタラクションのための実行コンポーネントを生成するために必要とされた情報を保存するクラス（グローバルインタラクション分析クラス）と、
継承階層のための実行コンポーネントを生成するために必要とされた情報を保存するクラス（継承階層分析クラス）と、
質問コンポーネントを生成するために必要とされた情報を保存するクラス（質問クラス）と、
Ｔコンポーネントを生成するために必要とされた情報を保存するクラス（Ｔクラス）と、
Ｃコンポーネントを生成するために必要とされた情報を保存するクラス（Ｃクラス）と、
ＣＣコンポーネントを生成するために必要とされた情報を保存するクラス（ＣＣクラス）と、
Ｐコンポーネントを生成するために必要とされた情報を保存するクラス（Ｐクラス）と、
ＰＬコンポーネントを生成するために必要とされた情報を保存するクラス（ＰＬクラス）と、
前記概念モデルにおけるすべてのクラスのすべてのサービスについての引数上で情報を保存するクラス（引数リストクラス）と、
前記概念モデルにおけるすべてのクラスのアイデンティフィケーション機能上で情報を保存するクラス（分析クラスリストクラス）と、
実行コンポーネントにおいてのサービスを決定するために必要な方法を生成するクラス（イベントクラス、共有イベントクラス、トランザクションクラス、インタラクションクラス）と、
実行コンポーネントと継承階層のための実行コンポーネント両方におけるサービスを決定するのに必要な補助の方法を生成するクラス（前提条件クラス、静的制限クラス、動的な制限クラス、など）と、
質問とＴコンポーネントにおいて必要な方法を生成するクラス（Ｔ方法クラスとＱ方法クラス）と、
継承指定方法を生成するクラス（継承方法クラス）と、
そしてジェネレーションプロセスを監視するクラス（コードジェネレーションクラス）と、
を備えており、
なお、前記ソースコードを生成するため前記変換構造における前記方法の実行をコントロールし、前記生成されたコードをファイルに書き込み、そして前記ソースコードをファイルに整理するために、前記コードジェネレーションクラスは、前記アプリケーションを実行する前記ソースコードを生成するために必要なすべての情報を前記変換構造から引き出し、それを適切な順序で行う、
請求項２の方法。
【請求項４】
プッシュポップ評価、状態−独立評価、あるいは個別の領域による評価のいずれかとして各前記評価を定義するデータを入力することをデザイナーに可能にするダイアグラムおよびテキスト対話型ダイアログを前記ディスプレイに表示するためにコンピュータ可読インストラクションにより前記プロセッサーをコントロールすることをさらに含み、なお、プッシュポップ評価は、それらの関連するイベントが属性の値をある一定の量増加したり減少したりする、もしくは属性をある値に再設定するものであり、状態−独立評価は関与する属性に対し、以前の属性の値とは独立的に新しい値を与え、個別の領域評価は、属性の前回の値に基づき、限定された領域から、属性に対し一つの値を与える、請求項１の方法。
【請求項５】
前記プロセッサーが前記アプリケーションの前記概念モデルの一部として前記メモリーに記憶し、さらに前記オブジェクトモデルにおいて定義されたクラスを定義するデータをデザイナーが入力することを可能にするダイアグラムおよびテキスト対話型ダイアログを表示するためにコンピュータ可読インストラクションを使用して前記プロセッサーをコントロールすることをさらに含み
前記入力データは、各クラスに関し、属性、サービス、派生、制約、トリガー、トランザクション式、ディスプレイセット、フィルター、デフォルト母集団選択パターンおよび状態遷移ダイアグラムを定義する、
請求項１の方法。
【請求項６】
前記アプリケーションの前記概念モデルの一部として、前記プロセッサーが前記メモリーに記憶するデザイナーがデータを入力することを可能にするダイアグラムおよびテキスト対話型ダイアログを表示するためコンピュータ可読インストラクションを使用して前記プロセッサーをコントロールすること、をさらに含み、前記入力データは各クラスに関する状態遷移ダイアグラムの形式で各クラスにおけるオブジェクトの可能な状態遷移を定義する、請求項５の方法。
【請求項７】
毎回満たさなくてはならない式として完全性制約を定義する入力データをデザイナーが入力することを可能にするダイアグラムおよびテキスト対話型ダイアログを表示するためにコンピュータ可読インストラクションにより前記プロセッサーをコントロールすることをさらに含む、
請求項５の方法。
【請求項８】
有効なオブジェクトライフを定義する状態遷移ダイアグラムを有する前記動的なモデルを定義するデータをデザイナーが入力することを可能にするダイアグラムおよびテキスト対話型ダイアログと、前記デザイナーによる前もって指定された条件が満たされた時に自動的に作動するオブジェクトサービスであるトリガーと、異なったオブジェクトのサービスおよび／あるいはその他のグローバルトランザクションに関与するサービスであるグローバルトランザクションと、を介したインターオブジェクト通信を定義するオブジェクトインタラクションダイアグラムと、を表示するためにコンピュータ可読インストラクションにより前記プロセッサーをコントロールすることをさらに含む、
請求項５の方法。
【請求項９】
前記トリガーを定義するデータを入力することをデザイナーに可能にするダイアグラムおよびテキスト対話型ダイアログを表示するためにコンピュータ可読インストラクションにより前記プロセッサーをコントロールすることをさらに含み、各トリガーは、自分自身により指定されるトリガーターゲット、クラスまたはオブジェクト、トリガー条件、可能なエージェントのリストを加えたサービスであるトリガードアクション、トリガー条件が保たれる場合には起動されるトリガードアクション、および前記関連するサービスの前記引数と関連するデフォルト値のリストから構成される、
請求項５の方法。
【請求項１０】
自動ソフトウェア生成装置であって、
ディスプレイ、入力デバイス、カーソルコントロールデバイス、メインメモリーおよび記憶装置とバスにより結合されたプロセッサーを有するコンピューターを含み、
コンピュータエイデッドシステムエンジニアリングコンピュータプログラムが前記記憶装置に記憶され、そして、コンピュータ可読インストラクションを実行するために前記プロセッサーをコントロールするコンピュータ可読インストラクションを含み、前記コンピュータ可読インストラクションは、最終的なソフトウェアアプリケーション（以下、「アプリケーションプログラム」）のデザイナーが前記アプリケーションプログラムに関する要求データを入力するために前記入力デバイスおよび前記カーソルコントロールデバイスを使用して対話可能とするように状態遷移およびオブジェクトインタラクションダイアグラム、クラスダイアグラム、およびテキスト対話型ダイアログボックス（以下、「ダイアグラムおよびテキスト対話型ダイアログボックス」）を表示するために前記プロセッサーをコントロールするために構成され、前記要求データは、前記アプリケーションプログラムの概念モデルを生成し、前記コンピュータにおいてクラスデータ構造で保存されており、前記概念モデルはオブジェクトモデル、動的なモデル、機能モデルおよび表示モデルを含み、前記オブジェクトモデルは前記アプリケーションプログラムにおいて使用されるオブジェクトのクラスのモデルであり、そして、前記オブジェクトの各クラスに関する１つまたはより多くの固定されたおよび／または変化可能な属性を定義し、ダイアグラムおよびテキスト対話型ダイアログは、クラスに関するサービスおよび各サービスに関する引数のリストについて定義する要求データを入力するため前記入力デバイスおよび前記カーソルコントロールデバイス使用する前記デザイナーとそこで対話する機会を提供し、各サービスはイベントまたはトランザクションであり、各サービスは単一のサービスでありそして各トランザクションは要求データとして前記デザイナーにより入力される式として定義され、前記式は前記トランザクションを定義するサービスの構成を示し、前記ダイアグラムおよびテキスト対話型ダイアログは前記デザイナーが前記入力デバイスおよび前記カーソルコントロールデバイスを介してそこで対話し、少なくともいくつかの前記クラス、前記クラスによって認められるイベント、および前記クラスによって認められる変数属性、および望む場合には前記クラスによって認められる評価条件に関し定義する要求データを入力することをさらに可能にし、前記評価条件の状態は評価がさらに実行される前記要求データによって指定されるか否かをコントロールし、そしてここで、前記ダイアグラムは、前記オブジェクトモデルにおいて定義される全てのクラスに関する有効なオブジェクトライフサイクルを指定することにより、これらのそれぞれが状態の有効な変化を表す遷移を指定することにより、サービス、トリガーおよびグローバルトランザクションに対応するオブジェクトの行動を指定する前記動的なモデルを定義するために、前記入力デバイスおよび前記カーソルコントロールデバイスを使用して要求データを入力することにより前記デザイナーによって構成される状態遷移ダイアグラムおよびオブジェクトインタラクションダイアグラムを含み、前記オブジェクトインタラクションダイアグラムはトリガーおよびグローバルトランザクションに応答してオブジェクト間のインター−オブジェクト通信を指定し、そしてイベント発生の結果として、前記ダイアグラムおよびテキスト対話型ダイアログは前記デザイナーが前記概念モデルにおいて定義されたオブジェクトの状態の全ての変化を定義することにより前記機能モデルを定義する要求データを入力するために前記カーソルコントロールデバイスを使用してそれと対話する機会を提供し、前記ダイアグラムおよびテキスト対話型ダイアログは、前記デザイナーがクラスを選択する要求データを入力することを可能にし、前記クラスの変数属性を選択し、前記クラスのイベントを選択し、そしてイベントの発生がどのように前記式において指定される前記変数属性の値に影響するかを定義する数学的式を指定することにより前記クラスに関する状態の変化を指定し、前記ダイアグラムおよびテキスト対話型ダイアログは、前記デザイナーに関しさらに前記評価条件が満される場合のみ前記評価が実行されるように、評価条件を指定する機会を提供し、そして前記ダイアグラムおよびテキスト対話型ダイアログは、前記デザイナーに関し、ユーザインターフェースの必要条件を反映するためにデザインされたパターンを集めたものを選択することにより前記表示モデルを定義することにより前記アプリケーションプログラムのユーザインターフェースを定義する要求データを入力する機会を提供し、各前記パターンは前記アプリケーションプログラムに関し実行し得る異なるタイプのユーザインターフェースを表わし、前記基本パターンは、
サービス表示パターン、
導入パターン、
定義選択パターン、
母集団選択パターン、
依存パターン、
ステータス回復パターン、
補助情報パターン、
引数分類表示パターン、
インスタンス表示パターン、
クラス母集団表示パターン、
マスター−詳細表示パターン、
アクション選択パターン、
フィルタ表現、
ディスプレイセット、そして
オーダー基準
を含み
前記プロセッサーによって実行されるコンピュータエイデッドシステムエンジニアリングコンピュータプログラムの前記コンピュータ可読インストラクションは、前記概念モデルを形式言語概念として表される対応する形式対応相手へと定義する前記デザイナーによって入力された前記要求データの各部分を変換することによって前記概念モデルを定義する前記要求データをオブジェクト指向形式仕様に自動的に変換するために前記プロセッサーをコントロールするために構成され、それによって前記形式仕様がシンタックスとセマンティックスのルールを有するオブジェクト指向形式言語で書かれようにし、これらは前記形式仕様が明確であり、正確であり、そして完全であることを確実にするために、前記形式仕様を含む前記形式言語におけるステートメントがシンタックスとセマンティックスの前記ルールを使用して検証され得るようにし、
前記プロセッサによって実行された前記コンピュータエイデッドソフトウェアエンジニアリングコンピュータプログラムの前記コンピュータ読み取り可能インストラクションは、前記形式仕様が欠落している情報がないという点で完全であり、前記概念モデルを定義するためにデザイナーによって導入された前記情報がシンタックス的にもセマンティクス的にも一貫しているという点で正確であり、前記概念モデルにおいて定義されたすべてのプロパティが有効な値を有するように曖昧ではないということを確実にするために、前記形式仕様を検証するため、シンタックスおよびセマンティクスの前記ルールを使用するように前記プロセッサをコントロールするために構成されている、
装置。
【請求項１１】
前記コンピュータエイデッドシステムエンジニアリングコンピュータプログラムは、それら自身の識別および確証によりログインするために前記アプリケーションプログラムのユーザに要求するコンピュータプログラムコードを書き込むことにより実行モデルに続くことにより、前記アプリケーションプログラムの作業用のコンピューターコードに前記形式仕様を自動的に変換し、
ログインしたユーザが見ることのできる全ての属性およびログインしたユーザが開始することができる全てのサービスを決定するために前記形式仕様におけるデータを質問し、
ログインしたユーザが呼び出すことのできる全てのサービスに関するオブジェクトサーバーを識別するコンピュータプログラムコードを書きこみ、
ログインするユーザにより呼び出された何れかのサービスに関するサービス引数に関するデータを検索するコンピュータプログラムコードを書き込み、
前記サービスを呼び出しそして前記サービスに前記サービス引数を送り、
全てのサービスに関しオブジェクトサーバーを実行するコンピュータプログラムコードを書きこみ、
前記オブジェクトサーバーの各々は、前記サービスを実行しそして前記サービスが作用するオブジェクトの状態を変更する前に、状態遷移が有効であることを確認する最初のチェックをし、前提条件が満されていることを確かめ、全ての評価計算を行い、前記サービスの実行の後で完全性制約が満されていることを確かめ、前記サービスの実行によって満されたトリガー条件に対して試験し、そしてトリガー条件が満されている場合に前記形式仕様における前記トリガーによって指定されたアクションを実行するように構成される、
ように前記プロセッサーをコントロールするように構成されたコンピュータ可読インストラクションさらに含む、
請求項１０の装置。
【請求項１２】
ディスプレイ、入力デバイス、カーソルコントロールデバイス、および記憶装置とバスにより結合されたプロセッサーを有するコンピューターにおいて実行される方法であって、前記プロセッサーは前記コンピューターをコントロールするコンピュータ可読インストラクションを用いて以下のプロセスを実行するためにプログラムされ、
アプリケーショプログラムの概念モデルの一部であるオブジェクトモデルの一部としてクラスを定義する要求データを入力するために自動的に書き込まれる最終的なソフトウェアアプリケーション（以下、「アプリケーションプログラム」）のデザイナーが、前記入力デバイスおよび前記カーソルコントロールデバイスを使用して対話することのできる状態遷移およびオブジェクトインタラクションダイアグラム、クラスダイアグラム、およびテキスト対話型ダイアログ、（以下、「ダイアグラムおよびテキスト対話型ダイアログ」）を前記ディスプレイに表示し、前記要求データは前記コンピュータにおいてクラスデータ構造で保存されており、前記要求データはさらに前記クラスに関するサービスおよび前記サービスに関する引数をさらに定義し、各前記サービスはイベントあるいはトランザクションであり、各トランザクションは複数のサービスの実行から成り、前記要求データはさらに前記クラスにより有されるイベントを定義し、変数属性は前記クラスにより有され、オプションの評価条件は前記クラスにより有され、前記評価条件の状態は前記要求データデータによってさらに指定される評価が実行されるか否かをコントロールし、前記要求データによって指定される前記評価はさらに前記クラスによって有され、前記ダイアグラムおよびテキスト対話型ダイアログは前記デザイナーが要求データを前記評価を定義する式の形式で入力することをさらに可能とし、前記式はクラスを選択し、前記評価条件が指定されそして前記クラスが前記アプリケーションプログラムの構造および動作を定義する概念モデルの一部であることを満たす場合、前記選択されたイベントが発生すると、前記クラスの変数属性および前記クラスのイベントが前記選択されたクラスに関する状態変更を定義し、
シンタックスのルールおよびセマンティクスのルールを有する形式言語で書かれた形式仕様を生じさせる形式言語概念として表される対応する形式対応相手に、前記概念モデルを定義する前記デザイナーによって入力された各要求データを変換することによって、形式仕様に変換するように前記コンピューターをコントロールし、そして
前記形式仕様が欠落している情報がないという点で完全であり、前記概念モデルを定義するためにデザイナーによって導入された前記情報がシンタックス的にもセマンティクス的にも一貫しているという点で正確であり、前記概念モデルにおいて定義されたすべてのプロパティが有効な値を有するように曖昧ではないということを確実にするために、前記形式仕様を検証するため、シンタックスおよびセマンティクスの前記ルールを使用するように前記プロセッサをコントロールする、
を含む方法。
【請求項１３】
前記コンピュータは、それが、プッシュポップカテゴリー、または状態−独立カテゴリー、または個別の領域カテゴリーの状態になるようにし、前記プッシュポップカテゴリー評価は評価であり、ここで前記イベントは、前記要求によって指定される確実な値に関し前記評価により影響を受けるように、前記要求データによって指定される前記変数属性の値の再設定の結果として、所定の数量または前記プッシュポップカテゴリーの評価により前記要求データによって指定される前記変数属性の値を増加させまたは減少させる数学的式として実行される前記評価の計算をトリガーする前記要求データによって指定され、
前記状態−独立評価カテゴリーは、その数学的式が、前記評価の数学的式の評価をトリガーする前記イベントが生じた時に前記変数属性が有する値に関係なく前記要求データにより指定される変数属性に新しい値を提供するものであり、
そしてここで、評価の前記ディスクリート領域カテゴリーはその数学的式が前記変数属性の現在の値に従い前記評価により影響を受ける前記要求データによって指定される変数属性に関し新しい値を提供するものであるように、
前記デザイナーが、前記入力デバイスおよび前記カーソルコントロールデバイスを使用して、前記評価を定義する要求データを入力するためにこれらと対話することを可能にするダイアグラムおよびテキスト対話型ダイアログを表示するためにコントロールされる、
請求項１２の方法。
【請求項１４】
各前記トランザクションに関する式を定義する要求データを入力するために、デザイナーが前記入力デバイスおよび前記カーソルコントロールデバイスを使用してこれらと対話することを可能にするダイアグラムおよびテキスト対話型ダイアログを表示するように、前記コンピューターがコントロールされ、前記式は、前記トランザクションを構築するサービスの構成を定義し、各前記トランザクショは２つの特性を有し、前記２つの特性は、第１に、各前記トランザクショはトランザクションの実行中に失敗が発生した場合を意味する複雑なイベントの実行に関して、前記失敗の時間までに為された全ての状態の変化を逆転することにより前記トランザクションの実行が開始された時にそれが有する状態に戻され、そして第２に、前記トランザクションの実行中に成された中間状態は観察できない、
請求項１３の方法。
【請求項１５】
前記概念モデルの一部として、前記アプリケーションプログラムが有するユーザインターフェースを定義するユーザインターフェースパターンから成る動的なモデル、機能モデルおよび表示モデルを定義する要求データを入力するために、デザイナーが前記入力デバイスおよび前記カーソルコントロールデバイスを使用してこれらと対話することを可能にするダイアグラムおよびテキスト対話型ダイアログを表示するように、前記コンピューターがコントロールされ、ここで前記ダイアグラムおよびテキスト対話型ダイアログはさらに前記デザイナーが前記入力デバイスおよび前記カーソルコントロールを使用して、派生、制約、集合及び継承階層、前提条件、完全性制約、有効なオブジェクトライフ、サーバクラスに対するエージェント関係、およびトリガー関係、およびグローバルトランザクション、を定義するためにこれらと対話することを可能にする、
請求項１４の方法。
【請求項１６】
検証の前記ステップが、実在しなければならずそして生成時に有効な値を有する前記要素の全ての性質を正確に意味する前記形式仕様のいくつかの要素を検証し、そして後の時点で要素の正確な検証を生ずることができ、そして生成時には要素の正確な検証が行なわれる必要がない点で、他の要素が柔軟に検証される、
請求項１５の方法。