JP6725535B2 - 設計仕様書に基づきソフトウェアタイプアプリケーションを表示するコンピュータに実装された方法 - Google Patents

Description

この発明は、ソフトウェア設計仕様書に基づいて完全に操作可能なソフトウェアタイプアプリケーションを自動的に生成するためコンピュータにより実行されるシステム及び方法である。

このシステムは、ユーザが入力／出力デバイスを介してクラス設計値及び画面設計値（ソフトウェア設計仕様書）を入力することを可能にする。プロセッサは、メモリデータベースに記憶される機能モデル及び視覚モデルを自動的に作成するために２つのプロトコルを適用する。次いで、プロセッサは、グラフィック構成要素とこれらのモデルを結合し、コンパイル可能なコードを発生することなくソフトウェアタイプアプリケーションをインスタンス化する。これらのアプリケーションは、操作しようとしているユーザに提示され、結果として情報を生成する。

関連出願の相互参照

本出願は、本出願と同じ発明者により２０１５年５月１３日に出願された米国特許仮出願第６２／１６１，２１６号、名称「Ｍｅｔｏｄｏ ｉｍｐｌｅｍｅｎｔａｄｏ ｐｏｒ ｃｏｍｐｕｔａｄｏｒ ｑｕｅ ｅｘｐｏｎｅ ｌａｓ ａｐｌｉｃａｃｉｏｎｅｓ ｔｉｐｏ ｓｏｆｔｗａｒｅ ａｐａｒｔｉｒ ｄｅ ｅｓｐｅｃｉｆｉｃａｃｉｏｎ ｄｅ ｄｉｓｅｎｏ」（Ｍｅｔｈｏｄ ｅｍｐｌｏｙｅｄ ｂｙ ａ ｃｏｍｐｕｔｅｒ ｆｏｒ ｅｘｐｏｓｉｎｇ ｓｏｆｔｗａｒｅ−ｔｙｐｅ ａｐｐｌｉｃａｔｉｏｎｓ ｂａｓｅｄ ｏｎ ｄｅｓｉｇｎ ｓｐｅｃｉｆｉｃａｔｉｏｎｓ（設計仕様書に基づきソフトウェアタイプアプリケーションを公開する（ｅｘｐｏｓｅ）ためにコンピュータにより採用された方法））」の優先権を主張する。前述の仮出願の内容は、本文献において開示されているかのように、参照によりその全体が組み込まれている。

ソフトウェア産業は、解決策をもたらす機構として、データベースの構築及びコンピュータプログラムのコーディングがその中に見られ得る一連の動作を提案する。これらの動作は、得られるソフトウェアが複数のユーザ環境で操作されることを可能にするアーキテクチャの枠組み内で働く。このようなタスクは、ソフトウェア設計を理解することで認定された人及びプログラムを開発した者から認定された人により実行される。これらのタスクの性質は、下記の専門化したプロフィールが傑出しているチームによりソフトウェアを作ることが実行されることを決定する。

企画者：エンドユーザ環境を考慮した上でアプリケーションレイヤアーキテクチャを規定する。アーキテクチャの例は、ＳＯＡ（サービス指向アーキテクチャ）、クライアントサーバ、等である。

データベースプログラマ：アプリケーションを使用しながらユーザ発生データが記憶される構造を構築する。様々な技術に基づくが一般的で既に確立された標準の下で現在働いているデータベースエンジンと呼ばれるツールがある。

アプリケーションプログラマ：具体的な言語（Ｊａｖａ（登録商標）、Ｃ＃、Ｖｂｎｅｔ、等）でプログラムのコードを記述し、このコードは、次いでコンパイルされて、コンピュータが実行するオブジェクトのコードを取得し、ユーザがアクセスする最終アプリケーションを生成する。

ユーザインターフェース設計者：画面、視覚構成要素、及びコンピュータプログラムがユーザフレンドリに見え、且つ容易に使用することが可能であるグラフィックスタイルテンプレートを設計する。

ソフトウェアを作成するために、通常ソフトウェアを作成することを必要としているある人は、数年の勉強を必要とする前述のスキルを持たないので、上に述べたような専門家チームを頼りにすることが必要である。

ソフトウェア産業において生じる問題は、下記のような様々な次元を有する：
ｉ．解決策に対する要求が、この分野の専門家を養成するために必要な速度よりも早い速度で世界中で増大している。そのため、大きな未対処の開発要求が見受けられることがある。
ｉｉ．ソフトウェアを記述するプロセスは、費用が掛かり、多くの時間を要する、これは、上記プロセスを要求している部門が効率的に利便性良くすべてのニーズを満足させることができないことを暗に意味している。
ｉｉｉ．速いペースで進展している様々な技術（データベース、プログラミング言語、アーキテクチャ、ユーザインターフェース）が、既に開発されたアプリケーションにおいて技術的な陳腐化の問題を引き起こしている。これは、ソフトウェアが操作可能であると、通常は、産業の専門家により採用される新しい技術が生じることを意味している。このようなソフトウェアのアップグレードは、ソフトウェアが最初に作成されたときと同様に重要なリエンジニアリング努力を暗に意味している。
ｉｖ．不安定な世界経済におけるビジネス運用規則の定常的な変化は、金銭／時間要因が技術的な陳腐化と相まって一般に実行不可能である、ソフトウェアアプリケーションへの適応及び改善を必要とする。この理由のために、ソフトウェアアプリケーションは、タイムリーで柔軟な発展を提供できていない。

先行技術は、ソフトウェアアプリケーション開発ライフサイクルにおける時間及びコストを削減するためにソフトウェアを自動的に発生するための無数のシステム及び方法を明らかにしている。米国特許出願公開第２００６／００１５８３９号は、２つの可能なソースに基づくＪ２ＥＥコンパイル可能なソースコード、開発しようとするシステムのすべてのパラメータ、チャート及びアーキテクチャが明確に特定されており、技術設計の詳細な知識が入力として要求されることを意味しているデータベースを発生するシステム及び方法を開示している。この詳細な規定に基づき、ＸＭＬファイルが記述され、このＸＭＬファイルは設計を調節するためにユーザにより変更されることが可能である。最終的なＸＭＬドキュメントは、Ｊ２ＥＥコード及びシステムアーキテクチャを自動的に発生するフレームワークツールにより処理される。フォームツールは、ＸＭＬソースドキュメント内に明確に規定されている構造にやはり基づいて、ユーザインターフェースフォームを自動的に生成する。システム展開ツールは、ソースデータベースとプログラムコードとをコンパイル可能な構造へと統合し、ソフトウェアアプリケーションを結果としてもたらす。

本発明とは異なり、米国特許出願公開第２００６／００１１５８３９号は、Ｊ２ＥＥコンパイル可能なコードを発生し、プログラムの計算アーキテクチャ並びにそのデータベース構造、オブジェクトパラメータ及びテーブルフィールドの前の知識を必要とする。また、ＸＭＬの詳細な知識及びいくつかのケースでは直接コードインジェクションが、記述した構成及び編集プログラムにより実行されなかったいくつかのタスクを実行するために要求される。

同様に、米国特許出願公開第２００２／００７７８２３号は、入力データとして解釈するための音声認識法を暗に意味する音声操作型プラットフォームを特に含め、多数のクライアントプラットフォームでランできるソフトウェアアプリケーションを作成する方法及びシステムを開示している。例えば、限られた画面又はキーボードアクセスを用いてセル電話機ユーザは、オーディオフォーマットでウェブページ上の情報を入手でき、そして記述されるよりはむしろ話された言葉及び文章を介してウェブサイトと返信で対話できる。前述のドキュメントは、会話認識に、テキストへの翻訳にそれ自体を限定し、このテキストは任意の他のアプリケーション入力データとしてその後処理される。本発明とは異なり、このようなドキュメントは、ソフトウェアモデルを構築することを提示していないし、また自動的にアーキテクチャドキュメント又は仕様書を構築することも提示していない。このようなドキュメントは、ＶｏｉｃｅＸＭＬ、音声構成要素仕様に関する標準言語、に基づいている。受信したコマンドを解釈するために、ＶｏｉｃｅＸＭＬは、手作業で修正されることがある音声会話テンプレートを使用し、上記テンプレートは、受信したコマンド及びアプリケーションが提供すべき回答の流れをマッピングするためにプログラマにより使用される手動スクリプトである。ユーザにより発せられたときにアプリケーションが認識できるスピーチ認識動詞句を定義するために、開発者は、「文法」を作成するべきであり、文法は予期され話されたコマンドの明示的な特徴付けであり、少数の認められた語系列であるこのようなコマンドに入力を制限するように働く。

この特許で設計されたシステムは、プログラマ用の機構をやはり含み、「自然言語文法（ｎａｔｕｒａｌ ｌａｎｇｕａｇｅ ｇｒａｍｍａｒ）」を定義し、上記文法は、それ自体の句を有するテンプレートに基づいて、予期される回答のタイプについてアプリケーションの平易な訓練を可能にする。その後で、引き続いて処理されるように、アプリケーション変数を用いて識別された会話成分を手作業でマッピングすることがプログラマにとって必要である。最後に、このような口述成分が適正に識別されることを確かめるために、音響パターン及び発音のデータベースを持つことが必要である。このような文書は、音声コマンドを取得するため、そして音声コマンドをアプリケーションの入力変数へと変換するための機構を提供し、自己発生型音声コマンドの形式で出力変数を公開する反対のケースを結果として提供する。そうするために、アプリケーションは、「自然言語文法」及び「言語モデル」の仕様を頼りにするが、この発明とは異なり、ソフトウェアモデル、又はアプリケーションの機能構成要素若しくは設計構成要素を自動的に推論するために、自由で網羅的な方法で自然言語入力を直接解析する能力を開示していない。

同様に、米国特許出願公開第２０１２／０２１０２９６号は、ＢＰＭタイプ（ビジネスプロセス管理）のソフトウェアアプリケーションを作成するための方法を開示している。これは、様々なプロセスに関係する機能を表している予め構築されたソフトウェアモジュールを使用している。これらは、ユーザ選択に基づき、メタデータ中のモジュールに関係する所定の自然言語の言葉を使用して得られるソフトウェアアプリケーションを生成するために組み立てられる。ユーザは、システムにより提示され、制御され、利用可能なモジュールにリンクされた用語のリストからプロセスを選択することができる。ユーザは、リストに初めは利用可能ではないだけでなく、存在するモジュールの組み合わせとして規定され、用語のリストに追加されることが可能な機能をやはり実装することができる。

本発明は、米国特許出願公開第２０１２／０２１０２９６号とは異なり、予め構築されたプロセス機能を使用しない。本発明は、自由な自然言語の使用を可能にし、この自然言語から、単にＢＰＭ解のためだけでなく、自然言語で記述されることが可能なすべての種類の解に対してもソフトウェアアプリケーションとしてインスタンス化されるモデルを作成することにより機能を構築する。この発明は、コンパイル可能なコード発生のための方法を暗に示さないし、特徴の有限なリストに結果を限定もしない。米国特許出願公開第２０１２／０２１０２９６号は、言語の構造から操作せず；むしろ、上記特許は、機能プログラムの技術構成要素のユーザ選択を容易にするために言語を使用する。

何が上に述べられているかに則して、そして自動開発動作を包含する既に存在する先行技術にも拘わらず、特にエラーデバッグのため、開発ライフサイクル専門家を包含する必要性が依然としてある。このようにして、本発明は、プログラミングプロセスを装置により置き換え、上記装置は、プロセス入力として与えられ、記述されようとしているソフトウェアタイプのアプリケーションのケースを表しているクラス及び画面の設計に基づいて自動的にソフトウェアを生成する。この発明は、下記のように産業問題の主な態様を解決する：

データベースを構築すること、コンパイル可能なコードをプログラミングすること、及び具体的なアーキテクチャを作ることなどの典型的な産業上のタスクを実行せずにソフトウェアアプリケーションの作成を可能にし、上記タスクのすべてが、いずれか、手作業で又は仕様書からプログラムコードを発生するこれらのツールにより自動的に現在実行されている。この発明は、データベースメモリに記憶され、ユーザにより入力として提供されたクラス設計値及び画面設計値にこの発明のプロトコルを適用することにより得られた機能モデル及び視覚モデルからプログラムコードを発生しないで自動的に結果を生成する。

時間及び金銭に関する高コスト、技術的陳腐化、需要不足を削減し、製品が柔軟性及び利便性を発達させることを可能にする。

先行技術は、インタープリッタである発明を報告している。ソフトウェア産業では、コンパイラ又はアセンブラはプログラミング言語の記述からシステムのマシンコードへと翻訳する、ところがインタープリッタは必要な時に、典型的にはインストラクションによるインストラクション及び通常はコードとしてこのような翻訳の結果を記憶せずに翻訳するだけであるということで、インタープリッタはコンパイラ又はアセンブラとは異なる。本発明が個別のプログラムインストラクションのリアルタイムコンパイルからソフトウェアを解かないという理由で、本発明はモデルインスタンシエータである。この発明では、インストラクションが、モデルインスタンシエータエンジンにより求められたときに、エンジンの一部としてコンパイルされた様々なプログラムインストラクションの実行を介してこれらのモデルにより表された機能をメモリ内に作成するデータベースに記憶されたモデルにより置き換えられるという理由で、インストラクションをプログラムする必要がない。プログラムの流れは、ユーザの制御下に、並びにエンジンへとコンパイルされたインストラクションに基づいて生じる他とのモデルの再発する呼び出し下にある。

この発明のモデルインスタンシエンジンは、いずれかのケースを解決することに限定されないので、特に、関係するモデルの任意のセットから任意の機能をインスタンス化することができる。このような機能を修正することは、いずれかのコンパイルしたプログラムを修正することを必要とせずに、データベースにモデルを追加すること又はデータベースからモデルを削除することにより行われる。これは、新しい機能に対して新しいプログラムを作成することよりも容易且つ早く、プログラムをテストすることを必要としない。機能性を解決するためにインタープリッタ又はコンパイラを使用すると、高品質のソフトウェアを生成するまで、各繰り返しで、この動作が有する強い影響力をともなうプログラムをテストする必要である。

［用語集］
この特許出願において開示した概念の理解を容易にするために、下記は、本発明において使用したこのような概念のうちのいくつかの範囲を示している用語のリストである。

最終ユーザ：提供されたユーザインターフェースを介して解決策を最終的に使用する当事者。

ユーザのインターフェース：ユーザがこれを介して装置、デバイス又はコンピュータと通信できる媒体。これは、ユーザとシステムとの間のすべての接触点を包含する。

ソフトウェアアプリケーション：これは、２つの部分から構成される：ビジネスを記述し、解決策の機能的行動ルールを決定する概念モデルのグループ、及びユーザが対話するユーザのインターフェースにおいてこのような機能を具体化することを可能にする表示モデルのグループ。

プログラミング：コンピュータプログラミングは、コンピュータプログラムソースコードをコーディングする、デバッグする及び維持管理するプロセスとして理解されるべきである。ソースコードは、プログラミング言語で記述される。プログラミングの目的は、所望の行動を示すプログラムを作成することである。コードを記述するプロセスは、使用しようする言語の習熟度、特殊用途アルゴリズム及び形式論理の他に、様々な領域の知識を通常必要とする。プログラミングは、アプリケーション解析及び設計（とはいえ、コード設計を本当に含む）などの他のタスクが小さなアプリケーションの開発において通常一緒に融合される場合でさえ、これらの他のタスクを必ずしも含む必要がない。

オブジェクト指向プログラミング（ＯＯＰ）パラダイム：これは、現在のところ最も多く使用されているプログラミングパラダイムである。その中心コアは、「オブジェクト」と呼ばれる単一のエンティティへのデータ及び処理の結合であり、その結果として、他の「オブジェクト」エンティティと関係付けられる。慣例的に、データ及び処理は、設計及びソフトウェア実装とは離れた領域に分類されてきている。これが、大きな開発に信頼性、維持管理、変化適応及びスケーラビリティの点で問題を生じさせている。オブジェクト指向及びカプセル化、多態性又は継承などの特徴を用いると、顕著な進歩が、いずれの製造規模においてもソフトウェア開発の点で達成された。

メタクラス：ＯＯＰパラダイムでは、メタクラスは、そのインスタンスがクラスであるクラスである。この概念は、いくつかの特殊性とともにこの発明では機能仕様プロトコルに適用される。

プログラムコード：コンピュータが解釈でき実行できる言語で記述され、コンピュータにより処理されるべきインストラクション及びデータのグループである。計算コードは、バイナリコードであっても上位レベル言語で記述されたソースコードであってもよい。

手続き型言語：これは、構造化されたプログラミングフォーマットで発生されたプログラムコードの名前である。このフォーマットは、手続き、サブルーチン又は機能の名前を受け取る構成要素の構造化プログラムコードに基づいている。

インタープリッタ：コンピュータ科学では、インタープリッタは、他のプログラムを解析し実行することができる計算プログラムである。コンパイラ又はアセンブラがプログラミング言語でのプログラムの記述からシステムのマシンコードへとプログラムを翻訳する一方で、インタープリッタは必要なときに、典型的にはインストラクションによるインストラクションで翻訳するだけであり、通常は、インタープリッタはこのような翻訳を記憶しないという理由で、インタープリッタは、コンパイラ又はアセンブラとは異なる。

コンパイラ：コンパイラは、プログラミング言語で記述されたプログラムをマシン言語へと翻訳する計算プログラムである。この翻訳処理はコンパイルとして知られている。

システム：本発明では、設計仕様書に基づいて視覚デバイスソフトウェアアプリケーションに公開するために相互間で対話する電子素子又はオプトエレクトロニック素子のグループとして理解されるべきである。

ＵＩ構成要素：これらは、画面タイプのデバイス又は類似のデバイス上への情報の提示に視覚的形態を与えるために使用されるコード部分（ＨＴＭＬ、等）である。これらの構成要素は、サードパーティー構成要素セットとして知られており、ソフトウェアアプリケーション開発における補集合としてソフトウェア産業では使用される。

この発明は、メモリ及びプロセッサを備えている電子デバイスへの論理情報構造の入力に基づいて視覚デバイスにおいて出力を自動的に生成するシステム及び方法を開示している。上記システム及び方法は、ビジネスプロセス情報を作成するように運用されることがあり、ソフトウェア産業において知られているような慣例的なプログラミングを介して通常開発されているソフトウェアアプリケーションを置き換える。

コンピュータにより使用される方法は、下記の段階：

ａ．入力／出力デバイス１２０を介して、機能仕様プロトコル（ＰＥＦ）、視覚仕様プロトコル（ＰＥＶ）及びＵＩリソースをロードし、機能仕様プロトコル（ＰＥＦ）、視覚仕様プロトコル（ＰＥＶ）及びＵＩリソースをデータベースメモリ１３０に記憶する段階と；

ｂ．段階ａのプロトコルに対して識別し、検証し、ソフトウェア設計仕様書に基づいて機能設計構成要素及び視覚設計構成要素をデータベースメモリ１４０に記憶する段階と；

ｃ．段階ｂからの上記機能設計構成要素及び視覚設計構成要素に基づいて機能モデル及び視覚モデルを自動的に作成し、上記モデルをそれぞれ上記データベースメモリ１３０、モデルＭＦ１３５、及びモデルＭＶ１３４論理構造に記憶する段階と、

ｄ．モデルインスタンシエータ１５３として構成されたプロセッサ１５０を介して、段階Ａにおいて記憶したプロトコルの規範（ｎｏｒｍ）に従ってＵＩリソースと結合された、段階ｃにおいて作成された機能モデル及び視覚モデルを読み取り、インスタンス化し、入力／出力デバイス１２０のアプリケーションインターフェース１２３に自動的に公開する段階と
を含む設計仕様に基づいてソフトウェアタイプアプリケーションを解釈し、表示する。

加えて、この発明は、ソフトウェア設計仕様書に基づいて操作可能なソフトウェアアプリケーションをインスタンス化し、公開するシステムであって：

ａ．ソフトウェア設計仕様書を入力し、得られるソフトウェアタイプアプリケーションを提示するための、ＣＤＦインターフェース１２１、ＣＤＶインターフェース１２２、アプリケーションインターフェース１２３として構成された入力／出力デバイス１２０と、

ｂ．入力／出力デバイス１２０に接続された中央処理装置（ＣＰＵ）１１０であり、

上記入力／出力デバイス１２０とペアリングされ、プロセッサ１５０と対話し、機能構成要素、視覚構成要素及びＵＩ構成要素を揮発的に記憶するように構成された汎用メモリ１４０と、

上記入力／出力デバイス１２０を介して少なくとも１つのソフトウェア設計仕様を受け取るように構成されたプロセッサ１５０で、上記プロセッサが、段階Ａのプロトコルに対してソフトウェア仕様を検証し、上記得られたソフトウェアタイプアプリケーションを識別するモデルバリデータ１５１として構成され、上記機能モデル及び視覚モデル、並びに上記ＵＩリソースを統合し、

上記プロセッサが上記アプリケーションインターフェース１２３に上記得られたソフトウェアタイプアプリケーションを表示するためにモデルインスタンシエータ１５３として構成される、
プロセッサ１５０と
を含む、中央処理装置（ＣＰＵ）１１０と、

ｃ．ＣＰＵ１１０に接続され、プロセッサ１５０とペアリングされ、仕様視覚ＰＥＶの上記プロトコルを論理構造ＰＥＶ１３１へと、機能仕様ＰＥＦの上記プロトコルを論理構造ＰＥＦ１３２へと及び上記ＵＩリソースをＵＩリソース１３３の論理構造へと静的に記憶するように構成され、並びに視覚モデルを論理構造モデルＭＶ１３４へと、機能モデルを論理構造モデルＭＦ１３５へと及びオブジェクトを論理構造オブジェクト１３６へと動的に記憶するようにやはり構成されたデータベースメモリ１３０と
を含む、システムを備える。

この発明のシステムの構造を示す図である。 機能仕様ＰＥＦプロトコルを示す図である。 視覚仕様ＰＥＶプロトコルを示す図である。 モデルＭＦのデータベースメモリの論理構造を示す図である。 モデルＭＶのデータベースメモリの論理構造を示す図である。 オブジェクトのデータベースメモリの論理構造を示す図である。 この発明の方法の段階を示す図である。 段階Ａの下位段階を詳細に示す図である。 段階Ｂの下位段階を詳細に示す図である。 機能構成要素及びＯＯタイプ識別の例を示す図である。 段階Ｃの下位段階を詳細に示す図である。 クラス図でのプロトコルＰＥＦのアプリケーションの例を示す図である。 画面図でのプロトコルＰＥＶのアプリケーションの例を示す図である。 段階Ｄの下位段階を詳細に示す図である。 この発明の方法の段階の追加モードを示す図である。 この発明の方法の段階の追加モードを示す図である。

この発明は、ソフトウェアアプリケーションの詳細な設計を表しているクラスモデルをデータベースメモリに記憶することを可能にし、このようなモデルをインスタンス化することにより得られるソフトウェアタイプアプリケーションを公開するシステム及びコンピュータ適用方法である。図２に説明したように、プロセスは、ソフトウェア設計値をデータベースメモリに記憶することにより始まり、次いで、ソフトウェアタイプアプリケーションを最終的に構成するモデルインスタンス化を解決するためにシステムに以前に記憶したプロトコル定義を使用してこのような設計の構成要素を識別する。この発明では、モデルは、データベースメモリに具体化された機能設計構成要素又は視覚設計構成要素を表している。

この方法をランさせるために、図１に記述したもののようなシステムが、入力／出力デバイス１２０にクラス設計値及び画面を入力するために使用される。入力された設計値は、汎用メモリへ転送され、次いでプロセッサ１５０により処理される。このプロセッサは、データベースメモリ１３４及び１３５の存在するモデルを検証し、結合し、インスタンス化するように構成される。各処理機能の結果は、入力／出力デバイス１２０の画面に表示される。

システム１００図１の構成要素は、下記のように記述される：

１．入力／出力デバイス１２０：これは、ソフトウェア設計値がこれにより入力されるデバイスである。入力／出力デバイス１２０は、ユーザが（図２Ｂに表示されたものなどの）クラス及び画面設計値を入力できる構造を、プロセッサが視覚媒体（数ある中で、画面、プロジェクタ、ＴＶ受信機、プリンタ、モニタ、移動デバイス）上に表示すること、及び下記の構成により得られるソフトウェアタイプアプリケーションを見ることを可能にする：

ａ．インターフェース１２１：これは、データベースメモリ１３０におけるモデルＭＦ１３５の論理構成に記憶されているクラス図に基づいてソフトウェアアプリケーションの機能設計構成要素をユーザが入力することを可能にする視覚構造である。

ｂ．ＣＤＶインターフェース１２２：これは、データベースメモリ１３０におけるモデルＭＶ１３４の論理構成に記憶されるクラス図に関係する画面図に基づいてソフトウェアアプリケーションの視覚設計構成要素をユーザがロードすることを可能にする視覚構造である。

ｃ．アプリケーションインターフェース１２３：このインターフェースは、一旦、プロセッサ１５０がデータベースメモリ１３０内の利用可能な機能モデル及び視覚モデルをインスタンス化してしまうと、得られるソフトウェアアプリケーションの視覚構造をユーザに示す。

２．ＣＰＵ１１０：これは、システム１００を処理するデバイスである。このデバイスは、対応するプロトコルに対して機能モデル及び視覚モデルを検証し、ＵＩリソースを結合し、前のステップに基づいてソフトウェアタイプアプリケーションをインスタンス化するように構造化される。ＣＰＵ１１０は、システムの機能と他の構成要素との間の交換を認める汎用メモリを備える。

ａ．汎用メモリ１４０：これは、データベースメモリと、プロセッサと、入力／出力デバイスとの間の交換デバイスの手段として使用される揮発性記憶システムである。汎用メモリ１４０は、その構成に応じて下記の機能を実行する：

ｉ．ＭＦマトリックス１４２：これは、モデルインスタンシエータ１５３として構成され、データベースメモリ１３１及び１３２に記憶されたプロトコルと提携するプロセッサ１５０を介してデータベースメモリ１３５内に存在する機能モデルの処理を可能にする汎用メモリの構成である。

ｉｉ．ＭＶ１４３マトリックス：これは、モデルインスタンシエータ１５３として構成され、データベースメモリ１３１及び１３２に記憶されたプロトコルと提携するプロセッサ１５０を介してデータベースメモリ１３４内に存在する視覚モデルの処理を可能にする汎用メモリの構成である。

ｂ．プロセッサ１５０：これは、すべての処理タスク及び交換タスクが実行されるデバイスである。プロセッサ１５０は、その構成に応じて下記の機能を実行する：

ｉ．モデルバリデータ１５１：これは、データベースメモリ１３１及び１３２内に存在するプロトコルに対してユーザにより入力された機能モデルを検証することを主に担当するプロセッサの構成であり、一旦検証すると、それぞれデータベースメモリ１３４及び１３５に記憶する。

ｉｉ．ＵＩコンバイナ１５２：これは、インスタンス化プロセスの前に、データベースメモリ１３３内に存在するＵＩリソースをデータベースメモリ１３０に記憶された視覚モデルと結合することを主に担当するプロセッサの構成である。

ｉｉｉ．モデルインスタンシエータ１５３：これは、アプリケーションのインターフェース１２３に得られたソフトウェアタイプアプリケーションを自動的に公開するために、汎用メモリ１４２及び１４３の論理構成内に存在するＵＩリソースを既に結合された機能モデル及び視覚モデルをインスタンス化することを主に担当するプロセッサの構成である。

３．データベースメモリ１３０：これは、ユーザにより入力され、その異なる構成へとプロセッサ１５０により発生されたデータを記憶する永久メモリである。このメモリは、２つのストレージ構成、スタティック構成及びダイナミック構成を含む。スタティック構成は、処理のために一旦入力され「ケース」に属さない必要なデータを記憶する。ダイナミック構成は、ケース毎に入力される「ケース」に関係するデータを記憶する。

ａ．スタティックメモリ：

ｉ．ＰＥＦ１３１：視覚仕様プロトコル（ＰＥＶ）に基づいて規定され、このメモリに入力された機能モデルをプロセッサ１５０が検証し、インスタンス化するために使用するルールを含むデータベースメモリ１３０構成。

ｉｉ．ＰＥＶ１３２：視覚仕様プロトコル（ＰＥＶ）に基づいて規定され、データベースメモリ１３０に入力された機能モデルを検証し、インスタンス化するためにプロセッサ１５０が使用するルールを含むデータベースメモリ１３０構成。

ｉｉｉ．ＵＩリソース１３３：プロセッサ１５０がユーザにより制御された画面上にアプリケーションのインターフェース１２３内のモデルを表示することを可能にするソフトウェア構成要素を含むデータベースメモリ１３０構成。

ｂ．ダイナミックメモリ：

ｉ．モデルＭＶ１３４：ＣＤＶインターフェース１２２を用いてユーザにより入力され、視覚仕様プロトコル（ＰＥＶ）に対してプロセッサ１５０により検証された機能モデルを含むデータベースメモリ１３０構成。このメモリは、図１Ｂに示した視覚仕様プロトコルの概念に関連付けられた下記の論理構造から構成される：

１．概念ＡｃｔｉｏｎＬｉｎｋに関連付けられた構成
ａ．論理構造ＲｅｎｄｅｒＡｃｔｉｏｎ
ｂ．論理構造ＲｅｎｄｅｒＡｃｔｉｏｎＥｄｉｔｏｒ
ｃ．論理構造ＲｅｎｄｅｒＡｔｔｒｉｂｕｔｅＢａｓｅＡｃｔｉｏｎ
ｄ．論理構造ＲｅｎｄｅｒＢａｓｅＶｉｅｗＡｃｔｉｏｎ

２．Ａｐｐｌｉｃａｔｉｏｎの概念に関連付けられた構成
ａ．論理構造Ａｐｐｌｉｃａｔｉｏｎ

３．ＡｔｔｒｉｂｕｔｅＲｅｎｄｅｒＩｎｆｏの概念に関連付けられた構成
ａ．論理構造ＲｅｎｄｅｒＡｔｔｒｉｂｕｔｅ
ｂ．論理構造ＲｅｎｄｅｒＡｔｔｒｉｂｕｔｅＢａｓｅ
ｃ．論理構造ＲｅｎｄｅｒＤｉａｇｒａｍＶｉｅｗ
ｄ．論理構造ＲｅｎｄｅｒＭａｐＶｉｅｗ
ｅ．論理構造ＲｅｎｄｅｒＮａｖＢａｒＶｉｅｗ
ｆ．論理構造ＲｅｎｄｅｒＯｂｊｅｃｔＲｅｆｅｒｅｎｃｅＡｔｔｒｉｂｕｔｅ
ｇ．論理構造ＲｅｎｄｅｒＰｉｖｏｔＶｉｅｗ
ｈ．論理構造ＲｅｎｄｅｒＲｅｐｏｒｔＶｉｅｗ
ｉ．論理構造ＲｅｎｄｅｒＷｉｄｇｅｔＡｔｔｒｉｂｕｔｅ

４．概念ＣｏｌｕｍｎＶｉｅｗＭｏｄｅｌに関連付けられた構成
ａ．論理構造ＲｅｎｄｅｒＣｏｌｕｍｎ

５．概念Ｃｏｎｔａｉｎｅｒに関連付けられた構成
ａ．論理構造ＲｅｎｄｅｒＣｏｎｔａｉｎｅｒ

６．概念ＬｉｓｔＶｉｅｗＭｏｄｅｌに関連付けられた構成
ａ．論理構造ＲｅｎｄｅｒＦｉｎｄＶｉｅｗ
ｂ．論理構造ＲｅｎｄｅｒＧｒｉｄＡｇｇｒｅｇａｔｅＣｏｌｕｍｎ
ｃ．論理構造ＲｅｎｄｅｒＧｒｉｄＡｔｔｒｉｂｕｔｅ
ｄ．論理構造ＲｅｎｄｅｒＧｒｉｄＣｏｌｕｍｎ
ｅ．論理構造ＲｅｎｄｅｒＧｒｉｄＣｏｌｕｍｎＡｃｔｉｏｎ
ｆ．論理構造ＲｅｎｄｅｒＧｒｉｄＶｉｅｗ

７．概念Ｍｅｎｕに関連付けられた構成
ａ．論理構造Ｍｅｎｕ

８．概念ＭｅｎｕＧｒｏｕｐに関連付けられた構成
ａ．論理構造ＭｅｎｕＧｒｏｕｐ

９．概念ＴｒｅｅＶｉｅｗＭｏｄｅｌに関連付けられた構成
ａ．論理構造ＲｅｎｄｅｒＲｅｌａｔｉｏｎＶｉｅｗ
ｂ．論理構造ＲｅｎｄｅｒＲｅｌａｔｉｏｎＶｉｅｗＡｃｔｉｏｎ
ｃ．論理構造ＲｅｎｄｅｒＴｒｅｅＶｉｅｗ

１０．概念ＶｉｅｗＭｏｄｅｌに関連付けられた構成
ａ．論理構造ＰｏｐＵｐＥｄｉｔｏｒ
ｂ．論理構造ＰｒｉｎｔＣｏｎｆｉｇｕｒａｔｉｏｎ
ｃ．論理構造ＲｅｎｄｅｒＢａｓｅＶｉｅｗ
ｄ．論理構造ＲｅｎｄｅｒＢａｓｅＶｉｅｗＩｎｈｅｒｉｔａｎｃｅ

ｉｉ．ＭＦモデル１３５：機能仕様プロトコル（ＰＥＦ）に対してプロセッサ１５０により検証されたインターフェースＣＤＦ１２１を用いてユーザにより入力された機能モデルを含むデータベースメモリ１３０構成。このメモリは、図１Ａに示したような、機能仕様プロトコル概念、Ｍｏｒｅ−Ｃｌａｓｓ象限図に関連付けられた下記の論理構造から構成される：

１．概念Ｄｏｍａｉｎに関連付けられた構成
ａ．論理構造Ｄｏｍａｉｎ

２．概念Ｆｏｒｍｕｌａに関連付けられた構成
ａ．論理構造Ｆｘ
ｂ．論理構造ＭａｔｃｈＡｔｔｒｉｂｕｔｅ
ｃ．論理構造ＭａｔｃｈＦｉｅｌｄＳｔｒａｔｅｇｙ
ｄ．論理構造ＭａｔｃｈＩｎｆｏ
ｅ．論理構造ＭａｔｃｈＶａｌｕｅ
ｆ．論理構造ＭａｔｃｈＶａｌｕｅＳｔｒａｔｅｇｙ

３．概念ＦｘＣａｌｌＡｒｇｕｍｅｎｔに関連付けられた構成
ａ．論理構造ＦｘＣａｌｌ

４．概念ＭｏｄｅｌＡｔｔｒｉｂｕｔｅに関連付けられた構成
ａ．論理構造ＭｏｒｅＣｌａｓｓＡｔｔｒｉｂｕｔｅ

５．概念ＭｏｄｅｌＣｌａｓｓに関連付けられた構成
ａ．論理構造ＭｏｒｅＣｌａｓｓ
ｂ．論理構造ＭｏｒｅＣｌａｓｓＩｎｈｅｒｉｔａｎｃｅ

６．概念ＭｏｄｅｌＲｅｌａｔｉｏｎＣｌａｓｓに関連付けられた構成
ａ．論理構造ＭｏｄｅｌＲｅｌａｔｉｏｎＣｌａｓｓ

ｉｉｉ．オブジェクト１３６：モデルインスタンシエータ１５３として構成されたプロセッサ１５０により、ユーザがソフトウェアタイプアプリケーションを介してインスタンス化されたモデルに基づいて発生するオブジェクトを含むデータベースメモリ１３０構成。このメモリは、図１Ａに示したように、機能仕様プロトコル、Ｏｂｊｅｃｔ−Ｃｌａｓｓ象限図の概念に関連付けられた下記の論理構造から構成される：

１．概念ＡｔｔｒｉｂｕｔｅＶａｌｕｅに関連付けられた構成
ａ．論理構造ＭｏｒｅＯｂｊｅｃｔＡｔｔｒｉｂｕｔｅＶａｌｕｅ
ｂ．論理構造ＭｏｒｅＯｂｊｅｃｔＡｔｔｒｉｂｕｔｅＶａｌｕｅＦｉｌｅＥｘｔｅｎｄｅｄ
ｃ．論理構造ＭｏｒｅＲｅｌａｔｉｏｎＯｂｊｅｃｔＭｏｒｅＯｂｊｅｃｔＡｔｔｒｉｂｕｔｅＲｅｌａｔｉｏｎ

２．Ｏｂｊｅｃｔの概念に関連付けられた構成
ａ．論理構造ＭｏｒｅＯｂｊｅｃｔ

３．ＲｅｌａｔｉｏｎＯｂｊｅｃｔの概念に関連付けられた構成
ａ．論理構造ＭｏｒｅＲｅｌａｔｉｏｎＯｂｊｅｃｔ

この発明は、説明したシステム、及び設計仕様書に基づいてソフトウェアタイプアプリケーションを解釈し、公開するコンピュータ適用方法を含む。図２を参照すると、この発明の方法は、下記の段階を含む：

段階Ａ．入力／出力デバイス１２０を介して、データベースメモリ１３０から、論理構造ＰＥＦ１３２内の機能仕様プロトコル（ＰＥＦ）並びに論理構造ＰＥＶ１３１内の対応するＵＩリソース及びＵＩリソース１３３とともに視覚仕様プロトコル（ＰＥＶ）をロードする。

段階Ｂ．クラス設計に基づき、インターフェースＣＤＦ１２１を介してクラス図に詳細に述べられた機能設計の構成要素を識別し、記憶し、汎用メモリ１４０に、論理構造ＭＦマトリックス１４２にこれらを一時的に記憶する。クラス設計に関連付けられた画面設計に基づいて、インターフェースＣＤＶ１２２を介して詳細に述べられた視覚設計構成要素を識別し、ロードし、汎用メモリ１４０に、論理構造ＭＶマトリックス１４３にこれらの構成要素を一時的に記憶する。

段階Ｃ．段階Ａにおいて記憶したデータベースメモリ１３０内に存在するプロトコルＰＥＦ及びＰＥＶと互換性のあるモデルを、汎用メモリ１４０に記憶した各モデルから作成するためにモデルバリデータ１５１のようなプロセッサの構成でプロセッサ１５０を使用して、段階Ｂにおいて作成した機能モデル及び視覚モデルを検証する。データベースメモリ１３０に、それぞれその論理構成モデルＭＦ１３４及びモデルＭＶ１３３に得られた機能モデルを記憶する。

段階Ｄ．データベースメモリ１３０から、段階Ｃにおいて作成した機能モデル及び視覚モデル並びに段階Ａにおいて記憶したＵＩリソースを復元し、ＵＩコンバイナ１５２として構成されたプロセッサ１５０を使用して汎用メモリ１４０にこれらを記憶する。モデルインスタンシエータ１５３として構成されたプロセッサ１５０を使用して、汎用メモリ１４０に記憶された視覚構成要素及び機能構成要素をＵＩリソースと結合し、結合されたモデルをインスタンス化し、入力／出力デバイス１２０のアプリケーションインターフェース１２３にソフトウェアタイプアプリケーションの画面を表示する。アプリケーションインターフェース１２３を介してユーザ要求を取得し、データベースメモリ１４０、オブジェクト論理構造１３６内のアプリケーションの操作にプロセッサ１５０の回答から得られたオブジェクトを追加する。

プロセスの段階は、下記のように詳細に説明される：
段階Ａ．メモリへとプロトコルをロードする

この段階では、図２Ａが示すように、１回だけデータベースメモリ１３０へとロードされる２つの規範が規定され、プロトコルと呼ばれる。プロセッサ１５０は、すべてのプロセス中に異なる構成でこれらのプロトコル：ｉ）機能仕様プロトコル（ＰＥＦ）；及びｉｉ）視覚仕様プロトコル（ＰＥＶ）を使用する。

これらのプロトコルは、プロセッサ１５０が、自動的に操作可能なソフトウェアアプリケーションを得るために、ソフトウェアクラス設計図（ＯＯ）及び画面設計図のすべての機能構成要素を結合するモードを確立する。

この発明では、対応する画面設計図を有するクラス図は、「ケース」として考えられる。クラス設計図は、（機能構成要素のセットから作られる）ソフトウェアアプリケーション機能を表し、画面図は、ユーザにソフトウェアタイプアプリケーションを表示する（視覚構成要素のセットから作成される）視覚構造を表している。両方のプロトコルは、下記のように説明される：

下位段階Ａ１． 機能仕様プロトコル（ＰＥＦ）をロードする

このプロトコルは、行動を規定するルールであり、プロセッサ１５０は、システム１００の操作のための論理構造を決定するクラス設計図、以降ＰＥＦ構成要素、に基づいてユーザがロードした機能構成要素を割り当てる。このプロトコルの機能を規定するアーキテクチャが、図１Ａに観察され得る。

ＰＥＦプロトコルは、ＯＯに従って、そのインスタンスがクラスであるクラスを呼ぶメタクラスを規定する。このプロトコルでは、メタクラスのインスタンスであるクラスは、モデル（Ｉｎｓｔａｎｃｅ−Ｃｌａｓｓ象限図図１Ａ）として知られている。

ＰＥＦプロトコルを使用することにより、得られるソフトウェアタイプアプリケーションの機能は、一方ではクラス設計における非明示的な言語の意味を、他方では数学的論理の意味をインスタンス化することにより取得される。「ケース」のセマンティック部分では、クラス図において識別された方法（ＯＯ）は、プロトコルを介してクラスになり、数学では、数学的機能を意味する方法（ＯＯ）は、数式になる。機能仕様プロトコルＰＥＦでは、図１Ａ象限図Ｍｏｄｅｌ−Ｃｌａｓｓに示されたように、セマンティックスを解くための３つの構成要素（ＭｏｄｅｌＣｌａｓｓ、ＭｏｄｅｌＲｅｌａｔｉｏｎＣｌａｓｓ、及びＭｏｄｅｌＡｔｔｒｉｂｕｔｅ）、並びに数学を解くための４つの構成要素（Ｄｏｍａｉｎ、ｅｘｔｅｒｎａｌ Ｄｏｍａｉｎ、Ｆｏｒｍｕｌａ及びＦｘＣａｌｌ）がある。

このプロトコルは、オブジェクトクラス（図１Ａの象限図Ｏｂｊｅｃｔ−Ｃｌａｓｓ）をやはり規定する。オブジェクトＭｏｄｅｌＯｂｊｅｃｔ及びＭｏｄｅｌＡｔｔｒｉｂｕｔｅＶａｌｕｅのこれらのクラスは、システム１００がＩｎｓｔａｎｃｅ−Ｏｂｊｅｃｔ象限図からモデルのインスタンスを記憶するために使用する構成要素である。

ＰＥＦ構成要素は、象限図Ｍｏｄｅｌ−Ｃｌａｓｓ及びＯｂｊｅｃｔ−Ｃｌａｓｓに属するものである。象限図Ｍｏｄｅｌ−Ｃｌａｓｓ内には：ＭｏｄｅｌＣｌａｓｓ、ＭｏｄｅｌＲｅｌａｔｉｏｎＣｌａｓｓ、ＭｏｄｅｌＡｔｔｒｉｂｕｔｅ、Ｆｏｒｍｕｌａ、Ｄｏｍａｉｎ、及びＦｘＣａｌｌがある。これらは、データベースメモリ１３０に、論理構造モデルＭＦ１３５に記憶される機能モデルを発するメタクラスのセットである。象限図Ｏｂｊｅｃｔ−Ｃｌａｓｓ内には：ＭｏｄｅｌＯｂｊｅｃｔ及びＭｏｄｅｌＡｔｔｒｉｂｕｔｅＶａｌｕｅがある。これらは、データベースメモリ１３０、オブジェクト１３６の論理構造に記憶されるシステムオブジェクトを生成するクラスのセットである。下記は、ＰＥＦ構成要素の説明である：

ｉ．ソフトウェアアプリケーション機能モデル（象限図Ｍｏｄｅｌ−Ｃｌａｓｓ）を発するメタクラス

ＭｏｄｅｌＣｌａｓｓ

これは、そのインスタンスがモデルであるという理由でメタクラス構成要素である。この構成要素は、ＯＯ設計図のクラスである設計構造をモデル化する。ＭｏｄｅｌＣｌａｓｓが、もう１つのＭｏｄｅｌＣｌａｓｓからもたらされることがある。

例：メタクラスＨｕｍａｎ Ｅｎｔｉｔｙ（ＭｏｄｅｌＣｌａｓｓ）、もう１つのメタクラスＰｅｒｓｏｎ（ＭｏｄｅｌＣｌａｓｓ Ｈｕｍａｎ ＥｎｔｉｔｙからもたらされるＭｏｄｅｌＣｌａｓｓ）を作成することができる。Ｐｅｒｓｏｎインスタンスは、自然人であっても法人であってもよい。自然人及び法人の両者は、メタクラスＰｅｒｓｏｎのインスタンスを構成するモデルである。

ＭｏｄｅｌＲｅｌａｔｉｏｎＣｌａｓｓ

これは、ＭｏｄｅｌＣｌａｓｓから継承するメタクラス構成要素である。ＭｏｄｅｌＣｌａｓｓを拡張する機能は、ＯＯにより規定されるような２つのタイプ：アソシエーション（ａｓｓｏｃｉａｔｉｏｎ）又はコンポジション（ｃｏｍｐｏｓｉｔｉｏｎ）であってもよい２つのＭｏｄｅｌＣｌａｓｓを関連付ける能力をこのメタクラスに与える。

例えば：ＭｏｄｅｌＣｌａｓｓ Ｐｈｙｓｉｃａｌ Ｐｅｒｓｏｎ及びＭｏｄｅｌＣｌａｓｓ Ｌｅｇａｌ Ｐｅｒｓｏｎを取り上げる場合には、自然人（Ｐｈｙｓｉｃａｌ Ｐｅｒｓｏｎ）インスタンス（Ｊｕａｎ Ｐｅｒｅｚ）が法人（Ｌｅｇａｌ Ｐｅｒｓｏｎ）インスタンス（グーグル社）の従業員であってもよいと考えられる。このケースでは、メタモデルのレベルでＭｏｄｅｌＣｌａｓｓ Ｐｅｒｓｏｎをそれ自体とリンクする「関連付けられる（ｉｓ ｒｅｌａｔｅｄ ｗｉｔｈ）」と呼ばれるＭｏｄｅｌＲｅｌａｔｉｏｎＣｌａｓｓがある。このリンクは、自然人と法人との間の雇用関係を表すために使用されることがある、又はこのリンクは、ＭｏｄｅｌＲｅｌａｔｉｏｎＣｌａｓｓが「関連付けられる」から継承する特殊性ＭｏｄｅｌＲｅｌａｔｉｏｎＣｌａｓｓが「従業員である」をそのときには作成するために、ＭｏｄｅｌＣｌａｓｓ Ｐｈｙｓｉｃａｌ Ｐｅｒｓｏｎ及びＬｅｇａｌ ＰｅｒｓｏｎのＭｏｄｅｌＣｌａｓｓ Ｐｅｒｓｏｎをやはり特殊化させることができる。

ＭｏｄｅｌＡｔｔｒｉｂｕｔｅ

これは、ＭｏｄｅｌＣｌａｓｓを構成するメタクラス構成要素である。ＭｏｄｅｌＣｌａｓｓは、ＭｏｄｅｌＡｔｔｒｉｂｕｔｅのリストを有する。ＭｏｄｅｌＡｔｔｒｉｂｕｔｅは、ＭｏｄｅｌＣｌａｓｓのインスタンスとして作成されたモデルに含まれる属性の公開である。

ＭｏｄｅｌＡｔｔｒｉｂｕｔｅは、数ある中で、生成している属性データのタイプを規定する。

プロトコルは、ＭｏｄｅｌＡｔｔｒｉｂｕｔｅについて３つのタイプのデータを規定する。

単純ＭｏｄｅｌＡｔｔｒｉｂｕｔｅ：単純なタイプは、その値インスタンスがＭｏｄｅｌＯｂｊｅｃｔインスタンスを伴わないものである。例えば：数字データ、テキストデータ、画像データ。

ＭｏｄｅｌＡｔｔｒｉｂｕｔｅ ＲｅｌａｔｉｏｎＯｂｊｅｃｔ：これらの属性は、ＭｏｄｅｌＲｅｌａｔｉｏｎＣｌａｓｓに関与のＭｏｄｅｌＣｌａｓｓ製品内に存在する。このタイプの属性は、その値インスタンスで及び関係に応じて、関係オブジェクトの１つ又は複数のインスタンスを有することができる。これは、関係の基数を決定する。例：ＭｏｄｅｌＣｌａｓｓ「Ｐｅｒｓｏｎ」とＭｏｄｅｌＣｌａｓｓ「Ａｒｔｉｃｌｅ」との間にＭｏｄｅｌＲｅｌａｔｉｏｎＣｌａｓｓがある場合には、Ａｒｔｉｃｌｅに関連付けられている当事者をインスタンスとして有するＭｏｄｅｌＣｌａｓｓ ＰｅｒｓｏｎにタイプＲｅｌａｔｉｏｎＯｂｊｅｃｔのＭｏｄｅｌＡｔｔｒｉｂｕｔｅがあり；その逆も言え：ＭｏｄｅｌＣｌａｓｓ Ｐｅｒｓｏｎは、インスタンスとしてＰｅｒｓｏｎに関係するアーティクルを有するＲｅｌａｔｉｏｎＯｂｊｅｃｔタイプＭｏｄｅｌＡｔｔｒｉｂｕｔｅを有する。

ＭｏｄｅｌＡｔｔｒｉｂｕｔｅ ＯｂｊｅｃｔＲｅｆｅｒｅｎｃｅ：このタイプのデータは、前のデータに類似しているが、関係に参加することに属するＭｏｄｅｌＣｌａｓｓの製品として現れない。属性それ自体は、それ自体のための値のインスタンスを折よく構成するオブジェクトの性質をどちらが知るかである。例：ＭｏｄｅｌＣｌａｓｓの一部としてＭｏｄｅｌＡｔｔｒｉｂｕｔｅを作成するときに、ＯｂｊｅｃｔＲｅｆｅｒｅｎｃｅを宣言される。

Ｆｏｒｍｕｌａ

数式（ｆｏｒｍｕｌａ）は、数式を呼び出すモデルから情報を受け取るために表現式及びパラメータのセットを有する独立したモデルである。数式は、実行されると、数式を呼び出しているモデルに値を常に返す。得られる値は、配列又は多次元配列の一部として１つのインスタンス又は多数のインスタンスであってもよい。

機能仕様プロトコルは、引数としてモデルインスタンスを使用する数学演算の実行を機能的に必要とするこのような論理を解くために使用される数式構成要素を規定する。数式は、代数演算、行列演算、及び集合演算のためのすべての数学演算を定め、図１ＡのＭｏｄｅｌ−Ｉｎｓｔａｎｃｅ象限図からモデルのインスタンスとして存在する引数を使用する表現式を規定することを可能にする。数学的解を暗に示す機能は、このタイプの機能がＯＯモデルからのクラスの方法として実装される慣例的なソフトウェア設計とは異なり、Ｍｅｔａｃｌａｓｓ Ｆｏｒｍｕｌａを使用して実装される。例えば、売買取引の合計値を計算する数式は、販売した単位数を加算する代数表現式を有し、販売した単位数がＭｏｄｅｌＡｔｔｒｉｂｕｔｅインスタンスの集合であるＭｏｄｅｌＡｔｔｒｉｂｕｔｅインスタンス内の１つの値を返す。

Ｄｏｍａｉｎ

ドメイン（ｄｏｍａｉｎ）は、モデルインスタンスのサブセット（セットの中の演算（ｏｐｅｒａｔｉｏｎ））を選択することを可能にする条件を宣言する構成要素である。モデルインスタンスは、ＰＥＦプロトコルに基づいてプロセッサ１５０により既に検証され構造化されているデータベースメモリ１３０内に、オブジェクト論理構造１３６内に、又はプロトコルに従っては構造化されていない外部メモリ内に見つけられることがある。結果として、ドメインは、下記のように分類される：
Ｉｎｔｅｒｎａｌ Ｄｏｍａｉｎｓ

これらのドメインは、データベースメモリ１３０の上で、数式を介して他のモデルにより処理されることがあるインスタンスの集合を求めるオブジェクト１３６論理構造で解かれる。例えば：データベースに記憶したインスタンスを取得しようとするＭｏｄｅｌＣｌａｓｓ Ｃｌｉｅｎｔである場合には、Ｉｎｔｅｒｎａｌ Ｄｏｍａｉｎは、ＭｏｄｅｌＣｌａｓｓ名及び取得しようとするインスタンスが満足すべきであるいずれかの条件でのみ使用され、呼び出されなければならない。
Ｅｘｔｅｒｎａｌ Ｄｏｍａｉｎｓ

これらは、ＰＥＦプロトコルに従って構造化されたメモリＮＯＴ（外部ファイルのデータ）の上で解かれるドメインである。これらのケースでは、外部ドメイン構成要素は、オブジェクトインスタンスをアクセスし、プロセッサ１５０は、プロトコルに基づいてオブジェクトインスタンスを構造化し、それで、オブジェクトインスタンスが内部ドメインによりアクセス可能な空間の一部を作る。例えば、データを含む３つの列：名前、年齢、及び会社を有する外部ファイルがある場合には、データを回復するために、外部ドメインが作成されなければならず、このようなフィールドがクライアントに属すること及び列と対応するＭｏｄｅｌＡｔｔｒｉｂｕｔｅ（Ｎａｍｅ列：ＭｏｄｅｌＡｔｔｒｉｂｕｔｅ Ｎａｍｅ、年齢列：ＭｏｄｅｌＡｔｔｒｉｂｕｔｅ年齢、会社列：ＭｏｄｅｌＡｔｔｒｉｂｕｔｅ Ｃｏｍｐａｎｙ）の間の一致を特定する。ＭｏｄｅｌＡｔｔｒｉｂｕｔｅ会社は、クライアントが会社に関連付けられるＲｅｌａｔｉｏｎＯｂｊｅｃｔのタイプのである。

ＦｘＣａｌｌ

この構成要素は、ＭｏｄｅｌＡｔｔｒｉｂｕｔｅインスタンスの値がＦｏｒｍｕｌａからのものであるときに、いずれかのＭｏｄｅｌＡｔｔｒｉｂｕｔｅインスタンスをＦｏｒｍｕｌａインスタンスと関係付けることを担当する。これは、数式表現式の評価を解き、数式表現式を呼び出すモデルに結果を返すモデルであり、処理すべき数学演算子及び引数をプロセッサ１５０へ送る。ＦｘＣａｌｌは、インスタンスの引数の値を更新し、それで呼び出された数式は、プロセッサ１５０からの解を要求する。

ｉｉ．ソフトウェアアプリケーションＯｂｊｅｃｔｓを発するクラス（象限図Ｏｂｊｅｃｔ−Ｃｌａｓｓ）

ＭｏｄｅｌＯｂｊｅｃｔ

ＭｏｄｅｌＣｌａｓｓからインスタンス化されたクラスのインスタンスは、ＭｏｄｅｌＯｂｊｅｃｔとして知られている。ＭｏｄｅｌＯｂｊｅｃｔは、ＭｏｄｅｌＣｌａｓｓでモデル化されたオブジェクトのインスタンスを具体化する具体的なクラスである。例えば：ＭｏｄｅｌＣｌａｓｓインスタンスであるＭｏｄｅｌ Ａｒｔｉｃｌｅは、順に具体的なインスタンスＭｏｄｅｌＯｂｊｅｃｔ「ミルク」を有する。このオブジェクトは、同時にＭｏｄｅｌＯｂｊｅｃｔインスタンスの具体化である。

ＭｏｄｅｌＡｔｔｒｉｂｕｔｅＶａｌｕｅ

ＭｏｄｅｌＡｔｔｒｉｂｕｔｅでモデル化されたモデルのインスタンスは、ＭｏｄｅｌＡｔｔｒｉｂｕｔｅＶａｌｕｅとして知られている。ＭｏｄｅｌＡｔｔｒｉｂｕｔｅＶａｌｕｅは、そのインスタンスがＭｏｄｅｌＯｂｊｅｃｔ Ｉｎｓｔａｎｃｅの値を表す具体的なクラスである。例えば：ＭｏｄｅｌＯｂｊｅｃｔ「ミルク」であり、ＭｏｄｅｌＡｔｔｒｉｂｕｔｅ名に関するそのＭｏｄｅｌＡｔｔｒｉｂｕｔｅＶａｌｕｅが「ミルク」である。

下位段階Ａ２． 視覚仕様プロトコル（ＰＥＶ）をロードする

このプロトコルは、図１Ｂに示したように、ユーザが画面設計図に基づいてロードする視覚構成要素、以降ＰＥＶ構成要素、に、プロセッサ１５０が与える行動を規定する。これらの構成要素は、システム１００を操作するために入力／出力デバイス１２０のアプリケーションインターフェース１２３に表示される視覚構造を決定する。このプロトコルの視覚提示を規定するアーキテクチャが、図１Ｂに示されている。

視覚仕様プロトコルＰＥＶは、ＰＥＦ構成要素及びＰＥＶ構成要素が関係付けられる方法を規定する。ＰＥＶ構成要素は、入力／出力デバイス１２０のアプリケーションインターフェース１２３を介して１つ又は複数のＰＥＦ構成要素の機能を表示する。

このプロトコルの規定は、アーキテクチャがＰＥＦ構成要素内に埋め込まれているという理由で、各ケースに特有の層アーキテクチャの設計を行わずにビジネスプロセス情報を生成するために操作されることがある視覚デバイス上に表示を生じさせることが可能であることを決定する。

この発明のもう１つの実施形態では、ＰＥＦ構成要素に関係しないＰＥＶ構成要素が作成される。例えば：ウェブサイトリンクを含む視覚モデル。ＰＥＶ構成要素は：Ａｐｐｌｉｃａｔｉｏｎ、ＡｃｔｉｏｎＬｉｎｋ、ＡｂｍＶｉｅｗＭｏｄｅｌ、ＬｉｓｔＶｉｅｗＭｏｄｅｌ、ＴｒｅｅＶｉｅｗＭｏｄｅｌ、ＲｅｐｏｒｔＶｉｅｗＭｏｄｅｌである。

Ａｐｐｌｉｃａｔｉｏｎ

Ａｐｐｌｉｃａｔｉｏｎ構成要素は、ソフトウェアアプリケーションを視覚的に構造化する。プロトコルは、アプリケーションを特定するＭｏｄｅｌとしてＡｐｐｌｉｃａｔｉｏｎ構成要素を規定する。アプリケーションは、ユーザが提示された機能にアクセスすることを可能にする最も重要な態様としてＭｅｎｕを規定する。Ｍｅｎｕは、ツリーのＭｅｎｕＧｒｏｕｐモデル及びＭｅｎｕＩｔｅｍモデルの集合であり、ここでは、ＭｅｎｕＧｒｏｕｐは、他のＭｅｎｕＧｒｏｕｐ又はＭｅｎｕＩｔｅｍを同時に含むことができる。ＭｅｎｕＩｔｅｍは、ユーザがＭｅｎｕＩｔｅｍをクリックするときに取られるべき行動をリンクするものである。アイテムは、下記の可視化モデル（ＶｉｗＭｏｄｅｌ）：ＡｂｍＶｉｅｗＭｏｄｅｌ、ＬｉｓｔＶｉｅｗＭｏｄｅｌ、ＴｒｅｅＶｉｅｗＭｏｄｅｌのうちのいずれかと関係付けられる。ユーザがＭｅｎｕＩｔｅｍを実行すると、システム１００のプロセッサ１５０は、アプリケーションインターフェース１２３を介してこのような要求を受け取り、ＭｅｎｕＩｔｅｍに関係付けられたＰＥＶ構成要素により呼び出された構成要素ＰＥＦの機能をユーザが実行することを可能にする同じインターフェース内の構造を返す。

ＶｉｅｗＭｏｄｅｌ

ＶｉｅｗＭｏｄｅｌ構成要素は、視覚デバイス上にＭｏｄｅｌＯｂｊｅｃｔインスタンスを公開するのに役立つ。ＶｉｅｗＭｏｄｅｌ構成要素は、ＶｉｅｗＭｏｄｅｌがＭｏｄｅｌＣｌａｓｓモデルにしたがった動作を実行することを可能にするＡｃｔｉｏｎＬｉｎｋ構成要素から作られており、ＭｏｄｅｌＣｌａｓｓモデルから、インスタンス及びＶｉｅｗＭｏｄｅｌ構成要素が参照するＶｉｅｗＭｏｄｅｌのクラスである。

ＰＥＶ構成要素は、ＶｉｅｗＭｏｄｅｌ及びその特性に基づいて入力／出力デバイス１２０のアプリケーションインターフェース１２３に表示されるレイアウト（テンプレート又は視覚レイアウト構造）を規定する。

モデルインスタンスを表示するために、ＶｉｅｗＭｏｄｅｌの３つのクラス：異なる特性及びレイアウト設定値を有するＡｂｍＶｉｅｗＭｏｄｅｌ、ＬｉｓｔＶｉｅｗＭｏｄｅｌ、及びＴｒｅｅＶｉｅｗＭｏｄｅｌがある。
（１）ＡｂｍＶｉｅｗＭｏｄｅｌ

プロトコルは、ＭｏｄｅｌＯｂｊｅｃｔ Ｍｏｄｅｌを作成すること、消去すること又は更新することを可能にする画面の表現を指定するＭｅｔｈｏｄとしてＡｂｍＶｉｅｗＭｏｄｅｌ構成要素を規定する。画面表現は、対応するＭｏｄｅｌＣｌａｓｓモデルに従ってＭｏｄｅｌｏｂｊｅｃｔインスタンスのＭｏｄｅｌＡｔｔｒｉｂｕｔｅＶａｌｕｅのすべて又はいくつかを表示する。

ＡｂｍＶｉｅｗＭｏｄｅｌがＶｉｅｗＭｏｄｅｌであり、ＣｏｎｔｒｏｌＶｉｅｗＴｙｐｅ構成要素を介してその機能を及びＡｂｍＶｉｅｗＭｏｄｅｌの特殊な特性を拡張するという理由で、ＡｂｍＶｉｅｗＭｏｄｅｌは、ＡｃｔｉｏｎＬｉｎｋ構成要素から作られる。

ＣｏｎｔｒｏｌＶｉｅｗＴｙｐｅ構成要素は、属性データのタイプに従ってＭｏｄｅｌＡｔｔｒｉｂｕｔｅＶａｌｕｅｓを公開する。ここで、ＣｏｎｔｒｏｌＶｉｅｗＴｙｐｅは、発明の実施形態に関する属性のタイプのリストである。

ＴｅｘｔＥｄｉｔｏｒ：テキストタイプＭｏｄｅｌＡｔｔｒｉｂｕｔｅＶａｌｕｅｓを公開する。

ＮｕｍｅｒｉｃＥｄｉｔｏｒ：数値タイプＭｏｄｅｌＡｔｔｒｉｂｕｔｅＶａｌｕｅｓを公開する。

ＤａｔａＴｉｍｅＥｄｉｔｏｒ：データタイプＭｏｄｅｌＡｔｔｒｉｂｕｔｅＶａｌｕｅｓを公開する。

ＯｂｊｅｃｔＲｅｆｅｒｅｎｃｅＣｏｍｂｏＥｄｉｔｏｒ：ＭｏｄｅｌＯｂｊｅｃｔｓセレクタタイプＭｏｄｅｌＡｔｔｒｉｂｕｔｅＶａｌｕｅｓを公開する。

ＯｂｊｅｃｔＲｅｆｅｒｅｎｃｅＬｉｓｔＥｄｉｔｏｒ：ＭｏｄｅｌＯｂｊｅｃｔｓセレクタタイプＭｏｄｅｌＡｔｔｒｉｂｕｔｅＶａｌｕｅｓを公開する。

ＡｂｍＶｉｅｗＭｏｄｅｌを構成するＡｃｔｉｏｎＬｉｎｋ構成要素は：

Ｓａｖｅ：ＭｏｄｅｌＯｂｊｅｃｔインスタンスをトランザクションデータベースの内部に保存する。

Ｃａｎｃｅｌ：ＡｂｍＶｉｅｗＭｏｄｅｌにより表示された視覚構造を閉じ、ｍｏｄｅｌＯｂｊｅｃｔのインスタンスにユーザにより行われた変更を破棄する。

Ｓａｖｅ ａｎｄ Ｎｅｗ：ＭｏｄｅｌＯｂｊｅｃｔインスタンスを保存し、ユーザが属性の値を埋めるように新しいインスタンスを作成し、ＡｂｍＶｉｅｗＭｏｄｅｌの視覚構造に新しいインスタンスを提示する。

Ｐｒｉｎｔ：修正されようとしているインスタンスから属性値をプリントする。

発明のある実施形態では、他のＶｉｅｗＭｏｄｅｌｓを呼び出す追加された動作がある。

ＡｂｍＶｉｅｗＭｏｄｅｌの特殊な特性：

ＡｔｔｒｉｂｕｔｅＲｅｎｄｅｒＩｎｆｏ：このモデルは、ＭｏｄｅｌＯｂｊｅｃｔのある種のインスタンス属性の値を表す制御の表現特殊性を表すために使用される。

ＣｏｎｔｒｏｌＴｅｍｐｌａｔｅ：ＭｏｄｅｌＡｔｔｒｉｂｕｔｅを表現するためにセレクタを制御する。属性データタイプに応じて、これは、タイプの性質に従って様々な方法で表されることがある。ＣｏｎｔｒｏｌＴｅｍｐｌａｔｅは、可能な選択肢のどれが属性を効果的に表現するかの指示を可能にする概念である。

Ｃｏｎｔａｉｎｅｒ：ＡｂｍＶｉｅｗＭｏｄｅｌ内には、視覚デバイス内の制御レイアウトを管理するためにコンテナの構造がある。属性を視覚的に表示する構成要素の各々は、コントロールとして知られている。コンテナのこの構造は、ツリーの形式である、言い換えると、コンテナは、他を含むことができる。

ＣｏｌｕｍｎＶｉｅｗＭｏｄｅｌ：コンテナ内では、コントロールは、列の下に設定され、列が含むコントロールのための内部順序を有する。
（２）ＬｉｓｔＶｉｅｗＭｏｄｅｌ

プロトコルは、ＭｏｄｅｌＯｂｊｅｃｔインスタンスの集合を列挙する画面の表現を特定するモデルとしてＬｉｓｔＶｉｅｗＭｏｄｅｌ構成要素を規定する。この画面の表現は、表に示されているＭｏｄｅｌＯｂｊｅｃｔインスタンスの集合のためのインスタンスであるＭｏｄｅｌＣｌａｓｓモデルに従ってこのようなＭｏｄｅｌＯｂｊｅｃｔが有するＭｏｄｅｌＡｔｔｒｉｂｕｔｅＶａｌｕｅを表し、表では、各ＭｏｄｅｌＡｔｔｒｉｂｕｔｅＶａｌｕｅがセルに当てはめられ、ここで、行はインスタンスに対応し、列はＭｏｄｅｌＡｔｔｒｉｂｕｔｅに対応する。

ＬｉｓｔＶｉｅｗＭｏｄｅｌ構成要素は、これがＶｉｅｗＭｏｄｅｌであり、構成要素ＳｅａｒｃｈＶｉｅｗＭｏｄｅｌ、ＣｏｌｕｍｎＶｉｅｗＭｏｄｅｌ、ＯｂｊｅｃｔＲｅｆｅｒｅｎｃｅＬｉｓｔＧｒｉｄＥｄｉｔｏｒ及びＬｉｓｔＶｉｅｗＭｏｄｅｌの特殊な特性を介してその機能を拡張するのでＡｃｔｉｏｎＬｉｎｋ構成要素から作られる。

ＬｉｓｔＶｉｅｗＭｏｄｅｌに適合するＡｃｔｉｏｎＬｉｎｋ構成要素は：Ｎｅｗ；Ｃｕｔ；Ｅｄｉｔ；Ｐｒｉｎｔ；Ｅｘｅｃｕｔｅ Ｆｏｒｍｕｌａである。

加えて、ＲｅｌａｔｉｏｎＯｂｊｅｃｔリストに関して、下記の動作が生じる：

ＮｅｗＭＴａｒｇｅｔ：関係ターゲットとして指定されたモデルの新たなＭｏｄｅｌＯｂｊｅｃｔの作成を呼び出す。

ＮｅｗＭＴａｒｇｅｔ＆Ａｓｓｏｃｉａｔｅ：関係ターゲットとして指定されたモデルの新たなＭｏｄｅｌＯｂｊｅｃｔの作成を呼び出し、関係の属性のＭｏｄｅｌＯｂｊｅｃｔ所有者と関係を実現する。

ＤｅｌｅｔｅＭＴａｒｇｅｔ：関係のインスタンスにおいて、関係するＭｏｄｅｌＯｂｊｅｃｔ並びに関係のインスタンスを削除する。

ＥｄｉｔＭｔａｒｇｅｔ：関係するＭｏｄｅｌＯｂｊｅｃｔの編集画面を呼び出す。

ＬｉｓｔＶｉｅｗＭｏｄｅｌの特別な特性：

Ｈｉｅｒａｒｃｈｉｃａｌ ｖｉｅｗ：これは、ＭｏｄｅｌＲｅｌａｔｉｏｎＣｌａｓｓモデルにより関係付けられたオブジェクトのグラフの階層構造表示を指す。

ＩｎＬｉｎｅ Ｅｄｉｔｉｏｎ：リストの同じ行内のオブジェクトの属性を修正することをサポートする。
（１）ＴｒｅｅＶｉｅｗＭｏｄｅｌ

プロトコルは、ＲｅｌａｔｉｏｎＯｂｊｅｃｔｓにより関係付けられたＭｏｄｅｌＯｂｊｅｃｔｓツリーの表現を特定するモデルとしてＴｒｅｅＶｉｅｗＭｏｄｅｌ構成要素を規定する。この画面の表現は、基本的に、このようなＲｅｌａｔｉｏｎＯｂｊｅｃｔｓが関係するＭｏｄｅｌＣｌａｓｓから呼び出すＭｏｄｅｌＡｔｔｒｉｂｕｔｅＶａｌｕｅｓのすべて又はいくつかの公開である。

ＴｒｅｅＮｏｄｅＭｏｄｅｌ構成要素に表されたツリーノードは、ＭｏｄｅｌＯｂｊｅｃｔのインスタンス及び問題のノードとその親との間の存在する関係であるＲｅｌａｔｉｏｎＯｂｊｅｃｔのインスタンスを表す。このように、ツリーの第１のレベルノードは、これらがいずれの親ノードにも関係しないので、ＲｅｌａｔｉｏｎＯｂｊｅｃｔのいずれのインスタンスによっても公開されない。

ＴｒｅｅＶｉｅｗＭｏｄｅｌ構成要素がＶｉｅｗＭｏｄｅｌであり、ＴｒｅｅＶｉｅｗＭｏｄｅｌの特殊な特性を介してその機能を拡張するので、ＴｒｅｅＶｉｅｗＭｏｄｅｌ構成要素は、ＡｃｔｉｏｎＬｉｎｋ構成要素から作られる。

ＴｒｅｅＶｉｅｗＭｏｄｅｌに適合するＡｃｔｉｏｎＬｉｎｋ構成要素は：

Ｎｅｗ：これは、行動が呼び出されようとしているノードについてのツリーの表示モデルにしたがった対応するＭｏｄｅｌＲｅｌａｔｉｏｎＣｌａｓｓに基づいて新たなＲｅｌａｔｉｏｎＯｂｊｅｃｔインスタンスを作成する。

Ｄｅｌｅｔｅ：これは、現在のノードをその親ノードとリンクするＲｅｌａｔｉｏｎＯｂｊｅｃｔインスタンスを削除する。

Ｅｄｉｔ：これは、現在のノードをその親ノードとリンクするＲｅｌａｔｉｏｎＯｂｊｅｃｔインスタンスを編集する。

ＮｅｗＭＴａｒｇｅｔ：これは、行動が呼び出されようとしているノードについてのツリーの表示モデルにしたがった対応するＭｏｄｅｌＲｅｌａｔｉｏｎＣｌａｓｓモデルについての関係のターゲットに対応する新たなＭｏｄｅｌＯｂｊｅｃｔインスタンスの作成を呼び出す。

ＮｅｗＭＴａｒｇｅｔ＆Ａｓｓｏｃｉａｔｅ：ＮｅｗＭＴａｒｇｅと同じく、行動が呼び出されたノードによって表されたＭｏｄｅｌＯｂｊｅｃｔと新たなＭｏｄｅｌＯｂｊｅｃｔとをリンクさせるためにＲｅｌａｔｉｏｎＯｂｊｅｃｔインスタンスを次いで作成することを追加される。

ＥｌｉｍｉｎａｔｅＭＴａｒｇｅｔ：これは、現在のノードによって表されたＭｏｄｅｌＯｂｊｅｃｔインスタンスを削除する。

ＥｄｉｔＭｔａｒｇｅｔ：現在のノードによって表されたＭｏｄｅｌＯｂｊｅｃｔインスタンスを編集する。

ＴｒｅｅＶｉｅｗＭｏｄｅｌの特殊な特性：

ＬｏａｄＯｎＤｅｍａｎｄ：これは、ユーザがツリーを拡張することと対話する一方で、ツリーがそのノードに気付き、ロードすべきかどうかを指示する。

ＳｈｏｗＥｘｐａｎｄｅｄ：これは、ツリーを可視化するときに、ツリーが拡張したノードのすべてとともに表示されるべきであることを指示する。

ＥｄｉｔＯｎＣｌｉｃｋ：これは、ユーザがクリックすると、ノードによって表されたオブジェクトの編集が呼び出されるべきであることを指示する。
（４）ＡｃｔｉｏｎＬｉｎｋ

ＡｃｔｉｏｎＬｉｎｋ構成要素は、ＭｏｄｅｌＯｂｊｅｃｔのインスタンスに実行するためにＶｉｅｗＭｏｄｅｌにおいて利用可能である動作を規定する。

各ＶｉｅｗＭｏｄｅｌサブクラスは、視覚デバイスに公開された機能に関してＡｃｔｉｏｎＬｉｎｋの異なるリストを有する。
（５）ＲｅｐｏｒｔＶｉｅｗＭｏｄｅｌ

ＲｅｐｏｒｔＶｉｅｗＭｏｄｅｌは、モデルインスタンシエータ１５３として構成されたプロセッサ１５０が、例えば、Ｒｅｐｏｒｔｉｎｇ Ｓｅｒｖｉｃｅｓのような任意のレポート配送サービスと対話することができるように、必要な仕様を含む。

ＭｏｄｅｌＯｂｊｅｃｔインスタンスレポジトリがクエリ方法と矛盾しないので、これらのサービスが、レポートを容易に発生し、埋め込むことが可能であるこれらの技術を備え、すべての必要なレポート用の構成を有する表示構成要素を使用させるような方法で実装することが可能である。

下位段階Ａ３． ＵＩリソースをロードする

視覚仕様プロトコルＰＥＶは、プロセッサ１５０が視覚構成要素をＵＩリソースと結合することができるような方法で設計される。この結合の目的は、プロセッサがユーザインターフェースをモデル化するためにこれらの構成要素を迅速に利用可能させることができることである。これは、ＵＩリソースとそしてＶｉｅｗＭｏｄｅｌから直接リンクされる下位段階Ａ２においてロードしたＰＥＶプロトコルのＣｏｎｔｒｏｌＶｉｅｗＴｙｐｅの概念を通して可能であり、どのＵＩリソースが、入力／出力デバイス、アプリケーションインターフェース１２３上のユーザインターフェースのある種の部分を表すかを示している。

ＵＩリソースは、任意のＵＩ言語（例えば、ＨＴＭＬ５）で宣言された一部分であり、その外観は、階層式スタイルシート（ｃｓｓ）で調節されることが可能である。これらのリソースは、データベースメモリ１３０、論理構造ＵＩリソース１３３に記憶される。次いで、ＵＩコンバイナ１５２として設定されたプロセッサ１５０が、その機能を実行すると、プロセッサは、これらのＵＩリソースをデータベースメモリ１３０、論理構造モデルＭＶ１３４に存在する論理構造ＣｏｎｔｒｏｌＶｉｅｗＴｙｐｅのインスタンスとリンクし、これらの融合させたモデルをソフトウェアタイプアプリケーションの提示において使用されるように利用可能なままにする。
段階Ｂ． 設計構成要素を識別し、記憶する

設計がこの発明により包含されるプロセスへの入力として重要であるという理由で、設計が記述される。

設計ドキュメントは、図２Ｂに示したように、２つのタイプの知られている図を特に参照して、ソフトウェアタイプアプリケーションを規定する機能及び視覚構造を規定する。

機能設計を表すクラス図（２２０）。これらの設計値は、機能モデルの作成において使用される。

要求される視覚設計を表す画面図（２２１）。これらの設計値は、視覚モデルを作成するために使用される。

機能設計及び画面設計のこの段階の時点では、下記の下位段階が行われる：

下位段階Ｂ１． 機能設計構成要素を識別する

解決されるべき論理を表すクラス設計（２２０）に基づいて、図に存在するクラスを列挙する。クラス図に基づき、構成要素のタイプがＯＯパラダイムに従って規定されることを考慮してクラスの構成要素を識別し、下位段階Ａ１においてロードしたＰＥＦプロトコルにより何が確立されたかに従って、ＭｏｄｅｌＣｌａｓｓ構成要素に対応させる。図２Ｂ１の例に示されているように、識別した各構成要素の名前を識別し、図２Ｃ１の例に認められ得る通りに、対応するＰＥＦ構成要素を決定し、このようである：

図がクラスを表す場合には、機能構成要素タイプＯＯ Ｃｌａｓｓを識別し、ＰＥＦ ＭｏｄｅｌＣｌａｓｓ構成要素がこれに対応することを判断する。

図がクラス内の属性を表す場合には、機能構成要素タイプＯＯ Ａｔｔｒｉｂｕｔｅを識別し、ＰＥＦ ＭｏｄｅｌＡｔｔｒｉｂｕｔｅがこれに対応することを判断する。

図が関係を表す場合には、機能構成要素タイプＯＯ Ｒｅｌａｔｉｏｎｓｈｉｐを識別し、ＰＥＦ ＭｏｄｅｌＲｅｌａｔｉｏｎＣｌａｓｓがこれに対応することを判断する。

図がクラス内の方法を表す場合には、機能構成要素タイプＯＯ Ｍｅｔｈｏｄを識別し、下記を決定する：

方法が代数数学計算に言及する場合には、これはＰＥＦ Ｆｏｒｍｕｌａ構成要素に対応する。

方法が集合理論に等価な数学機能に言及する場合には、システムの外部のデータを参照するケースでは外部にあるはずのＰＥＦ Ｄｏｍａｉｎ構成要素に対応する。

図が継承を公開する場合には、機能構成要素タイプＯＯ Ｉｎｈｅｒｉｔａｎｃｅを識別し、象限図Ｍｏｄｅｌ−ＣｌａｓｓのＰＥＦプロトコルに規定されるように、２つのＭｏｄｅｌＣｌａｓｓ間の継承関係がこれに対応することを判断する。

ユーザは、入力／出力デバイス１２０、ＣＤインターフェース１２１を介して、識別したＰＥＦ構成要素をロードし、モデルバリデータ１５１として構成されたプロセッサ１５０は、汎用メモリ１４０、論理構造ＭＦマトリックス１４２にＰＥＦ構成要素を記憶させる。

下位段階Ｂ２． 視覚設計構成要素を識別する

モデルインスタンシエータ１５３として構成されたプロセッサ１５０により自動的に構築されるソフトウェアタイプアプリケーションを見ること及び対話することを人が望む方法を表している画面設計を参照すると、「ケース」のためのソフトウェアタイプアプリケーションを公開するように作成されるはずの視覚モデルを決定するために実行されるべきステップが、下記のように説明される。

ＰＥＦ構成要素リストに基づいて、視覚仕様プロトコルが段階Ａにおいてロードされ、ＭｏｄｅｌＣｌａｓｓタイプの概念を識別し、下記のようにプロトコルＰＥＶ（Ａｐｐｌｉｃａｔｉｏｎ、ＡｂｍＶｉｅｗＭｏｄｅｌ、ＬｉｓｔＶｉｅｗＭｏｄｅｌ、ＴｒｅｅＶｉｅｗＭｏｄｅｌ）を規定する視覚モデルを作成する：

ａ．各ＭｏｄｅｌＣｌａｓｓに対して、下記のＶｉｅｗＭｏｄｅｌが作成されるはずである：ＡｂｍＶｉｅｗＭｏｄｅｌ、ＬｉｓｔＶｉｅｗＭｏｄｅｌ。

ｂ．各モデルＲｅｌａｔｉｏｎＣｌａｓｓに対して、下記のＶｉｅｗＭｏｄｅｌが作成されるはずである：ＬｉｓｔＶｉｅｗＭｏｄｅｌ、ＴｒｅｅＶｉｅｗＭｏｄｅｌ。

ｃ．すべてのＰＥＦ構成要素を表示するために、下記が作成されるはずである：ＡｐｐｌｉｃａｔｉｏｎＭｏｄｅｌ、ＭｅｎｕＶｉｅｗＭｏｄｅｌモデル、ＭｅｎｕＧｒｏｕｐモデル及び前のステップにおいて作成された各ＶｉｅｗＭｏｄｅｌに関するＩｔｅｍＧｒｏｕｐモデル。

この発明のもう１つの実施形態では、システム１００は、プロセス入力として利用可能な「ケース」に対応する画面設計値とおそらく最も近い類似性を実現するために作成された視覚モデルを編集することを可能にする。

ユーザは、入力／出力デバイス１２０、インターフェースＣＤＶ１２２を介して、識別したＰＥＦ構成要素をロードし、モデルバリデータ１５１として構成されたプロセッサ１５０は、汎用メモリ１４０、論理構造ＭＶマトリックス１４３にＰＥＦ構成要素を記憶する。
段階Ｂ’． 自然言語からＣＦ及びＣＤを発生する

この発明の実施形態では、図３Ａに示したように、段階Ｂ’が段階Ｂを置き換える。

この段階では、ユーザは、自然言語からＣＦ及びＣＤを発生する。例えば、その全体を参考文献として提出した、「ＰＲＯＣＥＳＳ ＡＮＤ ＳＹＳＴＥＭ ＦＯＲ ＡＵＴＯＭＡＴＩＣ ＧＥＮＥＲＡＴＩＯＮ ＯＦ ＦＵＮＣＴＩＯＮＡＬ ＡＲＣＨＩＴＥＣＴＵＲＥ ＤＯＣＵＭＥＮＥＴＳ ＡＮＤ ＳＯＦＴＷＡＲＥ ＤＥＳＩＧＮ ＡＮＤ ＡＮＡＬＹＳＩＳ ＳＰＥＣＩＦＩＣＡＴＩＯＮ ＤＯＣＵＭＥＮＴＳ ＦＲＯＭ ＮＡＴＵＲＡＬ ＬＡＮＧＵＡＧＥ」という名称の米国特許出願公開第１５／１４１，７４８号に記載されているように使用する。

この実施形態では、次の下位段階が続く：

下位段階Ｂ’１． 機能構成要素を取得する

プロセッサ１５０は、米国特許出願公開第１５／１４１，７４８号で識別されたデータベースメモリ、論理構造１７２に接続し、「ケース」から機能構成要素を取得し、ＭＦマトリックス１４２に機能構成要素を記憶する。

下位段階Ｂ’２ 視覚構成要素を識別する

プロセッサ１５０は、下位段階Ｂ’１中に取得した機能構成要素のリストを通読し、下位段階Ａ２において規定した視覚仕様プロトコルＰＥＦを適用する。図２Ｃ２に示されているように、各機能構成要素から１つ又は複数の視覚構成要素を取得し、ＭＶマトリックス１４３に視覚構成要素を記憶する。
段階Ｃ． 機能モデル及び視覚モデルを作成する

この段階では、プロセッサ１５０は、汎用メモリ１４０、論理構造ＭＦマトリックス１４２から下位段階Ｂ１において作成されたＰＥＦ構成要素を引き出し、次の下位段階が続く：

下位段階Ｃ１． ＰＥＦ構成要素を識別し、機能モデルを作成する

この下位段階では、図２Ｃに示されているように、プロセッサ１５０は、下位段階Ｂ１において作成され、汎用メモリ１４０内の利用可能なＰＥＦ構成要素を識別し、下位段階Ａ１においてロードしたプロトコルに従ってＰＥＦ構成要素を特定する。次いで、プロセッサ１５０が「ケース」のためのソフトウェアタイプアプリケーションをインスタンス化するために使用する機能を特定する機能モデルを作成する。プロセッサ１５０は、これらのステップにしたがう：

１．下位段階Ｂ１において決定されたように、どんなＰＥＦ概念が設計構成要素の各ＯＯタイプに関する仕様プロトコルに基づいて作成されなければならないかを識別するためにリストを通読する。

２．関係付けられたＰＥＦ概念が数式であるこれらの設計構成要素に関して、下記の追加のＰＥＦ構成要素を作成する：

ａ．これは、ＰＥＦ構成要素ＦｘＣａｌｌタイプを作成し、これを同じクラス内の数式を使用するＭｏｄｅｌＡｔｔｒｉｂｕｔｅにリンクする。

ｂ．数式論理が方法の設計構成要素所有者に属さない属性の使用を暗に示す場合には、数式論理は、数式の引数として作用するデータを設置するＰＥＦ概念Ｄｏｍａｉｎタイプを作成する。

プロセッサ１５０は、データベースメモリ１３０、論理構造モデルＭＦ１３５に記憶された機能モデルを記憶する。

プロセスのクラス設計入力の変換は、機能仕様プロトコルＰＥＦを適用すると、その時にはプロセッサ１５０により解釈され、モデルインスタンシエータ１５３として構成されるモデルのセットに由来する。

下位段階Ｃ２． ＰＥＦ構成要素を識別し、視覚モデルを作成する

この下位段階では、図２Ｃ２に示されているように、プロセッサ１５０は、下位段階Ｂ２において作成され、汎用メモリ１４０内の利用可能なＰＥＦ構成要素を識別し、下位段階Ａ２においてロードしたプロトコルにしたがうＰＥＶ概念を特定する。その後、プロセッサ１５０が入力／出力デバイス１２０のアプリケーションインターフェース１２３内の情報構造を表している「ケース」についてのソフトウェアタイプアプリケーションを表示するために使用する機能を特定する視覚モデルを作成する。プロセッサ１５０は、これらの次のステップにしたがう：
１．視覚仕様プロトコル（ＰＥＶ）において何が確立されているかに基づいて下位段階Ｂ２において作成されたＰＥＦ概念のリストを通読する。
２．前の段階で識別された各ＰＥＶ概念に対して、ＰＥＶプロトコルにおいて何が確立されているかに従って視覚モデルを作成する。
３．「ケース」を表している名前を有する視覚モデルＡｐｐｌｉｃａｔｉｏｎタイプを作成する。
４．代表する名前を有する視覚モデルＭｅｎｕタイプ及び設計構成要素の各々毎にＭｅｎｕ Ｇｒｏｕｐを作成し、設計構成要素名をグループに割り当てる。
５．設計構成要素により作成された各視覚モデル当たり１つ、各Ｍｅｎｕグループ内に２つのＭｅｎｕ項目を作成する。例えば：クラス構成要素１について、「Ｃｌａｓｓ」と名付けたＭｅｎｕグループそして次いで２つのＭｅｎｕ項目：１つは「ＡＢＭ Ｃｌａｓｓ１」と呼ばれ、もう１つは「Ｌｉｓｔ Ｃｌａｓｓ１」と呼ばれる、を作成する。各Ｍｅｎｕ項目をその名前に対応する視覚モデルとリンクする。

視覚モデルは、視覚モデルと機能モデルとの間のリンクを修正せずに編集される。視覚モデルを編集するときに、段階Ａにおいてロードされたプロトコルにおいて何が確立されているかに従って、それぞれの視覚モデルと機能モデルとの間に存在するリンクを変えずに入力／出力デバイス１２０内のレイアウト構成要素について、大きさ及び位置が変更される。

プロセッサ１５０は、データベースメモリ１３０、論理構造ＭＶモデル１３４に視覚モデルを記憶する。
段階Ｃ’． 機能モデル及び視覚モデルを組み込む

この発明の実施形態では、図３Ｂに示されているように、段階Ｃ’は段階Ｃの置き換えである。

この段階では、ユーザにより作成された機能モデル及び視覚モデルが、下位段階Ａ１及びＡ２において規定したプロトコルの基準を手作業で適用して組み込まれる。

入力／出力デバイス１２０により、ユーザは、手作業で作った機能モデルをデータベースメモリ１３０、論理構造モデルＭＦ１３５へとロードする。

入力／出力デバイス１２０により、ユーザは、手作業で作った機能モデルをデータベースメモリ１３０、論理構造モデルＭＶ１３４へとロードする。
段階Ｄ． 操作可能なソフトウェアタイプアプリケーションとして機能モデル及び視覚モデルを読み取り、インスタンス化する

この段階では、モデルインスタンシエータ１５３として構成されたプロセッサ１５０は、汎用メモリ１４０が記憶する結合型モデルを構築する目的でデータベースメモリ１３０にアクセスする。結合型モデルは、機能モデルＭＦ（ＰＥＦプロトコルに基づいて規定される）を視覚モデルＭＶ（プロトコル毎に基づいて規定される）と結合するモデルである。これゆえ、結合型モデルは、ユーザによってアクセス可能であり、操作可能であるソフトウェアタイプアプリケーションとして、アプリケーションインターフェース１２３に表示される単一のモデルに結合され、任意のＵＩリソース１３３に関係付けられた視覚モデルの機能及び定義を表す。

モデルインスタンシエータ１５３として構成されたプロセッサ１５０により生成された結果は、ソフトウェアタイプアプリケーションに関する解釈及び配送サービスにより表示される。ユーザがこのサービスを認証すると、見る最初のものは、対話することを開始するために用いるアプリケーションのインターフェースである。

この発明では、解釈は、サービスとしてそして結合型モデル（Ｍｏｄｅｌ ＭＦ＋Ｍｏｄｅｌ ＭＶ＋ＵＩリソース）を読むことにより実行されるプロセスであり、解釈は、入力／出力デバイス１２０のアプリケーションインターフェース１２３に表示されたソフトウェアタイプアプリケーションにおいてユーザにより実行された動作を解決する。

システム１００を実行することの主な結果として、下記を取得することが可能である：

アプリケーションインターフェース１２３に表示されたソフトウェアタイプアプリケーション。

ソフトウェアタイプアプリケーションと対話することにより作成されたユーザが発生した情報のセット、一般に「ユーザデータ」と呼ばれ、プロセッサ１５０がデータベースメモリ１３０、論理構造オブジェクト１３６に記憶する。

この結果を満足させるために、モデルインスタンシエータ１５３として構成されたプロセッサ１５０は、これらの下位段階にしたがう：

下位段階Ｄ１． 視覚モデルＭＶを読み取り、解釈する

モデル（機能及び視覚の両者）は、段階Ａでロードされ、それぞれデータベースメモリ１３０、論理構造ＰＥＦ１３２及びＰＥＶ１３１に記憶されたプロトコルを尊重する構造である。

この下位段階では、モデルインスタンシエータ１５３として構成されたプロセッサ１５０は、下位段階Ａ２においてロードしたＰＥＶプロトコルからの定義に従って記憶され、検証される視覚モデルをデータベースメモリ１３０、論理構造モデルＭＶ１３４から再生する。

一旦、視覚モデルが読み取られると、システム１００は、レイアウト内にＭｏｄｅｌＯｂｊｅｃｔ及びＡｃｔｉｏｎＬｉｎｋインスタンスの配置を配列するレイアウト構造を構成し、このような構造を汎用メモリ１４０、論理構造ＵＩ構成要素マトリックス１４１に記憶する。

下位段階Ｄ２． 機能モデルＭＦを読み取り、解釈する

この下位段階では、モデルインスタンシエータ１５３としてのプロセッサ１５０は、下位段階Ａ１中にロードしたＰＥＦプロトコルの定義に従って記憶され、検証されているデータベースメモリ１３０、論理構造モデルＭＦ１３５の機能モデルを読み取る。

システム１００のプロセッサ１５０は、３つのタイプの機能モデル：計算モデル、データ持続性モデル及び対話型データモデルを処理する：

計算モデル：表現式を解くサービスへ表現式を運ぶＭＦリポジトリに見つけられた数式クラスからの表現式を処理し、ＦｘＣａｌｌを介してＭｏｄｅｌＡｔｔｒｉｂｕｔｅのインスタンスの形式で結果を返す。

データ持続性モデル：Ｏｂｊｅｃｔリポジトリ１３６内で動作するＤｏｍａｉｎクラスにより提供されるデータベースメモリ１３０へのアクセス表現式を処理し、リポジトリＭＦで見つけられたものを実行する。

対話型データモデル：ユーザが対話する各ＶｉｅｗＭｏｄｅｌ毎のＡｃｔｉｏｎＬｉｎｋにより対話式に、アプリケーションインターフェース１２３からユーザが入力したデータを処理する。

一旦、機能モデルが読み取られると、システム１００プロセッサ１５０は、ビジネスタイプ構造を解釈し、インスタンス化し、これを下位段階Ｄ１において作成された視覚構造にリンクされた汎用メモリ１４０、論理構造ＵＩ構成要素マトリックスに記憶し、ここで、インスタンス化された視覚モデルと機能モデルとの間のリンクが段階Ａにおいてロードしたプロトコルから論理に応答する。

下位段階Ｄ３． ＵＩリソースを選択し、結合する

ＵＩリソースは、データベースメモリ１３０、ＵＩリソース論理構造に予め記憶されたソフトウェア構成要素であり、ＵＩリソース論理構造は、視覚モデルに基づいて実行されると、アプリケーションインターフェース１２３内の画面上に図を表現する。これらは、視覚モデルを処理するための定義である。ソフトウェア産業では、異なるＵＩリソースセットが利用可能であり、これらは、得られたソフトウェアタイプアプリケーション用に異なる視覚化モードを提案するために、下位段階Ａ３に示されているようなシステムに組み込まれることがある。

各融合モデルを完成させるために、システム１００は、マトリックスＭＦ１４２から構成要素、マトリックスＭＶ１４３からその対応する構成要素、及び選択したＭＶのタイプと互換性のあるＵＩリソース１３３を選択する。ＵＩコンバイナ１５２として構成されたプロセッサ１５０は、選択した構成要素を結合し、ＵＩリソースの機能のための引数、構成要素が機能することを必要とする結合型モデル（Ｍｏｄｅｌ ＭＦ＋関係するＭｏｄｅｌ ＭＶ）の部品として配送する。

このようにして、プロセッサ１５０は、入力／出力デバイス１２０に結合型構成要素を提示し、「ケース」に対して作成された構成要素の各々について手順を繰り返す。表示された構成要素は、動作ボタン、データ取り込みセル及び結合型モデルに含まれる他の構成を表示するソフトウェアタイプアプリケーションの操作画面を構成する。例えば：ＭｏｄｅｌＡｔｔｒｉｂｕｔｅ名を有するＭｏｄｅｌＣｌａｓｓ Ａｒｔｉｃｌｅが、ＭｏｄｅｌＡｔｔｒｉｂｕｔｅ Ｎａｍｅのインスタンスを編集するＴｅｘｔＥｄｉｔｏｒで画面を規定するＡｂｍＶｉｅｗＭｏｄｅｌに表示される。この画面は、ＭｏｄｅｌＶｉｅｗから各ＡｃｔｉｏｎＬｉｎｋ毎に機能を規定する。

ビューモデルは、名前を示すために「コントロールＴｅｘｔＢｏｘ ３ｄ」と呼ばれるＵＩ構成要素を使用することを指定し、この理由で、プロセッサ１５０は、結合型モデルを完成させるためにＵＩリソースメモリ１３３に記憶されている既に述べた構成要素を結合する。このような結合は、「コントロールＴｅｘｔＢｏｘ ３ｄ」構成要素の特性に従って、ネームテキストフィールドが３ｄ及び色外観で入力／出力デバイス１２０に表示されることを可能にする。構成要素タイプＴｅｘｔＥｄｉｔｏｒは、ＵＩリソーステキストボックス３Ｄと結合され、プロセッサ１５０用のＭｏｄｅｌＡｔｔｒｉｂｕｔｅ機能にリンクされて、ボックスをアプリケーションインターフェース１２３上でインスタンス化し、ボックスではユーザが三次元外観でテキストを追加することができ、データがデータベースメモリ１３０、論理構造オブジェクト１３６へと持続され得るようにテキスト取り込みをサポートする。

下位段階Ｄ４． 呼び出したＭｏｄｅｌＣｌａｓｓインスタンスを解く

一旦、結合することが下位段階Ｄ３において行われると、得られるソフトウェアタイプアプリケーションを形成する結合型モデルを汎用メモリ１４０、論理構造ＵＩ構成要素マトリックスに見つけることが可能である。モデルインスタンシエータ１５３として構成されたプロセッサ１５０は、ユーザに提示される結合型モデル（ＭｏｄｅｌＣｌａｓｓ−ＶｉｅｗＭｏｄｅｌ−ＵＩリソース）に関連付けられたＭｏｄｅｌＯｂｊｅｃｔからインスタンスを取得する。選択したインスタンスに対応するＡｔｔｒｉｂｕｔｅＶａｌｕｅｓは、結合型モデルに規定されたレイアウトに従って入力／出力デバイス１２０のアプリケーションインターフェース１２３へ送られ、このようにしてソフトウェアタイプアプリケーションの操作可能な画面がユーザに提示される。

下位段階Ｄ５． ユーザの要求を受け取り、解決する

一旦、入力／出力デバイス１２０のアプリケーションインターフェース１２３上に表示があると、ユーザは、いずれかのボタンを押すこと、セルのうちの１つに何らかのデータを入力すること、若しくはいずれかの選択肢リストを開くこと、又は利用可能な視覚構造のどれかにアクセスすることにより対話する。これが生じると、モデルインスタンシエータ１５３として構成されたプロセッサ１５０は、下位段階Ａ１においてロードしたプロトコルＰＥＦに何が規定されているかに従って、ＡｃｔｉｏｎＬｉｎｋ又は存在する機能のうちのいずれかを介して、ユーザが操作している結合型モデルを形成する機能モデルに対応する機能を実行する。

下位段階Ｄ６． 更新したＭｏｄｅｌＣｌａｓｓ Ｉｎｓｔａｎｃｅｓを表示する

一旦、結合型モデルが解決されると、モデルインスタンシエータ１５３として設定されたプロセッサ１５０は、入力／出力デバイス１２０のアプリケーションインターフェース１２３に公開された結合型モデルのインスタンス更新を生じさせる。プロセッサ１５０は新しいインスタンスを取出し、生成された変更で入力／出力デバイス１２０を更新する。
方法適用例：

図２Ｃ１に示したもののようなクラス図及び図２Ｄに示したもののような画面図から構成されるケースが与えられると、方法の段階は下記のように実行される：

段階Ａ．メモリへとプロトコルをロードする

この段階は、プロトコルがロードされ、最終的にはＵＩリソースがシステムに追加される時点だけであるので、システムの開始と考えられる。

段階Ｂ．設計構成要素を識別し、記憶する

この段階では、「ケース」についてのクラス設計及び画面設計が行われ、下記の下位段階が生じる：
（ｉ）下位段階Ｂ１． 機能設計構成要素を識別する

クラス図内の各構成要素に関して、対応するＰＥＦ構成要素が、下位段階Ａ１においてロードした機能仕様プロトコルＰＥＦを適用して識別され、このようである：

ユーザは、入力／出力デバイス１２０、インターフェースＣＤＦ１２１を介してこのリスト、表１の列１、２、及び３（設計構成要素、ＯＯタイプ、及び名前）を入力し、プロセッサ１５０は、これを汎用メモリ１４０、論理構造ＭＦマトリックス１４２に記憶する。次いで、モデルバリデータ１５１として設定されたプロセッサ１５０は、下位段階Ａ１においてロードした機能仕様プロトコルＰＥＦを読み取り、表１の列３及び４（ＰＥＦ概念及び作成されるモデルの名前）を完成し、これらのデータで汎用メモリ１４０、論理構造ＭＦマトリックス１４２を更新する。
（ｉｉ）下位段階Ｂ２．視覚設計構成要素を識別する

画面設計値の各々毎に、対応するＰＥＶ構成要素は、下位段階Ａ２においてロードした視覚仕様プロトコルＰＥＶを適用して識別され、次の通りである：

モデルバリデータ１５１として設定されたプロセッサ１５０は、汎用メモリ１４０、論理構造マトリックスＭＦ１４２に存在する機能構成要素のリストを取り出し、表２の列１及び２（機能構成要素、概念ＰＥＦ）に正に示されているかのように、これを入力／出力デバイス１２０、ＣＤＶインターフェース１２２に公開する。プロセッサ１５０は、下位段階Ａ２においてロードした視覚仕様プロトコルＰＥＶを読み取り、列３及び４（ＰＥＦ概念、作成されるＶｉｓｕａｌ Ｍｏｄｅｌ）を完成し、これらのデータで汎用メモリ１４０、論理構造ＭＶマトリックス１４３を更新する。

段階Ｃ． 機能モデル及び視覚モデルを作成する

この例から段階Ｂにおいて識別した機能構成要素及び視覚構成要素に関して、下記の下位段階が生じる：
（ｉｉｉ）下位段階Ｃ１． ＰＥＦ構成要素を識別し、機能モデルを作成する

プロセッサ１５０は、表１の列３及び４（ＰＥＦ概念及び作成されるモデルの名前）に対応し、汎用メモリ１４０、ＭＦマトリックス１４２上の利用可能なＰＥＦ構成要素を識別し、下位段階Ａ１においてロードしたプロトコルに従ってＰＥＦ概念を特定する。リストを通読し、ＰＥＦ概念を識別し、ＰＥＦプロトコル定義に従ってＰＥＦ概念を必要とするこれらの方法において数学用に規定された構成要素を作成する。この仕様は、機能モデルを作成し、機能モデルを論理構造モデルＭＦ１３５に記憶するために、ＰＥＦ概念及びデータベースメモリ１３０内の対応する論理構造を識別するように暗に示している。

この例では、データベースメモリ１３０、論理構造モデルＭＦ１３５に記憶された機能モデルの下記のリストが、この段階の結果として得られる：

機能モデル作成の技術的構造は、図２Ｃ１に認められることがあり、表３の各構成要素が、対応するＰＥＦプロトコル概念に関連して表されている。
（ｉｖ）下位段階Ｃ２．ＰＥＶ構成要素を識別し、視覚モデルを作成する

プロセッサ１５０は、表２の列３及び４（ＰＥＦ概念、作成される視覚モデル）に対応する汎用メモリ１４０、ＭＦマトリックス１４２で利用可能なＰＥＶ構成要素を識別し、下位段階Ａ２においてロードしたプロトコルに従ってＰＥＶ概念を特定する。

この例では、データベースメモリ１３０、論理構造モデルＭＶ１３４に記憶された視覚モデルの下記のリストが、この段階の結果として得られる：

段階Ｄ． 操作可能なソフトウェアタイプアプリケーションとして機能モデル及び視覚モデルを読み取り、インスタンス化する

下位段階Ｄ１．視覚モデルＭＶを読み取り、解釈する

下位段階Ｄ１において指し示された発明のプロセスは、表４の例からのリストに基づいて実行される。

下位段階Ｄ２．機能モデルＭＦを読み取り、解釈する

下位段階Ｄ２おいて指し示された発明のプロセスは、表３の例からのリストに基づいて実行される。

下位段階Ｄ３．ＵＩリソースを選択し、結合する。

選択したＵＩリソースは、図２Ｄに示したもののような視覚設計を実現するまで、画面設計から要求される画面を表示するために結合される。

下位段階Ｄ４．呼び出したＭｏｄｅｌＣｌａｓｓインスタンスを解決する

ユーザがアプリケーションインターフェースを操作するので、システムは、この発明の下位段階Ｄ４において列挙した動作を実行することにより応答する。

下記の下位段階は、ユーザが例の得られるアプリケーションと対話しながら生成される。

下位段階Ｄ５．ユーザの要求を受け取り、解決する

下位段階Ｄ６．更新したＭｏｄｅｌＣｌａｓｓ Ｉｎｓｔａｎｃｅｓを公開する

当業者には明白ので、別記の特許請求の範囲によってのみ規定される発明の本質から離れては求められない様々な変形形態及び可能な修正形態があるという理由で、この発明は、説明し、図示した実施形態に限定されないことが、理解されなければならない。

Claims (8)

1. ソフトウェア設計仕様書に基づいてソフトウェアタイプアプリケーションを自動的にインスタンス化し、表示するコンピュータ実装方法であって、
   ａ．中央処理装置（ＣＰＵ）に接続された入力／出力デバイス１２０を介して、機能仕様プロトコル（ＰＥＦ）、視覚仕様プロトコル（ＰＥＶ）、及びＵＩリソースをロードし、前記機能仕様プロトコル（ＰＥＦ）、前記視覚仕様プロトコル（ＰＥＶ）及び前記ＵＩリソースを前記ＣＰＵに接続されたデータベースメモリ１３０に記憶する段階と、
   ｂ．段階ａのプロトコルに対して識別し、検証し、前記ソフトウェア設計仕様書に基づいて機能設計構成要素及び視覚設計構成要素を汎用メモリ１４０に記憶する段階であって、前記識別する段階及び前記記憶する段階は、
   メモリ又は前記入力／出力デバイスからロードしたクラス設計に基づいて前記機能設計構成要素を識別する下位段階と、
   メモリ又は前記入力／出力デバイスからロードした画面設計に基づいて前記視覚設計構成要素を識別する下位段階と、を含み、
   ｃ．段階ｂにおいて識別した前記機能設計構成要素及び前記視覚設計構成要素に基づいて機能モデル及び視覚モデルを自動的に作成し、前記機能モデル及び前記視覚モデルを前記データベースメモリ１３０の論理構造モデルＭＦ１３５及びモデルＭＶ１３４それぞれに記憶する段階であって、前記機能モデル及び前記視覚モデルを作成する段階は、
   前記中央処理装置を介して、前記機能仕様プロトコル（ＰＥＦ）を処理して機能構成要素を識別し、識別された前記機能構成要素に基づいて機能オブジェクトと共に前記機能モデルを作成する下位段階と、
   中央処理装置を介して、前記視覚仕様プロトコル（ＰＥＶ）を処理して視覚構成要素を識別し、識別された前記視覚構成要素に基づいて機能コンテンツと共に前記視覚モデルを作成する下位段階と、を含み、
   ｄ．モデルインスタンシエータ１５３として設定されたプロセッサ１５０を使用して段階ａにおいて記憶されたプロトコルからの規範に従ってＵＩリソースと結合された、段階ｃにおいて作成された前記機能モデル及び前記視覚モデルを共に読み取り、インスタンス化し、前記入力／出力デバイス１２０のアプリケーションインターフェース１２３に自動的に表示する段階と
   を含む、方法。
2. 段階ｄが、
   ａ．前記中央処理装置を介して、前記視覚モデルを読み取り、処理する下位段階と、
   ｂ．前記中央処理装置を介して、前記機能モデルを読み取り、処理する下位段階と、
   ｃ．前記中央処理装置を介して、前記機能モデルを処理して、ユーザインターフェース（ＵＩ）構成要素を選択し、結合する下位段階と、
   ｄ．前記中央処理装置を介して、前記機能モデルの構成要素を処理して、前記入力／出力デバイスと対話することを介して前記ユーザにより呼び出されたメタクラスのインスタンスを解決する下位段階と、
   ｅ．前記入力／出力デバイスを介して送られたユーザ要求を受け取り、解決し、前記中央処理装置により前記ユーザ要求を処理する下位段階と、
   ｆ．表示デバイスに更新したメタクラスインスタンスを示す下位段階と、
   を含む、請求項１に記載の方法。
3. 段階ａが、
   ａ．前記中央処理装置を介して、前記データベースメモリ１３０に記憶した機能図を処理して、前記機能図に含まれているクラスを識別するステップと、
   ｂ．各クラスの名前を識別し、前記各クラスの前記名前を前記データベースメモリ１３０に記憶するステップと
   を含む、請求項１に記載の方法。
4. 段階ｂが、
   ａ．前記視覚仕様プロトコルを適用し、前記視覚仕様プロトコルを前記データベースメモリ１３０に記憶して識別したクラスに基づいて視覚モデルを作成するステップと、
   ｂ．前記作成された視覚モデルの外観を編集し、必要とされるケースでは前記入力／出力デバイス１２０を使用して前記データベースメモリ１３０に前記外観を記憶するステップと
   を含む、請求項１に記載の方法。
5. 段階ａが、
   ａ．前記機能モデルのリストを前記中央処理装置を介して処理して、前記機能構成要素及び前記視覚構成要素の各々についてデータベースメモリ１３０へとロードした前記機能仕様プロトコルに従って、前記機能モデルに含まれているオブジェクトを作成するステップと、
   ｂ．前記中央処理装置を介して、数式に関連付けられた機能図の構成要素を処理して、前記数式の実行を可能にする追加の構成要素を作成し、前記追加の構成要素を前記データベースメモリに記憶するステップと、
   を含む、請求項１に記載の方法。
6. 段階ｂが、
   ａ．前記中央処理装置を介して、各機能概念に対して、前記視覚仕様プロトコル（ＰＥＶ）からの概念を規定するために、前記データベースメモリ１３０に記憶した機能仕様プロトコル概念（ＰＥＦ Ｃｏｎｃｅｐｔｓ）のリストを処理するステップと、
   ｂ．各機能概念に対して視覚モデルを作成し、前記視覚モデルを前記データベースメモリ１３０に記憶するステップと、
   ｃ．代表ケース名を使用し、前記ケース名を前記データベースメモリ１３０に記憶して、アプリケーションのための視覚モデルを作成するステップと、
   ｄ．前記視覚設計構成要素の各々についての代表名及びメニューグループを使用し、前記グループに視覚設計構成要素名を割り当て、前記グループを前記データベースメモリ１３０に記憶してメニュータイプ視覚モデルを作成するステップと
   を含む、請求項１に記載の方法。
7. ソフトウェア設計仕様書に基づいて、操作可能なソフトウェアタイプアプリケーションをインスタンス化し、公開するシステムであって、
   ａ．機能設計構成要素（ＣＤＦ）インターフェース１２１、視覚設計構成要素（ＣＤＶ）インターフェース１２２、及びアプリケーションインターフェース１２３を含み、ソフトウェア設計仕様書を入力し、得られるソフトウェアタイプアプリケーションを表示するための、入力／出力デバイス１２０と、
   ｂ．前記入力／出力デバイス１２０に接続された中央処理装置（ＣＰＵ）１１０であり、
   プロセッサ１５０と対話する前記入力／出力デバイス１２０と通信し、機能設計構成要素及び視覚設計構成要素、並びにＵＩ構成要素を揮発的に記憶するように設定された汎用メモリ１４０と、
   前記入力／出力デバイス１２０から少なくとも１つの前記ソフトウェア設計仕様書を受け取るように設定されたプロセッサ１５０であり、
   前記プロセッサ１５０が、データベースメモリ１３０に記憶されているプロトコルに対して前記少なくとも１つのソフトウェア設計仕様書を検証し、前記得られるソフトウェアタイプアプリケーション、統合される機能モデル及び視覚モデルを識別する、モデルバリデータ１５１として設定され、
   前記プロセッサ１５０が、前記機能モデル及び前記視覚モデル、並びにＵＩリソースを結合して、前記得られるソフトウェアタイプアプリケーションを得るためのユーザインターフェース（ＵＩ）コンバイナ１５２として設定され、
   前記プロセッサ１５０が、前記アプリケーションインターフェース１２３に前記得られるソフトウェアタイプアプリケーションを表示するモデルインスタンシエータ１５３として設定された、プロセッサ１５０と
   を含む、中央処理装置（ＣＰＵ）１１０と、
   ｃ．ＣＰＵ１１０に接続され、プロセッサ１５０とペアリングされ、論理構造ＰＥＶ１３１に視覚仕様プロトコルＰＥＶを、論理構造ＰＥＦ１３２に機能仕様プロトコルＰＥＦを、及び、ＵＩリソース１３３の論理構造にユーザインターフェースＵＩリソースを、静的に記憶するように構成されるとともに、論理構造視覚モデルＭＶ１３４の内部に視覚モデルを、論理構造機能モデルＭＦ１３５に機能モデルを、及び、論理構造オブジェクト１３６の内部にオブジェクトを、動的に記憶するように設定されたデータベースメモリ１３０と
   を備え、
   前記中央処理装置は、
   前記入力／出力デバイスに記憶したすべての設計モデルを復元し、前記データベースメモリにロードした機能検証プロトコル（ＰＥＦ）に対する全ての前記設計モデルの検証を処理し、
   前記入力／出力デバイスに記憶したユーザインターフェースの前記設計モデルを復元し、前記データベースメモリにロードした視覚検証プロトコル（ＰＥＶ）に対するユーザインターフェースの前記設計モデルの検証を処理し、
   前記機能モデルの解釈を処理し、前記機能モデルの解釈を前記データベースメモリに記憶し、
   前記視覚モデルの解釈を処理し、前記視覚モデルの解釈を前記データベースメモリに記憶し、
   前記データベースメモリから前記機能モデル及び前記視覚モデルを復元し、前記機能モデルと前記視覚モデルとの間の結合及び対話処理の実行に基づいてユーザインターフェースを作成し、前記データベースメモリに前記インターフェースを記憶し、前記入力／出力デバイスに前記得られるソフトウェアタイプアプリケーションを表示する、
   システム。
8. 前記入力／出力デバイスが、
   ａ．前記機能モデルを作成するために前記中央処理装置により復元される機能図を汎用メモリ１４０へと入力することを可能にし、
   ｂ．前記視覚モデルを作成するために前記中央処理装置により復元される画面設計を汎用メモリ１４０へと入力することを可能にする
   ことを特徴とする、請求項７に記載のシステム。