(57)【要約】【課題】自動ソフトウェア作成システム【解決手段】システムの要求を捉え、その要求を公式仕様へと変換し、その正しさと完全性についてヴァリデートする、自動ソフトウエア作成システムを提供する。加えて、ヴァリデートした公式仕様に基づいて、ユーサーインターフェースコードとエラー処理コードを含む、完全でロバストなソフトウエアアプリケーションをジェネレートするためのトランスレーターを提供する。【選択図】図１
2004506962.tif 000002
【特許請求の範囲】
【請求項１】
自動ソフトウェア作成ツールであって、
完全なソフトウェアアプリケーションとなる条件を指定する概念モデルの公式仕様を保存するコンピュータ可読媒体で、その概念モデルがソフトウェアアプリケーションへのユーザーインターフェースのパターンを指定する表示モデルを含む、コンピュータ可読媒体と、
公式仕様をヴァリデートするヴァリデーターと、
そのヴァリデートされた公式仕様をもとに、完全なソフトウェアアプリケーションをジェネレートするトランスレーターで、その完全なソフトウェアアプリケーションが表示モデルで指定されたパターンに基づいたユーザーインターフェースの取り扱いのインストラクションを含むトランスレーターと、から成ることを特徴とする自動ソフトウェア作成ツール。
【請求項２】
ユーザーがソフトウェアアプリケーションの明確な公式条件を入力できるグラフィックなユーザーインターフェースを表示し、そのソフトウェアアプリケーションへの公式条件の入力に基づいた公式仕様をジェネレートするためのＣＡＳＥツールからさらに成ることを特徴とする、請求項１に記載のツール。
【請求項３】
そのＣＡＳＥツールがさらに、一つのイベントがどのように一つのオブジェクトの状態を変えるかを示すヴァリュエーションを指定するユーザー入力を受諾するよう設定されていることを特徴とする、請求項２に記載のツール。
【請求項４】
そのヴァリュエーションが実質的にプッシュポップ、ステートインディペンデント、およびディスクリートドメインから成る一つのセットから選ばれることを特徴とする、請求項３に記載のツール。
【請求項５】
公式仕様がロバストなソフトウェアアプリケーションの条件を含み、
トランスレーターがエラーの検査とエラーの処理についてのインストラクションをジェネレートするよう設定されている
ことを特徴とする、請求項１に記載のツール。
【請求項６】
トランスレーションが公式仕様に基づいて、内部エラーの検査と内部エラーの処理についてのインストラクションをジェネレートするよう設定されていることを特徴とする、請求項５に記載のツール。
【請求項７】
トランスレーションが外部エラーの検査と外部エラーの処理についてのインストラクションをジェネレートするように設定されていることを特徴とする、請求項５に記載のツール。
【請求項８】
公式仕様に基づいたソフトウェアアプリケーションのドキュメンテーションをジェネレートするドキュメンテーションジェネレーターからさらに成ることを特徴とする、請求項１に記載のツール。
【請求項９】
自動ソフトウェア作成ツールであって、
ユーザーがソフトウェアアプリケーションの明確な公式条件を入力できるようグラフィックなユーザーインターフェースを表示し、そのアプリケーションソフトウェアの公式条件の入力に基づいてそのアプリケーションソフトウェアの公式仕様をジェネレートするＣＡＳＥツールと、
その公式仕様をヴァリデートするヴァリデーターと、
そのヴァリデートされた公式仕様に基づいてソフトウェアアプリケーションをジェネレートするトランスレーターと、
から成ることを特徴とする自動ソフトウェア作成ツール。
【請求項１０】
その明確な公式条件がソフトウェアアプリケーションのソフトウェアのユーザーに表示されるアプリケーションユーザーインターフェースのパターンを含み、
そのジェネレートされたソフトウェアアプリケーションが表示モデルで指定されたパターンに基づいた、ユーザーインターフェースの取り扱いについてのインストラクションを含む
ことを特徴とする、請求項９に記載のツール。
【請求項１１】
明確な公式条件がロバストなソフトウェアアプリケーションの条件を含み、
そのジェネレートされたソフトウェアアプリケーションがエラーの検査とエラーの処理についてのインストラクションを含む
ことを特徴とする、請求項９に記載のツール。
【請求項１２】
ＣＡＳＥツールがさらに、一つのイベントがどのように一つのオブジェクトの状態を変えるかを示すヴァリュエーションを指定するユーザー入力を受諾するよう、設定されていることを特徴とする、請求項９に記載のツール。
【請求項１３】
そのヴァリュエーションが、プッシュポップ、ステートインディペンデント、およびディスクリートドメインから実質的に成る一つのセットから選択されていることを特徴とする、請求項１２に記載のツール。
【請求項１４】
自動ソフトウェア作成ツールであって、
ロバストなソフトウェアアプリケーションの条件を指定する概念モデルの公式仕様を保存するためのコンピュータ可読媒体と、
その概念モデルが正しく、完全で、そして明確であることを決定する公式仕様をヴァリデートするヴァリデーターと、
そのヴァリデートされた公式仕様に基づいて、ロバストなソフトウェアアプリケーションをジェネレートするトランスレーターで、そのロバストなソフトウェアアプリケーションがエラーの検査とエラーの処理についてのインストラクションを含む、トランスレーターと、
から成ることを特徴とする自動ソフトウェア作成ツール。
【請求項１５】
ユーザーがソフトウェアアプリケーションの明確な公式条件を入力できるようにグラフィックなユーザーインターフェースを表示し、そのソフトウェアアプリケーションの公式条件の入力に基づいて公式仕様をジェネレートするためのＣＡＳＥツールからさらに成ることを特徴とする、請求項１４に記載のツール。
【請求項１６】
そのＣＡＳＥツールがさらに、一つのイベントがどのように一つのオブジェクトの状態を変えるかを示すヴァリュエーションを指定するユーザー入力を受諾するよう設定されていることを特徴とする、請求項１５に記載のツール。
【請求項１７】
そのヴァリュエーションが、実質的にプッシュポップ、ステートインディペンデント、およびディスクリートドメインから成る一つのセットから選ばれていることを特徴とする、請求項１６に記載のツール。
【請求項１８】
自動的にソフトウェアアプリケーションをジェネレートする方法であって、
ソフトウェアアプリケーションのユーザーインターフェースのパターンを指定する表示モデルを含む概念モデルであり、ソフトウェアアプリケーションの条件を指定する概念モデルの公式仕様にアクセスすること、
その公式仕様をヴァリデートすること、および
その表示モデルで指定されたパターンに基づいてそのユーザーインターフェースの処理をするためのインストラクションを含むソフトウェアアプリケーションを、そのヴァリデートされた公式仕様に基づいてジェネレートすること、
から成ることを特徴とする、自動的にソフトウェアアプリケーションをジェネレートする方法。
【請求項１９】
明確な公式条件がロバストなソフトウェアアプリケーションの条件を含み、
そのジェネレートされたソフトウェアアプリケーションがエラーの検査とエラーの処理についてのインストラクションを含む
ことを特徴とする、請求項１８に記載の方法。
【請求項２０】
公式仕様に基づきソフトウェアアプリケーションのドキュメンテーションを作成することからさらに成ることを特徴とする、請求項１８に記載の方法。
【請求項２１】
どのように一つのイベントが一つのオブジェクトの状態を変えるかを示すヴァリュエーションを指定するユーザー入力を受諾することからさらに成ることを特徴とする、請求項１８に記載の方法。
【請求項２２】
そのヴァリュエーションがプッシュポップ、ステートインディペンデント、およびディスクリートドメインから実質的に成る一つのセットから選択されることを特徴とする、請求項２１に記載の方法。
【請求項２３】
自動的にソフトウェアアプリケーションをジェネレートする方法であって、
ユーザーがソフトウェアアプリケーションの明確な公式条件を入力できるよう、グラフィックなユーザーインターフェースを掲示すること、
そのソフトウェアアプリケーションの公式条件入力に基づき、ソフトウェアアプリケーションの公式仕様をジェネレートすること、
その公式仕様をヴァリデートすること、および
そのヴァリデートされた公式仕様に基づき、ソフトウェアアプリケーションをジェネレートすること、
から成ることを特徴とする、自動的にソフトウェアアプリケーションをジェネレートする方法。
【請求項２４】
その明確な公式条件がそのソフトウェアアプリケーションのソフトウェアのユーザーに表示されるためのアプリケーションユーザーインターフェースのためのパターンを含み、および
そのジェネレートされたソフトウェアアプリケーションが、表示モデルの中で指定されたパターンに基づくユーザーインターフェースの取り扱いについてのインストラクションを含む、
ことを特徴とする、請求項２３に記載の方法。
【請求項２５】
その明確な公式条件がロバストなソフトウェアアプリケーションの条件を含み、また
そのジェネレートされたソフトウェアアプリケーションがエラーの検査とエラーの処理についてのインストラクションを含む
ことを特徴とする、請求項２３に記載の方法。
【請求項２６】
公式仕様に基づき、内部エラーの検査と内部エラーの処理についてのインストラクションをジェネレートすることより成ることを特徴とする、請求項２５に記載の方法。
【請求項２７】
外部エラーの検査と外部エラーの処理に関するインストラクションをジェネレートすることより成ることを特徴とする、請求項２５に記載の方法。
【請求項２８】
一つのイベントがどのように一つのオブジェクトの状態を変えるかを示すヴァリュエーションを指定するユーザー入力を受諾することよりさらに成ることを特徴とする、請求項２３に記載の方法。
【請求項２９】
そのヴァリュエーションがプッシュポップ、ステートインディペンデント、およびディスクリートドメインより実質的に成る一つのセットから選択されていることを特徴とする、請求項２８に記載の方法。
【請求項３０】
自動的にロバストなソフトウェアアプリーションをジェネレートする方法であって、
ロバストなソフトウェアアプリケーションの条件を指定する概念モデルの公式仕様にアクセスし、
その概念モデルが正しく、完全で、明確であることを決定する公式仕様をヴァリデートし、および、
エラーの検査とエラーの処理に関するインストラクションを含むロバストなソフトウェアアプリケーションを、そのヴァリデートされた公式仕様に基づきジェネレートする
ことを特徴とする自動的にロバストなソフトウェアアプリケーションをジェネレートする方法。
【請求項３１】
一つのイベントがどのように一つのオブジェクトの状態を変えるかを示すヴァリュエーションを指定するユーザー入力を受諾することよりさらに成ることを特徴とする、請求項３０に記載の方法。
【請求項３２】
そのヴァリュエーションがプッシュポップ、ステートインディペンデント、およびディスクリートドメインから実質的に成る一つのセットより選択されていることを特徴とする、請求項３１に記載の方法。
【請求項３３】
自動的にソフトウェアアプリケーションをジェネレートするためのインストラクションを有するコンピュータ可読媒体であって、前記インストラクションが実行されることによって、一つまたはそれ以上のプロセッサーが、
ソフトウェアアプリケーションの条件を指定する概念モデルで、ソフトウェアアプリケーションのユーザーインターフェースのパターンを指定する表示モデルを含む概念モデルの公式仕様にアクセスするステップと、
その公式仕様をヴァリデートするステップと、
表示モデルで指定されたパターンに基づいたユーザインターフェースの取り扱いインストラクションを含むソフトウェアアプリケーションを、そのヴァリデートされた公式仕様に基づいてジェネレートするするステップと
を実施するように、前記インストラクションが設定されていることを特徴とするコンピュータ可読媒体。
【請求項３４】
明確な公式条件がロバストなソフトウェアアプリケーションの条件を含み、および、
ジェネレートされたソフトウェアアプリケーションがエラーの検査とエラーの処理に関するインストラクションを含む
ことを特徴とする、請求項３３に記載のコンピュータ可読媒体。
【請求項３５】
公式条件に基づいてソフトウェアアプリケーションのドキュメンテーションを作成するためのインストラクションをさらに有することを特徴とする、請求項３３に記載のコンピュータ可読媒体。
【請求項３６】
一つのイベントがどのように一つのオブジェクトの状態を変えるかを示すヴァリュエーションを指定するユーザー入力を受諾することからさらに成ることを特徴とする、請求項３３に記載のコンピュータ可読媒体。
【請求項３７】
そのヴァリュエーションがプッシュポップ、ステートインディペンデント、およびディスクリートドメインより実質的に成る一つのセットより選択されていることを特徴とする、請求項３６に記載のコンピュータ可読媒体。
【請求項３８】
自動的にソフトウェアアプリケーションをジェネレートするためのインストラクションを有するコンピュータ可読媒体であって、前記インストラクションが実行されることによって、一つまたはそれ以上のプロセッサーが、
ユーザーがソフトウェアアプリケーションのための明確な公式条件を入力できるようグラフィックなユーザーインターフェースを表示するステップと、
ソフトウェアアプリケーションのための公式条件の入力に基づいて、ソフトウェアアプリケーションの公式仕様をジェネレートするステップと、
その公式仕様をヴァリデートするステップと、
そのヴァリデートされた公式仕様に基づいてソフトウェアアプリケーションをジェネレートするするステップと
を実施するように、前記インストラクションが設定されていることを特徴とするコンピュータ可読媒体。
【請求項３９】
明確な公式条件が、ソフトウェアアプリケーションのソフトウェアのユーザーに表示されるアプリケーションユーザーインターフェースのパターンを含み、および、
ジェネレートされたソフトウェアアプリケーションが、表示モデルで指定されたパターンに基づくユーザーインターフェースを取り扱うためのインストラクションを含む
ことを特徴とする、請求項３８に記載のコンピュータ可読媒体。
【請求項４０】
明確な公式条件がロバストなソフトウェアアプリケーションの条件を含み、
ジェネレートされたソフトウェアアプリケーションがエラーの検査とエラーの処理に関するインストラクションを含む
ことを特徴とする、請求項３８に記載のコンピュータ可読媒体。
【請求項４１】
公式仕様に基づいて内部エラーの検査と内部エラーの処理をするためのインストラクションをジェネレートするインストラクションをさらに有することを特徴とする、請求項４０に記載のコンピュータ可読媒体。
【請求項４２】
外部エラーの検査と外部エラーの処理に関するインストラクションをジェネレートするインストラクションをさらに有することを特徴とする、請求項４０に記載のコンピュータ可読媒体。
【請求項４３】
一つのイベントがどのように一つのオブジェクトの状態を変えるかを示すヴァリュエーションを指定するユーザー入力を受諾することよりさらに成ることを特徴とする、請求項３８に記載のコンピュータ可読媒体。
【請求項４４】
ヴァリュエーションがプッシュポップ、ステートインディペンデント、およびディスクリートドメインより実質的に成る一つのセットから選択されていることを特徴とする、請求項４３に記載のコンピュータ可読媒体。
【請求項４５】
自動的にロバストなソフトウェアアプリケーションをジェネレートするためのインストラクションを有するコンピュータ可読媒体であって、前記インストラクションが実行されることによって、一つまたはそれ以上のプロセッサーが、
ロバストなソフトウェアアプリケーションの条件を指定する概念モデルの公式仕様にアクセスするステップと、
そのモデルが正しく、完全で、明確であることを決定する公式仕様をヴァリデートするステップと、
エラーの検査とエラーの処理に関するインストラクションを含むロバストなソフトウェアアプリケーションを、そのヴァリデートされた公式仕様に基づいてジェネレートするするステップと
を実施するように、前記インストラクションが設定されてることを特徴とするコンピュータ可読媒体。
【請求項４６】
一つのイベントがどのように一つのオブジェクトの状態を変えるかを示すヴァリュエーションを指定するユーザー入力を受諾することよりさらに成ることを特徴とする、請求項４５に記載のコンピュータ可読媒体。
【請求項４７】
ヴァリュエーションがプッシュポップ、ステートインディペンデント、およびディスクリートドメインより実質的に成る一つのセットより選択されていることを特徴とする、請求項４６に記載のコンピュータ可読媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本願発明は、コンピュータシステムに関わり、特に、自動ソフトウェア作成システムとスタンドアロンのシステムやインターネット上のシステムに適した方法論に関わる。
【０００２】
【従来の技術】
ソフトウェアエンジニアリングとはコンピュータプログラム、アプリケーション、およびその他のソフトウェアシステムの開発とメインテナンスのために、系統的で統制の取れたアプローチを適用することである。世界経済のコンピュータ化の増加にともない、効率的なソフトウェアエンジニアリングの方法論の必要性は、かつてないほど重要になっている。
【０００３】
従来のソフトウェア開発プロセスは多数のフェーズを必要とする。まず、プログラムの条件を、顧客の要求に基づき、通常は書面の仕様書というかたちで指定する。次に、ソフトウェア開発者が、たとえば、データ構造をデザインし、システムロジックをコード化することにより、その条件を満たすためのソースコードを書く。最後に、ソフトウェア開発者は、条件中のエラーやあいまいな点を探し、ソフトウェアコード中のエラーを修理する徹底的なテストとデバッグのフェーズを実施する。起こり得るもっとも深刻な問題の一つは、システム条件を変更しなければならなくなることである。どのような条件の変更でも、ソースコードの再開発が必要であり、すべてのプロセスをもう一度最初からやり直さねばならないからである。したがって、テストとデバッグのフェーズは、ソフトウェアエンジニアリングのプロセスの中で最も長いフェーズであり、完成に要する時間の見積もりが最も難しいフェーズである。
【０００４】
この４０年の間、ソフトウェアエンジニアリングのプロセスの個別の部分を改良する多くの試みがなされてきた。たとえば、ＦＯＲＴＲＡＮ等の最初の高級言語、そしてＡＬＧＯＬ等の構造化されたプログラミング言語の誕生は、システムロジックの構築の負担を軽いものとした。もう一つの例としては、オブジェクト志向の方法論の導入はデータ構造のデザインや実施に役立った。これらの、ソフトウェアエンジニアリングのプロセスにおける改善は、問題の場であるアプリケーションの概念モデルと、解決の場である実際のソフトウェアコードとの間の不適合を減少させた。しかしながら、問題の場と解決の場の不適合はまだいくらかあるため、プログラミングエラーを起こしかねない。そのため、ソフトウェアの欠点を見分け修正する、徹底的なテストとデバッグのフェーズを行う必要がある。
【０００５】
最近、「必要条件分析」と、必要条件の確認と必要条件の明示の段階であるソフトウェアエンジニアリングのプロセスの第一フェーズを容易にするコンピュータエイデッドソフトウェアエンジニアリング（ＣＡＳＥ）の使用に関心が持たれている。特に、これらの方法はソフトウェア技術者が公式に必要条件を指定し、その条件をヴァリデートしテストするためのプロトタイプを作ることができるようにする。必要条件がテストされた後、そのプロトタイプは破棄され、ソフトウェア技術者はその必要条件に基づき、完全なソフトウェアアプリケーションを開発する。
【０００６】
一例として知られているのが「ＯＭＴＲＯＬＬ」で、その目的は、オブジェクトモデリングテクニック（ＯＭＴ）に準拠したグラフィック表記法を使って、ソフトウェアデザイナーがシステムの公式仕様をジェネレートするのを支援することである。この仕様はＴＲＯＬＬ仕様言語に基づき、完全なシステム仕様へと改良されなければならない。また、ＯＭＴＲＯＬＬは、グラフィックな概念仕様から独立的に実行可能なプロトタイプをジェネレートすることにより、プロトタイプ作成機能を供給するＴｒｏｌｌＷｏｒｋｂｅｎｃｈと呼ばれるＣＡＳＥサポートを有する。そのジェネレートされたプロトタイプはシステムのスタチック／ダイナミック面を含むＣ＋＋プログラムであり、仕様のリポジトリーとしてＩｎｇｒｅｓｓデータベースを利用する。
【０００７】
ＯＢＬＯＧは、もう一つのオブジェクト志向のソフトウェア開発へのアプローチであり、ヨーロッパのＥＳＰＲＩＴプロジェクトであるＩＳ―ＣＯＲＥ（情報システム−正確さと再利用性）の範囲に当てはまる。ＯＢＬＯＧのセマンティックスはカテゴリーの理論に照らして形式化されている。また、ＯＢＬＯＧは仕様の導入にＣＡＳＥツールを利用し、仕様をプロトタイプ用のコードに書き換えるための再書き込み規則を供給することにより、開発者がプロトタイプを作り上げることを可能にする。その再書き込み規則は、ＯＢＬＯＧによって定められた指定の言語によって書かれてなくてはならない。
【０００８】
形式化のレベルに、より焦点を合わせたもうひとつのアプローチとしては、オブジェクトシステム分析モデル（ＯＳＡ）がある。ＯＳＡの目的は、システムデザイナーが、非公式なものから数学的に厳格なものに亘るまで、違ったレベルの形式化で取り組めるようにする方法を開発することである。この意味において、このような調整可能な形式化は、理論研究者と実施者の両方が同じモデルに取り組めるようにし、モデルと言語の同等化において遭遇する困難を、ある特定の言語のためのＯＳＡに照らして克服することができる。ＯＳＡもまた、ＯＳＡモデルから必要条件をヴァリデートするためのプロトタイプをジェネレートすることができるＩＰＯＳＴと呼ばれるＣＡＳＥサポートツールを有する。
【０００９】
ＳＯＦＬ（体系的オブジェクトに基づいた公式言語）はまた違ったアプローチを提案し、その目的は、公式方法の統一と、体系的な分析と仕様、そしてオブジェクトに基 づいた方法を使用して、公式方法を、確立されている産業ソフトウェアのプロセスへと統一することを検討することである。ＳＯＦＬは、体系的な様式の必要条件の仕様から、オブジェクトに基づいた様式のデザインへの変換を容易にし、またデザインから適切な様式のプログラムへの変換を容易にする。先の論点のとおり、ＳＯＦＬの提案は、たとえばＶＤＭ（ウイーン開発法）様式のセマンティックス等のような公式方法を、その仕様モジュールに用いて、オブジェクト志向の方法論と体系的技術を結ぶリンクを探し出すことにより、公式方法が産業において広く使用されていないという事実を克服することを試みるものである。しかし、体系的技術とオブジェクト志向の技術を一つの方法に組み合わせることは、その方法のセマンティックスを明確にすることを困難にする。したがって、一貫性の確認には、効果的なツールのサポートが必要である。
【００１０】
さらに別のアプローチとして、ＴＲＡＤＥ（必要条件とデザインエンジニアリング用のツールキット）が知られており、その概念構造は内部の構成要素から外部システムのインタラクションを区別する。ＴＲＡＤＥは、体系的、オブジェクト志向の両方の仕様とデザイン方法からの技術を含む。ＴＲＡＤＥの構造をサポートするために、ＴＣＭ（概念モデリング用のツールキット）と呼ばれるグラフィック編集機能が設けられている。
【００１１】
これらのアプローチは、第一フェーズ、つまりコンピュータアプリケーションがコード化される前に必要条件を改良するフェーズにおいていくらかの助けになるものの、ソフトウェアエンジニアリングのプロセスの後のフェーズ、すなわちプログラミングのフェーズ、およびテストとデバッグのフェーズでの生産性不足の主たる原因には対処していない。たとえば、必要条件が一度確認されると、ソフトウェア技術者は通常これらの方法のほとんどによりジェネレートされたプロトタイプを破棄し、Ｃ＋＋のような標準プログラミング言語で必要条件をデザインし、その条件を実行する。問題の場と解決の場の間の不適合のため、新しく開発されたコードは一般的にコードのエラーを有し、徹底的なテストとデバッグを必要とする。
【００１２】
プロトタイプが破棄されずに最終的なアプリケーションの骨組みとして使用されたとしても、ソフトウェア開発者は、特にユーザーインターフェースの導入とエラー処理のために、追加のコードを開発しなければならない。その場合、プログラマーが書いたコードはやはりテストしデバッグする必要がある。さらにＯＢＬＯＧの規則再書き込みアプローチにおいては、プログラミングに関する難点が一つ前のレベル、未知の独自の言語で規則を書き直す開発にシフトしたに過ぎず、この必要性に対処していない。
【００１３】
その他のアプローチとしてはＲａｔｉｏｎａｌ法やＳｔｅｒｌｉｎｇ法などがあるが、これらは公式言語によるものではない。
【００１４】
【発明が解決しようとする課題】
したがって、ソフトウェアエンジニアリングのプロセスを改善する必要性、特にプログラミングフェーズやテストフェーズに費やす時間を削減する必要性が長期にわたり切実に感じられている。また、ロバストなソフトウェアアプリケーションを開発する間のプログラミングエラーを低減する方法を探す必要がある。さらに、必要条件が変更された場合に、ソフトウェアアプリケーションのメインテナンスを容易にする必要もある。
【００１５】
【課題を解決するための手段】
本発明はこれらの必要性とまたその他の必要性に対処するものであり、そのシステム必要条件は、（たとえばグラフィックユーザーインターフェースなどを通して）捉えられ、公式仕様に変換され、正確性と完全性をヴァリデートされる。また、そのヴァリデートされた公式仕様に基づいて、完全でロバストなソフトウェアアプリケーションを自動的にジェネレートするトランスレーターが設けられている。ヴァリデートされた公式仕様からアプリケーションのコードをジェネレートすることにより、エラーのないソースコードのストラテジーを利用できるようになり、開発者がマニュアルでソースコードを作成したり、不完全なプロトタイプを使用することがなくなる。したがって、従来のソフトウェアエンジニアリングプロセスにおけるエラーを起こしやすいマニュアルでのプログラミングフェーズが排除され、テストとデバッグの時間が大幅に削減される。ひとつの例では、あるアプリケーションのソフトウェア開発にかかった時間は本来の所要時間の２７％にまで削減された。従来のコード化、テスト、そして再ヴァリデーションのサイクルも排除されるため、ソフトウェアメインテナンスもまた低減される。
【００１６】
本発明の一側面は、曖昧さが、Ｃ＋＋のような従来のオブジェクト志向の高位のプログラミング言語に関係するプログラミングエラーの主な原因であるという洞察から生まれた。したがって、ユーザーがソフトウェアアプリケーションの明確な公式条件を入力できるように、グラフィックなユーザーインターフェースが掲示される、自動ソフトウェア作成ツール、ソフトウェア、および方法論が備わっている。ソフトウェアアプリケーションの公式条件の入力に基づき、ソフトウェアアプリケーションの公式仕様が作成、ヴァリデートされ、その仕様により、ソフトウェアアプリケーションがジェネレートされる。明確なヴァリデート済みの公式仕様から直接ソフトウェアアプリケーションをジェネレートすることにより、ソフトウェア開発者は、従来のプログラミング言語に伴うプログラミングエラーを避けることができ、かわりに問題の場で直接作業することができる。一つの実施例においては、ロバストな最終的ソフトウェアアプリケーションを作成するためにソフトウェアアプリケーションをジェネレートする時に、エラー処理のインストラクションもまた作成される。
【００１７】
本発明のもう一つの側面は、従来のプロトタイプ作成技術の欠点の主な原因は、これらの技術がユーザーインターフェースの特徴を指定する能力に欠けることであるという認識に基づくものである。したがって、そのような従来のプロトタイプは、顧客が即使用可能な、最終的なソフトウェアアプリケーションの条件を満たさない初期のユーザーインターフェースを有する。それ故、本発明のこの側面は、ソフトウェアアプリケーションの必要条件を指定する概念モデルの公式仕様を含む、自動ソフトウェアアプリケーション作成ツール、ソフトウェア、および方法論に関する。この概念モデルはソフトウェアアプリケーションのユーザーインターフェースのパターンを指定する表示モデルを含む。その表示モデルを指定する公式仕様はヴァリデートされ、そのヴァリデートされた公式仕様に基づき、ソフトウェアアプリケーションがジェネレートされる。結果として、ジェネレートされたソフトウェアアプリケーションは、表示モデルが指定したパターンに基づくユーザーインターフェースの処理についてのインストラクションを含む。実際、ジェネレートされたソフトウェアアプリケーションのコードは、高容積かつトランザクションに関る拡張可能で信頼できるシステムロジック機能をサポートし、表示モデルにより、クリエイティブデザイナーはユーザーインターフェースのコード化の詳細について懸念せずにすむため、ジェネレートされたソフトウェアアプリケーションのコードは、インターネット上の開発に非常に適している。
【００１８】
以下、本発明を最善のかたちで実施すべく意図された実例の詳細な説明により、本発明のその他の目的と効果はさらに明白になる。以下理解されるごとく、本発明はその他異なる例を実施する能力を有し、いくつかの内容は、さまざまな明白な面において、本発明から逸脱することなく変更可能である。したがって、図や説明は、本質的に解説のためのものであり、これらに限定するものではない。
【００１９】
本発明は、添付の図面の例により図解されるが、これらに限定されるものではなく、参照のように、図にある数字は類似する要素を表す。
【００２０】
【発明の実施の形態】
自動ソフトウェア作成システムを説明する。以下の説明では、本発明の徹底した理解を提供するため、説明の目的で、数々の具体的な詳細が述べられている。しかしながら、この技術に熟練した者には、本発明がこれらの具体的な詳細なしに実践されることもできるということは明らかだろう。その他の場合においては不必要に本発明を不明瞭にすることを避けるため、周知の構造やデバイスはブロックダイアグラムの形で示されている。
【００２１】
（ハードウェアの概要）
図１は、本発明の一実施例を実現し得るコンピュータシステム１００を示したブロックダイアグラムである。コンピュータシステム１００は、バス１０２、あるいはその他の情報を伝達するための通信メカニズムと、バス１０２と連動した、情報を処理するためのプロセッサー１０４を含む。コンピュータシステム１００はまた、プロセッサー１０４が実行する情報やインストラクションを保存するためのバス１０２と繋がれた、ランダムアクセスメモリー（ＲＡＭ）やその他のダイナミックストーレッジデバイスのようなメインメモリー１０６を有する。メインメモリー１０６はまた、プロセッサー１０４がインストラクションを実行している間の一時的なバリアブルやその他の中間情報の保存に使用されることもある。コンピュータシステム１００はさらに、プロセッサー１０４のスタチックな情報とインストラクションを保存するための、バス１０２に繋がれた読み出し専用のメモリー（ＲＯＭ）１０８、あるいはその他のスタチックなストーレッジデバイスをも有する。磁気ディスクや光学ディスクのようなストーレッジデバイス１１０が設けられており、情報とインストラクションの保管のため、バス１０２に繋がれている。
【００２２】
コンピュータシステム１００はバス１０２経由で、コンピュータユーザーに情報を掲示するためのカソードレイチューブ（ＣＲＴ）などのディスプレイ１１２に繋がれてもよい。英数字やその他のキーを含む入力デバイス１１４は、プロセッサー１０４への情報とコマンド選択の伝達のため、バス１０２に繋がれている。ユーザー入力デバイスのもう一つの形式は、プロセッサー１０４への方向情報やコマンド選択を伝達し、ディスプレイ１１２上のカーソルの動きをコントロールするマウスや、トラックボールや、カーソル方向キーのようなカーソルコントロール１１６である。この入力デバイスは通常一つの面での位置を指定できるように、二つの軸、第一軸（たとえば、ｘ）と第二軸（たとえば、ｙ）において二つの自由度を有する。
【００２３】
本発明は、自動ソフトウェア作成用のコンピュータシステム１００の使用に関する。発明の一つの実施例によれば、自動ソフトウェア作成は、メインメモリー１０６に保存されている一つ以上のインストラクションの中の一つ以上のシーケンスを実行するプロセッサー１０４に応じて、コンピュータシステム１００により成される。そのようなインストラクションは、ストーレッジデバイス１１０のような、もう一つのコンピュータ可読媒体から、メインメモリー１０６に読み込まれてもよい。メインメモリー１０６に保存されているインストラクションのシーケンスが実行されることにより、プロセッサー１０４がここで説明されているプロセスのステップを遂行する。メインメモリー１０６に保存されているインストラクションのシーケンスを実行するために、マルチプロセッシング配列された一つ以上のプロセッサーを使用してもよい。別の実施例においては、本発明を実施するためのソフトウェアインストラクションの代わりか、あるいはインストラクションとの組み合わせで、配線回路を使用することもできる。したがって、本発明の実施例は、ハードウェア回路とソフトウェアの特定な組み合わせに限定されるものではない。
【００２４】
本文で使われている「コンピュータ可読媒体」という言葉は、プロセッサー１０４の実行のためのインストラクションを与えることに関与するいかなる媒体をも意味する。そのような媒体は、不揮発性媒体、揮発性媒体、及び伝達媒体を含むが、それらに限定されず、多くの形状を取ることができる。たとえば、不揮発性媒体は、たとえばストーレッジデバイス１１０のような、光学、あるいは磁気ディスクを含む。揮発性媒体は、メインメモリー１０６のようなダイナミックメモリーを含む。伝達媒体は、バス１０２を構成するワイヤーを含め、同軸ケーブルや銅ワイヤー、及び光ファイバーなどを含む。伝達媒体はまた、ラジオ周波数（ＲＦ）や赤外線（ＩＲ）のデータ通信の間に発生するような音波や光波の形を取ってもよい。コンピュータ可読媒体の一般的な形状は、たとえば、フロッピーディスク、フレキシブルディスク、ハードディスク、マグネティックテープ、その他の磁気媒体、ＣＤ−ＲＯＭ、ＤＶＤ，その他の光学媒体、パンチカード、ペーパーテープ、その他の穴のパターンを持つ物理的媒体、ＲＡＭ，ＰＲＯＭ，およびＥＰＲＯＭ，ＦＬＡＳＨ−ＥＰＲＯＭ、その他のメモリーチップあるいはカートリッジ、この後説明する搬送波、もしくはその他のコンピュータが読み取ることができる媒体などを含む。
【００２５】
さまざまな形状のコンピュータ可読媒体は、プロセッサー１０４が遂行するための一つ以上のインストラクションの一つ以上のシーケンスを伝達することに関与してもよい。たとえば、インストラクションは最初に、遠隔のコンピュータの磁気ディスクに在ってもよい。そして、その遠隔コンピュータはそのインストラクションをダイナミックメモリーにロードして、モデムを使って電話線上で送ることができる。コンピュータシステム１００にローカルであるモデムは電話線上のデータを受信し、赤外線信号に変換するために赤外線送信機を使うことができる。バス１０２に繋がれた赤外線検出器は、赤外線信号によって伝達されたデータを受け取り、バス１０２上にそのデータを載せることができる。そして、バス１０２はそのデータをメインメモリー１０６に運び、そこからプロセッサー１０４がインストラクションを取り出し実行する。オプションとして、メインメモリー１０６が受け取るインストラクションは、プロセッサー１０４による実行の前か後のいずれかにストーレッジデバイス１１０に保存されてもよい。
【００２６】
コンピュータシステム１００はまた、バス１０２に繋がれた通信インターフェース１１８を有する。通信インターフェース１１８は、ローカルネットワーク１２２に繋がっているネットワークリンク１２０へ、双方向データ通信を提供する。たとえば、通信インターフェース１１８には、データ通信接続を対応する型の電話線に供給する統合サービス・デジタルネットワーク（ＩＳＤＮ）カード、あるいはモデムなどがある。もう一つの例としては、通信インターフェース１１８は、適したローカルネットワーク（ＬＡＮ）にデータ通信接続を提供するローカルネットワークカードでもよい。ワイヤレス接続も実施可能である。そのような実施のいずれにおいても、通信インターフェース１１８は、さまざまな情報を表すデジタルデータストリームを運ぶ電気、電磁、あるいは光学信号を送り、受け取る。
【００２７】
ネットワークリンク１２０は通常、一つ以上のネットワークを通じて、他のデータデバイスへのデータ通信を提供する。たとえば、ネットワークリンク１２０は、ローカルネットワーク１２２を通して、ホストコンピュータ１２４もしくはインターネットサービスプロバイダー（ＩＳＰ）１２６によって操作されているデータ機器への接続を提供することもできる。かわりに、ＩＳＰ１２６は、今日一般に「インターネット」１２８とよばれているワールドワイドパケットデータネットワークを通して、データ通信サービスを提供する。ローカルネットワーク１２２とインターネット１２８は共に、デジタルデータストリームを運ぶ電気、電磁、あるいは光学信号を使用する。さまざまなネットワークを通る信号や、ネットワークリンク１２０上の信号と通信インターフェース１１８を通る信号は、コンピュータシステム１００と行き来してデジタルデータを運ぶもので、情報を運ぶ搬送波の形状の例である。
【００２８】
コンピュータシステム１００は、ネットワーク、ネットワークリンク１２０、及び通信インターフェース１１８を通し、メッセージを送り、プログラムコードを含むデータを受け取ることができる。インターネットの例において、サーバー１３０は、インターネット１２８、ＩＳＰ１２６、ローカルネットワーク１２２および通信インターフェース１１８を通して、アプリケーションプログラムのための要求されたコードを伝達し得る。本発明に基づいて、そのようなダウンロードされたアプリケーションにより、本文で説明されるように、自動ソフトウェア作成が成される。受信されたコードは、受信されたままの形でプロセッサー１０４により実行されてもよいし、および／またはストーレッジデバイス１１０に保存されてもよいし、もしくはその他の不揮発性保存場所に保存されてもよい。この方法においては、コンピュータシステム１００が、搬送波という形でアプリケーションコードを取得してもよい。
【００２９】
（概念の概要）
図２は、本発明の一実施例に基づく自動ソフトウェア作成システム２０２の、ハイレベル構造とデータフローを図示した概略ブロックダイアグラムである。自動ソフトウェア作成システム２０２は、必要条件２００を入力として受理し、完全でロバストなアプリケーション２０４（システムロジックとユーザーインターフェースコードの両方を含む）とデータベーススキーマ２０６とドキュメンテーション２０８を作成するよう設定されている。実施の一例においては、自動ソフトウェア作成システム２０２は、ユーザーが必要条件を入力できるようにするコンピュータエイデッドソフトウェアエンジニアリング（ＣＡＳＥ）ツール２１０フロントエンドと、入力条件２００をヴァリデートするヴァリデーター２２０、およびヴァリデートされた入力条件２００を完全かつロバストなアプリケーション２０４に変換するいくつかのトランスレーターを含む。これらのトランスレーターには、システムロジックトランスレーター２３２、ユーザーインターフェーストランスレーター２３４、データベースジェネレーター２３６、およびドキュメンテーションジェネレーター２３８などを含んでもよい。
【００３０】
一つの実施例の動作の間に、アプリケーションの概念モデルを指定する必要条件２００は、ＣＡＳＥツール２１０により表示される図やテキスト対話型ダイアログを使って集められる。好ましくは、ＣＡＳＥツール２１０は、テキストのみの公式方法の使用に通常伴う複雑さを避けるために、オブジェクト志向のモデリング技術を用いる。実施の一例において概念モデルは、オブジェクトモデル、ダイナミックモデル、機能モデル、そして表示モデルの、４つの補完的なモデルに細分される。これらのモデルについては本文で後により詳しく説明する。必要条件２００を集めた後、ＣＡＳＥツール２１０は、たとえば、スペインのヴァレンシア工科大学で開発された、情報システム用のオブジェクト志向の言語であるＯＡＳＩＳランゲージのような公式仕様言語に基づき、入力条件を公式仕様２１５として保存する。その公式言語により定義された拡張文法を使用し、ヴァリデーター２２０は、公式仕様２１５が正しく完全であるか、シンタックス的、セマンティックス面でヴァリデートする。公式仕様２１５がヴァリデーションに合格しなかった場合、アプリケーションをジェネレートすることは許可されないので、正しく完全なアプリケーションだけがジェネレートされることになる。
【００３１】
一方、公式仕様２１５が確かにヴァリデーションに合格すると、そのヴァリデートされた公式仕様２１５に対応する精密な実行モデルを実施するため、「トランスレーター」と呼ばれているいくつかの自動ソフトウェア作成プロセス（システムロジックとユーザーインターフェースのもの）が用いられる。特に、トランスレーター２３２と２３４はそれぞれ、Ｃ＋＋、ビジュアルベイシック、あるいはＪＡＶＡのような高位言語で、アプリケーションのシステムロジックとユーザーインターフェースそれぞれのアプリケーションソースコード２０４を作成する。実施の一例では、データーベースジェネレーター２３６もまた、たとえば業界標準のＡＮＳＩ−９２ＳＱＬリレーショナルデータベース管理システム（ＲＤＭＤＳ）のアプリケーション用のデータモデルを作成するストラクチャークエリーランゲージ（ＳＱＬ）スクリプティング言語でインストラクションを作成する。
【００３２】
さらに、実施の一例においては、概念モデルに導入された情報からサービス可能なシステムドキュメンテーションを自動的にジェネレートするドキュメントジェネレーター２３８も使用される。
【００３３】
（ＣＡＳＥモデラー）
上記のとおり、ＣＡＳＥツール２１０には、テキストのみの公式方法の使用に通常伴う複雑さを避けるため、オブジェクト志向のモデリング技術を使用するのが好ましい。むしろ、デザイナーがシステム必要条件を指定できるよう、オブジェクトモデル、ダイナミックモデル、機能モデル、および表示モデルの４つの補完的モデルが使用される。しかし、従来の技術とは反対に、ＣＡＳＥツール２１０は実際、デザイナーがＣＡＳＥツール２１０でシステムを指定している最中に、デザイナーのシステムの公式仕様を公式仕様言語に基づきキャプチャーする。
【００３４】
この特徴は、従来の方法論にしばしば欠けている、仕様における明確に定義された表現の導入を可能にする。特に、ＣＡＳＥツール２１０は、公式仕様言語でのクラス定義を満たすのに関係のある情報だけが導入されるような制約を強化する。ＣＡＳＥツール２１０によって入力される公式仕様の使用はしたがって、解決の場におけるシステムをヴァリデートし、検証するための環境を提供し、本文で後に説明されるように、機能的に仕様と同等なソフトウェア製品を得ることができる。それにもかかわらず、これは、前に述べられたように、常に最も広範囲のモデリング技術に対応するこの外見を保存しながら達成される。このようにして、多くの従来のアプローチの単調な形式主義的特徴はデザイナーの目につかなくなり、グラフィックモデリング表記の使用によりデザイナーは快適に感じるようになる。
【００３５】
表記に関して、実施の一例における概念的モデリングは、統一モデリング言語（ＵＭＬ）に対応するダイアグラムを使用する。したがって、情報システムを形作るために、システムデザイナーが別のグラフィック表記を学ぶ必要はない。広く受け入れられているオブジェクト志向の概念モデリングの原則に基づき、概念モデルは、オブジェクトモデル、ダイナミックモデル、そして機能モデルに細分される。しかしながら、完全なアプリケーションはまたユーザーインターフェースをも必要とするため、完全なアプリケーションを指定するために、これら３つのモデルだけでは不十分である。したがって、ＣＡＳＥツール２１０は表示モデルと呼ばれる４つ目のモデルにおいて、後にアプリケーションのためのコードにトランスレートされるユーザーインターフェースパターンについての情報も回収する。
【００３６】
実施の一例では、ＣＡＳＥツール２１０は、異なるアプリケーションに対応するプロジェクトにそってまとめられた情報を収集する。ＣＡＳＥツール２１０によって構築されたそれぞれのプロジェクトは、クラスや、クラス間の関係、グローバルトランザクションやグローバル機能、およびビューについての情報を含むこともできる。
【００３７】
各クラスは、アトリビュート、サービス、デリベーション、制約、トランザクションフォーミュラ、トリガー、ディスプレイセット、フィルター、ポピュレーション選択パターン、状態遷移図、および公式インターフェースからなる。これらのリストの情報に加え、クラスはまた、名前、エイリアス、およびデフォルトポピュレーション選択インターフェースパターンを保存することもできる。そして、余分な情報は、なぜクラスがモデル内に存在するかについての情報をデザイナーが入力できるとコメントとして保存される。
【００３８】
各アトリビュートは、以下のような特徴を持つことができる。名前、公式データタイプ（たとえばコンスタント、バリアブル、デライブドなど）、データタイプ（リアル、ストリング）、デフォルト値、アトリビュートがクラスのオブジェクトを区別する識別子であるか、長さ、オブジェクトが形成されるときアトリビュートが必要か否か、ＮＵＬＬバリューがアトリビュートに割り当てられるか、そしてなぜアトリビュートが形成されたかについてのいくつかの注意点を伝えるためのフィールド、である。各アトリビュートはまた、イベントによってどのようにオブジェクトの状態が変化するかを宣言するフォーミュラであるバリュエーションについての情報を含むことができる。バリュエーションフォーミュラは、以下の部分により構成されている。（その効果を適用するために満たさなければならない）条件、イベント、および特定のアトリビュートへのイベントの効果である。アトリビュートは、アトリビュートに関係する対応するサービスアーギュメントに適用される表示モデルに属する、ユーザーインターフェースパターンを含んでもよい。
【００３９】
サービスには、イベントとトランザクションという２つのタイプがある。イベントとは、アトミックな動作であり、トランザクションは、イベントあるいはトランザクションで在り得るサービスよりなる。どのサービスも以下の特徴を持つことができる。名前、サービスの種類（イベントあるいはトランザクション）、サービスエイリアス、注意点およびヘルプメッセージである。イベントは、新規、破壊、およびそのどちらでもない、の３タイプある。イベントはまた、プロジェクトのいくつかのクラスに共有されることも可能である。共有されたイベントはそれを共有するすべてのクラスに属する。トランザクションは、サービスの構成を表すフォーミュラを有する。この情報に加え、サービスは、アーギュメントのリストを保管し、そのアーギュメントの特徴は、名前、データタイプ、ＮＵＬＬが有効な値と認められるか、アーギュメントがオブジェクトの一つのセット（コレクション）を表すか、デフォルトバリュー、エイリアス、および注意点である。また、各アーギュメントについて、アーギュメントに関係するユーザーインターフェースパターンは、導入パターン、ポピュレーション選択パターン、定義された選択パターン、および依存パターンである。クラスは、デリベーションについての情報や制約を保存することもできる。各デリベーションは、それぞれの条件下においてどのフォーミュラが適用されるかを指定する、条件フォーミュラのペアのリストを指定する。各制約は、しっかりと作られたフォーミュラに加え、制約が破られたときに表示されるエラーメッセージである。ダイナミック制約に関しては、フォーミュラは、フォーミュラのエバリュエーションのガイドをなすグラフへと内部的にトランスレートされる。
【００４０】
クラスはさらに、トリガーを保存することができる。個々のトリガーは、自分自身により指定されるトリガーターゲット、クラスまたはオブジェクト、トリガー条件、アクティベートされるトリガードアクション（サービスに加え、可能なエージェントのリスト）、および関連するサービスのアーギュメントと関連するデフォルトバリューのリストにより構成されてもよい。クラスは、ディスプレイセット、フィルター、およびクラスに影響する表示モデルのユーザーインターフェースパターンとしてのポピュレーション選択パターンも有することができる。各ディスプレイセットは、ヴィジュアライゼーションの要素（ユーザーに表示されるアトリビュート）を保存することができる。各フィルターは、しっかりと形成されたフォーミュラ、フォーミュラを限定するのに有効な補助バリアブルのリストより成る。ポピュレーション選択パターンは、ディスプレイセットやフィルターに関係している。クラスはまた、クラスとクラスの間の状態と変化のセットである状態遷移ダイアグラムをも有する。それぞれの状態遷移は、オブジェクトの状態を変えることができるアクション（サービスに加え、可能なエージェントのリスト）に関係している。アクションは、前提条件と対応するエラーメッセージ（前提条件が適用しないと表示される）を有してもよい。前提条件とは、対応するアクションが実行されるために満たされねばならないフォーミュラである。決論を生み出さないトランザクションの場合、決論はぞれぞれのトランザクションにコントロール条件を付けることにより達成される。コントロール条件は、どの状態遷移が効果を生じるか指定するフォーミュラである。最後に、クラスはインターフェースのリストを保存することができる。各インターフェースは、アクターが実行できるサービス（エージェント）のリストと観測可能なアトリビュートのリストを保存する。
【００４１】
モデルはまた、クラス間の関係についての情報も維持し、その関係は、アグリゲーション（「を持つ」または「の一部」）とインヘリタンス（「である」）の２種類が可能である。それぞれのアグリゲーション関係は、オブジェクトの構成を示し、そしてカーディナリティー（そのアグリゲーション関係における参加者の最小と最大の数）、アグリゲーションがスタチックであるかダイナミックであるか、アグリゲーションが包括的であるか参照的であるか、アグリゲーションがアイデンティフィケーション依存を有するか、およびアグリゲーションが複数の値である場合の分類項についての情報をキャプチャーする。それぞれのインヘリタンス関係はオブジェクトの特殊化を示し、親クラスの名前、子クラスの名前、および特殊化が一時的であるか永久的であるかを保存する。最後に、特殊化が永久的ならば、バリアブルアトリビュート上のしっかりと形成されたフォーミュラを特殊化条件として保存する。特殊化が一時的な場合は、条件もしくは、子の役割を有効／無効にするイベントのリストを保存する。
【００４２】
最後に、プロジェクトは、グローバルトランザクションのリストをキャプチャーすることもでき、そのリストの中で、保存される関連した特徴は、グローバルインタラクション、フォーミュラ、およびアーギュメントのリストを含む。グローバル機能のリストのキャプチャーも可能であり、そのリストの中で、各機能は、名前、返還された値のデータタイプ、アーギュメントのセット（サービスに類似）、および機能についてのコメントを保存する。
【００４３】
プロジェクトは、選ばれたエージェントクラスが有するシステムの具体的なビジョンから構成される一つのセットのヴューを有する。つまり、ひとつのエージェントクラスに許容される公式インターフェースのセット（アトリビュートとサービス）である。それぞれのエージェントクラスは、インターフェースのリストを有する。
【００４４】
（オブジェクトモデル）
オブジェクトモデルは、特にエンティティーのクラスを定義することにより、オブジェクト志向の方法で、システムデザイナーがアプリケーションで使用されるエンティティーを指定することができるようにするグラフィックモデルである。したがって、クラス定義は、たとえば、アトリビュートや、サービス、およびクラス関係（アグリゲーションとインヘリタンス）などを含む。加えて、エージェント関係は、一つのクラスのオブジェクトが起動できるサービスを決定するために指定される。
【００４５】
図３は、図書館利用者（ｒｅａｄｅｒ）、本（ｂｏｏｋ）、および貸し出し（ｌｏａｎ）を有する図書館システム用のオブジェクトモデル３００の例を図示する。オブジェクトモデル３００におけるクラスは、３つの部分、すなわちクラスの名前、アトリビュート、およびサービスを有する長方形で表されている。この例においてオブジェクトモデル３００は、貸し出しがされた時のために貸し出しコード３１２と貸し出し日３１４を示すアトリビュートを有する、貸し出しクラス３１０を含む。貸し出しクラス３００はまた、２つのサービス（方法）を含む。一つは本の貸し出し３１６であり、もう一つは本の返却３１８である。
【００４６】
オブジェクトモデル３００はさらに本クラス３２０を含み、その本クラス３２０は、その本の著者３２２、本コード３２４、状態３２６（たとえば、予約済み、使用中、貸し出し中など）、および新しい本を創設するｎｅｗ＿ｂｏｏｋ３２８のようなサービスを指定するアトリビュートを有する。もう一つのクラスは、図書館員クラス３３０であり、その名前３３２はアトリビュートによって指定され、ｎｅｗ＿ｌｉｂｒａｒｉａｎサービス３３４により創設されたものである。
【００４７】
図書館に属する各図書館利用者は、図書館利用者クラス３４０で説明され、そのアトリビュートは、年齢３４２、図書館利用者の借りた本の冊数３４４、および図書館利用者の名前３４６を含む。図書館利用者は、ｎｅｗ＿ｒｅａｄｅｒサービス３４８と創設されてもよい。信頼性のない図書館利用者クラス３５０も、（たとえば、期限を過ぎた貸し出し本の料金の未払いために）信頼することのできない図書館利用者３４０を表示するために、オブジェクトモデルの一部となっている。信頼性のない図書館利用者３５０は、図書館員３３０により免除３５２されることもある。
【００４８】
オブジェクトモデル３００において、インヘリタンス関係は、クラスを結ぶ矢印によって表される。たとえば、信頼性のない図書館利用者クラス３５０は、図書館利用者クレーム３４０と矢印でつながっている。したがって、信頼性のない図書館利用者クラス３５０は、図書館利用者クレーム３４０からインヘリタンスをするよう指定される。別の言い方をすれば、信頼性のない図書館利用者クラス３５０は、図書館利用者クレーム３４０のサブクラスである。サブクラスとベースクラスをつないでいる矢印は、専門条件かあるいは、子の役割を起動もしくはキャンセルするイベントで同等にすることができる。オブジェクトモデル３００の例においては、信頼性のない図書館利用者クラス３５０と図書館利用者クラス３４０の間の矢印は、「図書館利用者を罰する／免除する」サービスというラベルを貼られる。したがって、図書館利用者３４０が罰せられると、その人物は信頼性のない図書館利用者３５０になる。反対に、信頼性のない図書館利用者３５０が免除３５２されると、その人物は普通の図書館利用者３４０になる。
【００４９】
アグリゲーション関係は、与えられた構成クラスとその合成クラスまでの線で、合成クラス側にダイアモンドのついた線を使うことによって、オブジェクトモデル３００の中に表される。アグリゲーションは、与えられた入れ物にいくつの構成要素が付属できるかや、構成クラスがいくつの入れ物に関連できるかを決定する。この例においては、本３２０と図書館利用者３４０は、貸し出し３１０にアグリゲーションされる。なぜならば、貸し出し３１０は図書館の図書館利用者３４０に本３２０を貸し出すことに関与するからである。アグリゲーションのリプレゼンテーションは、両方向における（つまり最小数と最大数の）カーディナリティー、役割名、および関係名も含む。この例において、貸し出しから本への、貸し出し：本の関係のカーディナリティーは、この概念モデルの中では厳密に一冊の本が一回の貸し出しのの対象であるため、１：１であり、本からローンへは、ある時にはちょうど本が貸し出しされているかもしれないし、貸し出されてないかもしれないため、０：１である。
【００５０】
さらに、エージェント関係は、関連するクライアントクラスとサーバークラスのサービスを結ぶ点線であらわされている。この例において、図書館員３３０は信頼性のない図書館利用者クラス３５０の免除サービス３５２のエージェントであり、したがって、免除サービス３５２と図書館員クラス３３０の間に点線がある。これは、図書館員が信頼性のない図書館利用者を免除できることを意味する。もう一つの例では、図書館利用者３４０はまた、本の貸し出し３１６と本の返却３１８のサービスのエージェントである。
【００５１】
最後に、共有されるイベントは、ふたつのクラス間の関連するイベントを結ぶ実線で表されている。この例において、貸し出し＿本のイベントは、本クラス３２０と図書館利用者クラス３４０での前記イベントが実線で結ばれているため、共有されるイベントである。共有されるイベントは、一つのオブジェクト以上に影響を及ぼし、その中で、それぞれのオブジェクトはそのローカル仕様に基づき、その状態を変化させることもある。この例において、貸し出し＿本のイベントは、本３２０の状態を「入手不可能」に変え、図書館利用者３４０の本の数を一つ増加させ、そして貸し出しクラス３１０の場合と、本３２０のアグリゲーション、および図書館利用者３４０を創設する。貸し出し＿本のイベントは貸し出しクラス３１０の場合を創設するので、アグリゲーションされたクラスにとって、それは「新しい」イベントとなる。
【００５２】
オブジェクトモデルにおける追加の情報は、クラスの公式説明を完成するために指定される。特に、オブジェクトモデルにおけるすべてのクラスに関して、表１に示すように、以下の情報がキャプチャーされる。
【００５３】
［表１］
2004506962.tif 000003
【００５４】
アグリゲーションとインヘリタンスに関連する追加情報もまた収集される。アグリゲーションされたクラスについては、追加情報は、アグリケーションがＵＭＬ特徴化に基づいた関連か合成であるか、もしくはアグリゲーションがスタチックかダイナミックかであるかを指定することができる。インヘリタンスヒエラルキーについては、追加情報は、インヘリタンスによって成された専門化が永久的か一時的かを指定することができる。専門化が永久的であれば、コンスタントアトリビュート上の対応する条件が専門化関係を特徴づけなければならない。一方、専門化が一時的であれば、バリアブルアトリビュートに基づいた条件、あるいは子の役割を有効／無効化するイベントが指定されなければならない。
アプリケーションによっては、完全に指定するには多数のクラスを必要とすることもある。その場合、クラスはクラスターとして集めてもよい。クラスターは、一回に一つのクラスターずつ、デザイナーやシステムアナリストがアプリケーションを理解し易くする。したがって、クラスターは、オブジェクトモデルのビューの複雑さを削減する。
【００５５】
（ダイナミックモデル）
システムクラスアーキテクチャーはオブジェクトモデルで指定される。しかしながら、どのオブジェクト寿命が有効とされ得るかや、どのインターオブジェクト通信が設定され得るかなどの追加の特徴はさらに、システム仕様に入力されなければならない。この目的のために、ダイナミックモデルは設けられている。
【００５６】
ダイナミックモデルは、サービス、トリガー、およびグローバルトランザクションに応じて、オブジェクトの動きを指定する。一つの実施例において、ダイナミックモデルは、状態遷移ダイアグラムとオブジェクトインタラクション図という二つの図により表される。
【００５７】
状態遷移ダイアグラム（ＳＴＤ）は、すべてのクラスの有効なオブジェクトライフサイクルを設定することにより、正しい行動を説明するために使用される。有効なライフは、特定のクラスに属するオブジェクトの正しい行動を特徴づける、適切な一連の状態を意味する。遷移は有効な状態の変化を表す。一つの遷移は一つのアクションと、オプションとしてコントロール状態、あるいはガードを有する。一つのアクションは、一つのサービスに加えて、オブジェクトモデルで定義された有効なエージェントのサブセットにより構成される。すべてのエージェントが選択されると、遷移は星印（＊）を付けられる。コントロール条件は、与えらたアクションの何の決定も生み出さない可能性を避けるための、オブジェクトアトリビュートおよび／あるいはサービスアーギュメント上で定義されたしっかりと形成されたフォーミュラである。アクションは、その実行を受け入れるために満たされなければならない一つの前提条件を有することもある。埋め込まれた丸を持つ丸は、オブジェクトの存在以前の状態を表す。この状態をソースとする遷移は、創設アクションにより構成されなければならない。同じように、矢の命中した的はオブジェクトの破壊後の状態を表す。この状態を目的地とした遷移は、破壊アクションにより構成されなければならない。中間の状態は、状態の名前の付いた丸により表される。したがって、状態遷移ダイアグラムは、オブジェクトのさまざまな状態と状態間の遷移のグラフィックな表現である。図４Ａは、本発明の一実施例による状態遷移ダイアグラム４００の例を図示する。状態は、状態名を貼られた丸により、状態図４００の例では表されている。図４Ａを参照に、「本０」状態４０４は、「本０」という名を付けられた丸により示されている。オブジェクトが生まれる前に、対応する創設アクションの名の付いた初期遷移４１０のソースであるこの存在していない状態を表すために、空の丸４０２が使用される。矢の命中した的４０６は、［＊］：破壊＿本アクションによって起きる遷移４１６により生じるような、オブジェクトが破壊された後の状態を表すために使用される。
【００５８】
変化は、ソースの状態から目的地の状態への実線の矢印で表されている。遷移矢印の中心には、アクション、前提条件、およびガード（実行された場合）を表示するテキストが付けられている。この例において、遷移４１２は、遷移４１２と前提条件である、「もし、状態＝「利用可能であれば」に関連する、貸し出し＿本アクションの名でラベルを付けられている。したがって、システムは、本の状態アトリビュートが「利用可能」である場合のみ、アクションの実行を受け付ける。言い換えれば、概念モデルは、本が利用可能な場合のみ本を貸し出すことができる、ということを要求する。もう一つの例として、遷移４１４は、遷移４１４と前提条件である、「もし、状態＝「貸された」に関連する返却＿本アクションの名を付けられる。言い換えれば、概念モデルは、本が貸し出された場合のみ本を返却することができる、ということを要求する。
オブジェクトインタラクション図は、インターオブジェクト通信を指定する。トリガーとグローバルトランザクションの２つのインタラクションが定義される。トリガーとは、前もって指定された条件が満たされた時に自動的に作動するオブジェクトサービスで、グローバルトランザクションとは、それら自身が、異なったオブジェクトのサービスおよび／あるいはその他のグローバルトランザクションに関与するサービスである。すべてのクラスに対して、一つの状態遷移ダイアグラムがあるが、以前のインタラクションがグラフィックに指定される場である概念モデル全体に対しては、唯一つのオブジェクトインタラクション図しかない。
【００５９】
一つの実施例においては、下線の引かれた名前の付いた箱はクラスオブジェクトを表す。トリガー仕様は、目的地：：トリガー条件であればアクション、というシンタックスに従う。トリガーの第一の構成要素は目的地で、つまりトリガーされたサービスが対象とするオブジェクトである。トリガーの目的地は、条件が満たされる場である同じオブジェクト（つまり自分自身）、指定のオブジェクト、もしくはサービスをブロードキャストする場合は、一つのクラスポピュレーション全体であってもよい。最後に、トリガーされたサービスとその対応するトリガー関係が宣言される。グローバルトランザクションは、宣言されたインタラクションに関与するアクションを結びつけることにより、グラフィックに指定される。これらのアクションは、それらを供給するオブジェクト（箱）をつなぐ実線で表されている。
【００６０】
それゆえに、オブジェクトと活動ルール間の通信は、グラフィックの箱、グラフィックのトリガー、およびグラフィックなインタラクションを表示するオブジェクトインタラクション図に説明されている。図４Ｂは、本発明の一実施例に基づくオブジェクトインタラクション図４２０の例を図示する。
【００６１】
オブジェクトインタラクション図４２０において、グラフィックインタラクションは、グラフィックインタラクションの構成要素の線によって表されている。図書館利用者箱４２２のようなグラフィックな箱は、この場合、図書館利用者のようなオブジェクトを（個々にもしくは総称的に）参照する特別な箱として宣言される。グラフィックトリガーは、実行するサービスとトリガー条件を示すテキストを有する実線を使って表されている。グラフィックインタラクションの構成要素もまた、実線を使用している。それぞれは、インタラクションの数と実行されるアクションを示すテキストを有する。この例においてトリガー４２４は、一人の図書館利用者がその時に借りている本の数が１０に達すると発動する図書館利用者を罰するアクションをあらわす。
【００６２】
（機能モデル）
多くの従来のシステムは、機能モデルを供給する際にショートカットを取るが、これは機能仕様の正確さを制限する。時に、使用されるモデルは、機能モデルとして構造化されたＤＦＤの使用を提案したＯＭＴの初期版で起こったように、オブジェクト志向のモデルのホモジェニエティーを破壊する。オブジェクトモデリングの状況におけるＤＦＤ技術の使用は、主にそれが他のモデル（オブジェクトの観点）と異なったシステムの観点（機能の観点）を提供するという理由で、不正確であると批判されてきた。その他のモデルは、システム動作の自由仕様をデザイナーの手に託しているが、それは不一致につながる。
【００６３】
しかしながら、本発明の一実施例では、これら従来のアプローチとはまったく異なった機能モデルを使用する。この機能モデルにおいて、オブジェクトの状態の変化に関連するセマンティックスは、イベント発生の結果としてキャプチャーされる。これを行うために、以下の情報が、宣言的に指定される。すべてのイベントが、関与するイベントのアーギュメントによってどのようにオブジェクトの状態を変化させるかと、そのオブジェクトの最新の状態である。これは、「ヴァリュエーション」と呼ばれる。
【００６４】
特に、機能モデルは、ヴァリュエーションの分類の概念を使用する。プッシュポップ、ステートインディペンデント、およびディスクリートドメインによるという３種類のヴァリュエーションが定義される。それぞれの種類は、その機能性を定義するのに必要な情報のパターンを決定する。
【００６５】
プッシュポップヴァリュエーションは、それらの関連するイベントがアトリビュートの値をある一定の量増加したり減少したりする、もしくはアトリビュートをある値に再設定するものである。
【００６６】
ステートインディペンデントヴァリュエーションは関与するアトリビュートに対し、以前のアトリビュートの値とは独立的に新しい値を与える。
【００６７】
ディスクリートドメインヴァリュエーションは、アトリビュートの前回の値に基づき、限定されたドメインから、アトリビュートに対し一つの値を与える。このドメインの異なった値は、アトリビュートに可能な有効な状況を作る。
【００６８】
これらの特徴を図示するため、表２は、通常の図書館を表す概念モデルにおける、図書館利用者クラス３４０の「本ナンバー」アトリビュート３４４の機能モデルを示す。
【００６９】
［表２］
クラス：図書館利用者アトリビュート：本＿ナンバーカテゴリー：プッシュポップ
イベント　　　　　　　　　数　　　　　　　　　　効果
貸し出し（）　　　　　　　１　　　　　　　　　　増加
返却（）　　　　　　　　　１　　　　　　　　　　減少。
【００７０】
これらのエヴァリュエーションは、これらの関係するイベントが、本＿ナンバーアトリビュート３４４の値を一定の量（１）増加したり減少したりするので、プッシュポップとして分類される（１）。この例において、その関係するイベント貸し出し（）は増加する効果を有し、返却（）は減少する効果を有する。
【００７１】
このエヴァリュエーションの分類は、完全な公式仕様が自動的にジェネレートされるようにし、完全にイベントの機能性をキャプチャーする本発明の一側面の貢献である。
【００７２】
ゆえに、機能モデルは、一つのクラスのアトリビュートの、すべての状態の変化のセマンティックスをキャプチャーする責任を担う。グラフィックな図は無い。テキストの情報は、前に説明された情報構造の対応する部分を満たすインターアクティブなダイアログを通して収集される。図５は、機能モデルの入力を受け取るダイアログの例を図示する。
【００７３】
（表示モデル）
表示モデルとは、ユーザーインターフェースの必要条件を説明するのに使用することができる、前もって定義した概念のセットである。これらの概念は、ユーザーインタフェイスを開発する際に繰り返されるシナリオを抜き出し抽象化することから生じる。これらの繰り返されるシナリオの抽象概念はパターンと呼ばれる。パターンの一つのセットは、パターン言語と呼ばれる。
【００７４】
この意味で表示モデルは、ユーザーインターフェースの必要条件を反映するためにデザインされたパターンを集めたものである。一つのパターンは、ある特定の限定されたドメインにおける、初期状況を与える、繰り返す問題に対して繰り返す解決の明確な説明である。ドキュメント化したパターンは問題の本質と解決の本質を抽象化し、したがって、初期状況とドメインに合う問題を解決するために何度も適用されることができる。パターン言語は多数のパターンから構成される。本発明は、どのような特定のパターンのリストにも限定されることはないが、以下は、有用と判明した、いくつかのユーザーインターフェースのパターンの簡単な説明である。サービス表示パターン、例表示パターン、クラスポピュレーション表示パターン、マスター−詳細表示パターン、およびアクション選択表示パターンなどである。
【００７５】
サービス表示パターンは、サービスがどのように最終的なユーザーに対してデータを要求するかをキャプチャーする。このパターンは、サービスアーギュメントの記入をコントロールし、サービスを始めたり終了したりするためのアクションを含む。これは、導入パターン、定義選択パターン、ポピュレーション選択パターン、依存パターン、ステイタス回復パターン、補助情報パターン、およびアーギュメント分類表示などの、より特定化したインターフェースタスクに当てはまるような、その他の低いレベルのパターンに基づく。
【００７６】
導入パターンは、最終ユーザー（つまり、最終的なアプリケーションを使用するユーザー）によって、システムに供給されなければならないデータを入力するための制限を取り扱う。特に、編集マスクと範囲値が導入され、有効にインターフェースに入力することができる値を制限する。このパターンは、入力アーギュメントをヴァリデートすることによりデータ入力過程を改善するため、サービスの中のアーギュメント、あるいはクラスの中のアトリビュートに適用することができる。
【００７７】
定義選択パターンは、アーギュメントの有効な値のセットを指定する。入力データー項目がスタチックで数が限られていて良く知られている場合、デザイナーはそのような有効な値を含むセットを計数することにより宣言することができる。このパターンは、計数したタイプや選択のデフォルト値を定義するものに類似している。したがって、最終ユーザーは前もって指定されたセットからの登録だけを選択することができ、したがってエラーのでやすい入力を減少することができる。たとえば、このパターンの一つの表現になりえるものは、コンボ箱である。このパターンは、データー入力過程を改善するために、サービスの中のアーギュメント、もしくはクラスの中のアトリビュートに適用されることができる。
【００７８】
ポピュレーション選択パターンは、ディスプレイや、複数のオブジェクトに知らせるオブジェクトの選択を取り扱う。特に、このパターンは、どのようにオブジェクトがフィルターされるか（フィルター表現）、どのデータがディスプレイされるか（ディスプレイセット）、およびオブジェクトがどのようにオーダーされるか（オーダー基準）をそれぞれ決定する、フィルター、ディスプレイセット、およびオーダー基準を含む。このパターンは、フィルター表現用のｗｈｅｒｅとオーダー条項用のｏｒｄｅｒ　ｂｙのコラムを有する、ＳＱＬセレクトステートメントとして考えてもよく、存在するオブジェクトのある特定のポピュレーションからオブジェクトを選択することが可能な時はいつでも、サービスにおけるオブジェクトでエヴァリュエーションされたアーギュメントに適用することができる。
【００７９】
依存パターンは、サービスの中のアーギュメント間の依存ルールの仕様を許可する、イベント−条件−アクション（ＥＣＡ）のセットである。アーギュメントが他に依存しているとき、これらの制限はこの種のルールを用いる。
【００８０】
ステイタス回復パターンは、サービスアーギュメントを初期化するオブジェクトアトリビュートからデータを回復する、潜在的に作られたパターンである。これは、依存パターンの潜在的なセットとしてモデル化することもできる。たとえば、カスタマーオブジェクトに関連したデータを変えるために、変化サービスを始める形が現れる。ユーザーがカスタマーＯＩＤ（オブジェクトアイデンディファイアー）を用意すると、インターフェースはオブジェクトを探すためにこのＯＩＤを使用することができ、名前や電話番号、および住所などのカスタマーに関係したデータを回復することができる。
【００８１】
補助情報パターンは、最終ユーザーが、存在するオブジェクトの正しいＯＩＤ（アイデンディファイされたオブジェクト）を選ぶ、もしくは入力することを確認するために、最終ユーザーに供給されるフィードバックを取り扱う。たとえば、カスタマーを選択するために、ＯＩＤが供給されなければならない。カスタマーの名前がＯＩＤ入力の答えとして自動的にディスプレイされると、ユーザーは、入力データを選択もしくは修正する際に、ユーザーを保証する価値のあるフィードバックデータを受け取る。補助情報パターンは、オブジェクト−ヴァリュエーテッドのアーギュメントに適用できる。
【００８２】
アーギュメント分類表示パターンは、ユーザーの希望に基づき、要求されたサービスアーギュメントをどのように分類するかをキャプチャーする。
【００８３】
例表示パターンは、オブジェクトの特性がどのように最終ユーザーに表示されるかをキャプチャーする。これに関して、ユーザーはサービスを開始、もしくはその他の関連したオブジェクトにナビゲートすることができる。例表示パターンは、一つの例の詳細なビューである。
【００８４】
クラスポピュレーション表示パターンは、一つのクラスの複数のオブジェクトの特性がどのように最終ユーザーに表示されるかをキャプチャーする。この意味において、オブジェクトが一度選択されると、最終ユーザーはサービスを始めることができるか、もしくはその他の関連したオブジェクトにナビゲートすることができるようになる。オブジェクトはまた、フィルターすることができる。
【００８５】
マスター−詳細表示パターンは、オブジェクトの全詳細を完全にする他の関連するオブジェクトを有する一つのクラスの、ある特定の一つのオブジェクトをどのように表示するかをキャプチャーする。このパターンを築くためには、以下のパターンが使用される。例表示、クラスポピュレーション表示、および帰納的に、マスター−詳細表示である。このように、マルチ詳細（複数の詳細）とマルチレベルのマスター詳細（帰納的に複数レベル）をモデルすることができる。たとえば一つのシナリオは、インボイスヘッダー、つづいてそのインボイスに関連したインボイスの一組のラインに関係する。
【００８６】
アクション選択パターンは、サービスが段階的なアプローチの原則に従い、どのように最終ユーザーに提供されるかをキャプチャーする。このパターンは、たとえば、ツリー構造を使用し、アプリケーションのメニューをジェネレートできる。最終的なツリー構造は、概念モデルのクラスで指定されたサービスのセットから得られる。ユーザーは、概念モデルで定義されたサービス、もしくは質問（観察）を開始することができる。
【００８７】
フィルター表現は、ブールタイプに対しエヴァリュエートするしっかりと形成されたフォーミュラである。このフォーミュラは、以下のように解釈される。フォーミュラを満たすオブジェクトはフィルターを通り抜ける。条件を満たさないものは、フィルターを通り抜けない。結果的に、このフィルターは、フォーミュラを満たすオブジェクトだけを通すふるいのような役割をする。これらのフォーミュラは、実行時に解決されるパラメーターを含むことができ、ヴァリアブルの値を供給したり、それらを直接最終ユーザーに聞くことができる。フィルターは、ＳＱＬのｗｈｅｒｅ条項の抽象概念して考えることもでき、ポピュレーション選択パターンに適用される。
【００８８】
ディスプレイセットは、オブジェクトのステータスを反映するために示されている、オーダーされたアトリビュートのセットである。ディスプレイセットは、ＳＱＬ条項のコラムの抽象化として考えることができ、ポピュレーション選択パターンに適用される。
【００８９】
オーダー基準は、アトリビュートと順序（増える順／減る順）を含む、順に並んだ組のセットである。この組のセットは、フィルターされたオブジェクトに対するオーダー基準を決定する。オーダー基準パターンは、ＳＱＬ条項によるオーダーの抽象概念として考えることもでき、ポピュレーション選択パターンに適用される。
【００９０】
（公式仕様）
ＣＡＳＥツール２１０は、システム必要条件２００をキャプチャーするためにユーザーインターフェースを表示した後、システム必要条件を公式仕様２１５に変換する。特に、ＣＡＳＥツール２１０は、以前に説明されたモデルを開始点として構築され、対応する公式のオブジェクト志向の、高レベルのシステム保存場所の役割をする仕様２１５を自動的にジェネレートする。好ましい実施例においては、使用される公式言語は、１９９５年１０月に、「Ｓｅｒｖｉｃｉｏ　ｄｅ　Ｐｕｂｌｉｃａｃｉｏｎｅｓ　ｄｅ　ｌａｓ　Ｕｎｉｖｅｒｓｉｄａｄ　Ｐｏｌｉｔｅｃｎｉｃａ　ｄｅ　Ｖａｌｅｎｃｉａ」 （法的保管番号：Ｖ−１２８５−１９９５）により刊行されたオスカー　パスター　ロペスとイシドロ　ラモス　サラバートによるＯＡＳＩＳ２．２版である。
【００９１】
キャプチャーされたシステム必要条件２００の公式仕様２１５への変換は、本発明の一側面の主な特徴である。概念モデリングのステップで導入されたそれぞれの情報には、公式言語概念として表される、公式対応相手がある。本発明の一実施例に関連するグラフィックなモデリング環境は、したがって公式仕様の上級グラフィック編集機能としてみなされても良い。
【００９２】
したがって、ＯＡＳＩＳ仕様言語の導入の表示をここで、本発明のこの実施例のより詳細な様子として提示する。表３は、自動的に概念モデルから得られた図書館利用者クラスの公式仕様２１５を表す。
【００９３】
［表３］
概念　スキーマ　図書館〔ＣＯＮＣＥＰＴＵＡＬ　ＳＣＨＥＭＡ　ｌｉｂｒａｒｙ〕
ドメイン　ｎａｔ，ｂｏｏｌ，　ｉｎｔ，　ｄａｔｅ，　ｓｔｒｉｎｇ
〔ｄｏｍａｉｎｓ　ｎａｔ，ｂｏｏｌ，　ｉｎｔ，　ｄａｔｅ，　ｓｔｒｉｎｇ〕
クラス　図書館利用者〔ｃｌａｓｓ　ｒｅａｄｅｒ〕
アイデンティフィケーション〔ｉｄｅｎｔｉｆｉｃａｔｉｏｎ〕
ｂｙ＿図書館利用者＿コード：（図書館利用者＿コード）
〔ｂｙ＿ｒｅａｄｅｒ＿ｃｏｄｅ：（ｒｅａｄｅｒ＿ｃｏｄｅ）；〕
コンスタント＿アトリビュート〔ｃｏｎｓｔａｎｔ＿ａｔｔｒｉｂｕｔｅｓ〕
歳：ストリング；〔ａｇｅ：Ｓｔｒｉｎｇ；〕
ヴァリアブル＿アトリビュート〔ｖａｒｉａｂｌｅ＿ａｔｔｒｉｂｕｔｅｓ〕
本＿カウント：Ｉｎｔ；〔ｂｏｏｋ＿ｃｏｕｎｔ：Ｉｎｔ；〕
私的＿イベント〔ｐｒｉｖａｔｅ＿ｅｖｅｎｔｓ〕
新しい＿図書館利用者（）新しい；〔ｎｅｗ＿ｒｅａｄｅｒ（）ｎｅｗ；〕
破壊＿図書館利用者（）破壊；〔ｄｅｓｔｒｏｙ＿ｒｅａｄｅｒ（）ｄｅｓｔｒｏｙ；〕
罰（）；〔ｐｕｎｉｓｈ（）；〕
共有＿イベント〔ｓｈａｒｅｄ＿ｅｖｅｎｔｓ〕
貸し出し（）ｗｉｔｈ本；〔ｌｏａｎ（）ｗｉｔｈ　ｂｏｏｋ；〕
制限〔ｃｏｎｓｔｒａｉｎｔｓ〕
スタチック本＿カウント＜１０；〔ｓｔａｔｉｃ　ｂｏｏｋ＿ｃｏｕｎｔ＜１０；〕
ヴァリュエーション〔ｖａｌｕａｔｉｏｎ〕
［貸し出し（）］本＿カウント＝本＿カウント＋１；〔［ｌｏａｎ（）］ｂｏｏｋ＿ｃｏｕｎｔ＝ｂｏｏｋ＿ｃｏｕｎｔ＋１；〕
［返却（）］本＿カウント＝本＿カウント−１；〔［ｒｅｔｕｒｎ（）］ｂｏｏｋ＿ｃｏｕｎｔ＝ｂｏｏｋ＿ｃｏｕｎｔ−１；〕
前提条件〔ｐｒｅｃｏｎｄｉｔｉｏｎｓ〕
図書館員：破壊＿図書館利用者（）もし〔ｌｉｂｒａｒｉａｎ：ｄｅｓｔｒｏｙ＿ｒｅａｄｅｒ（）ｉｆ〕
本＿ナンバー＝０；〔ｂｏｏｋ＿ｎｕｍｂｅｒ＝０；〕
トリガー〔ｔｒｉｇｇｅｒｓ〕
自分自身：：罰（）もし本＿カウント＝１０；〔Ｓｅｌｆ：：ｐｕｎｉｓｈ（）ｉｆ　ｂｏｏｋ＿ｃｏｕｎｔ＝１０；〕
プロセス〔ｐｒｏｃｅｓｓ〕
図書館利用者＝図書館員：新しい＿図書館利用者（）図書館利用者０；〔ｒｅａｄｅｒ＝ｌｉｂｒａｒｉａｎ：ｎｅｗ＿ｒｅａｄｅｒ（）ｒｅａｄｅｒ０；〕
図書館利用者０＝図書館員：破壊＿図書館利用者（）＋〔ｒｅａｄｅｒ０＝ｌｉｂｒａｒｉａｎ：ｄｅｓｔｒｏｙ＿ｒｅａｄｅｒ（）＋〕
貸し出し（）図書館利用者１；〔ｌｏａｎ（）ｒｅａｄｅｒ１；〕
図書館員１＝もし本＿カウント＝１返却（）図書館利用者０〔ｒｅａｄｅｒ１＝ｉｆ　ｂｏｏｋ＿ｃｏｕｎｔ＝１ｒｅｔｕｒｎ（）ｒｅａｄｅｒ０〕
＋（もし本＿カウント＞１返却（）〔＋（ｉｆ　ｂｏｏｋ＿ｃｏｕｎｔ＞１ｒｅｔｕｒｎ（））〕
＋もし本＿カウント＜１０貸し出し（））読者利用者１；〔＋ｉｆｂｏｏｋ＿ｃｏｕｎｔ＜１０ｌｏａｎ（））ｒｅａｄｅｒ１；〕
エンド＿クラス〔ｅｎｄ＿ｃｌａｓｓ〕
エンド　概念　スキーマ〔ＥＮＤ　ＣＯＮＣＥＰＴＵＡＬ　ＳＣＨＥＭＡ〕。
【００９４】
図書館利用者（ｒｅａｄｅｒ）クラス仕様の例の公式説明を統一する異なった部分の意味を説明する。ＯＡＳＩＳにおけるクラスは、「図書館利用者」というクラス名、クラスの例（オブジェクト）のアイデンティフィケーション機能、およびすべての例が分け合うタイプもしくはテンプレートによりなる。
【００９５】
アイデンティフィケーション機能ｂｙ＿図書館利用者＿コード（ｂｙ＿ｒｅａｄｅｒ＿ｃｏｄｅ）は、オブジェクトにより使用される名づけの仕組みを特徴づけ、すでに定義された種類もしくは、ユーザーによって定義された種類（ＯＡＳＩＳにおいてはすなわちドメインと呼ばれる）に属するサロゲートを生み出す。これらのドメインは、クラス定義にインポートされる。最も通常のものは、ｉｎｔ、ｎａｔ、ｒｅａｌ、ｂｏｏｌ、ｃｈａｒ、ｓｔｒｉｎｇ、およびｄａｔａと前もって定義される。これらはある特定の書式において、数、ブール値、文字、ストリングおよび日付を表す。新しいドメインは、対応する抽象データタイプを定義することにより、仕様に導入される。
【００９６】
タイプは、考慮されているクラスの可能なオブジェクトすべてが共有するすべての特性（構造と行動）を収集するテンプレートである。シンタックス面で、タイプは、ソートを含む署名、機能、アトリビュートと使用されるイベント、ダイナミックロジックにおいてはフォーミュラであるアクシオムのセット、ある特定のプロセス代数で解かれるソートプロセスのヴァリアブルを有する方程式のセットとしてのプロセスクエリーとして公式化することができる。これらのヴァリアブルが例示される場合、私たちは、インスタンス（オブジェクト）の可能な寿命を表す基礎項を有することになる。
【００９７】
クラス署名は、部分的なオーダー関係を有するソートのセットを含む。このソートのセットの中に、定義されるクラスに関連する対象となるソート（クラス名）もある。クラス署名はまた、（すでに定義された）ソートの定義の機能や、クラス仕様に暗黙に供給されるアイデンティティーに対するＡＤＴ（抽象的なデータタイプ）であるソートがアイデンティフィケーション機能に含まれる機能を含む機能のセットも含む。アイデンティフィケーション機能は、ある特定のクラスのオブジェクトが独自のアイデンティティーであることを保証するために、オブジェクトをアイデンティファイするある特定のソートの値を供給する。仕様目的のため、アイデンティフィケーションは、オブジェクトを確認するエイリアスとして使用される一つ以上のキーマップの宣言からなる導入された仕組みである。キーマップは、リレーショナルモデルの候補キー観念に類似する。ある特定のキー値から、これらのマップは、関連したオブジェクトアイデンティティーを返還する。キーマップは、コンスタントアトリビュートアトリビュート（の組）として宣言される。
【００９８】
クラス署名はまた、アトリビュートアトリビュートのセット（コンスタント、ヴァリアブルおよびデライブド）を含む。表３のコンスタント＿アトリビュート（ｃｏｎｓｔａｎｔ＿ａｔｔｒｉｂｕｔｅ）およびヴァリアブ＿アトリビュート（ｖａｌｕａｂｌｅ＿ａｔｔｒｉｂｕｔｅ）の項を参照。これらのアトリビュートはすべて、ドメインとしてのクラスのソートと、共同ドメインと考えられるアトリビュートに関連したある特定のソートを有する。
【００９９】
イベントのセットはまた、ドメインとしてのクラスのソートに加えイベント情報を表す追加のソート、および共同ドメインとしてのクラスのソート（関心のあるソート）とともに、クラス署名に含まれる（表３の私的イベントと共有イベントを参照）。このいわゆる関心のあるソートは、オブジェクトがプロセスとみなされた場合、全体的なソートプロセスのサブソートとしてみなされることができる。
【０１００】
それぞれのイベントの発生は、それをアクティベートできるエージェントにより名を付ける。このアクター観念を扱う時、もしエージェントＸがイベントａを開始することがＸ：ａと記載され、これがアクションと呼ばれると、Ｘは環境、もしくはシステムクラスのオブジェクトとなりえる。一つの実施例において、イベントは常にエージェントと関連している。イベントを定義する時、デザイナーはしたがって、どのエージェントがそれをアクティベートできるかを決定することを余儀なくされる。結果的に、アクションのセットＡはイベントの初期のセットから定義され、入手され、結び付けられる。
【０１０１】
このように、オブジェクトサービスのセットの観念は、その他のオブジェクトがその状態にアクセスできるようにするインターフェースとして表されることができる。オブジェクトサービスは、これらのサービスが提供されたか、あるいは要求されたかによって、イベント（サーバービュー）もしくはアクション（クライアントビュー）であり得る。アクションは一つのオブジェクトにより要求されたサービスとなり、それによりそのオブジェクトはそのほかのオブジェクトの状態（もしくはそれ自体の状態）を診察、もしくは変更できる。
【０１０２】
ＯＡＳＩＳにおいて、以下のような種類のダイナミックフォーミュラがある（クラスアキシオムのセット）。
【０１０３】
エヴァリュエーションはφ［ａ］φ‘の形式のフォーミュラであり、このセマンティックスは、基礎アクションａから可能な世界の間の一つの機能を与えるという一つのρ機能を定義することにより、得られる。他の言葉で言えば、いかなる有効な状態のオブジェクトに対しても可能な世界であり、ρ機能は、オブジェクト状態間のどの遷移が、アクションａの実行の後に有効であるかを決定する。この例において、以下のようなエヴァリュエーションがある。
［貸し出し（）］本＿カウント＝本＿カウント＋１；
〔［ｌｏａｎ（）］ｂｏｏｋ＿ｃｏｕｎｔ＝ｂｏｏｋ＿ｃｏｕｎｔ＋１；〕
［返却（）］本＿カウント＝本＿カウント−１；
〔［ｒｅｔｕｒｎ（）］ｂｏｏｋ＿ｃｏｕｎｔ＝ｂｏｏｋ＿ｃｏｕｎｔ−１；〕
このダイナミックなロジック環境の中で、フォーミュラφは、ｓ∈Ｗでエヴァリュエートされ、φ’はρ（ａ）でエヴァリュエートされる。ρ（ａ）は、考慮されているアクションのｓでの実行の後のオブジェクト状態によって表される世界である。
【０１０４】
デリベーションは、タイプφ ―＞ φ’のフォーミュラである。これは、ある特定のデリベーション条件（φで記述された）によってデライブしたドアトリビュートφ’を定義する。デリベーションは基本的に、このデライブしたエヴァリュエーションが特有の状態でなされたという点で、エヴァリュエーションフォ−ミュラとは異なる。
【０１０５】
インテグリティー制限は、すべての世界において満たされなければならないフォーミュラである。スタチックとダイナミックなインテグリティー制限は、区別されてもよい。スタチックなインテグリティー制限は、すべての可能な世界に対して定義されているものである。それらは、つねに有効でなければならない。一方、ダイナミックなインテグリティー制限は、異なった世界を関係づけるものである。それらは、対応する時間的ロジックオペレーターとともに、時間的ロジックの使用を必要とする。
【０１０６】
前提条件は、φがアクションａの実行以前の世界で有効でなければならいフォーミュラであるテンプレート、┐φ［ａ］ｆａｌｓｅを有するフォーミュラである。φが有効である世界のみにおいて、ａの発生を許可される。┐φが有効なら、ａの発生は、相続者としての状態を生み出さない。私たちは、図書館利用者仕様において、以下のような前提条件を持っている。
本＿ナンバー＝０［図書館員：破壊＿図書館利用者（）］ｆａｌｓｅ；
〔ｂｏｏｋ＿ｎｕｍｂｅｒ＝０［ｌｉｂｒａｒｉａｎ：ｄｅｓｔｒｏｙ＿ｒｅａｄｅｒ（）］ｆａｌｓｅ；］
あるいは、仕様目的のためにより便利な方法で、私たちは以下のように書くことができる。
図書館員：破壊＿図書館利用者（）もし本ナンバー＝０
〔ｌｉｂｒａｒｉａｎ：ｄｅｓｔｒｏｙ＿ｒｅａｄｅｒ（）　ｉｆ　ｂｏｏｋ　ｎｕｍｂｅｒ＝０〕
トリガーは、φ［┐ａ］ｆａｌｓｅのフォーミュラである。ここで┐ａはアクションの否定である。このフォーミュラは、ａは起こらず、そして何が起こるかは指定されていない、ということを意味する。もしφが有効で、ａ以外のアクションが発生すると、相続状態は存在しない。これは、ａの発生を強要するか、もしくは、システムがブロックされた状態にとどまる。たとえば、（オブジェクトインタラクションダイアグラム４２０が導入されたときに提示された、トリガーエキスプレッシブネスに基づき）目的地についてのトリガーされたサービス情報を含んだ、適切なダイナミックフォーミュラを使用し、私たちは、以下のことを宣言する。
本＿カウント＝１０［自分自身：：罰（）］ｆａｌｓｅ
〔ｂｏｏｋ＿ｃｏｕｎｔ＝１０［Ｓｅｌｆ：：ｐｕｎｉｓｈ（）］ｆａｌｓｅ〕
このトリガーは、仕様目的において、同等ではあるが、より便利な以下の方法で記載されても良い。
自分自身：：罰（）もし本＿カウント＝１０
〔Ｓｅｌｆ：：ｐｕｎｉｓｈ（）　ｉｆ　ｂｏｏｋ＿ｃｏｕｎｔ＝１０〕
したがって、トリガーは、φに記述された条件が有効なときアクティベートされるアクションである。前提条件とトリガーの主な違いは、ある特定の条件が満たされるとすぐにアクションをアクティベートさせるという義務がトリガー内にあるという事実に由来する。このように、トリガーは、モデル化されるオブジェクト社会における内部活動を導入できるようにする。
【０１０７】
これらのダイナミックフォーミュラどれにおいても、φとφ’は、考慮される状態もしくは世界において、オブジェクトのアトリビュートアトリビュートに付属された値のセットにより特徴ずけられる、ある特定のシステム状態を普通意味する、第一オーダーロジックにおけるしっかりと形成されたフォーミュラである。
【０１０８】
ＯＡＳＩＳにおいて、オブジェクトは、観測可能なプロセスと定義される。クラスのプロセス仕様は、私たちが、オブジェクトダイナミックを指定できるようにし、インスタンスの状態間のアクセス関係を決定する。プロセスは、アトミックアクションとしてイベントを使用することにより、組み立てられる。しかし、デザイナーはまた、トランザクションとよばれる実行ユニットにイベントを分類するという選択肢を有する。
トランザクションであるモレキュラーユニットは、二つの主な特性を有する。第一に、これらは、関与するイベントの実行に対して、オール−オア−ナッシングのポリシーに従う。トランザクション実行中にフェイリャーが起きると、結果として生じる状態は、初期のものとなる。第二に、これらは、中間状態の観察の不可能を示す。
【０１０９】
私たちは、表４の図書館利用者クラスのプロセス仕様を紹介し、このセクションを終える。
【０１１０】
［表４］
図書館利用者＝図書館員：新しい＿図書館利用者（）○図書館利用者＿０；
〔ｒｅａｄｅｒ＝ｌｉｂｒａｒｉａｎ：ｎｅｗ＿ｒｅａｄｅｒ（）○ｒｅａｄｅｒ＿０；〕
図書館利用者＿０＝図書館員：破壊＿図書館利用者（）＋貸し出し（）
〔ｒｅａｄｅｒ＿０＝ｌｉｂｒａｒｉａｎ：ｄｅｓｔｒｏｙ＿ｒｅａｄｅｒ（）＋ｌｏａｎ（）〕
○図書館利用者＿１；
〔○ｒｅａｄｅｒ＿１；〕
図書館＿１＝もし本＿カウント＝１返却（）○図書館＿（）
〔ｒｅａｄｅｒ＿１＝ｉｆ　ｂｏｏｋ＿ｃｏｕｎｔ＝１　ｒｅｔｕｒｎ（）○ｒｅａｄｅｒ＿（）〕
＋（もし本＿カウント＞１返却（）
〔＋（ｉｆ　ｂｏｏｋ＿ｃｏｕｎｔ＞１　ｒｅｔｕｒｎ（））
＋もし本＿カウント＜１０貸し出し（））○図書館利用者＿１；
〔＋ｉｆ　ｂｏｏｋ＿ｃｏｕｎｔ＜１０　ｌｏａｎ（）〕○ｒｅａｄｅｒ＿１；〕。
【０１１１】
プロセスの実行は、プロセスの明確に定義された代数における項として表される。したがって、可能なオブジェクトライフは、構成要素がトランザクションとイベントである項として宣言される。すべてのプロセスは、○（シーケンス）と＋（オルタナティブ）プロセスオペレーションを用いて、基礎プロセス代数ＢＰＡ＿δεにおける項に書き換えられることができる。これは、任意のインターリービングに基づき、同時発生の実施を提供する。
【０１１２】
本発明の一実施例による概念モデルと、それに関連したＯＡＳＩＳ公式概念を説明したので、概念モデルで導入されたグラフィックな情報を入力として受け止め、（ＯＡＳＩＳでは仕様である）テキストのシステムリプレゼンテーション２１５をジェネレートするマッピングの説明に入る。この公式仕様２１５は、実際ＣＡＳＥツール２１０を使用し得られれたもので、ソース概念モデルで表示されたように、初期必要条件に準拠する最終ソフトウェアー製品を得るためのソリッドシステムドキュメンテーションを構成する。
【０１１３】
前項で紹介されたクラス用テンプレートによると、概念パターンとそれらの対応するＯＡＳＩＳリプレゼンテーションのセット。
システムクラスは、オブジェクトモデルから得られる。それぞれのクラスにおいて、コンスタント、ヴァリアブル、およびデライブドアトリビュートのセット、私的イベントと共有のイベントとローカルトランザクションを含んだサービスのセット、クラス用に指定されたインテグリティー制限、およびデライブドアトリビュートに対応するデリベーションエキスプレションがある。複雑なクラス（供給されたアグリゲーションとインヘリタンスクラスオペレーターを使用して定義されたもの）に対して、オブジェクトモデルはまた、対応する複雑なアグリゲートされた、もしくは専門化されたクラス用に指定された、特定の特徴を供給する。
【０１１４】
オブジェクトモデルによって与えられた情報は基本的に、クラスのシグニチャーが正確に宣言される、システムクラスの骨組みを指定する。ダイナミックモデルは、状態遷移ダイアグラムとオブジェクトインタラクションダイアグラムの二種類を使用する。状態遷移ダイアグラムから、以下のものが取得される。イベント遷移に名を付けるフォーミュラであるエヴェント前提条件と、有効なオブジェクトライフのテンプレートが決定されるクラスのプロセス定義である。オブジェクトインタラクションダイアグラムからは、ＯＡＳＩＳクラス仕様の持つ他の２つの特徴が完成される。異なったオブジェクトに関係する、トリガー関係とグローバルトランザクションである。
【０１１５】
最後に、機能モデルは、エヴァリュエーションに関係したダイナミックフォーミュラを産出し、それでアトリビュートに対するイベントの効果を指定する。
【０１１６】
本発明の一実施例に基づき概念モデルに導入できる関連した情報のセットをかくして明確に定義すると、必要条件２００に対応する公式仕様２１５は、ＯＡＳＩＳのオブジェクト志向のモデルに基づき、システム説明が完全にキャプチャーされる正確なシステムリポジトリーを供給する。これは、実行プロセス（実行モデル）が、関与する情報が意味のある明確な開始点から行われること可能にする。なぜなら、ＯＡＳＩＳにおける公式な相手方をさらに有する概念モデルのパターンの限られたリストから、それらが由来するからである。
【０１１７】
（モデルヴァリデーション）
概念モデルから（Ｃ、Ｃ＋＋、あるいは、ジャバのような第三ジェネレーション言語ような）実施言語への、完全でロバストなアプリケーションの自動ソフトウェアー作成において、概念モデルは正しく、そして完全である必要がある。このセクションにおいて、「正しい」および「完全」という言葉は、自動ソフトウェアー作成プロセスシステムの特定の必要性によって、以下のような意味を持つ。
【０１１８】
概念モデルは、必要条件仕様に欠けている情報がない場合、「完全」である。つまり、概念モデルのすべての必要とされる特性が定義され、値を有する。
【０１１９】
概念モデルは、概念モデルで導入された情報が、シンタックス面でもセマンティックス面でも一貫しており明確である時、「正しい」。つまり、概念モデルで定義されるすべての特性は有効な値を有する。
【０１２０】
図２に戻ると、ヴァリデーター２２０は、オブジェクト志向の公式仕様言語（ＯＡＳＩＳのような）を高レベルデータリポジトリーとして使用し、概念モデルの公式仕様２１５を入力として受け取る。公式な視点からは、仕様２１５は明確に定義され断定的で動作可能のセマンティックスを使用しており、公式にダイナミックロジック論と同等であるため、ヴァリデートされたＯＡＳＩＳ仕様２１５は正しく、完全である。
【０１２１】
公式仕様２１５が有効であること、あるいは有効であることを調べることができることを公式環境が保証できるので、公式仕様言語は利益を得ている。公式言語は、言語エキスプレッシブネスを規定する文法を定義する。
【０１２２】
概念モデルのヴァリデーションには、二つの手順が使用される。完全さについては、ヴァリデーションの規則は、直接概念モデルのために集められたデータを調べることにより執行される。つまり、クラスは名前と、そのアイデンティファイヤーであるひとつのアトリビュート、および一つのサービスを持たなければならない。正確さについては、広範囲の公式言語文法が、概念モデルのすべてのフォーミュラのシンタックスと意味をヴァリデートするために執行される。
【０１２３】
（正確さ）
さらに具体的には、正確さについては、公式仕様言語のすべての構成要素が、存在しなければならず、有効な値を持たなけらばならない特性のセットを有する。特性のほとんどは、完全な定義と有効な値を持つために、厳密に執行される。しかしながら、ＣＡＳＥツール２１０は、モデル入力中の使いやすさのために、いくらか不完全である特性か、もしくは、無効な値を有する特性を残す。これらの特性は、ヴァリデーター２２０により、自動ソフトウェアー作成プロセスの前に、完全（そして正確）であることを調べられる。
【０１２４】
概念モデルをヴァリデートするために使用される要素を、次に説明する。それぞれの要素について、ヴァリデーションが厳密であるかどうか（たとえば、生成時に、すべての特性が存在し、有効な値を持たなければならない場合）、あるいはフレキシブルであるかどうか（たとえば、後にヴァリデーションが達成される）、が述べれる。特性には、オプションであるものもあるが、（たとえば、存在しないかもしれない）それらが定義された場合、それらはヴァリデートされなければならない。これらの構成要素は、表５にまとめられている。
【０１２５】
［表５］
2004506962.tif 000004
2004506962.tif 000005
2004506962.tif 000006
【０１２６】
（完全さ）
公式仕様言語における構成要素のいくつかの特性は、明確なシンタックスに従い精密形成されたフォーミュラである。したがって、概念モデルで導入されたすべてのフォーミュラが、シンタックス面でもセマンティックス面でも正しいことを確実にすることは、必須事項である。
【０１２７】
概念モデルで使用されるすべてのフォーミュラが、同じ目的を有するわけではない。したがって、いくつかのタイプのフォーミュラが存在する。フォーミュラのタイプにより、ある特定のオペレーターや項（コンスタント、クラスアトリビュート、ユーザーインターフェースなどのようなオペランド）が許るされる。概念モデルにおけるフォーミュラのすべてのタイプをヴァリデートするための、プロセスとルールのセットも文法の中にまた存在する。
【０１２８】
より具体的に、概念モデルは表６に示されるように、以下のようなタイプのフォーミュラを含む。
【０１２９】
［表６］
−　のデフォルト値計算
○　　クラスアトリビュート（コンスタントとヴァリアブル）
○　　サービスとトランザクションアーギュメント
−　インヘリタンス：専門化条件
−　スタチックとダイナミックインテグリティー制限
−　デリヴェーションとヴァリュエーション
○　　計算フォーミュラ（それぞれデライブドあるいはヴァリアブルアトリビュート）
○　　条件（オプション）
−　アクションのための前提条件（サービスもしくはトランザクション）
−　状態遷移ダイアグラムにおける遷移のためのコントロール条件
−　トリガーする条件
−　ローカルとグローバルトランザクションのフォーミュラ。
【０１３０】
これらのフォーミュラは、導入された時に、フォーミュラがシンタックス面でもセマンティックス面でも正しくなければ、デザイナーがインターアクティブテキストダイアログを去ることを防ぐことにより、ヴァリデートされる。
【０１３１】
一般に、すべてのフォーミュラは、シンタックス面で正しくなくてはならない。つまり、すべてのクラスはアイデンティフィケーション機能とクリエーションエベントを保持しなくてはならず、すべてのトリガーするフォーミュラはセマンティックス面で正しくなくてはならない。（たとえば、無関係のクラスへのセルフトリガーは禁止されている。）そして、アグリゲーションのすべての名前は、概念スキーマにおいてユニークでなければならない。もしこれらの条件が満たされなければ、エラーが発生する。
【０１３２】
一方、以下のことが当てはまらなければ、警告が発生する。すべてのクラスが破壊イベントを有する場合、すべてのデライブドアトリビュートが少なくともデリベーションフォーミュラを有する場合、すべてのサービスがそれを実行すると宣言されたエージェントを有する場合、そして、すべてのサービスで宣言されたアーギュメントが使用された場合である。
【０１３３】
ヴァリデーションプロセスもまた、デザイナーがひとつ以上のフォーミュラを無効化し得る変化をモデルに加えるたびに、発動される。前に述べたように、使い易さのために、ある特定のタイプのフォーミュラは正確でなくてもよいが、デザイナーが後に見直さなければならない。しかしながら、本発明の一実施例による自動ソフトウェアー作成プロセスは、すべてのフォーミュラが正しくないかぎり、コードのジェネレーションを続行しない。デザイナーが、概念モデル仕様に変更を導入するたびに、影響されるすべてのフォーミュラは検査される。結果として、以下のようなケースが起こりうる。
【０１３４】
１．影響されたフォーミュラの一つでも「厳密な」特性を参照した場合、変更は拒絶される。デザイナーに告知するためにエラーが表示する。
【０１３５】
２．影響されたフォーミュラすべてが、「厳密な」特性を参照しない場合、概念モデルへの変更は受諾される。アクションをとる前に、アクション確認ダイアログがディスプレイされる。
【０１３６】
３．影響されたフォーミュラがない場合、変更は直接行われる。ユーザーインターフェース情報をヴァリデートするために、ヴァリデーター２２０は以下のようにエラーを検査する。定義されたパターンは、不可欠の情報が欠けることなくしっかりと組み立てられていなければならない。フィルターに使用されるアトリビュートは、定義クラスから明らかでなければならない。オーダークライテリアで使用されるアトリビュートは、定義クラスから明らかでなければならない。フィルターのフォーミュラは、モデルで定義された用語を使用したしっかりと形成されたフォーミュラでなければならない。アクション選択パターンは、概念モデルで定義された最終アクションオブジェクトとして使用しなければならない。依存パターンのセットは末端となり、合流点を有さなければならない。警告は、次の条件下でジェネレートされてもよい。一つのパターンが定義されても使用（適用）されない場合、あるいはインスタンスパターンが複製された場合である。
【０１３７】
概念モデルからの自動ソフトウェアー作成は、概念モデルが正しく完全である必要がある。公式仕様言語の特徴と特性の適用は、概念モデルを効果的にヴァリデートすることを可能にする。ヴァリデーションプロセスは、公式仕様言語により定義された文法に基づき、そして部分的なヴァリデーションは、デザイナーが概念モデル仕様に変更を導入したときいつでも発動されるようになっている。自動ソフトウェア作成プロセス以前に、概念モデルは前提必須条件として、完全なヴァリデーションにおいてヴァリデートされる。
【０１３８】
（トランスレーション概観）
ヴァリデートされた公式仕様２１５は、特定の機械表現に関連した実施依存の特徴を扱う実行モデルのためのソースである。指定されたシステムを実施するため、ユーザーがシステムオブジェクトとインターアクトする方法が、事前に定義される。一実施例によると、図６で表されている実行テンプレートは、この行動を達成するために使用することができる。図６は、「実行モデル」と言及されているものに従うことにより、公式仕様を完全なアプリケーションにトランスレートする作業の高レベルなビューを図示するフローダイアグラムである。
【０１３９】
プロセスは、ユーザーがシステムへログインし、ユーザーの確認をすることにより開始する（ステップ６００）。ユーザーが見えるかアクティベートできるオブジェクトアトリビュートとサービスにより決定されるオブジェクトシステムビューが、供給される（ステップ６０２）。ユーザーが接続し、明確なオブジェクトシステムビューを得た後、ユーザーの世界ビューにおいて利用可能なサービスであればどれでもユーザーはアクティベートすることができる。これらのサービスの中に、観察（オブジェクトクエリー）、ローカルサービス、あるいは他のオブジェクトによりサーブされたトランザクションが存在する。
【０１４０】
どのサービスアクティベーションにも２つのステップがある。メッセージを作ること、そして、もし可能であればメッセージを実行することである。メッセージを作るには、ユーザーは、オブジェクトサーバーを示す情報を供給しなくてはならない（ステップ６０４）。オブジェクトサーバーの存在は、新しいというサービス以外のサービスを実行するための絶対条件である。続いてユーザーは、メッセージを作るために、（必要ならば）アクティベートされているサービスのサービスアーギュメントを導入する（ステップ６０６）。
【０１４１】
メッセージが一度送られると（ステップ６０８）、サービス実行は、サービスオブジェクトにおけるアクションの以下のシーケンスの発生により特徴付けられる。現在のオブジェクト状態で選ばれたサービスのための公式仕様に有効な遷移が存在していることを確かめるために、状態遷移を検査する（ステップ６１０）。サービスに関連した前提条件が適用しなければならないことを示すために、前提条件の達成を検査する。これらどのアクションも適用されない場合は、例外となり、メッセージは無視される。
【０１４２】
そうでなければ、プロセスは、ヴァリデーションを満たすことを続行し（ステップ６１４）、そこで誘導されたサービス変更が、関与するオブジェクト状態において行われる。サービス実行がオブジェクトを有効な状態に導くことを確かにするために、最終状態において、インテグリティー制限（ステップ６１６）が確かめられる。制限が適用しないと、例外となり、前回の状態の変更は無視される。状態の有効な変更の後、内部システム活動を表現する条件アクションルールのセットが確かめられる。これらのどれかが適用されると、指定されたサービスがトリガーされる（ステップ６１８）。
【０１４３】
したがって、図６に図示されたステップは、概念モデルで回収されたオブジェクトシステム仕様と、そのインペラティブなプログラミング環境における具体化が、機能的に等価であることを保証するために、プログラムの履行をガイドする。
【０１４４】
本発明の一実施例において、ＣＡＳＥツール２１０を補完し自動ソフトウェアー作成システムを構成するために、いくつかのトランスレーターを使用してもよい。たとえば、一つの履行例においてトランスレーターは、たとえばインターネットアプリケーションに適した３層構造に基づいてアプリケーションを作成する。特に、それぞれの層に対応して３つの異なったトランスレーターが発動する。システムロジックトランスレーター２３２、ユーザーインターフェーストランスレーター２３４、そしてデータベースジェネレーター２３６である。さらに、４つ目のトランスレーターであるドキュメンテーショントランスレーター２３８が使用される。これらの異なったトランスレーターは、作成されるアウトプットによって特徴付けられ、潜在的には同じアウトプットを有するが、それぞれのトランスレーターは、前述の高レベルリポジトリー２１５における情報内の特定のサブセットに焦点を定める。
【０１４５】
（システムロジックトランスレーション）
システムロジックトランスレーター２３２は、高レベルリポジトリーの情報から第３ジェネレーションプログラミング言語用のコードを自動的にジェネレートする。システムロジックトランスレーター２３２のアウトプットは、３層構造の真ん中の層に対応する。
【０１４６】
一実施例において、システムロジックトランスレーター２３２は、以下のことを扱うソースコードを作成する。（１）ユーザーインタフェイス機能との通信サブシステム、（２）固定層へのアクセスと固定層との通信、（３）固定層の内容を読むための標準クエリーサービス、そして（４）固定層とクライアント通信により作成されたエラー取り扱いである。
【０１４７】
通信サブシステムは、クライアントからのリクエストを受け取る、内部方法を発動する、リクエストした者に返答を返す、リクエストされたサービスを行うためにリクエストした者の存在と権限を確かめる、リクエストされたサーバーインスタンスの存在と有効性を確かめる、固定アトリビュートのために固定層にアクセスしながら、もしくはデライブドのアトリビュートの値を算出しながらメモリーにリクエストされたサーバーインスタンスのコピーを創設する、概念モデルにおける状態遷移ダイアグラム４００で指定されたように、リクエストされたサービスのための状態遷移をヴァリデートする、リクエストされたサービスの前提条件が適用することを確かめる、機能モデルで指定されたように、リクエストされたサービスに関係のあるすべてのヴァリュエーションを行う、リクエストされたサーバーインスタンスにより達成された新たな状態のための制限を確かめる、対応するアクションを実行するために、トリガー条件を検査する、リクエストされたサーバーインスタンスにおける変更を固定化する、といったことのために構成される。
【０１４８】
さらに、固定層へのアクセスと固定層との通信や、固定層の内容を読み取るためや、固定層により発生したエラーやクライアントとの通信を扱うためのサービス基準クエリーのために、コードがジェネレートされる。一つの履行例では、ジェネレートされたコードは、概念モデルのヴァリデートされた仕様２１５に基づき、テーブルや制限、そしてリレーショナルデーターベースシステム（ＲＤＢＭＳ）におけるデータモデルを定義するインデックスを創設したり、取り除いたりするためのスクリプティングを含んでもよい。
【０１４９】
一実施例において、コードジェネレーションの第一フェーズは、概念モデル２１５の情報の引き出しと、メモリー内のコードジェネレーション構造へのこの情報の保存である。３種類の要素が情報の引き出しをガイドする。クラス、グローバルトランザクション、そしてグローバル機能である。概念モデルのクラスから得られる関連のある情報には、名前、コンスタントアトリビュート（名前、タイプ、創設時にリクエストされた、そして初期化値フォーミュラ）、ヴァリアブルアトリビュート（名前、タイプ、創設時にリクエストされた、初期化値フォーミュラ、そしてＮＵＬＬ値アドミッタンス）、デライブドアトリビュート（名前、タイプ、そしてデリベーションフォーミュラ）、アイデンティフィケーション機能、イベント（名前、アーギュメント：名前とタイプ、そして前提条件フォーミュラ）、トランザクション（名前、タイプ、アーギュメント：名前とタイプ、前提条件フォーミュラ、そしてトランザクションフォーミュラ）、ヴァリュエーションフォーミュラ、状態遷移（初期状態、最終状態、サービス名、有効エージェント、そして遷移条件フォーミュラ）、スタチック制限フォーミュラ、ダイナミック制限フォーミュラ、トリガー条件フォーミュラ、アンセスタークラス（名前）、専門化クラス（名前、専門化条件フォーミュラ、前提条件再定義、そしてヴァリュエーション再定義）、アグレゲーション関係（関係するクラス、カーディナリティー、スタチックあるいはダイナミック、そして役名）、そしてポピュレーション選択パターン（フィルター：名前とフィルターヴァリアブル、オーダークライテリア）が含まれる。
【０１５０】
概念モデルのグローバルインタラクションから得られる、関係のある情報は、名前、アーギュメント（名前とタイプ）、そしてグローバルインタラクションフォーミュラを含む。概念モデルのグローバル機能から得られる、関連のある情報は、名前、リターンタイプ、そしてアーギュメント（名前とタイプ）を含む。
【０１５１】
ジェネレートされたコードは、概念モデルで見つけられた情報の主なユニット、つまりクラスに基づき、コンポーネントに基づいた構造に従う。概念モデルのそれぞれのクラスは、第一のアプローチにおいて、ソフトウェアーのコンポーネントをいくつか生み出す。たとえば、「サーバーコンポーネント」と呼ばれるコンポーネントは、対応するクラスのシグニチャーに存在するそれぞれのサービスに対しての一つの方法より成るインターフェースを有する。対応するクラスのポピュレーションをクエリーするために必要な方法より成るインターフェースを有するもう一つのコンポーネントは、「クエリーコンポーネント」と呼ばれる。特定の種類のエグゼキュティブコンポーネントは、概念モデルで定義されたグローバルインタラクションに関係するコンポーネントであり、そのインターフェースは、一つのグローバルインタラクションにつき、一つの方法で構成されている。
【０１５２】
これらのコンポーネントは、第二もしくは中間層が、第一もしくは表示層に提供する二つのアクセスポイントを構成する。サーバーコンポーネントは、サービスの実行に関係する表示層からリクエストを受け取り、クエリーコンポーネントは、固定層をクエリーすることに関係する表示層からリクエストを受け取る。これは、インターネットで展開するアプリーケーションに適切である。、なぜならば、コンテキストフリーで、スケーラブルで、トランザクション的な解決を可能なものとするからである。しかし、ジェネレートされるコンポーネントは、これだけではない。
【０１５３】
概念モデルのクラスに直接関わるもう一つのジェネレートされるコンポーネントは、「エグゼキュティブコンポーネント」と呼ばれるもので、それは、対応するクラスのシグニチャーでのそれぞれのサービスの解決あるいは実行の責任を担う。このコンポーネントは、その対応するサーバーコンポーネントからか、あるいはその他のエグゼキュティブコンポーネントからリクエストを受け取る。
【０１５４】
エグゼキュティブコンポーネントの主な目的は、クラスシグニチャーで提供されたサービスを解決することであるため、エキュゼキテイブコンポーネントがその他のコンポーネントに表示するインターフェースは、一つのサービスにつき一つの方法より成る。これらの方法のそれぞれは、本発明の一実施例に基づき、エグゼキューションモデルにより、構成される。
【０１５５】
言い換えれば、エグゼキュティブコンポーネントは、以下の作業の責任を担う。リクエストされたサーバーインスタンスの存在と有効性を確かめること、コンスタントとヴァリアブルアトリビュートの値を取り出すために、（前述の対応するクエリーコンポーネントで）固定層にアクセスして、メモリにリクエストされたサーバーインスタンスのコピーを創設すること、概念モデルにおける対応する状態遷移ダイアグラムで指定されたように、リクエストされたサービスの状態遷移とリクエストされたサーバーインスタンスの現状をヴァリデートすること、リクエストされたサービス前提条件の達成度を確かめること、概念モデルの機能モデルで指定されたように、サービスにより影響されたすべてのヴァリュエーションを行うことにより、インスタンスヴァリアブルアトリビュートの値を変更し、したがって、リクエストされたサーバーインスタンスの状態を変えること、スタチックとダイナミック制限を確かめることにで、リクエストされたサーバーインスタンスにより達成された新しい状態をヴァリデートすること、必要なときにどのアクションがトリガーされるべきかを決定するために、トリガー条件をテストすること、リクエストされたサーバーインスタンスのすべての固定アトリビュートのために、固定層と通信することである。加えて、クラスがサービスのエージェントであれば、インターフェースにもう一つの方法が加えられるが、その目的はリクエスト者の存在をヴァリデートすることである。
【０１５６】
もう一つの種類のエグゼキュティブコンポーネントは、概念モデルで定義されたグローバルインタラクションに関係するものであり、そのインターフェースは、一つのグローバルインタラクションにつき、一つの方法で構成されている。
【０１５７】
クラスがインヘリタンスヒエラルキーに属する場合、同じヒエラルキーのすべてのエグゼキュティブコンポーネントは、一つの特別なエグゼキュティブコンポーネントにまとめられる。しかしながら、ヒエラルキーにはなお、一つのクラスにつき一つのサーバーコンポーネントが存在する。
【０１５８】
概念モデルにおけるクラスが生み出すもう一つのコンポーネントは、「Ｔコンポーネント」と呼ばれるコンポーネントである。このコンポーネントは、対応するクラスのインスタンスのコンスタントおよびヴァリアブルアトリビュートのコピーとともに、そのデライブドアトリビュートの値を算出する方法を保存するために使用される。対応するクエリーコンポーネントは、コレクションを履行し、そのアイテムは、Ｔコンポーネントである。
【０１５９】
概念モデルにおけるクラスが生み出し得るもう一つのコンポーネントは、「Ｐコンポーネント」と呼ばれるコンポーネントである。このコンポーネントは、対応するクラスのインスタンスを創設する際にそのコンスタントとヴァリアブルアトリビュートを初期化するために必要な値か、あるいはクラスアイデンティフィケーションメカニズムを構成するアトリビュートの値だけを、メモリーに保存するために使用される。そのようなコンポーネントは、対応するクラスがアグレゲーション関係の複数値のコンポーネントであるときはいつでも現れる。
【０１６０】
概念モデルにおけるクラスが生み出し得るもう一つのコンポーネントは、「ＰＬコンポーネント」と呼ばれるコンポーネントである。このコンポーネントは、アイテムがＰコンポーネントであるコレクションを履行するとともに、コレクションからのアイテムを加えたり取り出すためや、コレクションにおけるアイテムの数を得るのに必要な方法を履行する。そのようなコンポーネントは、対応するクラスがアグレゲーション関係の複数値のコンポーネントであるときはいつでも現れる。
【０１６１】
概念モデルにおけるクラスが生み出し得るもう一つのコンポーネントは、「Ｃコンポーネント」と呼ばれるコンポーネントである。このコンポーネントは、対応するクラスのインスタンスを創設する際に、そのコンスタントとヴァリアブルのアトリビュートを初期化するために必要な値を、メモリーに保存することに使用される。そのようなコンポーネントは、対応するクラスが一時的あるいは永続的で、条件に基づいた専門化であるときはいつでも現れる。
【０１６２】
追加のコンポーネントは、ＣＣコンポーネント、エラーコンポーネント、トリガーコンポーネント、トリガーリストコンポーネント、インスタンスリストコンポーネント、条件コンポーネント、分離コンポーネント、そして結合コンポーネントを含む。
【０１６３】
ＣＣコンポーネントは、少なくとも一つの一時的、あるいは永続的な、条件に基づいた専門化が概念モデルに存在するときはいつでも現れる。ＣＣコンポーネントは、アイテムがＣコンポーネントであるコレクションを履行し、コレクションにアイテムを加えたり取り出したりする一組の方法（ジェネレートされた一つのＣコンポーネントにつき、一つの組）を履行し、そしてコレクションにおけるアイテムの数を得る方法を履行する。
【０１６４】
エラーコンポーネントは常に現れ、サービス実行の成功あるいは失敗についての情報を保存することに使用される。トリガーコンポーネントは、対応するアクションが後に実行されることができるように、満たされたトリガー条件についての情報を保存する。トリガーリストコンポーネントは、アイテムがトリガーコンポーネントであるコレクションを履行するとともに、アイテムをコレクションに加え、アイテムをコレクションから取り出し、最初のアイテムを取り出し、そしてコレクションにおけるアイテムの数を得るための方法を履行する。
【０１６５】
インスタンスリストコンポーネントは、アイテムが与えられたサービスの実行において作動するエグゼキュティブコンポーネントであるコレクションを履行する。アイテムをコレクションに加え、アイテムを取り出し、そしてコレクションにおけるアイテムの数を得るために使用される方法に加えて、このコンポーネントはそのアイデンティフィケーション機能によりインスタンスを探すために、かかるコレクションともう一つコレクションを空にするための方法を履行する。
【０１６６】
条件コンポーネント、分離コンポーネントそして結合コンポーネントは、常にジェネレートされ、固定層にクエリーするために使用され、分離の結合として構成されている複雑なブール表現の構造をサポートする。条件コンポーネントは、単純ブール条件、つまり二つのオペランドとオペレーター（＋、−、＊、／、＝、＜＞、＜、＜＝、＞＝、＞．．．）についての情報を保存する。分離コンポーネントは、アイテムが条件コンポーネント（つまり条件の分離）であるコレクションを履行するとともに、条件をコレクションに加えたり取り出したりする方法と、コレクションにおける条件の数を得る方法も履行する。結合コンポーネントは、アイテムが分離コンポーネント（つまり分離の結合）であるコレクションを履行するとともに、分離をコレクションに加えたり取り出したりする方法と、コレクションにおける分離の数を得る方法も履行する。
【０１６７】
さらに、二つのモジュールもまたジェネレートされる。アトリビュートと、ジェネレートされたコードから共有された方法を分類するためのグローバルモジュールと、概念モデルで定義されたすべてのグローバル機能のコードを分類するグローバル機能モジュールである。
【０１６８】
（トランスレーション戦略と構成）
一実施例に基づき、コードジェネレーションは、高レベルなリポジトリー２１５から引き出された情報により行われる。トランスレーションプロセスは、４つのフェーズに分けることができる。概念モデルのヴァリデーション（ヴァリデーター２２０により行われる）、対応するデータモデルの、リレーショナルデータベース管理システムへのトランスレーション（データベースジェネレーター２３６により行われる）、概念モデルからの情報の引き出しおよびこの情報のメモリー構造への保存、そして最後に、メモリーの保存された情報からのファイルのジェネレーション（たとえばメモリー構造内の情報を読み取り、ターゲットプログラミング言語でコードをジェネレートする）である。
【０１６９】
概念モデルのヴァリデーションは必須であるが、データモデルトランスレーションはオプションである。しかし、両方とも、コードジェネレーションに厳粛に関係した他の二つのフェーズに対する、前提条件として考えられることができる。トランスレーション構造は、概念モデルからの入力情報を保存するようにデザインされ、すべての構造は、ターゲットのプログラミング言語でソースコードをジェネレートするために、この情報を使用する方法を有する。
【０１７０】
これらのトランスレーション構造は、以下の物を含む。サーバーコンポーネントをジェネレートするために必要な情報を保存するクラス（サーバークラス）、グローバルインタラクションのためのサーバーコンポーネントをジェネレートするために必要な情報を保存するクラス（グローバルインタラクションサーバークラス）、エグゼキュティブコンポーネントをジェネレートするために必要な情報を保存するクラス（分析クラス）、グローバルインタラクションのためのエグゼキュティブコンポーネントをジェネレートするために必要な情報を保存するクラス（グローバルインタラクション分析クラス）、インヘリタンスヒエラルキーのためのエグゼキュティブコンポーネントをジェネレートするために必要な情報を保存するクラス（インヘリタンスヒエラルキー分析クラス）、クエリーコンポーネントをジェネレートするために必要な情報を保存するクラス（クエリークラス）、Ｔコンポーネントをジェネレートするために必要な情報を保存するクラス（Ｔクラス）、Ｃコンポーネントをジェネレートするために必要な情報を保存するクラス（Ｃクラス）、ＣＣコンポーネントをジェネレートするために必要な情報を保存するクラス（ＣＣクラス）、Ｐコンポーネントをジェネレートするために必要な情報を保存するクラス（Ｐクラス）、ＰＬコンポーネントをジェネレートするために必要な情報を保存するクラス（ＰＬクラス）、概念モデルにおけるすべてのクラスのすべてのサービスのためのアーギュメントについての情報を保存するクラス（アーギュメントリストクラス）、概念モデルにおけるすべてのクラスのアイデンティフィケーション機能についての情報を保存するクラス（分析クラスリストクラス）、エグゼキュティブコンポーネントにおいてのサービスを決定するために必要な方法をジェネレートするクラス（イベントクラス、共有イベントクラス、トランザクションクラス、インタラクションクラス）、エグゼキュティブコンポーネントとインヘリタンスヒエラルキーのためのエグゼキュティブコンポーネント両方におけるサービスを決定するのに必要な補助の方法をジェネレートするクラス（前提条件クラス、スタチック制限クラス、ダイナミック制限クラス、など）、クエリーとＴコンポーネントにおいて必要な方法をジェネレートするクラス（Ｔ方法クラスとＱ方法クラス）、インヘリタンス指定方法をジェネレートするクラス（インヘリタンス方法クラス）、そしてジェネレーションプロセスを監視するクラス（コードジェネレーションクラス）である。
【０１７１】
コードジェネレーションクラスは、コードをジェネレートするために必要なすべての情報を引き出し、それを適切な順序で行い、ジェネレートされたコードをファイルに書き込み、そしてコンポーネントに基づいた構造に基づき、それをきちんとファイルに整理する責任を担う。コードジェネレーションクラスは、メモリー内の前述のジェネレーション構造のリストを維持し、そしてそのメモリーには概念モデルより引き出された情報が保存され、それは後に、適切なファイルに書き込むために、これらのリストからループする。
【０１７２】
情報引出しプロセスは基本的に、必要なすべての情報を集めるために、概念モデルにおけるクラスを通る一連のループと、グローバルインタラクションを通る一つのループ、そして概念モデルのグローバル機能を通る一つのループから成る。
【０１７３】
コードジェネレーションプロセスの最後のフェーズは、ここで記述するコンポーネントに基づいた構造によるファイルへの書き込みを含む。このプロセスは、コンポーネントとそのアトリビュートと方法をジェネレートするために必要な情報を維持し、それぞれの要素のコードジェネレーション方法を呼び出す、前に説明されたインスタンスのリストを通してループすること、グローバルインタラクションエグゼキュティブコンポーネントをジェネレートすること、グローバルインタラクションサーバーコンポーネントをジェネレートすること、グローバル機能モジュールをジェネレートすること、そしてスタンダードコンポーネントをジェネレートすることより成る。
【０１７４】
それぞれのグローバル機能に対して、一つの方法がジェネレートされる。その方法は、そのグローバル機能と同じ名前と、一つのトランスレートされたリターンタイプを有する。その方法のそれぞれのアーギュメントは、グローバル機能の対応するアーギュメントと同じ名前と、一つのトランスレートされたタイプを有する。
【０１７５】
（
【ユーザーインターフェーストランスレーション】
一実施例において、ユーザーインターフェーストランスレーター２３４は、高レベルなリポジトリーにある情報から、ビジュアルベーシックやジャバのような高級プログラミング言語用のソースコードを自動的にジェネレートする。しかしながら、コードは、計算された言語のどれによってでもジェネレートされてよい。そのアウトプットは、三層構造の表示層に対応する。したがって、ユーザーインターフェーストランスレーター２３４は、ユーザーインターフェース機能を履行するコンポーネントのソースコードをアウトプットとして供給する。このコンポーネントは人の手を借りずに、自動的にジェネレートされる。ユーザーインターフェーストランスレーター２３４は、ヴァリデートされた概念モデル２１５を入力データとして使用し、そしてコンポーネントがデライブされた概念モデルに関係した等価の機能プロトタイプを履行する、第３ジェネレーション言語で書かれたソースコードをアウトプットデータとして提供する。
【０１７６】
本発明の一実施例において、ユーザーインターフェーストランスレーター２３４は、以下のものを行うソースコードを作成する。ビジネスコンポーネントにリクエストを送り、返答を受け取ることができる通信サブシステム、ユーザー確認のためのシステムへのログオン、そして特定の確認されたユーザーが利用できるサービスのメニューである。それぞれの利用できるサービス、フレーム、スクリーン、あるいはすべてのサービスアーギュメントのデータコレクションダイアログのために、ユーザーインターフェーストランスレーター２３４は、アーギュメントの初期値を設定し、導入されたデータ（タイプ、範囲、オブジェクト存在など）をヴァリデートし、そしてサーバーアクティベーションを呼びかけるコードをジェネレートする。加えて、ユーザーインターフェーストランスレーター２３４は、一つのクラスにおけるすべてのインスタンスのステータスとエラー取り扱いを一覧表にするスタンダードクエリーサービスのためのコードもジェネレートする。
【０１７７】
さらに、さらに広範囲でフレキシブルなユーザーインターフェース作業のためのコードがジェネレートされる。クエリーサービスフレーム、フォーム、あるいはスクリーンにおいて、ある特定のインスタンスが選ばれたとき、以下の機能が利用可能になる。それは、関係し選ばれたオブジェクトとの関係を通したナビゲーションである。このナビゲーションは、その関係するリンクに従い、関係するデーターアイテムの間をブラウズするのに使用される。したがって、結果として生じるコードは、インターネットアプリケーションに適している。追加機能は、選ばれたオブジェクトのサービスアクティベーション、フィルター（ポピュレーション選択）、ビュー（ステータス選択）、そしてソートのクライテリアを含む上級クエリーサービス、そして既知のサービスアーギュメントを記入するためのコンテクストの維持を含む。コンテキストの維持は、ユーザー設備である。コンテキストは、ユーザーが仕事をする環境に関連したデータである。このデータは、サービスアーギュメントのデフォルト値を供給するのに役立つ。
【０１７８】
その入力のために、ユーザーインターフェーストランスレーター２３４は、概念モデルの仕様２１５を読み取り、この種の情報をメモリー内の中間構造に保存する。ユーザーインターフェーストランスレーター２３４は、概念モデルが供給される入力媒体から独立している。このように、中間構造は、異なったデータソースからロードされることができる。このモデルは幾たびかイテレーションされ、公式仕様からトランスレーションプロセスのそれぞれのフェーズにおける、クラスや、アグレゲーション関係、インヘリタンス関係、エージェント関係、グローバルインタラクション、ユーザーの定義された機能、そしてインターフェースパターンについての情報などを含む、関係のある情報を引き出す。
【０１７９】
トランスレートされたアプリケーションは、最終ユーザーに提供されるユーザーインターフェースを含むフォームにより構成される。抽象的な意味で、フォームとは最終ユーザーとのインタラクションユニットである。フォームは、たとえば、ウィンドウズ環境のウィンドウズダイアログや、ウェッブプラットフォームでのＨＴＭＬページ、そしてジャバのアプレットなどのように、必要条件を満たすために、ターゲットの環境の能力に応じてトランスレートされる。
【０１８０】
トンランスレートされたアプリケーションは、システムにユーザー接続を供給する。ユーザー接続は、エージェントを確認するためにアクセスフォームを使用して解決される。加えて、トランスレートされたアプリケーションは、システムユーザービューを供給する。ユーザーは、ユーザーがローンチできるサービスにアクセスすることができなければならない。主要フォームは、この仕事を果たすようデザインされている。
ユーザーが実行できるそれぞれのサービスのために、トランスレートされたアプリケーションは、アクティベーションサービスフォームをジェネレートする。それぞれのクラス用には、トランスレートされたアプリケーションは、クエリー／選択フォームをジェネレートする。このフォームは、ユーザーがデータインスタンスにクエリーし、ある特定の条件を満たすインスタンスを探し、関連したインスタンスを観察し、そしてどのサービスが、その現在の状態におけるある特定のオブジェクトに対して、ローンチされることができるかを知ることができるようにする。それぞれのサービスに対し、トランスレートされたアプリケーションは、オブジェクト評価されたアーギュメントのために初期化値を提供する。初期データもまた、ユーザーによって作られたブラウズから得られた情報を管理することにより供給される。
【０１８１】
ユーザーは、アプリケーションとインターアクトする、異なったシナリオに遭遇する。これらのシナリオは、異なったタイプのフォームを定義するよう導く。次の項において、フォームのそれぞれの種類が説明される。
【０１８２】
概念モデル２１５において、いくつかのクラスは、サービスクラスのエージェントとして定義される（エージェントクラスと呼ばれる）。つまり、オブジェクトがサービスエージェントならば、そのサービスをリクエストすることを許可される。それぞれのエージェントオブジェクトは、サービスをリクエストしようとする前に、確認されヴァリデートされなければならない。アクセスフォームは、エージェントクラス（有効なエージェントクラスのリストより選ばれる）と、オブジェクトアイデンティファイヤー、そしてパスワードをリクエストする。回収されたデータは、システムにアクセスすることを許可された有効なエージェントオブジェクトが存在するかどうかを確かめるために使用される。
【０１８３】
アプリケーションメインフォームは、ユーザーが、実行を許されているサービスを見ることができるメニューを含む。ユーザーにより実現されるそれぞれのアクションに関連したソースコードは、自動的にジェネレートされる。
【０１８４】
少なくとも一つのエージェントのそれぞれのアクセス可能なサービスに対し、サービスフォームが一つジェネレートされる。これらのフォームは、ユーザーが供給しなくてはならないそれぞれのアーギュメントの導入フィールドを有する。このアーギュメントのフィールドは、データタイプ、サイズ、値の範囲、ＮＵＬＬなどをヴァリデートするための付属のコードを有する。オブジェクト評価されたフィールドは、情報をブラウズしそれをフィルターにかけるオブジェクトを探すための設備を供給する。コードは、この仕事を達成するためにジェネレートされる。
【０１８５】
それぞれのサービスアーギュメントは、この初期値を三つの異なった方法で取ることができる。
【０１８６】
１．初期値によって。概念モデルにおいて、デザイナーは、アトリビュートとアーギュメントのためにデフォルト値を供給することができる。そのような値が存在すると、その値を供給するために、コードがジェネレートされなければならない。
【０１８７】
２．コンテキストによって。コンテキスト情報（たとえば最近観察されたオブジェクトのリスト）は、アーギュメントを回収した同じタイプを有する、オブジェクト評価されたアーギュメントに、値を示唆することに役立つ。最近訪れたオブジェクトのリストの内から適切な値を探すための機能がジェネレートされる。
【０１８８】
３．依存パターンによって。概念モデルにおいて、システムデザイナーは依存パターンを定義することができる。状態回復パターンは、依存パターンの潜在的なセットでもある。両方の場合において、アーギュメント上の変化は、もう一方のパターンにおける値に影響を与えることができる。よって、ある特定のアーギュメント値は、このように最初に決定することができる。
【０１８９】
データヴァリデーションは、インターアクティブにユーザーに警告しながら、データ入力の後すぐと、システムロジックにデータを送る直前に起り得る。オブジェクト評価されたアーギュメントのヴァリデーションは、オブジェクトの存在の検査を必要とする。ヴァリデーションをサポートするため、それぞれのサービスアーギュメントに対し一つの機能がジェネレートされる。この機能は、リクエストをシステムロジックに送る前に発動される。
【０１９０】
ユーザーがサービスの実行をリクエストするとき、サービスアーギュメントがヴァリデートされる。サービスアーギュメントが有効ならば、システムロジックは、そのサービスを達成するために発動される。システムロジックを発動するために作られたメッセージは、アーギュメントをソートするために公式オーダーを使用する。サービスを実行した後、ユーザーは、サービスが成功したかどうか告知される。このトランザクションのアプローチは、インターネットアプリケーションにとって理想的である。したがって、アーギュメントをヴァリデートするコードと、公式オーダーにおける必要なアーギュメントとともにシステムロジックを発動するコードが、ジェネレートされる。さらに、可能なエラーは、ユーザーに告知するために返還される。
【０１９１】
クエリー／選択フォームは、オブジェクト（フィルターによって制限することができる）のクエリーとオブジェクトの選択を許可する。オブジェクトが選択されたとき、ユーザーは、そのオブジェクトに関係するその他のデータアイテムにブラウズすることができる。同じように、ユーザーは、その選択されたオブジェクトのサービスをローンチすることができる。
【０１９２】
これらのクエリー／選択フォームは、フィルターを表示するグラフィックアイテムを含む。ビジュアルコンポーネントを、クラスのポピュレーションをフィルターするために使用する。フィルターは、ヴァリアブルを含んでいてもよい。そのような場合、ヴァリアブルのためのフィールドが、フィルターの条件を定めるために、ユーザーにリクエストされる。たとえば、車をカラー別、タイプ別、そしてモデル別に見つける、などである。
【０１９３】
これらのクエリー／選択フォームはまた、オブジェクトを表すためのビジュアルコンポーネントも含む。このコンポーネントの中に、フィルター条件（あるいはフィルターが定義されていない場合は、すべてのクラスポピュレーション）を満たすオブジェクトが現れる。このコンポーネントにおいてディスプレイされるアトリビュートは、ディスプレイセットによって設定される。
【０１９４】
これらのクエリー／選択フォームはさらに、サービスをローンチするためのビジュアルコンポーネントを含む。たとえば車を例にすると、ユーザーはその車を借りたり、返したり、あるいは売却したりするためのサービスをローンチすることができる。この仕事は、どのオブジェクトの、どのサービスをローンチするかを決定する機能によって達成される。対応するサービスフォームは、それぞれの明らかにされたサービスに対し発動される。これらのクエリー／選択フォームはまた、ブラウジングを開始するためのコンポーネントを含む。たとえば車を例にすると、ユーザーはそのドライバー、そのドライバーの息子などを見ることができる。ユーザーが、ナビゲートするとき（オブジェクトからのリンクを辿り）、新しいクエリー／選択フォームがディスプレイされる。前回のコンポーネントと同じように、そこには、ユーザーがオブジェクトをブラウズする際にディスプレイされる次のフォームを発動するコードが存在する。ナビゲーションによりクエリー／選択フォームに到達したとき、フォームは、その最初のオブジェクトに関係したデータだけをディスプレイするために、前のオブジェクトについての情報を受け取る。
【０１９５】
アプリケーションには、訪問されたオブジェクトと、ユーザーによって辿られたナビゲーション通路が保存される。この情報はコンテキスト情報と名づけられる。ユーザーが、クエリー／選択フォーム間のデータをブラウズする際、辿られた通路は保存される。最後に、ユーザーがサービスを発動しようと試み、サービスフォームが必要とされると、アプリケーションは、サービスフォームへの追加入力として、このコンテキストの情報を供給する。したがって、サービスフォームは、オブジェクト評価のアーギュメントに初期値を供給するために、このデータを使用する。
【０１９６】
（ユーザーインターフェーストランスレーター構造）
入力として使用された概念モデル２１５を使用して、ユーザーインターフェーストランスレーター２３４は、クエリーＡＰＩあるいは、その他の入力ソースを使用して、メモリー構造からの情報、関係のあるデータベースを引き出すことができる。メモリー内の中間構造は、ユーザーインターフェースコンポーネントをトランスレートするために関連のある概念モデルのデータで満たされている。中間構造は、指定の概念モデルのクラスやサービス、そしてアトリビュートのために、クエリーすることができる概念モデルスキーマで定義されたものへと一つの構造に従う。
【０１９７】
データが中間構造にロードされる際、真のトランスレーションのフェーズが始まる。ジェネレートされたアプリケーションのソースコードファイルの中において、二つのタイプのファイルを区別することができる。一つのファイルは、固定された内容が入ったファイルのセットである。これらのファイルは、常に同じように作成され、広く使用される構造、あるいは補助機能に対応する。これらのファイルは、これらを創設するためにバイトストリームをトランスレーターから最終ファイルへ直接落とすことにより、ジェネレートされる。その他のファイルは、処理されている概念モデルに大いに依存する。したがって、これらのファイルはしっかりと定義された構造を有するが（前の項で詳しく述べれている）、それらは処理されたモデルによって決まる可変な部分を有する。ユーザーインターフェーストランスレーター２３４は概念モデルをイテレーションし、関連するデータを引き出し、これらの可変な部分をジェネレートする。
【０１９８】
ユーザーインターフェーストランスレーター２３４のトランスレーションプロセスは、以下の作業を含む。
【０１９９】
１．固定されたファイルをジェネレートする。たとえば、ヘッダー、定義、コンスタント、そしてそのそれぞれのファイルへの補助機能など。
【０２００】
２．アプリケーションにより、補助ウエッジ（コントロールあるいはジャバビーン）をジェネレートする。
【０２０１】
３．それぞれのクラスに対し、クエリー／選択フォーム、インスタンス選択コンポーネント、専門化コンポーネント（クラスが、その他のクラスから専門化されると、追加の初期化が必要とされる。）をジェネレートする。それぞれのサービスクラスに対し、サービスフォームもジェネレートする。
【０２０２】
４．アクセスフォームをジェネレートする（アイデンティフィケーション）。
【０２０３】
５．メニューアプリケーションを含むメインフォームをジェネレートする。
【０２０４】
６．システムロジックサーバーと連絡を取るための通信機能をジェネレートする。これらの機能は、プロトタイプにおいて利用可能なサービスの開始をインキャプシュレートする。
【０２０５】
アクセスフォームは、エージェントクラスのリスト（このリストから、ユーザーは一つ選択する）、ユーザーが前回に選択されたクラスに属する有効なオブジェクトインスタンスのためのＯＩＤを供給するフィールド、そしてパスワードのためのフィールドを含む、小さなダイアログボックスである。このフォームは主に固定された方法でジェネレートされる。それぞれのモデルによって異なる唯一の部分は、前述のエージェントクラスのリストである。モデルクラスのリストをイテレーションし、どのクラスがエージェントであるかを検査することにより、そのようなエージェントクラスのリストを獲得することができる。
【０２０６】
アプリケーションの機能性にアクセスを供給するために、サービスは、メニューバー（ビジュアルベーシッククライアント）、ＨＴＴＰページ（ウェッブクライアント）、あるいはブラウジングを許可するその他の構造に変換されるために、アクセスヒエラルキーに配列される。デフォルトにより、ヒエラルキーは、概念モデルにおけるクラスとサービスをイテレーションすることにより作られる。ヒエラルキーは、アプリケーションへのアクセスツリーとして見ることができる。それぞれのクラスのために、クラスエイリアスが付けられた一つのツリーアイテムが作られる。それぞれの内臓されたアイテムのために、このモードは子孫アイテムとして、以下のアイテムを有する。クエリーフォームにアクセスするための「クエリー」と名づけられたアイテム、現在のクラスで定義されサービスエイリアスを付けられたそれぞれのサービスのためのアイテム、そしてその他のクラスとのインヘリタンス関係を持つ場合は、サブクラスエイリアスを付けらたそれぞれの直接のサブクラスのために、一つのアイテムが作られる。帰納的に、インヘリタンスツリーが完全に調査されるまで、同じアルゴリズムが適用される。
【０２０７】
サービスフォームは、概念モデルから引き出された以下の入力データを必要とする。ジェネレートするサービス、サービスクラス、アーギュメントリスト、そしてアーギュメントとリンクされたインターフェースパターンである。それぞれのサービスのために、グラフィックな部分と機能的な部分とを含むフォームがジェネレートされる。グラフィックな部分は、ユーザーに聞かなくてはならないそれぞれのアーギュメントに付属したウエッジ一つと、サービス開始を許可したりキャンセルしたりする一対のウエッジを含む。機能的な部分は、以前のウエッジのためのイベントドライバーを履行し、デフォルト値でこれらのウエッジの特性を初期化し、導入された値をヴァリデートし、そしてシステムロジックコンポーネントにおけるサービスを発動するためのコードを含む。
【０２０８】
次は、サービスフォームをどのようにジェネレートするかの詳細な説明である。最初に、二つのアーギュメントリストが得られる。一つ目は、サービス宣言で定義されたアーギュメントに対応する（ＦＬ、公式リスト）。このリストにおいて、アーギュメントは、その公式宣言順序によってソートされる。二つ目は、表示順序によってソートされた、同じアーギュメントを含む（ＰＬ、表示リスト）。二つの順序は共に、概念モデルで指定される。
【０２０９】
公式リストを通してそれぞれのアーギュメントのためにイテレーションを行う。ユーザーにリクエストされなければならないそれぞれのアーギュメントのためのウエッジを一つ作り、タイプ、サイズ、ＮＵＬＬでも良い、導入パターン、定義された選択パターン、あるいはポピュレーション選択パターンのような、アーギュメントに関係した特性を設定する。
ウエッジは、オーケーコマンドやりキャンセルコマンドのために加えられ、そしてウエッジのグラフィックな部分は重複しないように整理される。一履行において、フォームは縦がｎ欄で横がｎ列のロジカルな格子に分けられ、ウエッジを便利に整理するために左から右、上から下まで位置を割り当てる。ロジカルな位置は、ターゲット言語において、物理的な位置にトランスレートされ、フォームの右下の隅にアクションコマンドが再整理する。最後に、このフォームは、そこで含まれるデータのサイズに調整するために、再度寸法合わせをされる。
【０２１０】
アウトプットのために、フォームの標準ヘッダーは、ファイルに落とされる。このステップは、選択されたターゲット言語に依存する。それから、フォームのグラフィックな部分は、べーシックフォーム特性の定義、それぞれのウエッジの定義、そしてウエッジのアクションを含み、ファイルに落される。
【０２１１】
最後に、このフォームに付属するソースコードは、トランスレートされ、落される。このプロセスには、イベントの開閉や、リソースを割り当てたり取り除いたりするためのコードを作成したりなど、フォームにおけるイベントを管理するための一般的な機能をトランスレートすることを含む。また、ステータス回復パターンとウエッジ間の依存性を取り扱う機能もトランスレートされる。サービスに付属したステータス回復パターンやサービスで定義された可能性のある依存性パターンにより、アーギュメント値を変更するコードと、そのような依存性をトリガーするコードをジェネレートしなければならない。ヴァリデーションコードもまた、トランスレートされる。ウエッジに集められた値が正しいかを検査するためのヴァリデーション方法が存在する。最後に、システムロジックサービスに対し、発動を呼びかけるサービスをトランスレートする機能がジェネレートされる。形成されたこの機能は、サービスが実行されるシステムロジックオブジェクトについての参照、システムロジックにおけるサービスを履行する方法の発動、そしてウエッジを通してユーザーから供給された値から構成された、そのような機能に必要なアーギュメントを含む。
【０２１２】
クエリー／選択フォームをジェネレートするために、以下の概念モデルの情報が必要とされる。クラスとその特性（エイリアス）、そしてそのクラスのために定義されたポピュレーション選択インターフェースパターンのリストである。それぞれのパターンは、ディスプレイセット、フィルター、そしてソート基準を含む。定義されたヴィジュアライゼーションセットが無い場合、クラスに属するアトリビュートのリストを推測する。クラスにポピュレーション選択パターンが欠けていると、以下のデフォルトバリューが仮定される。クラスで定義されたすべてのアトリビュートは、ディスプレイセットの一部とみなされ、フィルター（この場合、クラスの全ポピュレーションは、返還される）とソート基準のどちらも付属されない。
【０２１３】
クエリー／選択フォームをジェネレートするには、クラスの関係についての情報も必要とされる。すべてのクラスに対し、この情報に基づきフォームがジェネレートされ、そのフォームは、クラスのディスプレイセットの表の表示と、ポピュレーションに対するサーチを制限できるようにする、グループ化された一組のフィルター、そして最初のものに関係するクラスと、クラスのインスタンスに対してローンチされる利用可能なサービスへのナビゲーションリンクを含むポップアップメニューを含む。
【０２１４】
前に説明された、ジェネレートされたソフトウェアコンポーネントは、プロトタイプが引き出された概念モデルに対応するプロトタイプをヴァリデートし実行するために必要なすべての機能を含む、ユーザーインターフェースクライアント機能を供給する。コンポーネントのアプリケーションは、プロトタイピング、新しい必要条件をキャプチャーする前の概念モデルのユーザーヴァリデーション、モデルが忠実に必要条件を反映しているかを確かめる分析担当による概念モデルをヴァリデートするためのテスト、そして最終のアプリケーション作成である。必要条件のキャプチャーのプロセスが一度完成すれば、ジェネレートされたコンポーネントは、機能的に完全で、エルゴノミックなユーザーインターフェースを履行する最終バージョンとみなすことができる。コンポーネントは殆ど労力なくして、ユーザーの希望に沿ってアプリケーションをカスタマイズするために編集することができる。
【０２１５】
（データモデルトランスレーション）
一実施例においては、データベースジェネレーター２３６は、高レベルのリポジトリー２１５のヴァリデートされた仕様に基づき、リレーショナルデータベース管理システム（ＲＤＢＭＳ）におけるデータモデルを自動的に定義する。しかしながら、フラットファイルや、一連のファイル、あるいはオブジェクト志向のデータベースなど、その他の形態の永続的な保存を使用してもよい。データベースジェネレーター２３６のアウトプットは、複数層の構造における固定層に該当する。
【０２１６】
ある特定の概念モデルについての、高レベルのリポジトリーにある情報から、テーブルや制限（第一キーと外部キー）、そしてインデックスを創設したり削除したりするために、スクリプトがジェネレートされる。スクリプトは、前記のデータモデルを効果的に創設するために、リレーショナルデータベース管理システムにおいて、オプションとして実行することができる。
【０２１７】
リレーショナルデータベースの視点で、データはテーブルに、テーブル間の関係と共に保存される。しかし、オブジェクト志向のプログラミングの視点では、データはオブジェクトヒエラルキーに保存される。
本発明の一実施例による自動ソフトウェア作成システムはオブジェクト志向の方法論に基づくが、ジェネレートされたアプリケーションにより管理されるデータを、永久的に保存するための物理的なデータ保存システムを見つける必要がある。リレーショナルデータべースはデータを保存するための産業基準方法であるので好まれる。結果的に、オブジェクトの代わりにテーブルを使用することが好まれる。しかしながら、本発明の一実施例により作成されたもののように、多くのオブジェクト志向のアプリケーションは、トランスレーションプロセスに続いて、オブジェクトのスタチックな面をテーブルに保存することができるため、リレーショナルモデルと互換性を持つことができる。
【０２１８】
ジェネレートされたデータモデルは、一組のテーブルと、対応する関係と、そして基本キーと外部キーに対する制限とインデックスから成る。ジェネレートされたデータモデルは、クラスの仕様で定義されたアトリビュートと、インスタンスがエージェントならばインスタンスの状態や役割のような、その他のクラスインスタンスの特性とを有するシステムデータを反映する。
【０２１９】
高レベルのリポジトリー２１５から集められた、対応するデータモデルを作成するために必要とされる情報は、クラスに集中し、そして名前、コンスタントアトリビュート（新しいか、あるいはインヘリットしたもの）、ヴァリアブルアトリビュート（新しいか、あるいはインヘリットしたもの）、アイデンティフィケーション機能、インヘリットしたアイデンティフィケーション機能、アグリゲーション関係（新しいか、あるいはインヘリットしたもの）、そしてエージェント情報を含む。
【０２２０】
望ましくは、ジェネレートされたスクリプトは、標準：ＡＮＳＩ　ＳＱＬ９２に従う。この事実は、ジェネレートされたデータモデルは、ＡＮＳＩ　ＳＱＬ９２に基づいたデータベース管理システムであり、特に最も良く知られたリレーショナルデータベース管理システムであれば、どれでも適応することができるということを意味する。
【０２２１】
データモデルを得るためのプロセスは、以下のようなステップを踏む。概念モデルのそれぞれの基本クラスに対し、選ばれたリレーショナルデータベースに、テーブルが創設される。クラス仕様におけるそれぞれのコンスタントあるいはヴァリアブルアトリビュートに対し、クラスに対応するテーブルにおけるフィールドが創設される。フィールドデータタイプは、ターゲットのリレーショナルデータベースにトランスレートされた、概念モデルアトリビュートデータタイプに依存する。導出されたアトリビュートは、それらの値がジェネレートされたサーバーコードの特別な方法によりリクエストされた際に計算されるため、データベースには保存されない。
【０２２２】
基本キーは、概念モデルでアイデンティフィケーションアトリビュートであると示されたアトリビュートによって決定される。したがって、これらのアトリビュートに対応するテーブルフィールドは、テーブルの基本キーを構成する。特別な場合として、専門化されたクラスに対応するテーブルは、新しいアトリビュートを表すフィールドに加えて、アトリビュートの先祖クラスを表すテーブルの基本キーを構成するアトリビュートに対応するフィールドを有する。専門化されたクラスがそれ自身のアイデンティフィケーション機能を有さなければ、先祖クラスからコピーされたこれらのフィールドは、専門化されたテービルの基本キーを構成する。同時に、それらのフィールドは、親クラステーブルに対し、外部キーを構成する。一方、専門化されたクラスがそれ自身のアイデンティフィケーション機能を有する場合、これらのフィールドは、親クラステーブルに対する外部キーのみを構成する。
【０２２３】
アグリゲーションの場合は、より多くのディメンションを有するため、より複雑である。アグリゲーション関係のディメンションはそのカーディナリティを決定し、カーディナリティはデータベースでの表現を決定する。その関係が、両方の意味で複数値（Ｍに設定された最大カーディナリティ）ならば、新しいテーブルがこのアグリゲーション関係を表すために加えられる。このテーブルは関係するテーブルの基本キーを構成するそれぞれに対して一つのフィールドを持つ。これらすべてのフィールドのセットは基本キーを成し、フィールドは個々に、それぞれの関係するテーブルの基本キーに由来し、それぞれの関係するテーブルの外部キーを構成する。
【０２２４】
その関係が、一つの意味で単一の値（１に設定された最大カーディナリティ）ならば、一方の一つのみのインスタンスと関係するクラスが、その一方の基本のフィールドをコピーする。これらのフィールドは、関係するクラステーブルへの外部キーを構成する。
【０２２５】
その関係が両方の意味で単一の値ならば、どのテーブルも、もう一方への外部キーを有することができる。この場合採用されるオプションは、アグリゲーションクラスが、コンポーネントクラスを参照することである。最小カーディナリティに関して、最小カーディナリティが０ならば、その対応するフィールドは、ＮＵＬＬを採用する。他の状態では、採用しない。アイデンティフィケーション依存が二つのクラスの間に存在すると、依存しないクラスの基本キーのフィールドが、依存するクラスに対応するテーブルにコピーされる。それらはその基本キーの一部となり、依存していないクラスのテーブルへの外部キーとなる。
【０２２６】
サーチを最適化し応答時間を削減するために、インデックスをジェネレートしてもよい。外部キーもサーチインデックスになるように、それぞれの外部キーに対しインデックスがジェネレートされる。
【０２２７】
ここまで、オブジェクトのスタチックな面を取り扱ってきたが、ダイナミックな面もまたいくらか検討される必要がある。サービスのアトリビュートの値がサービスの状態を特徴付けるため、サービスが起こるたびにオブジェクトの状態が変化することから、サービスの発生はオブジェクトのライフにおける進化を特徴付ける。状態遷移ダイアグラムは、オブジェクトの有効なライフを決定する。状態遷移を監視するために、新しいフィールドがクラスに対応するそれぞれのテーブルに加えられ、オブジェクトがある特定の瞬間にある状態遷移ダイアグラムにおける状態の名前を保存する。
【０２２８】
ジェネレートされたアプリケーションは、システムにログオンしているエージェントに、アイデンティフィケーションとパスワードをリクエストすることにより、ユーザー確認を行っても良い。新しいフィールドが、システムの中のサービスのエージェントであるクラスに対応するテーブルへ加えられ、そのエージェントのパスワードを保存する。
【０２２９】
（ドキュメンテーショントランスレーション）
ＣＡＳＥツール２１０は、システムのドキュメンテーションをジェネレートするために使用することができる追加情報を、分析時に導入できるようにする。したがって、ドキュメンテーションジェネレーター２３８は、公式仕様、完全な概念モデル詳細ドキュメンテーション、ユーザーへのヘルプ、そしてその他を含む一組のドキュメントを、高レベルのリポジトリー２１５の情報から自動的に作成する。
【０２３０】
それらの異なった性質のため、公式システム仕様のためには特別のジェネレーションプロセスが存在する。残りの作成されたドキュメントは、一般的なデータ処理に拠る。この処理では、同じドキュメントを異なった書式で得ることができ、どんな新しいタイプのドキュメントでも定義することができる。
【０２３１】
ＣＡＳＥツールは、前回に集められた概念モデルから自動的にジェネレートされることができる複数のドキュメントを供給しなければならない。ドキュメンテーションジェネレーター２３８は、概念モデルに対して行われる情報リクエストやクエリーのための要求に答える。ドキュメンテーションジェネレーター２３８は、企画を適切にドキュメントするために、クエリー、特定の文書、あるいはしっかりと形成されたドキュメントのジェネレーションを可能にする。
【０２３２】
好ましい実施例において、概念モデルの完全なジェネレーションは、問題の分析に関係する概念モデルの部分を成すＯＡＳＩＳシンタックスのＡＳＣＩＩ書式でジェネレートされるが、表示モデルインターフェースパターンはこのシンタックスに含まれていない。
【０２３３】
ドキュメントジェネレーターは、デフォルトでは、一般ドキュメント、サービスドキュメント、そしてヘルプドキュメントを供給する。一般ドキュメントは、通常言語での仕様の説明を含む。サービスドキュメントは、クラスとサービスの詳細な説明を含む。ヘルプドキュメントは、ジェネレートされたプロトタイプのためのオンラインヘルプを含む。
【０２３４】
ドキュメンテーションジェネレーターは、ターゲット言語として、認識された幾つかの標準書式をドキュメンテーションに使用する。それらは、ＡＳＣＩＩ、プレーンテキスト、複数のドキュメントを有するナビゲーションのＨＴＭＬ、一つのドキュメントを有するナビゲーションのＨＴＭＬ、ＬａＴｅＸ、そしてリッチテキストフォーマット（ＲＴＦ）である。
【０２３５】
このドキュメンテーションシステムはスケーラブルで、新しい種類のドキュメントやターゲット言語を追加するために拡張することができる。新しいターゲット言語を加えることにより、すべての定義されたドキュメントが、この新しい言語でジェネレートされることができるようにする。同じように、新しいドキュメントタイプを加えることにより、支援されるどのターゲット言語ででもジェネレートできる。
【０２３６】
公式仕様を作成するために、一つのプロセスが情報構造上をイテレーションし、公式言語における対応するテキストストリングを一つのファイルに書き込む。内部プロセスにおいて、構造上のイテレーションは、（１）仕様ヘッダーを書き込む、（２）説明されるために選ばれるすべてのクラスに対し、その公式テンプレート（アトリビュート、イベント、デリベーション、制限、前提条件、トリガー、そしてプロセス）を書き込む、（３）すべてのグローバルトランザクションに対し、その宣言と公式定義を書き込む、（４）エンド仕様書を書き込む、というように詳細であることができる。
【０２３７】
ドキュメントは、中間ブロック言語（ＩＢＬ）でジェネレートされる。そのような言語では、ドキュメントはドキュメントタイプの一つのブロックであり、ｎ個の子ブロックを含む。帰納的に自制関係とブロック分類を固定することにより、ドキュメントは、ブロックの構造に基づき定義することができる。ブロックは、以下の特性を含む構造である。名前、カテゴリー、ブロックタイプ、ブロックテキスト、そして含まれるブロックのリストである。
【０２３８】
ジェネレーションは、ドキュメントにより固定された順序に従い、概念モデルをイテレーションするループを履行するアルゴリズムによりサポートされる。これらのイテレーションにおいてドキュメントは、ドキュメントを構成するブロックを創設し、そしてリンクしながら作られる。
ブロック構造が作られる際、結果として生じる構造であるブロックのツリーは、それを選ばれたターゲット言語のドキュメントに変換するトランスレーターにより処理される。この帰納的ディセント分析を使用したアルゴリズムは、ブロックと含まれたブロックに保存された情報次第で、ターゲット言語のタグにブロックを変換する能力がある。
例として、テキスト「タイトル」を含む一つのセクションブロックは、次のストリングＨＴＭＬに同等なものにトランスレートされる：＜Ｈ１＞タイトル＜／Ｈ１＞。
【０２３９】
（完全なアプリケーションのジェネレート）
したがって、自動ソフトウェア作成ツールは、情報必要条件をキャプチャーすると説明され、またスタチック、ダイナミック、そして機能の３つの観点から、「ビジネスプロセス」と呼ばれる。これによりシステムデザイナーと分析者は、彼らがモデルする現実のすべての面を完全にキャプチャーできるようになる。
【０２４０】
システムロジックトランスレーターは、したがって、正確さと完全さを確かめるために以前にすでにヴァリデートされる情報のすべてを集める責任を担い、モデルされた現実のすべての面を履行するコードを自動的に作成する。このシステムロジックコードは、以下のような特徴を有する。
【０２４１】
システムロジックコードは、完全で正確である。システムロジックトランスレーターによって集められた情報は以前にヴァリーデートされているので、作成されたコードは、供給されたトランスレーションレシピのセットのおかげで、完全且つ正確であることが保証することができる。トランスレーションレシピのセットは、分析者によってモデルされ得るすべての面を含み、したがって概念モデルで表現しキャプチャーすることができるすべてのものは、ソースコードにトランスレートすることができる。すべてのトランスレーションレシピは正確なトランスレーションを保証し、かくしてソースコードにエラーがなくなる。
【０２４２】
システムロジックコードはただのプロトタイプのためのものではなく、完全なアプリケーションのためのものである。ジェネレートされたコードは、（そのターゲットプログラミング言語による適切なコンパイラーで）コンパイルすることができ、概念モデルの情報入力から完全にトランスレートされているため、「そのまま」で実行することができる。ジェネレートされたコードは、ただの方法の骨組を集めたものではなく、完全な方法である。さらに、不必要なコードは作成されず、またコードの一行として一度以上ジェネレートされることはない。これに加え、ジェネレートされたコードがしっかりと構成されており可読であるが、コメントが内部コードドキュメンテーションの手段として自動的にジェネレートされ、可読性を改善する。
【０２４３】
システムロジックコードは、ロバストであり、エラーのテストと処理を含む。正確さと完全さが、ロバストなコードの作成を可能にする。概念モデルの情報に基づき、エラーは、二つのカテゴリーに分けられる。モデルエラーつまり内部エラーと外部エラーである。内部エラーは、概念モデルに基づき、ある特定の時点で、適用しなければならない特性に対応する（たとえば、適用しない前提条件、インテグリティ制限、アグリゲーション関係の最大カーディナリティの違反など）。外部エラーは、概念モデルの一部でない原因に相当する（たとえば、システムフェイリャー、データベースフェイリャーなど）。
【０２４４】
ジェネレートされたコードは、この分類に基づき、以下のようにエラーを処理する。内部エラーについては、システムロジックトランスレーターは、内部エラーが起こりえるすべての地点を確認し、エラーテストとエラー処理のコードを作成し、クライアントにそのようなエラーの発生を告知する。さらにまた、内部エラーは分類することができ、カスタマイズ可能なエラーメッセージやエラーコードのような特定の処理を加えることができる。外部エラーについては、システムロジックトランスレーターは、外部エラーが起こりえるすべての地点を確認し、エラーテストとエラー処理のコードを作成し、クライアントにそのようなエラーの発生を告知する。外部エラーはカテゴリー化されることができないため、同じ標準の方法で処理される。
【０２４５】
したがって、すべての起こりえる状況に対するエラーテストとエラー処理の自動作成は、概念モデルのどのようなトランスレーションもロバストであると保証することができる。
【０２４６】
システムロジックコードは、トランザクションの行動を取り扱う。ジェネレートされたコードは、コードがクライアントにシステムからサービスをリクエストできるようにする明確なインターフェースを供給するという意味で、トランザクションの行動を表示する。それらのサービスは、トランザクション的な方法で実行される。つまりすべてのサービスの入力アーギュメントはクライアントによって供給されなければならず、その後システムロジックは対応する作業を行いクライアントに返答する。概念モデルにおけるサービスは、アクションに分解することができる。ジェネレートされたコードは、サービスを構成するすべてのアクションが首尾良く達成され、さもなくば何も行われないことを保証する。加えて、サービスが分解されてできたアクションによって影響されたオブジェクトに対する変化は、これらすべてのアクションが首尾良く終わるまで、実質的には起こなわれない。トランザクションの行動はまた、レガシーシステムとのインテグレーションを強化する。
【０２４７】
システムロジックコードは、ユーザーインターフェースから独立している。ジェネレートされたコードは、クライアントがサービスをリクエストできるようにする、明確なインターフェースを供給する。しかし、このインターフェースは、クライアントがそれとインターアクトすることに依存しない。これは、異なるクライアントのグループが同じシステムロジックとインターアクトすることを可能にする。したがって、特定のシステムロジックのクライアントは、それが彼らに表示するインターフェースのみを知る必要がある。この特徴は、インターネットアプリケーションの展開を簡単にし、またレガシーシステムへの統合と、巨大な情報システム、あるいは概念モデルを、明確なインターフェースを持ちそのためにそれぞれがインターアクトできるより小さなものへ分解することがよりよくできるようにする。
【０２４８】
システムロジックコードは、固定層から独立している。ジェネレートされたコードは、「固定サービス」とみなされるものを履行する固定層と相互作用する責任を担う。これらのサービスは、固定層における情報を加えたり、引き出したり、改定したり、そして削除したりする責任を担う。これらのサービスは、その作業を実行するシステムロジックにとって必要であるが、これに加え、システムロジックは、固定層に対するのクエリーを実行するサービスを供給することにより、クライアントに対し、固定層を隠蔽する。これは、クライアントが固定層の物理的な位置を知る必要がなく、固定層に対するクエリーを実行するサービスを供給されているため、固定層の構造を知る必要がなく、固定層へのアクセスは完全にシステムロジックが管理しているため、固定層のアクセスを許可されたユーザーである必要がなく、そして固定層が存在するこさえ知る必要がないことを示唆する。
【０２４９】
要するに、本発明の一実施例の自動ソフトウェア作成システムによって自動的に作成されたコードは、ただのプロトタイプのそれではなく、本当に最終的なソフトウェアアプリケーションのそれに相当する。この識別を維持するために、ジェネレートされたシステムロジックコードとプロトタイプのそれとの違いの幾つかを説明する。
【０２５０】
（１）完全さ：プロトタイプは、情報システムの機能性を完全に含まず、すべての可能な実行の流れのために意図されている訳ではないが、我々の自動にジェネレートされた最終的なアプリケーションとなるコードは、すべての可能な実行の流れと共に、対応する概念モデルでキャプチャーされた機能性をも完全に含む。
【０２５１】
（２）正確さ：プロトタイプは、ユーザーのニーズと必要条件を確かめ、そして実行の正確さを確かめる目的をもつ。一方、本発明の一実施例に基づく自動的にジェネレートされたコードは正しくジェネレートされているため、ユーザーのニーズと必要条件を確かめる目的をもつ。
【０２５２】
（３）ロバストなこと：プロトタイプは、エラーテストとエラー処理のコードで作成されていないため、ロバストではない。むしろ、このコードは、通常は手作業あり、ユーザーのニーズと必要条件が満たされていることが証明され、したがって、最終アプリケーションが作成されることができるコード化の最終フェーズまで作成されない。我々の自動的に作成されたコードの場合であるような最終アプリケーションは、ロバストであることを確かめるために必要なすべてのコードを有しなければならない。これは通常、手作業でコード化されるため、プログラマーが、コードを必要な箇所の多くに加え忘れることが多々ある。これは、維持のコストを高いものとし、システムロジックコードとエラーテストとエラー処理のコードの間のバランスを崩す。本文で説明されたシステムロジックのトランスレーターは、エラーテストとエラー処理に必要な（そして必要ちょうどの）すべてのコードを供給する。
【０２５３】
（４）スケーラブルなこと：プロトタイプは、ユーザーのニーズと必要条件をヴァリデートするプロセスの間に破棄される傾向にあるため、スケーラブルではない。最終アプリケーションは、プロトタイプよりはるかに長く持続するよう目指しているため、スケーラブルである。とはいえ、スケーラブルであるということは、デザインのフェーズの間にあるガイドラインに従わなければならないことを示唆する。本発明の実施例で、システムアナリストはスケーラブルであることに気を使う必要はない。これはこのような作業が、システムロジックトランスレーター２３２の責任に含まれているためである。したがって、アナリストは結果として生じるコードがスケーラブルであることを知り、分析事項に集中することができる。さらに、システムロジックトランスレーターによってトランスレートされた異なった概念モデルは、それらの明確なインターフェースを通して、お互いにインターアクトすることができる。
【０２５４】
本発明は、現時点で最も実用的で好ましい実施例と関連して説明されてきたが、本発明は発表された実施例に限定されるものではなく、逆に、当然のことながら、付属の請求項の精神と範囲内に含まれるさまざまな改良や等価の処置を含むように意図されていることは理解されるに及ぶものである。
【図面の簡単な説明】
【図１】
図１は、本発明の一実施態様を施行し得るコンピュータシステムを表す。
【図２】
図２は、本発明の一実施態様による、自動ソフトウェア作成システムの上位構造とデータフローを図示する概略ブロックダイアグラムである。
【図３】
図３は、図書館利用者（ｒｅａｄｅｒ）と、本と、貸し出し（ｌｏａｎ）のついた図書館システム用のオブジェクトモデルの一例を示す。
【図４Ａ】
図４Ａは、本発明の一実施態様による、状態遷移の例を図示する。
【図４Ｂ】
図４Ｂは、本発明の一実施態様による、オブジェクトインタラクションの例を図示する。
【図５】
図５は、機能モデルへの入力を受け取るダイアログの例を図示する。
【図６】
図６は、「実行モデル」と呼ばれるものに従うことにより、公式仕様を完全なアプリケーションにトランスレーションする作業の上位の様子を図示するフローダイアグラムである。
【符号の説明】
１００　…　コンピュータシステム
１０２　…　バス
１０４　…　プロセッサー
１０６　…　メインメモリー
１０８　…　メモリー
１１０　…　ストーレッジデバイス
１１２　…　ディスプレイ
１１４　…　入力デバイス
１１６　…　カーソルコントロール
１１８　…　通信インターフェース
１２０　…　ネットワークリンク
１２２　…　ローカルネットワーク
１２４　…　ホストコンピュータ
１２６　…　インターネットサービスプロバイダー
１２８　…　インターネット
１３０　…　サーバー
２０２　…　自動ソフトウェア作成システム
２０４　…　アプリケーションソースコード
２０６　…　データベーススキーマ
２０８　…　ドキュメンテーション
２１０　…　コンピュータエイデッドソフトウェアエンジニアリングツール
２２０　…　ヴァリデーター
２３２　…　システムロジックトランスレーター
２３４　…　ユーザーインターフェーストランスレーター
２３６　…　データベースジェネレーター
２３８　…　ドキュメンテーションジェネレーター
【図１】
2004506962.tif 000007
【図２】
2004506962.tif 000008
【図３】
2004506962.tif 000009
【図４Ａ】
2004506962.tif 000010
【図４Ｂ】
2004506962.tif 000011
【図５】
2004506962.tif 000012
【図６】
2004506962.tif 000013
【国際公開パンフレット】
2004506962.tif 000014
2004506962.tif 000015
2004506962.tif 000016
2004506962.tif 000017
2004506962.tif 000018
2004506962.tif 000019
2004506962.tif 000020
2004506962.tif 000021
2004506962.tif 000022
2004506962.tif 000023
2004506962.tif 000024
2004506962.tif 000025
2004506962.tif 000026
2004506962.tif 000027
2004506962.tif 000028
2004506962.tif 000029
2004506962.tif 000030
2004506962.tif 000031
2004506962.tif 000032
2004506962.tif 000033
2004506962.tif 000034
2004506962.tif 000035
2004506962.tif 000036
2004506962.tif 000037
2004506962.tif 000038
2004506962.tif 000039
2004506962.tif 000040
2004506962.tif 000041
2004506962.tif 000042
2004506962.tif 000043
2004506962.tif 000044
2004506962.tif 000045
2004506962.tif 000046
2004506962.tif 000047
2004506962.tif 000048
2004506962.tif 000049
2004506962.tif 000050
2004506962.tif 000051
2004506962.tif 000052
2004506962.tif 000053
2004506962.tif 000054
2004506962.tif 000055
2004506962.tif 000056
2004506962.tif 000057
2004506962.tif 000058
2004506962.tif 000059
2004506962.tif 000060
2004506962.tif 000061
2004506962.tif 000062
2004506962.tif 000063
2004506962.tif 000064
2004506962.tif 000065
2004506962.tif 000066
2004506962.tif 000067
2004506962.tif 000068
2004506962.tif 000069
2004506962.tif 000070
2004506962.tif 000071
2004506962.tif 000072
2004506962.tif 000073
2004506962.tif 000074
2004506962.tif 000075
2004506962.tif 000076
2004506962.tif 000077
2004506962.tif 000078
2004506962.tif 000079
2004506962.tif 000080
2004506962.tif 000081
2004506962.tif 000082
2004506962.tif 000083
2004506962.tif 000084
2004506962.tif 000085
2004506962.tif 000086
2004506962.tif 000087
2004506962.tif 000088
2004506962.tif 000089
2004506962.tif 000090
2004506962.tif 000091
2004506962.tif 000092
2004506962.tif 000093
2004506962.tif 000094
2004506962.tif 000095
2004506962.tif 000096
2004506962.tif 000097
2004506962.tif 000098
【国際公開パンフレット（コレクトバージョン）】
2004506962.tif 000099
2004506962.tif 000100
【国際公開パンフレット（コレクトバージョン）】
2004506962.tif 000101
2004506962.tif 000102
2004506962.tif 000103
2004506962.tif 000104
2004506962.tif 000105
2004506962.tif 000106
2004506962.tif 000107
2004506962.tif 000108
2004506962.tif 000109
2004506962.tif 000110
2004506962.tif 000111
2004506962.tif 000112
2004506962.tif 000113
2004506962.tif 000114
2004506962.tif 000115
2004506962.tif 000116
2004506962.tif 000117
2004506962.tif 000118
2004506962.tif 000119
2004506962.tif 000120
2004506962.tif 000121
2004506962.tif 000122
2004506962.tif 000123
2004506962.tif 000124
2004506962.tif 000125
2004506962.tif 000126
2004506962.tif 000127
2004506962.tif 000128
2004506962.tif 000129
2004506962.tif 000130
2004506962.tif 000131
2004506962.tif 000132
2004506962.tif 000133
2004506962.tif 000134
2004506962.tif 000135
2004506962.tif 000136
2004506962.tif 000137
2004506962.tif 000138
2004506962.tif 000139
2004506962.tif 000140
2004506962.tif 000141
2004506962.tif 000142
2004506962.tif 000143
2004506962.tif 000144
2004506962.tif 000145
2004506962.tif 000146
2004506962.tif 000147
2004506962.tif 000148
2004506962.tif 000149
2004506962.tif 000150
2004506962.tif 000151
2004506962.tif 000152
2004506962.tif 000153
2004506962.tif 000154
2004506962.tif 000155
2004506962.tif 000156
2004506962.tif 000157
2004506962.tif 000158
2004506962.tif 000159
2004506962.tif 000160
2004506962.tif 000161
2004506962.tif 000162
2004506962.tif 000163
2004506962.tif 000164
2004506962.tif 000165
2004506962.tif 000166
2004506962.tif 000167
2004506962.tif 000168
2004506962.tif 000169
2004506962.tif 000170
2004506962.tif 000171
2004506962.tif 000172
2004506962.tif 000173
2004506962.tif 000174
2004506962.tif 000175
2004506962.tif 000176
2004506962.tif 000177
2004506962.tif 000178
2004506962.tif 000179
2004506962.tif 000180
2004506962.tif 000181
2004506962.tif 000182
2004506962.tif 000183
2004506962.tif 000184
2004506962.tif 000185
2004506962.tif 000186
2004506962.tif 000187
【手続補正書】
【提出日】平成13年12月4日(2001.12.4)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】特許請求の範囲
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
自動ソフトウェア作成ツールであって、
ソフトウェアプログラムが書かれるべき問題を規定する入力条件を集め、そして、公式仕様が正確かつ完全であることを保証するため公式仕様がヴァリデート可能なように、前記入力条件を文法、シンタックスおよびセマンティックが所定の規則を有する公式のオブジェクト志向の言語に公式仕様として形式化して変換するＣＡＳＥツールと、
前記公式仕様を保存するコンピュータ可読媒体と、
前記公式仕様が正確かつ完全であることを保証するために公式仕様をヴァリデートするヴァリデーターと、
ヴァリデートされた公式仕様に基づき完全なソフトウェアアプリケーションをジェネレートするトランスレーターとを有し、該完全なソフトウェアアプリケーションは表示モデルで指定されたパターンに従いユーザーインターフェースを処理するインストラクションを含む
ことを特徴とする自動ソフトウェア作成ツール。
【請求項２】
ユーザーがソフトウェアアプリケーションの明確な公式条件を入力できるグラフィックなユーザーインターフェースを表示し、そのソフトウェアアプリケーションへの公式条件の入力に基づいた公式仕様をジェネレートするためのＣＡＳＥツールをさらに含むことを特徴とする、請求項１に記載のツール。
【請求項３】
そのＣＡＳＥツールがさらに、一つのイベントがどのように一つのオブジェクトの状態を変えるかを示すヴァリュエーションを指定するユーザー入力を受諾するよう設定されていることを特徴とする、請求項２に記載のツール。
【請求項４】
そのヴァリュエーションが実質的にプッシュポップ、ステートインディペンデント、およびディスクリートドメインから成る一つのセットから選ばれることを特徴とする、請求項３に記載のツール。
【請求項５】
公式仕様がロバストなソフトウェアアプリケーションの条件を含み、
トランスレーターがエラーの検査とエラーの処理についてのインストラクションをジェネレートするよう設定されている
ことを特徴とする、請求項１に記載のツール。
【請求項６】
トランスレーションが公式仕様に基づいて、内部エラーの検査と内部エラーの処理についてのインストラクションをジェネレートするよう設定されていることを特徴とする、請求項５に記載のツール。
【請求項７】
トランスレーションが外部エラーの検査と外部エラーの処理についてのインストラクションをジェネレートするように設定されていることを特徴とする、請求項５に記載のツール。
【請求項８】
公式仕様に基づいたソフトウェアアプリケーションのドキュメンテーションをジェネレートするドキュメンテーションジェネレーターをさらに含むことを特徴とする、請求項１に記載のツール。
【請求項９】
自動ソフトウェア作成ツールであって、
ユーザーがソフトウェアアプリケーションの明確な公式条件を入力できるようグラフィックなユーザーインターフェースを表示し、そのアプリケーションソフトウェアの公式条件の入力に基づいてそのアプリケーションソフトウェアの公式仕様をジェネレートするＣＡＳＥツールと、
その公式仕様をヴァリデートするヴァリデーターと、
そのヴァリデートされた公式仕様に基づいてソフトウェアアプリケーションをジェネレートするトランスレーターと、
を含むことを特徴とする自動ソフトウェア作成ツール。
【請求項１０】
その明確な公式条件がソフトウェアアプリケーションのソフトウェアのユーザーに表示されるアプリケーションユーザーインターフェースのパターンを含み、
そのジェネレートされたソフトウェアアプリケーションが表示モデルで指定されたパターンに基づいた、ユーザーインターフェースの取り扱いについてのインストラクションを含む
ことを特徴とする、請求項９に記載のツール。
【請求項１１】
明確な公式条件がロバストなソフトウェアアプリケーションの条件を含み、
そのジェネレートされたソフトウェアアプリケーションがエラーの検査とエラーの処理についてのインストラクションを含む
ことを特徴とする、請求項９に記載のツール。
【請求項１２】
ＣＡＳＥツールがさらに、一つのイベントがどのように一つのオブジェクトの状態を変えるかを示すヴァリュエーションを指定するユーザー入力を受諾するよう、設定されていることを特徴とする、請求項９に記載のツール。
【請求項１３】
そのヴァリュエーションが、プッシュポップ、ステートインディペンデント、およびディスクリートドメインから実質的に成る一つのセットから選択されていることを特徴とする、請求項１２に記載のツール。
【請求項１４】
自動ソフトウェア作成ツールであって、
ロバストなソフトウェアアプリケーションの条件を指定する概念モデルの公式仕様を保存するためのコンピュータ可読媒体と、
その概念モデルが正しく、完全で、そして明確であることを決定する公式仕様をヴァリデートするヴァリデーターと、
そのヴァリデートされた公式仕様に基づいて、ロバストなソフトウェアアプリケーションをジェネレートするトランスレーターで、そのロバストなソフトウェアアプリケーションがエラーの検査とエラーの処理についてのインストラクションを含む、トランスレーターと、
を含むことを特徴とする自動ソフトウェア作成ツール。
【請求項１５】
ユーザーがソフトウェアアプリケーションの明確な公式条件を入力できるようにグラフィックなユーザーインターフェースを表示し、そのソフトウェアアプリケーションの公式条件の入力に基づいて公式仕様をジェネレートするためのＣＡＳＥツールからさらに成ることを特徴とする、請求項１４に記載のツール。
【請求項１６】
そのＣＡＳＥツールがさらに、一つのイベントがどのように一つのオブジェクトの状態を変えるかを示すヴァリュエーションを指定するユーザー入力を受諾するよう設定されていることを特徴とする、請求項１５に記載のツール。
【請求項１７】
そのヴァリュエーションが、実質的にプッシュポップ、ステートインディペンデント、およびディスクリートドメインから成る一つのセットから選ばれていることを特徴とする、請求項１６に記載のツール。
【請求項１８】
自動的にソフトウェアアプリケーションをジェネレートする方法であって、
ソフトウェアアプリケーションのユーザーインターフェースのパターンを指定する表示モデルを含む概念モデルであり、ソフトウェアアプリケーションの条件を指定する概念モデルの公式仕様にアクセスすること、
その公式仕様をヴァリデートすること、および
その表示モデルで指定されたパターンに基づいてそのユーザーインターフェースの処理をするためのインストラクションを含むソフトウェアアプリケーションを、そのヴァリデートされた公式仕様に基づいてジェネレートすること、
を含むことを特徴とする、自動的にソフトウェアアプリケーションをジェネレートする方法。
【請求項１９】
明確な公式条件がロバストなソフトウェアアプリケーションの条件を含み、
そのジェネレートされたソフトウェアアプリケーションがエラーの検査とエラーの処理についてのインストラクションを含む
ことを特徴とする、請求項１８に記載の方法。
【請求項２０】
公式仕様に基づきソフトウェアアプリケーションのドキュメンテーションを作成することからさらに成ることを特徴とする、請求項１８に記載の方法。
【請求項２１】
どのように一つのイベントが一つのオブジェクトの状態を変えるかを示すヴァリュエーションを指定するユーザー入力を受諾することからさらに成ることを特徴とする、請求項１８に記載の方法。
【請求項２２】
そのヴァリュエーションがプッシュポップ、ステートインディペンデント、およびディスクリートドメインから実質的に成る一つのセットから選択されることを特徴とする、請求項２１に記載の方法。
【請求項２３】
自動的にソフトウェアアプリケーションをジェネレートする方法であって、
ユーザーがソフトウェアアプリケーションの明確な公式条件を入力できるよう、グラフィックなユーザーインターフェースを掲示すること、
そのソフトウェアアプリケーションの公式条件入力に基づき、ソフトウェアアプリケーションの公式仕様をジェネレートすること、
その公式仕様をヴァリデートすること、および
そのヴァリデートされた公式仕様に基づき、ソフトウェアアプリケーションをジェネレートすること、
を含むことを特徴とする、自動的にソフトウェアアプリケーションをジェネレートする方法。
【請求項２４】
その明確な公式条件がそのソフトウェアアプリケーションのソフトウェアのユーザーに表示されるためのアプリケーションユーザーインターフェースのためのパターンを含み、および
そのジェネレートされたソフトウェアアプリケーションが、表示モデルの中で指定されたパターンに基づくユーザーインターフェースの取り扱いについてのインストラクションを含む、
ことを特徴とする、請求項２３に記載の方法。
【請求項２５】
その明確な公式条件がロバストなソフトウェアアプリケーションの条件を含み、また
そのジェネレートされたソフトウェアアプリケーションがエラーの検査とエラーの処理についてのインストラクションを含む
ことを特徴とする、請求項２３に記載の方法。
【請求項２６】
公式仕様に基づき、内部エラーの検査と内部エラーの処理についてのインストラクションをジェネレートすることより成ることを特徴とする、請求項２５に記載の方法。
【請求項２７】
外部エラーの検査と外部エラーの処理に関するインストラクションをジェネレートすることより成ることを特徴とする、請求項２５に記載の方法。
【請求項２８】
一つのイベントがどのように一つのオブジェクトの状態を変えるかを示すヴァリュエーションを指定するユーザー入力を受諾することよりさらに成ることを特徴とする、請求項２３に記載の方法。
【請求項２９】
そのヴァリュエーションがプッシュポップ、ステートインディペンデント、およびディスクリートドメインより実質的に成る一つのセットから選択されていることを特徴とする、請求項２８に記載の方法。
【請求項３０】
自動的にロバストなソフトウェアアプリーションをジェネレートする方法であって、
ロバストなソフトウェアアプリケーションの条件を指定する概念モデルの公式仕様にアクセスし、
その概念モデルが正しく、完全で、明確であることを決定する公式仕様をヴァリデートし、および、
エラーの検査とエラーの処理に関するインストラクションを含むロバストなソフトウェアアプリケーションを、そのヴァリデートされた公式仕様に基づきジェネレートする
ことを特徴とする自動的にロバストなソフトウェアアプリケーションをジェネレートする方法。
【請求項３１】
一つのイベントがどのように一つのオブジェクトの状態を変えるかを示すヴァリュエーションを指定するユーザー入力を受諾することよりさらに成ることを特徴とする、請求項３０に記載の方法。
【請求項３２】
そのヴァリュエーションがプッシュポップ、ステートインディペンデント、およびディスクリートドメインから実質的に成る一つのセットより選択されていることを特徴とする、請求項３１に記載の方法。
【請求項３３】
自動的にソフトウェアアプリケーションをジェネレートするためのインストラクションを有するコンピュータ可読媒体であって、前記インストラクションが実行されることによって、一つまたはそれ以上のプロセッサーが、
ソフトウェアアプリケーションの条件を指定する概念モデルで、ソフトウェアアプリケーションのユーザーインターフェースのパターンを指定する表示モデルを含む概念モデルの公式仕様にアクセスするステップと、
その公式仕様をヴァリデートするステップと、
表示モデルで指定されたパターンに基づいたユーザインターフェースの取り扱いインストラクションを含むソフトウェアアプリケーションを、そのヴァリデートされた公式仕様に基づいてジェネレートするするステップと
を実施するように、前記インストラクションが設定されていることを特徴とするコンピュータ可読媒体。
【請求項３４】
明確な公式条件がロバストなソフトウェアアプリケーションの条件を含み、および、
ジェネレートされたソフトウェアアプリケーションがエラーの検査とエラーの処理に関するインストラクションを含む
ことを特徴とする、請求項３３に記載のコンピュータ可読媒体。
【請求項３５】
公式条件に基づいてソフトウェアアプリケーションのドキュメンテーションを作成するためのインストラクションをさらに有することを特徴とする、請求項３３に記載のコンピュータ可読媒体。
【請求項３６】
一つのイベントがどのように一つのオブジェクトの状態を変えるかを示すヴァリュエーションを指定するユーザー入力を受諾することからさらに成ることを特徴とする、請求項３３に記載のコンピュータ可読媒体。
【請求項３７】
そのヴァリュエーションがプッシュポップ、ステートインディペンデント、およびディスクリートドメインより実質的に成る一つのセットより選択されていることを特徴とする、請求項３６に記載のコンピュータ可読媒体。
【請求項３８】
自動的にソフトウェアアプリケーションをジェネレートするためのインストラクションを有するコンピュータ可読媒体であって、前記インストラクションが実行されることによって、一つまたはそれ以上のプロセッサーが、
ユーザーがソフトウェアアプリケーションのための明確な公式条件を入力できるようグラフィックなユーザーインターフェースを表示するステップと、
ソフトウェアアプリケーションのための公式条件の入力に基づいて、ソフトウェアアプリケーションの公式仕様をジェネレートするステップと、
その公式仕様をヴァリデートするステップと、
そのヴァリデートされた公式仕様に基づいてソフトウェアアプリケーションをジェネレートするするステップと
を実施するように、前記インストラクションが設定されていることを特徴とするコンピュータ可読媒体。
【請求項３９】
明確な公式条件が、ソフトウェアアプリケーションのソフトウェアのユーザーに表示されるアプリケーションユーザーインターフェースのパターンを含み、および、
ジェネレートされたソフトウェアアプリケーションが、表示モデルで指定されたパターンに基づくユーザーインターフェースを取り扱うためのインストラクションを含む
ことを特徴とする、請求項３８に記載のコンピュータ可読媒体。
【請求項４０】
明確な公式条件がロバストなソフトウェアアプリケーションの条件を含み、
ジェネレートされたソフトウェアアプリケーションがエラーの検査とエラーの処理に関するインストラクションを含む
ことを特徴とする、請求項３８に記載のコンピュータ可読媒体。
【請求項４１】
公式仕様に基づいて内部エラーの検査と内部エラーの処理をするためのインストラクションをジェネレートするインストラクションをさらに有することを特徴とする、請求項４０に記載のコンピュータ可読媒体。
【請求項４２】
外部エラーの検査と外部エラーの処理に関するインストラクションをジェネレートするインストラクションをさらに有することを特徴とする、請求項４０に記載のコンピュータ可読媒体。
【請求項４３】
一つのイベントがどのように一つのオブジェクトの状態を変えるかを示すヴァリュエーションを指定するユーザー入力を受諾することよりさらに成ることを特徴とする、請求項３８に記載のコンピュータ可読媒体。
【請求項４４】
ヴァリュエーションがプッシュポップ、ステートインディペンデント、およびディスクリートドメインより実質的に成る一つのセットから選択されていることを特徴とする、請求項４３に記載のコンピュータ可読媒体。
【請求項４５】
自動的にロバストなソフトウェアアプリケーションをジェネレートするためのインストラクションを有するコンピュータ可読媒体であって、前記インストラクションが実行されることによって、一つまたはそれ以上のプロセッサーが、
ロバストなソフトウェアアプリケーションの条件を指定する概念モデルの公式仕様にアクセスするステップと、
そのモデルが正しく、完全で、明確であることを決定する公式仕様をヴァリデートするステップと、
エラーの検査とエラーの処理に関するインストラクションを含むロバストなソフトウェアアプリケーションを、そのヴァリデートされた公式仕様に基づいてジェネレートするするステップと
を実施するように、前記インストラクションが設定されてることを特徴とするコンピュータ可読媒体。
【請求項４６】
一つのイベントがどのように一つのオブジェクトの状態を変えるかを示すヴァリュエーションを指定するユーザー入力を受諾することよりさらに成ることを特徴とする、請求項４５に記載のコンピュータ可読媒体。
【請求項４７】
ヴァリュエーションがプッシュポップ、ステートインディペンデント、およびディスクリートドメインより実質的に成る一つのセットより選択されていることを特徴とする、請求項４６に記載のコンピュータ可読媒体。
【国際調査報告】
2004506962.tif 000188
2004506962.tif 000189
2004506962.tif 000190