JP2001506028A - コンピュータソフトウェアアプリケーションの開発および実行のための方法、システムおよびデータ構造 - Google Patents

Abstract

(57)【要約】 ソフトウエアの開発および実行のための方法、システム、および データ構造はランタイムイベントマネージャおよび１セットのモデルを含む。モデルは、コードではないが、他のモデル、方法、または他のオブシェクトを参照する順序付けられたセットを含むデータ構造のタイプである。モデルは、条件のセットを満足してこれらを登録することによってランタイムイベントマネージャにアクセス可能となっている。本発明の一実施の形態では、ランタイムイベントマネージャは、各ループで、モデルのセットの１つを動作し、外部Ｉ／Ｏ状態をチェックし、このような状態を支配し、デフォルト状態に関連する標準またはパラダイム（Ｐａｒａｄｉｇｍ）モデルよりもむしろ、異なったまたはバリアント（Ｖａｒｉａｎｔ）モデルを処理するコード内で実現されるフェッチ実行ループである。また、動的に拡張可能なデータベース機能を可能とするエラステック（Ｅｌａｓｔｉｃ）データベースは本発明によって実現される。

Description

【発明の詳細な説明】 コンピュータソフトウェアアプリケーションの開発および実行のための方法、シ ステムおよびデータ構造 技術分野 本発明は、コンピュータプログラミングの分野、より詳細には、コンピュータ ソフトウェアアプリケーションの開発および実行に関する。 背景技術 コンピュータのアプリケーションソフトウェアの開発および修正には、コード の書き込み、またはプログラミングパラダイム（ｐａｒａｄｉｇｍ）を使用した ソフトウェアオブジェクト（「オブジェクト」）が必要であり、これには例えば 、第三世代言語（「３ＧＬ」）、第四世代言語（「４ＧＬ」）、またはオブジェ クト指向デベロップメント（「ＯＯＤ」）メソドロジィがある。こうした従来の メソドロジの決定的な制約の一つに、これらをソフトウェアの開発および修正で 使用する上でデベロッパが実際にコードを修正しなければならないということが ある。このことは、こうしたコーディングに付随する手間という観点からだけで なく、ソフトウェアの開発およびテスト処理における労力の調整という点におい ても面倒な制約である。 近年における主要なプログラミングメソドロジィとしてのオブジェクト指向の 出現により、高度なモジュール方式の自然で再利用可 能なプログラミング構造が提供され、ソフトウェア開発の労力は軽減されるよう になった。従来では、「オブジェクト」という用語は、オブジェクト指向ソフト ウェアまたはプログラミングの当業者によって使われるように、一方から他方へ メッセージを送ることにより互いにコミュニケーションしたり呼び出したりする ことができるデータ構造の形態のソフトウェア要素のことをいう。同じメッセー ジに応答するオブシェクトは共通の「クラス」にあると言われる。「クラス」と いうオブジェクトは、クラスの「インスタンス（ｉｎｓｔａｎｃｅ）」（すなわ ち、オブジェクト）の挙動を取り込む方法を全て記述および実現する。クラスの インスタンスの状態または構造はテンプレートにより指定され、テンプレートは オブジェクトの条件か他のオブシェクトを含むということを指定してもよい。こ うして、ＯＯＤが導入したモジュール方式は、デバッグをより容易にし、現実世 界の問題または環境の忠実なモテルをより高度にし、再利用可能なコードを生成 できるような分割統治問題解決アプローチに役立つ。それにもかかわらず、コー ドを書き込みおよびテストする条件は変わらない。 コンピュータ「アプリケーション」とは、コンピュータのユーザか対話するこ とでタスクを実行するプログラムであり、アプリケーションソフトウェアが動作 するよう設計された機能的環境を作成するシステムまたは他のソフトウェアとは 区別される。コンピュータアプリケーションソフトウェアのデベロッパは、その ため、ユーザ対話のサポートおよびユーサの目的達成に関心を持っている。 多くのアプリケーション環境において、特にソフトウェアがカスタムベースで 開発される場合、ユーザの要求はより発展する。こう した要求に合わせるよう意図されたアプリケーションソフトウェアもまた、好ま しくは発展することができる。しかし、既存のアプローチ（ＯＯＤにより提供さ れるモジュール方式のアプローチであっても）を使用したアプリケーションソフ トウェアの修正には、コンピュータのコードの書き込みまたは修正、コードのデ バッグ、アプリケーションの使用に対してその破壊を最小限に抑えたそれらの処 理が必要である。しかし、この目標は達成しづらいことがわかっている。 ソフトウェアアプリケーションを開発または修正するために、新しいコードを 書き込み、統合する必要性に関連する問題に加えて、ソフトウェアアプリケーシ ョンの開発または修正の既存の方法に伴う別の問題として、こうしたコーディン グは、ユーザＩ／Ｏまたは他の発生など、外部のイベントの処理に適応しなけれ ばならない。しかしながら、こうしたユーザＩ／Ｏまたはその他のイベントは、 あるユーザ環境と別のユーザ環境（例えば、文字入力に対するグラフィカルユー ザインターフェース（「ＧＵＩ」））との間でかなり広範に変化しているため、 既存の技術でこうした異なる外部のイベントに適応する能力としては、（１）デ バッグで完了するカスタムソフトウェア開発に時間がかかる処理をするか、（２ ）そのために様々な既知のアプリケーション環境で動作可能な十分な不測事態処 理能力を有するコードのセットを開発するかのいずれかを必要とする。どちらの 場合も、大量のコーディングおよびテスト処理がそれぞれのローカルアプリケー ション環境で必要とされ、結果としてアプリケーション環境における展開に伴う ソフトウェアの短所を受け入れるか、またはこうした外部のイベントの条件にお いて変化が起 こると、難しい再コーディングおよびデバッグ処理を終了するに過ぎない。 発明の開示 本発明は、開発（設計、構築、テスト、メンテナンス、および修正を含む）の ための方法、システム、およびデータ構造に関し、同様に、既存の技術のユーザ が直面するアプリケーション設計、テスト、および修正の問題の多くを解消する コンピュータアプリケーションソフトウェアの実行に関する。 本発明は、以下で詳述するように、ランタイムイベントマネージャ（Ｒｕｎ Ｔｉｍｅ Ｅｖｅｎｔｓ Ｍａｎａｇｅｒ）、および事後結合、再利用可能なモ デル、方法、または他のオブジェクトのライブラリでコードを置換することによ って、コード化されたアプリケーションプログラムを不要にすることができると いう点が最も注目される。プログラムソース、オブジェクトコード、またはアプ リケーションとしては働く事後結合または動的結合のランタイムアプリケーショ ンコードの形態に代わって、本発明の実施の形態は、ここでランタイムイベント マネージャ（「ＲＴＥＭ」）として参照され、以下に記載される単一のアプリケ ーション非依存型ソフトウェアエンティティを提供する。ＲＴＥＭは、本発明に よって開発されたアプリケーションの動作中に存在する単一の制御エンティティ である。ＲＴＥＭは、所定の時間にアプリケーションおよび入力／出力（「Ｉ／ Ｏ」の条件に最も適して与えられる使用可能な手段をどれでも呼び出すことによ ってコンピュータが実行しているかどうかをたえず判断する。しかし、ＲＴＥＭ は適当であると判断した機 能を実際に実現するのではなく、その機能を実現するのに必要な手段（オブジェ クト、アプリケーション特定オブジェクト、およびツールを含む）を呼び出すの みである。（ここで使用される用語の「ツール」は、低レベルへのアクセスまた はオペレーティングシステムの機能を可能にするまたは提供する手続き上のコー ドをいう。例えば、以下で説明するデータベースアクセス（「ＤＢＡＣ」）ツー ルはデータベースに対する情報を読み出し、書き込む。ここで使用される用語の 「ツール利用（Ｔｏｏｌｕｓａｇｅ）」は、ツールへのアクセス可能な、すなわ ち、ＤＢＡＣを用いたＲＥＡＤまたはＷＲＩＴＥを行うパラメータのようなイン ターフェース定義をツールに提供するモデル設計オブジェクトをいう。）こうし たオブジェクトおよびツール（方法、Ｉ／Ｏツール、またはコンピュータで機能 を実現することが可能な他のソフトウェア構成を含む）は、ＲＴＥＭの指示と独 立に動作しない。つまり、これらはＲＴＥＭによって呼び出されることが最も好 ましく、またＲＴＥＭによってのみ、ＲＴＥＭがこれらを呼び出して実行させる ことを実現する。 オブジェクトおよびツールは、ＲＴＥＭによって呼び出されて機能を実現する ためには、例えば、以下に述べるような登録処理によりＲＴＥＭで利用可能にし なければならない。本発明によると、例えば、ＲＴＥＭから制御を転送する命令 を含むＲＴＥＭによる使用をするために、オブジェクトまたはツールを登録する ことはできない。従って、例えば、ＲＴＥＭによって動作するアプリケーション を使用するオペレータは、課された特権をうっかり超えたり、またそうでなくて も、要求されているが禁止された動作の結果としてアプリケーションの統合が危 うくなるということからプロテクトでき る。さらに、ＲＴＥＭは、オペレータ対話のような外部のイベントを繰り返しチ ェックし、そのため、情報を提供したり、命令を受け入れたり、アプリケーショ ンタスクを可能にしたり、時間のトラックを保持したり、またはその他の機能な どによって、オペレータとの直接の対話を可能にする。 本発明の実施の形態では、ＲＴＥＭは全てのランタイムイベントを管理し、か つオペレータとの全てのコミュニケーションを行うモシュールである。「イベン ト」は計画されたハプニングとして定義しても良く、その予め決められた方法で アプリケーションを実行するときに生じるものを含むという点が最も注目される 。本発明によると、オペレータかアプリケーション自身と直接コミュニケーショ ンしているようにみえる時でも、ＲＴＥＭはアプリケーションのオペレータが直 接コミュニケーションするソフトウェアのみであることが好ましい。ＲＴＥＭは 、オペレータからの情報を、この情報を実行するように意図されたアプリケーシ ョンイベントに中継する。また、ＲＴＥＭはアプリケーションからの情報をオペ レータに再び中継する。 オペレータとアプリケーションとの間の媒介に加えて、述べられているように （および以下で詳述するように）、オブジェクト（方法など）またはツールは別 のオブジェクトを呼び出したりコミュニケーションすることができないため、本 発明の実施の形態のＲＴＥＭは、ランタイムタスク中の全てのイベントを媒介す る。本発明によると、繰り返し「モデル」を調べて処理することでＲＴＥＭはそ れを行い、モデルに取り込まれたアプリケーションと関連するロジックを実行す る。各モデルはアプリケーションと関連する処理を指 定する。モデルはデータだけを含み、実行可能なオブジェクト（全体または部分 にかかわらず）は含まないことが最も好ましい。モデルにおけるテータは、ルー ル、ツール、フォーム、およびアプリケーション処理に関連するランタイムイベ ントを発生させるためにＲＴＥＭが呼び出さなければならないアプリケーション 特定オブジェクトを判断するのに必要な情報を有するモデルを処理するＲＴＥＭ を提供する。 本発明の実施の形態では、モデルは、アプリケーションと関連する処理を開始 するデータと同様にオブジェクトに対するリファレンスリストであるが、以下で 述べるように、所定の時間にアプリケーションの条件または外部の条件に応じて 、ＲＴＥＭは、適宜、モデルが表す処理スキーマ（Ｓｃｈｅｍａ）の全体または 一部を無視、変更および／または追加してもよい。関連し、有効で許容されたそ れに代わる情報がない場合には、モデルはランタイムでＲＴＥＭに絶対的に従う 。 本発明によると、ＲＴＥＭによって呼び出され、調べられるモデルは、パラダ イムモデルと、所定のパラダイムモデルと関連するバリアントモデルとを含んで いる。パラダイムモデルはアプリケーションと関連する「標準」処理を記述する 。バリアントモデルは「標準」処理における変更を記述する。両タイプのモデル は、それらの構成データを含むその形態が本発明によるＲＴＥＭ１０による処理 に関連する制約に従うかどうかを判断するための評価実行後に登録されなければ ならない。パラダイムモデルはアプリケーションの一部にルールのセットを設定 してもよく、また、バリアントモデルはある条件の下で、処理の標準的またはパ ラダイム的な方法を変更し たバリアントルールによって取りかえられるということを示すサブセットルール を表している。 本発明の実施の形態では、バリアントモデルは、それ自身とそれが関連するパ ラダイムモデルとの間の相違点または分散のみに言及しており、述べられている ように、ＲＴＥＭ１０は、その後アプリケーションと外部ランタイムイベントと を監視し、条件が変化すると、そうした条件下で「適用」するバリアントモデル を識別して調べ、適用するこうしたバリアントモデルを呼び出している。本発明 によると、モデルをＲＴＥＭで利用可能にするためのプレ条件として登録する場 合、バリアントモテルロジックをランタイムで呼び出す条件のセットを、ＲＴＥ Ｍによる将来的な使用のために識別して記憶する。 また、本発明によると、パラダイムモデルに関連するバリアントモデルは、パ ラダイムモデルまたはその他のバリアントモデルを修正せずに作成および登録す ることができ、バリアントモデルに対するモデルにおけるリファレンスを作成す る。新しいモデルを作成してアプリケーションを修正することにより、修正処理 中の不安定の発生と同様に、現在のモデルを再テストする必要性を最小限に抑え ている。どんな数の別のバリアントモデルも独立して作成することができ、各モ デルと関連するロジック間での干渉の危険性を招くことなくパラダイムモデルの 対応する部分を代えている。反対に、この能力は、テストを容易にし、モデルは 独立してテストすることができ、以前に開発されたモデルの機能を再テストする 必要はない。実際のソフトウェア開発のチームに関して、独立した開発／メンテ ナンスチームは、他のこうしたチームが働いているということを知 らずにバリアントモテルを作成することができる。また、ソフトウェアを配備し たローカルサイトで行われるカスタマイゼーションワークは、本来の（ローカル でない）オーサによって作成される更新の悪影譬を受けないため、更新時間で再 び行う必要はない。さらにまた、同じアプリケーションロジックの修正に対する 多数の衝突する要求は、協働していない開発またはメンテナンスチーム、または 個人によって同時に達成することができる。従って、合併したテストを減らした り除いたりしてもよい。 本発明の実施の形態において、ＲＴＥＭは、またツールを使用して、スクリー ンやリポート、電子データ互換処理（従来の「ＥＤＩ」など）のような、永続的 データ記憶装置（データベース）、外部（Ｉ／Ｏ）媒体を含む、周辺機器の出力 および入力を再形成および再フォーマットする。これを行うために、ＲＴＥＭは 、「スーパーツールキット（Ｓｕｐｅｒｔｏｏｌｋｉｔ）」としてここで参照さ れるツールのセットと同様に、ツールを使用してこうした周辺機器の入出力であ る、（１）データベースアクセスコントローラ（「ＤＢＡＣ」）（ツール）と（ ２）ユーザＩ／Ｏ（「ＵＩＯ」）とを取り扱う。この両者をさらに以下で述べる 。ここで使用される「スーパーツールキット」はツールの集合として参照される 。例えば、ＲＴＥＭは、ＵＩＯスーパーツールキットにアクセスして、キーボー ドを介してユーザからの情報を検索する入力ツールを含むユーザに対する全ての 表示を行い、また、異なるフォーマット（すなわちＧＵＩまたは文字）の形態で 情報を表示する表示ツールを含んでいる。表示ツールは、当業者に公知の方法に よって実現できる入力、表示テキストおよびスクリーンツールを含んでもよい。 本発明の実施の形態において、ＲＴＥＭは、また、ある意味においては、モデ ルをロードし、他のツール、モデルおよび方法を呼び出すツールであり、特定の アプリケーション（すなわち、表示層ツールを呼び出して視覚的な形態でデータ を表示したり、データベースアクセスツール（ＤＢＡＣ）を呼び出してこのデー タベースから情報を検索したりする）に必要な動作を実行する。 本発明の実施の形態において、ＤＢＡＣは、ＲＴＥＭに呼び出され、ＲＴＥＭ を使用したセッションと永続的なデータベースが関するものとの間でのロジカル なデポシットおよびデータの検索ができる。こうした実施の形態において、永続 的な記憶装置は、所定のアプリケーションセッションを通じて所定のモーメント でＲＴＥＭが働くバリアントモデルに依存し、行毎（すなわちより多くの要素、 より少ない要素、異なる要素）にデータ要素の異なる補数を有することが可能な テーブル、またはより多くのテーブルまたはより少ないテーブルを有することが 可能なテーブルとして見られる。この永続的な記憶装置のビューは「エラスティ ックテータベース（Ｅｌａｓｔｉｃ Ｄａｔａｂａｓｅ）」としてここで参照で きる。 本発明の実施の形態のＤＢＡＣはＲＴＥＭによって呼び出され、記憶装置にお けるアプリケーションのロジカルな「エラスティック」ビューと実際のＲＤＢＭ Ｓ（インエラスティック）行および列との間のギャップの橋渡しをする。ＤＢＡ Ｃは多数の従来のＲＤＢＭＳ制御テーブルにわたってエラスティックデータ行の 記憶および検索を管理する。モデルに使用される同じ登録処理（以下に記述）も また他の全てのオフジェクトを取り扱う。この登録処理により、従来のＲＤＢＭ Ｓにはなかった方法でエラスティック（またはバリア ント）関係の定義が可能になる。ＤＢＡＣのロジックは、効率化のために、クラ イアントおよびサーバのクスク間で分散されていてもよい。以前のテーブルを修 正して、最も好ましくはその行のいくつかまたは全てで可変情報をロジカルに結 合することなどによって、次のバリエーションに適応する必要がない。 本発明によると、バリアントファイルの関係は、通常の生成を妨害せずに、オ ンザフライでリアルタイムでデータベースに付け加える（ｒｅｔｒｏｆｉｔ）こ とができる。ＲＴＥＭの制御下でのＤＢＡＣは、アプリケーションと基礎になる データベースとの間の全ての対話を仲介するために用いられる。このことは、つ まり、ＲＴＥＭは別の場合にはアプリケーションとそのエラスティックデータベ ースとの間の通常の対話を取りなすことができ、また調整によってアプリケーシ ョンまたはデータベースのいずれかを修正する必要なくこの対話を変化させるこ とができる。このため、例えば、ＲＴＥＭは、プロダクションデータベース「ｉ ｎ−ｓｉｔｕ」を使用できる「テストセッション」が可能であり、一方で同時に 起こるライブプロダクション処理は、ライブデータを干渉および破壊することな くそれを変更しており、また一方では、テストされるアプリケーションにはその データベースに対する書き込みおよび更新が含まれている。 本発明の実施の形態では、ＲＴＥＭは、アプリケーションがテストまたはプロ ダクションモードであるかどうかにかかわらず、オプション的な断定または有効 性テストを実行してもよい。特に、ＲＴＥＭは、あらゆるモテルおよび方法、ひ いてはモデルの各ステップ（すなわち要素）の発動前および後にすべての変数お よび必須の条 件をチェックすることができる。 非破壊的なテストは、新しいか、バリアントであるか、または修正されたオブ ジェクトを登録して、名づけられたプロジェクトの一部としてテストしなければ ならない。こうしたテストオブジェクトは、「テスト」として指定され、プロジ ェクト定義中の適切なプロジェクト認証に関連するラン状態のセッション中にお いてＲＴＥＭで呼び出されることしかできない。新たに修正されたオブジェクト は、登録済みのテストセッションを終了していない場合、プロダクションではア クセスされないことが最も好ましい。 本発明の実施の形態において、テストセッション中に、テストプロジェクトで 名づけられたテストディレクトリデータベースの１つに全ての「書き込み」が再 度指向される。全ての「読み出し」は、まず、そのテーブルを適宜オンザフライ でＤＢＡＣによってセットアップしたテストディレクトリを試行し、次に、プロ ダクションデータベースを試行する。また、こうしたレコードがテストのプレ条 件としてデータフォーマットの変更が必要であっても、テストで使用される全て の読み出し専用プロダクションレコードはテストディレクトリにおいても再生成 される。このアプローチによって、テストセッションの高い忠実なレコードが可 能になり、最小限の労力でスクラッチから次に継続したり再実行されることがで きるようになる。 本発明の実施の形態においては、ＵＩＯがＲＴＥＭによって使用されてアプリ ケーションとそのユーザＩ／Ｏとの間の対話を仲介する。このユーザＩ／Ｏには 、コンピュータおよび関連するネットワークの限界を超えるＩ／Ｏが含まれてお り、スクリーンフォーム、 データ入力デバイス、電子データ互換（「ＥＤＩ」）処理およびその他のＩ／Ｏ が含まれる。 本発明によるアプリケーションは、設計または修正してＩ／Ｏ関係を考慮する 必要がなく、この機能に関連するいかなるロジックも含む必要かない。このアプ ローチは、従来の技術を改良したものであり、これはアプリケーション自身によ り密接に依存する。このアプローチでは、例えば、特定の時間の条件の機能とし て、フレキシブルでバリアントなＩ／Ｏの挙動を挿入することができる。 従って、本発明は、また、新たな能力を追加して、最小のコード変更で、また はコード変更なしにソフトウェアを配備し、従来のアプリケーションソフトウェ ア開発に通常関連するユーザアクティビィティの中断を可能にするアプリケーシ ョンソフトウェアの開発の新しい方法を提供する。 さらに、本発明は、ソフトウェアが動作するローカル環境の条件によって、そ の処理挙動の極端な差を示すことが可能なコンピュータソフトウェアと、処理す る特定のデータとを提供する。 本発明によるコンピュータ記憶可能データ構造および方法、および本発明によ りそれを可能にするソフトウェア開発の方法は、さらに、均一でないデータ構造 を、従来のデータベースにおいてそれぞれ正規化され定義されるロジカルデータ 構造のセットとして定義することができるようにする。本発明の一実施の形態に おいて、プロセッサと、メモリと、記憶媒体とを有するコンピュータにおいて実 装されるアプリケーションソフトウェアを動作させるシステムは、記憶媒体に記 憶される複数のモデルとランタイムイベントマネージャを含んでいる。これらの モデルは、それぞれ、１つまたはそれ以 上のオブジェクトへのリファレンスを含むデータを含み、ランタイムイベントマ ネージャは、複数のモデルのうち選択した１つを記憶媒体からメモリにロードし 、選択したモデルのデータを読み出し、オブジェクトへのリファレンスが読み出 されると、適切なツールを呼び出し実行し、オブジェクトを提供する。 本発明は、命令に関連する処理動作を実行し、外部入出力を通じてコンピュー タにコミュニケーションし、コンピュータ外部のイベントに応答するコンピュー タによって実行するランタイムイベントマネージャを提供する。このコンピュー タは、ランタイムイベントマネージャにアクセス可能なモデルのセットを記憶す る記憶媒体を含んでいる。ランタイムイベントマネージャは、モデルのライブラ リからモデルをロードする手段と、コンピュータとランタイムイベントマネージ ャの所定の状態でモデルが適切に呼び出されるかどうかを判断する手段と、コン ピュータとランタイムイベントマネージャの所定の状態が適当であると判断され る場合にモデルを呼び出す手段と、モデルを呼び出す（すなわちモデルの意図を 実行する）手段とを含んでいる。 また、本発明はランタイムイベントマネージャを利用してコンピュータアプリ ケーションソフトウェアを開発する方法を提供する。この方法は、各モデルが以 下の、ｉ．モデルへのリファレンス、ｉｉ．方法へのリファレンス、ｉｉｉ．デ ータ、およびｉｉｉ．入力または出力命令を少なくとも１つ含む場合に、複数の モデルを作成することを含むステップを含んでいる。更なるステップは、モデル において参照される方法はどれも、（１）モデル、方法、またはツールにかかわ らず、別のオブジェクトを呼び出したり、（２）スク リーン、ファイル、または他のいずれかのデバイスまたはオブジェクトのいずれ かに入力／出力（Ｉ／Ｏ）を実行することができないことを確かめるためにモデ ルをテストすることを含む。さらに、テスト下でマスタを受け渡すモデルは登録 され、ランタイムイベントマネージャによるアクセスが可能となる。 本発明は、また、ランタイムイベントマネージャで使用できるように登録され たオブジェクトのライブラリの生成を提供する。登録処理にはモデルに独自の識 別子に基づいたオブジェクトを呼び出すステップ、制限された内容がある時のオ ブジェクトの内容をスキャンするステップ、また、オブジェクトが制限された内 容を全く含まない場合に限り、ライブラリの一部としてのオブジェクトを登録す るステップを含んでいる。 本発明は、さらに、ベースファイルの特定のベースレコードにどのバリエーシ ョンセットを適用するかを判断するように適合したバリエーションセットランタ イムマップを実現するようにプログラムされたシステムと共に、プロセッサと、 メモリと、記憶媒体とを有するコンピュータ上で実現される、ベースファイルと バリエーションセットを含むデータベースシステムを提供する。バリエーション セットは、ベースレコードに対応する少なくとも１つの追加フィールドを有する レコードを含む。 本発明は、また、ベースファイルおよびバリエーションセットを有するデータ ベースシステムを動作する方法を提供する。この方法は、ベースレコードをロー ドし、ベースファイルに対応するバリエーションセットの存在についてバリエー ションセットランタイムマップをチェックし、バリエーションセットが存在する 場合にバリエ ーションセットからデータを検索することを含むステップを含んでいる。 従って、本発明は、アプリケーションに関連した機能を実現するための書き込 みコードを不要にしたアプリケーションソフトウェアを開発および修正する方法 、システムおよびデータ構造を提供することを目的とする。 さらに、本発明は、モデルのセットと共に、ランタイムイベントマネージャを 使用してアプリケーションソフトウェアを開発、テスト、および実行する方法、 システム、およびデータ構造を提供することを目的とする。 さらに、本発明は、ランタイムイベントマネージャとモデルのセットを使用し てアプリケーションソフトウェアを開発、テスト、および実行する方法、システ ム、およびデータ構造を提供することを目的とする。なお、別の方法による登録 していないオブジェクトの呼び出しまたは方法の呼び出しを含む動作を排除する 処理によるランタイムイベントマネージャによるアクセスのためにモデルが登録 されている。 さらに、本発明は、パラダイムモデルおよびバリアントモデルを含むモデルの セットの中のモデルのセットと関連して、ランタイムイベントマネージャを使用 してアプリケーションソフトウェアの開発、テスト、および実行する方法、シス テム、およびデータ構造を提供することを目的とする。 さらに、本発明は、バリエーションセットにおける追加のフィールドのベース ファイルでのベースレコードを拡張することができる「エラスティックデータベ ース」を実現する方法、システム、およ びデータ構造を提供することを目的とする。 さらに、本発明は、モデルの１つが新たに開発されたアプリケーションとレガ シーソフトウェアを統合する手段を提供するモデルのセットと関連してランタイ ムイベントマネージャを使用するアプリケーションソフトウェアを開発、テスト 、および動作させる方法、システム、およびデータ構造を提供することを目的と する。 本発明の他の目的および利点は、以下の説明を参照すると、当業者には明らか になるであろう。 図面の簡単な説明 第１図は本発明によるシステムの実施の形態のアーキテクチャを示す図である 。 第２図は本発明によるアプリケーションインターフェース、およびモデルライ ブラリまたはエンジンのセットの例の実施の形態を示す図である。 第３図は本発明の実施の形態によるランタイムイベントマネージャ、モデル、 方法、およびデータの構成を示す図である。 第４図は本発明によるモデルの実施の形態の形態を示すテンプレートの例を示 す図である。 第４Ａ図は第４図よりも詳細なモデルの別のテンプレートの例を示す図である 。 第４Ｂ図はモデルの詳細な処理情報を示すモデルのデータ構造の第１の部分の さらなる定義を示す図である。 第４Ｃ図はモデルのさらなる詳細な処理情報を示す（第４Ｂ図から続く）モデ ルのデータ構造の第２の部分のさらなる定義を示す図 である。 第５図はアプリケーションのメニューを実現する本発明によるモデルの特定の 例を示す図である。 第５Ａ図は本発明によるバリアントモデルの特定の例を示す図である。 第５Ｂ図はバリアントモデル情報を含むテーブルを示す図である。 第６図は本発明の実施の形態におけるモデルを含むオブジェクトの登録のフロ ーチャートを示す図である。 第６Ａ図は第６図で示される登録処理と関連して使用されるモデルデザインツ ールの操作のフローチャートを示す図である。 第７Ａ図は本発明の実施の形態におけるアプリケーションの開発または修正処 理中にモデルのテストにおいて使用されるテストベッドの生成のフローチャート の第１の部分を示す図である。 第７Ｂ図は本発明の実施の形態においてアプリケーションの開発または修正処 理中にモデルのテストにおいて使用されるテストベッド生成のフローチャートの 第２の部分を示す図である。 第８図は本発明の実施の形態におけるランタイムイベントマネージャの実施の 形態の動作を説明するフローチャートを示す図である。 第９図はバリアントモデルに関連する第８図のランタイムイベントマネージャ の実施の形態の処理の一部を説明するフローチャートを示す図である。 第１０図はバリアントモデルのロードおよびアンロードに関連する第８図およ び第９図のランタイムイベントマネージャの実施の形 態の処理の一部を説明するフローチャートを示す図である。 第１１図はエラスティックデータベースのベースファイルおよびベースレコー ドの例を示す図である。 第１２図はエラスティックデータベースの２つのバリエーションセットの定義 の例を示す図である。 第１３Ａ図はエラスティックデータベースにおいて新しいバリエーションセッ トを定義するのに関連するステップを説明するフローチャートの第１の部分を示 す図である。 第１３Ｂ図はエラスティックデータベースにおいて新しいバリエーションセッ トを定義するのに関連するステップを説明するフローチャートの第２の部分を示 す図である。 第１３Ｃ図はエラスティックデータベースにおいて新しいバリエーションセッ トを定義するのに関連するステップを説明するフローチャートの第３の部分を示 す図である。 第１４図はエラスティックデータベースにおいてデータ辞書を開く処理を説明 するフローチャートを示す図である。 第１５図はエラスティックデータベースにおいてロジックファイルを開く処理 を説明するフローチャートを示す図である。 第１６Ａ図はエラスティックデータベースにおいて選択されたベースレコード にどのバリエーションセットを適用するかを判断する処理を説明するフローチャ ートの第１の部分を示す図である。 第１６Ｂ図はエラスティックデータベースにおいて選択されたべースレコード にどのバリエーションセットを適用するかを判断する処理を説明するフローチャ ートの第２の部分を示す図である。 第１７Ａ図はデータベースのアクセスツールの「ＲＥＡＤ」機能 に関連するステップを説明するフローチャートの第１の部分を示す図である。 第１７Ｂ図はデータベースのアクセスツールの「ＲＥＡＤ」機能において関連 するステップを説明するフローチャートの第２の部分を示す図である。 第１８Ａ図はデータベースのアクセスツールの「ＥＸＴＲＡＣＴ」機能におい て関連するステップを説明するフローチャートの第１の部分を示す図である。 第１８Ｂ図はデータベースのアクセスツールの「ＥＸＴＲＡＣＴ」機能に関連 するステップを説明するフローチャートの第２の部分を示す図である。 第１９図はテータベースのアクセスツールの「ＶＥＲＩＦＹ」機能に関連する ステップを説明するフローチャートを示す図である。 第２０図はデータベースのアクセスツールの「ＧＥＮＥＲＡＴＥ」機能に関連 するステップを説明するフローチャートを示す図である。 第２１Ａ図はデータベースのアクセスツールの「ＷＲＩＴＥ」機能に関連する ステップを説明するフローチャートの第１の部分を示す図である。 第２１Ｂ図はデータベースのアクセスツールの「ＷＲＩＴＥ」機能に関連する ステップを説明するフローチャートの第２の部分を示す図である。 第２２図はデータベースのアクセスツールの「ＲＥＭＯＶＥ」機能に関連する ステップを説明するフローチャートを示す図である。 第２３図は、データベースのアクセスツールの「ＣＬＯＳＥ」機 能に関連するステップを説明するフローチャートを示す図である。 第２４図はデータベースのアクセスツールの「ＳＨＵＴ ＤＯＷＮ」機能に関 連するステップを説明するフローチャートを示す図である。 第２５図はテータベースのアクセスツールの「ＧＥＴ ＫＥＹ」機能に関連す るステップを説明するフローチャートを示す図である。 第２６図はデータベースのアクセスツールの「ＧＥＴ ＦＩＲＳＴ ＫＥＹ」 機能に関連するステップを説明するフローチャートを示す図である。 発明を実施するための最良の形態 第１図は本発明によるシステムの実施の形態のアーキテクチャを示す図である 。第８図から第１０図に関連して以下詳述されるランタイムイベントマネージャ （Ｒｕｎ Ｔｉｍｅ Ｅｖｅｎｔｓ Ｍａｎａｇｅｒ、「ＲＴＥＭ」）１０は、 アプリケーションに関連する全ての処理の実行に責任のある手続きのセットであ る。ＲＴＥＭ１０は、データ辞書１２、スタンダードモデル１４、デベロッパオ プションモデル１６、ローカルモデル１８、およびローカル環境２０を含む様々 なデータおよびオブジェクトへのアクセスを有する。「スタンダード」すなわち 「パラダイム」モデル１４は、そのアプリケーションと関連する処理を実行する として特定のアプリケーションのオーサによって提供されるものであり、アプリ ケーションをどのように実行するかを指定する規則を提供する。スタンダードす なわちパラダイムモデル１４はアプリケーション処理のために最終 的なデフォルトを提供する。デベロッパ「オプション」モデル１６は、スタンダ ードすなわちパラダイムモテルの全部または一部の代わりにアプリケーションの オーサによって提供されるが、スタンダードすなわちパラダイム処理の代わりで あるにもかかわらず、アプリケーションによって呼び出される処理を表している 。例として、ロジスティックアプリケーションの設定において、プロダクトのセ ットアップのモデルが提供されている場合、更なるオプションモデルを提供して 、ロードトランスポーテーションモシュールがオンになっている場合など、特定 の条件下においてのみ、入力をキャプチャし異なるファイルを更新する。ローカ ルモデル１８には、アプリケーションソフトウェアを配備され、かつそのサイト においてアプリケーション条件に適合するように独自に構成したサイトに特定の ものである。例えば、ローカルモデルは、装置、オペレータなど、そのサイトに おいて関連するローカルサイトに関連する処理を含んでいる。ローカル環境２０ は、アプリケーションが動作する特定の設定を記述するデータおよび条件を表し ている。 ＲＴＥＭ１０は、また、コントローラのセットに対するアクセスを有している 。こうしたコントローラの第１のものはステージング２２であり、これは以下で 述べるように、ＲＴＥＭ１０が処理するモデルによってデータ処理を実行する。 アプリケーション（例えば、モデル、方法、データ、テキスト等）およびツール など全てのサポーティングオブジェクトを含む全ての登録済みオブジェクトを「 ステージング」という。ステージング２２は、各オブジェクトとそれに付随する 各他のオブシェクトとの間のクロスリファレンスを提供して、当業者に公知の方 法により開発されたオブジェクトにデベ ロッパがアクセスおよび理解できるようになる。 ＲＴＥＭ１０がアクセスを有する第２のコントローラはデータベースアクセス コントローラ（「ＤＢＡＣ」）（クライアント側）２４である。ＤＢＡＣ（クラ イアント側）２４によって、ＲＴＥＭ１０が、必要時に、例えば、ネットワーク リンクすなわち共有メモリ２８などミドルウェア構成を通してデータへのアクセ スを取得することができる。さらに、ＤＢＡＣ（サーバ側）３０によって、任意 のアプリケーションを含むモデルによって必要時に、市販されているまたは著作 権を有するデータベースソフトウェアとのインターフェースが可能になる。例え ば、ＲＴＥＭ ＤＢＡＣ（サーバ側）３０は、オープンデータベースコネクティ ビィティ（「ＯＤＢＣ」）ドライバ３２およびＯｒａｃｌｅ^RＲＤＢＭ３４と、 またはＳＱＬ３サーバ３８およびＯｒａｃｌｅ^R８オブジェクト指向データベー ス管理システム（「ＯＯＤＢＭＳ」）４０と、またはＢＡＳＩＣファイルサーバ ４２およびＢＡＳＩＣファイルシステム４４と、または適切なデータベースソフ トウェアのいずれかと対話することができる。上で述べたデータベースソフトウ ェアを通して、ＲＴＥＭ１０はファイルサーバ（図示せず）に常駐するデータ３ ６へのアクセスを有する。ＲＴＥＭ１０および、ＲＴＥＭかアクセスを有するオ ブジェクトおよびデータを含むコードおよびデータの構成は、以下、第３図に関 連して説明する。 本発明の図示した実施の形態におけるＲＴＥＭ１０がアクセスを有する第３の コントローラは、ユーザＩ／Ｏ（「ＵＩＯ」）２６であり、これは好ましくはス ーパーツールキットである。ＵＩＯ２６は、ＲＴＥＭによって使用され、アプリ ケーションとその「外部」 入出力との間で対話を仲介するため、アプリケーション（またはこうしたモデル で言われるオブジェクト）を構成するモデルが同じことをする必要がない。外部 入出力は、ここでは、スクリーンフォーム、データ入力デバイスおよび電子デー タ互換（「ＥＤＩ」）処理を含むコンピュータおよび関連ネットワークの限界を 超えるものとして言及されている。 （ＲＴＥＭ１０がＵＩＯ２６の機能へのアクセスを有する）本発明の図示した 実施の形態によって開発され動作するアプリケーションは、設計したり修正した りして、ワーキングメモリデータをどこから検索するか、またどこに送るかを考 慮する必要はない。次に、こうしたアプリケーションは、スクリーンフォームま たはレポートドキュメント上に、またはＥＤＩ処理へとデータを配置するロジッ クを含む必要がなく、例えば、アプリケーションとデータを交換するデバイスま たは処理と対話する必要もない。さらに、本発明によって作成されたデータ構造 は、好ましくは、デベロッパがこうしたルールを回避することができるような手 続き上のまたは伝達上のコードを含まない。 本発明の実施の形態において、ＵＩＯ２６は、例えばスクリーン上で情報がリ フレッシュされる時期および場所を判断する。入出力はグラフィックまたは文字 のモードのどちらにするかが判断される。同様に、どのような人間言語を使用す るかを判断する。こうした外部イベントはいずれもＵエＩ２６によって適切に処 理される。基礎となるアプリケーションモデルにはＵＩＯ２６のこの機能を調整 するために設計または修正する必要はない。ＵＩＯ２６を使用したＲＴＥＭによ るユーサ入出力の仲介によって、アプリケーションに よって厳密に書き込まれたというよりは、特定の時間における条件の機能として 様々な入出力の挙動のフレキシブルな挿入が可能になる。 第２図は本発明によるアプリケーションインターフェースの実施の形態、およ びモデルライブラリまたはエンジンのセットの例を示す。本発明の用語において 、「モデル」はアプリケーション環境のルールを指定するデータを含み、また最 も好ましくはコードを全く含まないソフトウェアオブジェクトである。つまり、 モデルは、モデルが関連するアプリケーションの特定のサブセットに代わる処理 のリストを開始するデータパケットである。この処理には、ビジネスまたはアプ リケーション処理ルール、および機械的ルールを含むルールの仕様が含まれる。 以下で説明するランタイムイベントマネージャによる呼び出し時に、モデルは「 方法」、その他のモデル、またはツールを含む自立型の再利用可能な登録済みの 公的に示されたオブジェクトを呼び出す。ロシスティックスソフトウェアの設定 における例として、プロダクトに対して全てのホールドを読み出すことに関連し 、かつホールドがプロダクトの使用に影響を及ぼす度合いを判断するモデルは、 そのリストに含まれることができる。 １． ポインタをこのプロダクトの第一のレコードへのホールドファイルにセッ トする ２． 現在のレコードがプロダクト用である場合 ３． 現在のレコードを読み出す ４． 使用可能なブロダクトにおいてネット効果を蓄積する ５． ２．に戻る また、上記で一部説明するように、また以下でさらに説明するよ うに、モデルは、モデルを使用して構築したまたＲＴＥＭ１０によって動作する アプリケーションのフレキシビリティを最大限に高める数種類のものでもよい。 本明細書で使用される「方法」という用語は、従来のプログラムにおいてサブ ルーチンと類似した特定の目的を達成するために作成された手続き上のコードの ブロックをいう。本発明によると、方法は、「自立型」で再利用可能な登録済み の公的に示されたものとして使用されている。つまり、各方法は、その存在が登 録されたライブラリのみにおいて並ぶものかない。第６図と関連して以下により 詳細に説明している通り、方法を登録することでモデルにより指定された適切な 時間においてＲＴＥＭ１０によって呼び出してもよいライブラリのアクセス可能 な部分となる。本発明によると、方法のようなオブジェクトは、以下により詳し く定義するように、ペアレント、プレ処理、およびポスト処理を含むことができ る。 第２図は、これらの間でモデルおよびアプリケーションインターフェース５０ の２つのベーシックタイプのロジック環境を示している。モデルには２つの重要 なタイプが含まれる。すなわち、アプリケーション処理（またはビシネスルール ）モデルと、機械的モデルである。こうした２つのタイプは、指向先のアブスト ラクションのレベルが異なっている。アプリケーション処理またはビジネスルー ルモデルは、アプリケーションに特定の処理を実行する。例えば、ロジスティッ クスアプリケーションにおいて、アプリケーション処理またはビジネスルールモ デルは、オーダエントリまたはグッズの受信のために処理を指定する。アプリケ ーション処理またはビジネスルールモデルに関連するロジックは、１つのアプリ ケーションジ ョブのみに特定しており、一般的には、他のいずれのコンテキストにおいても再 利用不可能である。一方で、機械的モデルは、一般的により低レベルのアブスト ラクションにおいて処理を実行し、異なるアプリケーションコンテキストにおい て再利用可能である。ロジスティックス設定において、例えば、機械的モデルは 利用可能なストックを計算し、ウェアハウスにおいて場所Ａから場所Ｂへストッ クを移動させるために必要な時間を記録する。 ここで使用される「ライブラリ」という語は、構成されてＲＴＥＭ１０へアク セス可能になったオブジェクトのセットである。「エンジン」は、事後結合で再 利用可能なモデルおよび方法のライブラリであり、特に、共に機能する機械的処 理モデルと方法との集合である。第２図の例において、ロジスティックス関連の アプリケーション用のエンジンのセット（５２から６２まで）がそのアプリケー ションのインターフェース５０に関連して示されている。ハザードエンジン５２ は、ハザードイベントの処理に関連する機械的処理モデルのグループとして定義 される。ディスパッチエンジン５４は、ディスパッチに関連する機械的処理モデ ルのグループである。ビリングエンジン５６は、ビリング機能の、さらにアクテ ィビィティエンジン５８、インベントリエンジン６０、およびその他のエンジン ６２のそれぞれについて実行に関連する機械的処理モデルのグループである。 第２図では、エンジンの１つのみの内容の一部を示している。特に、ビリング エンジン５６は、代わりに方法１、７２および方法２、７４へのリファレンスを 含む機械的モデル７０を有し、この両方法は、少なくとも手続き上のコードブロ ック７８のサブセットを呼 び出すことができる。機械的モデル７０は、さらに、それ自体が２つの方法、つ まり方法Ｘ ８０および方法Ｙ ８２へのリファレンスを含む別の機械的モデル ７６へのリファレンスを含んでいる。モデルおよび方法の形態の制限の課すこと を第６図に関連して説明する。 第３図は本発明の実施の形態によるランタイムイベントマネージャ、モデル、 方法およびデータの構成を示す図である。一実施の形態において、メモリは、タ スクメモリ９０、タスクプライベートキャッシュ１００、サーバ側パブリックキ ャッシュ１１０、およびファイルシステム１２０の４つの部分を含んでいる。タ スクメモリ９０は、ＲＴＥＭ１０のオブジェクトコード９２を一部に含んでいる 。別の部分において、タスクメモリ９０は、プレコンパイルデータバンク（「Ｐ ＣＤＢ」）ポインタ９６およびダイナミック変数テーブル９８とを含む１つまた はそれ以上の変数テーブル（「ＶＴＡＢ」）９４を含んでいる。本発明による各 モデルは、第４図および第５図で以下に示すように、データを含み、モデルの呼 び出し時にＲＴＥＭ１０がロードするプレコンパイルされたデータバンクに記憶 される。モデルにおけるデータはフォーマットされ、ＲＴＥＭはデータに基づい たモデルを呼び出すことができ、これは最も好ましくは、ＲＴＥＭ１０がプログ ラムされた言語は参照された各オブジェクトのタイプを識別する拡張子または他 のデータに基づいてその内容を容易に理解し、こうしたオブジェクトを適切なロ ケーションから検索することができる。タスクプライベートキャッシュ１００は 、モデルセット１０２、方法ライブラリオブジェクトコード１０４、およびクラ イアント側プライベートデータファイルキャッシュ１ ０８を含んでいる。サーバ側パブリックキャッシュ１１０は、モデルセット１１ ２、方法ライブラリオブジェクトコード１１４、およびパブリックデータファイ ルキャッシュ１１８を含んでいる。最後に、ファイルシステム１２０は、プレコ ンパイルデータバンク１２２（ＰＣＤＢポインタ９６によってポイントされる） の形態のモデル１２２、オブジェクトコードオンディスク１２４、およびデータ ベーステーブル／ファイル１２６を含んでいる。 （第１図で示される）ＲＴＥＭ１０は、タスクのＶＴＡＢ９４へモデル「Ａ」 のメモリブロック（参照番号１０２参照）をリンクし、これはクライアント側プ ライベートキャッシュ１０８またはサーバ側パブリックデータファイルキャッシ ュ１１８のいずれかにある。モデル「Ａ」におけるデータはＰＣＤＢポインタ（ 参照番号９６参照）の形態であり、これはＶＴＢ９４のセグメントである。従っ て、多少の機械的命令が必要であり、モデルのサイズまたは複雑さに関わらず、 ＶＴＡＢ９４にこれをアクティブにリンクする。 例えば、モデル「Ａ」のステップ１（図示せず）がモデル「Ｂ」を呼び出すと 仮定する。以下でより詳細に説明するように、特定の時間において１つのモデル のみをアクティブできるとすると、ＲＴＥＭはモデル「Ａ」を下に「押し」（ス タックマシーンの場合）、それをパッシブにリンクさせたままにする。次に、Ｒ ＴＥＭ１０はモデル「Ｂ」のＰＣＤＢポインタをアクティブにリンクする（参照 番号９６参照）。 さらに、モデル「Ｂ」のステップ１（図示せず）がオブジェクトコードの１０ ６において方法「Ｘ」を実行するように指向すると仮定する。このイベントにお いて、ＲＴＥＭ１０は実行ポインタを方 法「Ｘ」に移動させ、これはどちらにしても、タスクプライベートは様々な制御 情報１００５を含み、ｌｖｓｅｑｕｅｎｃｅ＄ １００６は実行されるペアレン トオブジェクトのリストを提供し、ｌｖｅｘｉｔｏｂｊｅｃｔ＄ １００７はモ デルを終了する前に実行するオブジェクトを識別し（モデルが終了しようとする と、このオブジェクトはそのポスト処理で実行する）、ｌｖｔａｂｏｒｄｅｒ＄ １００８はフィールドからフィールドにジャンプするのに使用されるシーケン スを処理するフィールドナンバーのリストを提供し、ｌｖｆｉｒｓｔｉｎｐｕｔ １００８は、最後の入力が完了した時に処理を開始するフィールドナンバーを 提供し、ｌｖｌａｓｔｉｎｐｕｔ １０１０は、第１の入力に戻る処理を設定す る前に処理する最後のフィールドナンバーを提供し、また、ｌｖｄａｔａ ｌｉ ｓｔ＄ １０１１はこのモデルで使用される全てのデータ変数のリストを提供す る。 第４Ｂ図はモデルの詳細な処理情報を示すデータ構造の第１の部分１０００Ｂ の定義をさらに示している。特に、モデルを定義するオブジェクト数の識別を提 供し、｛ｏｂｊｅｃｔｉｄ｝．ｎａｍｅ＄ １０１２はモデルであるオブジェク トにリファレンス名を提供し、｛ｏｂｊｅｃｔｉｄ｝．ｄｅｓｃｒｉｐｔｎ＄ １０１３はこのオブジェクトの記述を提供し、｛ｏｂｊｅｃｔｉｄ｝．ｃｏｎｄ ｉｔｉｏｎ＄ １０１４はこのオブジェクトを実行するためにＲＴＥＭ１０に適 合する必要がある条件を開始し、｛ｏｂｊｅｃｔｉｄ｝．ｏｂｊｅｃｔｔｙｐｅ １０１５はこのオブジェクト（１：方法、２：ツール利用、または３：モデル ）のタイプをＲＴＥＭ１０に通知し、｛ｏｂｊｅｃｔｉｄ｝．ｍｏｄｕｌｅ＄ １０１６はツ ール利用、方法、またはモデルのモジュールを識別し、｛ｏｂｊｅｃｔｉｄ｝． ｒｅｐｏｓｉｔｏｒｙ １０１７はツール利用または方法のレポジトリを識別し 、｛ｏｂｊｅｃｔｉｄ｝．ｍｅｔｈｏｄ＄ １０１８は実行する方法を識別し、 ｛ｏｂｊｅｃｔｉｄ｝．ｔｏｏｌｕｓａｇｅ＄ １０１９は実行するツール利用 を識別し、｛ｏｂｊｅｃｔｉｄ｝．ｍｏｄｅｌ＄ １０２０は実行するモデルを 識別し、｛ｏｂｊｅｃｔｉｄ｝．ｐｅｒｆｏｒｍｆｌｇ １０２１はこのオブジ ェクトにアクセスする方法をＲＴＥＭ１０に命令し（０はモデルバールで指定さ れるオブジェクトが呼び出されることを示す一方、１は全てのモデルデータの受 け渡しをするオブジェクトを実行することを示すモデルデータを受け渡し、｛ｏ ｂｊｅｃｔｉｄ｝．ｍｏｄｅｌｖａｒｓ＄ １０２１は方法、ツール利用または モデルへ受け渡されるモデル変数のリストを提供し、｛ｏｂｊｅｃｔｉｄ｝．ｏ ｂｊ＿ｖａｒ＄ １０２３は（モデルバールで指定される）モデル変数から移さ れるオブジェクト変数のリストを開始する。 第４Ｃ図は、モデルのさらに詳細な処理情報を示すモデル（第４Ｂ図から続く ）のデータ構造の第２の部分の定義をさらに示している。特に、方法、ツール利 用、またはモデルにおいて受け渡されるこの変数の利用を識別する｛ｏｂｊｅｃ ｔｉｄ｝．｛ｍｏｄｅｌ ｖａｒｉａｂｌｅ｝＿｛ｔｙｐｅ ｏｆ ｖａｒｉａ ｂｌｅ｝．ｕｓａｇｅ＄ １０２４を含んでいる。Ｍｏｄｅｌ＿ｖａｒｉａｂｌ ｅは、｛ｏｂｊｅｃｔｉｄ｝．ｍｏｄｅｌｖａｒｓ＄で開始される各データ変数 を設定し、｛ｔｙｐｅ ｏｆ ｖａｒｉａｂｌｅ｝は以下のものを識別する。Ｃ は文字変数を示し、Ｎは数字変数を示し 、利用、Ｉは受け渡されるにすぎない変数を示し、Ｂは受け渡し、また受け渡さ れる変数を示し、Ｆは指定されたデフォルト値として中および外に受け渡される 変数を示している。 ｛ｏｂｊｅｃｔｉｄ｝．｛ｍｏｄｅｌ ｖａｒｉａｂｌｅ｝｛ｔｙｐｅ ｏｆ ｖａｒｉａｂｌｅ｝ １０２５は方法、ツール利用またはモデルへ受け渡すデ フォルト値を識別する。｛ｏｂｊｅｃｔｉｄ｝．ａｃｔｉｏｎ＄ １０２６はこ のオブジェクトのためにアタッチメントアクションを識別する（１：プレ処理オ ブジェクト、２：ペアレントオブジェクト、または３：ポスト処理オブジェクト ）。｛ｏｂｊｅｃｔｉｄ｝．ｐａｒｅｎｔｎａｍｅ＄ １０２７は、オブジェク トがプレ処理またはポスト処理である場合に、ペアレントオブジェクトの名前を 識別する。｛ｏｂｊｅｃｔｉｄ｝．ｐａｒｅｎｔ ｏｂｊ＄ １０２８は、プレ 処理またはポスト処理である場合に、ペアレントオブジェクトのオブジェクトＩ Ｄを指定し、｛ｏｂｊｅｃｔｉｄ｝．ｄｅｓｉｇｎｎａｍｅ＄ １０２９はモデ ルデザインオブジェクトのタイプを識別し、｛ｏｂｊｅｃｔｉｄ｝．ｍａｎｄａ ｔｏｒｙ １０３０はオブジェクトが入力である場合に、エントリーが強制であ るかどうか（強制でない場合には０、強制の場合には１）の入力へ示し、｛ｏｂ ｊｅｃｔｉｄ｝．ｐｒｅｐｒｏｃｓ＄ １０３１は、このペアレントオブジェク トのためにプレ処理オブジェクトのリストを識別し、｛ｏｂｊｅｃｔｉｄ｝．ｐ ｏｓｔｐｒｏｃｓ＄ １０３２はこのペアレントオブジェクトのためにポスト処 理のリストを識別する。 第５図はアプリケーションのメニューを実行する本発明によるモデル（特に、 パラダイムモデル）の特定の例１７０を示している。 メニュー例（Ｍｅｎｕ ｅｘａｍｐｌｅ）のヘッダ１７１の後に１２個のオブジ ェクトのセットが続き、８つの方法、入力および終了を含んでいる。このモデル のオブジェクトの１つ、ｓｅｌｅｃｔＶａｌは、「ペアレント」オブジェクトで ある。このペアレント（前のスラッシュ（／）によっても示される）に先行する ものはプレ処理と呼ばれ、ペアレントの後のものは（バックスラッシュ（＼）で 示される）ポスト処理と呼ばれる。 モデルを呼び出すと、ｃｌｒ ｓｅｌｅｃｔ方法１７２が動作し、これにより 選択されるメニュー項目の値を保持する変数をクリアする。Ｍｅｎｕ ａｃｔｉ ｖモデル１７３は、ｍｅｎｕｄｆｌｔ１７４方法が何の選択も行っていない場合 に表示する初期メニューなどのデフォルト値をセットした後で、現在の月日、オ ペレータ、端末、カンパニー、メニューアクティビィティを追跡するのに使用さ れるシステムをセット（ロジスティックスを含むアプリケーションコンテキスト において）する。方法ｍｅｎｕ ｄｉｓｐｌ １７５はメニューをロードおよび 表示する。ＳｅｌｅｃｔＶａｌ １７７がユーザによって選択された値を読み出 しおよび記憶した後、方法ｓａｖｅ ｖａｌｓ １７６は古い値をセーブする。 モデルｍｅｎｕｓｅｌｅｃｔ １７８はユーザによって行われたメニュー選択を 確認する。メニューのセキュリティを確認するための呼び出されるモデルの次の オブジェクトはｍｅｎｕｓｅｃｕｒｅ １７９である。メニューを使用したオペ レータが有効でない選択を入力し、または別のメニューを選択して表示を行う場 合、処理は方法ｃｌｒ ｓｅｌｅｃｔ １７２において繰り返される。これは、 ＲＴＥＭ１０への特別要求（第８図の参照番号３２４）を受け渡す方法ｍｅｎｕ ｓｅｃｕｒｅ １７９によって達成される。有効な選択が行われると（有効なジ ョブ）、モデルはｅｘｉｔ（オブジェクト）１８１を動作し、こうしてメニュー モデルの実行を終了したＲＴＥＭ１０に伝えるために制御変数をセットする（ｅ ｘｉｔ １８１に対する全てのポスト処理はＲＴＥＭ１０が実際にモデルを離れ る前に処理される）。 オペレータがプリケーション環境を終了することを選択する場合、メニュー選 択入力（ＳｅｌｅｃｔＶａｌ １７７）において適切に予め設計されたキー（こ の例では、Ｆ４キー）を押す。これによりｅｘｉｔ １８１に処理が送られ、こ うしてメニューモデルの処理を終了したＲＴＥＭ１０に伝えるために制御変数を セットする（ｅｘｉｔ １８１に対する全てのポスト処理は、ＲＴＥＭ１０が実 際にモデルを離れる前に処理される）。方法ｍｅｎｕｆ４ １８２は、メニュー 選択入力（ＳｅｌｅｃｔＶａｌ １７７）でＦ４キーを押すオペレータを条件と する。方法ｍｅｎｕｆ４ １８２はシステム構成フラグをチェックして、トップ レベルにおいてまだであれば、メニューモデルがメニューディスプレイにおいて １つのレベルをバックアップすべきかどうか確認し、トップレベルであればメニ ューモデルを終了し、またはシステム構成フラグがただちにメニューモデルをメ ニューディスプレイの以前のレベルに移動することなく終了する。Ｍｅｎｕ４ｆ １８２方法がメニューディスプレイで１つレベルを上げることを判断する場合 、ｅｘｉｔ １８１でセットされた制御変数（メニューモデルの実行を終了した ＲＴＥＭ１０に伝えるために）はリセットされて、表示する選択されたメニュー は前のメニューへセットされる。こうして方法ｃｌｒ＿ｓｅｌｅ ｃｔ １７２において処理を継続する。 モデルＭｅｎｕ ｅｘａｍｐｌｅ １７０と関連するデータ変数は、メニュー 選択を記憶するａｃｔｉｏｎ １８４と、５つのスペースを記憶するｂｌａｎｋ ５ １８５と、カンパニー名を記憶するｃｍｄｃｏｍｐａｎｙ １８６と、カ ンパニーコードを記憶するｃｏｍｐａｎｙ １８７と、メニュー説明を記憶する ｍｅｎｕ ｄｅｓｃ １８８と、前に表示されたメニューのアイデンティティを 記憶するｏｌｄｍｅｎｕｄｓｐ １８９と、ページディスプレイを記憶するｐａ ｇｅｄｉｓｐｌｙ １９０と、メニュー選択を記憶するｓｅｌｅｃｔｖａｌ １ ９１と、カンパニーの略名を記憶するｓｈｏｒｔ ｎａｍｅ １９２と、ステー タス値を記憶するｓｔａｔｕｓ １９３と、システムのサブメニューを記憶する ｓｕｂ−ｍｅｎｕ １９４と、コンピュータ端末を識別するｔｅｒｍｉｎａｌ １９５と、ｔｉｌｄｅ １９６と、ｔｉｌｄｅ２ １９７と、特定の時間を記憶 するｔｉｍｅ １９８とを含む。 第５Ａ図は第５図のパラダイムモデル１７０に基づいたバリアントモデル１７ ０Ａを示している。バリアントモデル１７０Ａは、パラダイムモデル１７０と殆 ど同じである。しかし、パラダイムモデル１７０にはない処理、特にメニューセ キュリティの確認後にログファイルへのメニュー対話を書き込むポスト処理ｔｒ ａｃｋ＿ａｌ １７９Ａを含んでいる。バリアントモデル１７０Ａのヘッダ１７ １Ａは、モデルがバリアントであり名前によって識別するということを示してい る。さらに、ヘッダは、バリアントモデル１７０Ａに必要な条件（この例では、 １つのみ）をリストし、可能性のある呼び出しのために「適用」し次にロードさ れる。この場合において、 ｔｒａｃｋ＿ａｌバリアントモデル１７０Ａに必要な条件は、カンパニーコード がＡ１に等しいということである。モデルのランタイム確認テーブル（ランタイ ム確認マップということもある）は、エラスティックテータベースと関連して以 下に述べるＤＢＡＣ２４、３０と同じ構造のランタイム確認テーブルである。 このテーブルまたはマップはあるバリエーションをモデルに適用する場合、以 下のようになる。 対応するランタイム表現テーブルは次のようになる。 （ＣＯＭＰＡＮＹ＄＝「Ａ１」） なお、ベースレコード読み出し後のメモリ内のデータは、 ＣＯＭＰＡＮＹ＄＝「Ａ１」 となる。ランタイム表現テーブルを使用して、ランタイム評価コードを生成する 。この例では、 （ＣＯＭＰＡＮＹ＄＝「Ａ１」） である場合、ランダイム評価コードは「１」になる。このランタイム評価コード は、バリエーションがアクティブであることを判断できるよう示されたテーブル と対照される。アクティブなバリエーションは、ランタイム評価コードと同じ位 置で「１」を有するものとなる。 バリアントテーブルはモデルのランタイム情報に対応する。このバリアントテ ーブル付随ファイルは、全てのバリアントモデルを作動させる全ての条件のテー ブルを記憶する。上記の例では、バリアントテーブルは以下のようになる。 LVRTEM.VAR CHECK$=「(COMPANY$=「A1」)」 LVRTEM.VAR TABLE$=「１」 LVRTEM.VARIATIONS$=「track a1」 ここで述べられている実施の形態の命名規則を明らかにすると、ＬＶ（すぐ上 で使用されている）はローカルな変数クラスをいい、ＳＹ（システム変数）、Ｄ Ｄ（データ辞書）、ＤＢ（テータベース）、ＬＬ（ローカルラベル）、ＲＴ（ル ーチン）など他のプレフィクスは他の変数クラスで使用される。 バリアントモデル１７０Ａの詳細にコメントされたものが第５Ｂ図に示されて おり、ＣＯＭＰＡＮＹが「Ａ１」である時にバリアントモデルがロードされると いうこと、各メニュー選択後にログファイルに書くＤＡＴＡ ＯＰＥＲＡＴＯＲ 、ＴＩＭＥ、およびＳＥＬＥＣＴＶＡＬに書き込むためにツール利用オブジェク トの例に加えるということを示している。オブジェクトはＥＸＩＴ ＭＥＮＵと 呼ばれるＤＥＣＩＳＩＯＮの前に実行される。まず、バリアントモデル１７０Ａ はオブジェクト名を含み、パラダイムモデルへ追加す る。次に、モデルての処理シーケンスにおいてそのオブジェクトをどこに挿入す るかを示す。特に、オブジェクト（「ｔｒａｃｋ Ａ１」）は、ポスト処理とし てペアレントオブジェクト「ｓｅｌｅｃｔｖａｌ」（第５図の参照番号１７７と 第５Ａ図の参照番号１７７Ａ）に添付され、ｅｘｉｔ ｍｅｎｕ（第５図の参照 番号１８０と第５Ａ図の１８０Ａ）に挿入される。例オブジェクト「ｔｒａｃｋ ａ１」に関連する処理の詳細があとに続く。まず、ストリング「Ｗｒｉｔｅ ｔｏ ｌｏｇ ｆｉｌｅ」にセットされた（ＤＥＳＣＲＩＰＴＮ＄）という説明 が提供される。オブジェクトのタイプはツール利用（この例では、この値は２） を示す値にセットされる。次に、ペアレントオブジェクト３２文字ＩＤ（ＰＡＲ ＥＮＴＯＢＪ＄）が開始され、ペアレントオブジェクト名（ＰＡＲＥＮＴＮＡＭ Ｅ＄）（上で述べているように、「ｓｅｌｅｃｔｂａｌ」である）が続く。詳細 には、オブシェクト設計名（ＤＥＳＩＧＮＮＡＭＥ＄）は「ツール利用」であり 、モジュール（ＭＯＤＵ１Ｅ＄）は「モジュール」であることをさらに含む。詳 細な情報にはさらに、オブジェクトが常駐するレポジトリ（ＲＥＰＯＳＩＴＯＲ Ｙ＄）のアイデンティティ、すなわちデータベースを含む。さらに、オブジェク ト（ＴＯＯＬＵＳＡＧＥ＄）によって呼び出される方法は、ｔｒａｃｋ ａｌが ログファイルに書き込むため「書き込み」として指定される。 さらに、バリアントモデルは、「ログファイル」（「モジュール」として識別 されるモジュール内のログファイル）、「書きこみ」（動作を示している）、お よびオブジェクト（すなわちオペレータ（ＺＯＰＲＩＮＦＯ＄（１、６））、時 間（ＴＩＭＥＳ）、メニュ ー選択（ＳＥＬＥＣＴＶＡＬ＄）に必要な条件が満たされる場合に書き込まれる 変数リストを含んでいる。バリアントモデルはさらに、ロジックファイル名（Ｓ ＹＬＦＮ＄）であるいくつかのオブジェクト変数（ＯＢＪ ＶＡＲＳ）、要求さ れたアクション（ＳＹＲＥＱＵＥＳＴ＄）、オペレータ（ＯＰＥＲＡＴＯＲ＄） 、時間（ＴＩＭＥ＄）、およびメニュー選択（ＳＥＬＥＣＴＶＡＬ＄）を含む。 バリアントモデルは、上記のパラメータでＤＢＡＣを呼び出して、書き込みを行 う。 第６図はモデルを含むオブジェクトの登録処理２００の実施の形態のフローチ ャートを示している。登録処理により、アプリケーション開発プロジェクト中に 、すべてのオブジェクトがＲＴＥＭ１０による呼び出しおよび適切な実行を可能 にするある制約に従うことを確認する。登録処理２００は、さらに、オブジェク トのテスト、最終的には登録済みオブジェクトに依存するアプリケーションを容 易にする。登録済みのオブジェクトは１つ以上のアプリケーションによって呼び 出してもよい。この登録処理２００は、デベロッパによって、オブジェクトにお けるデータのリスティングでステップ２０２で始まる。このデータには独特のオ ブジェクト識別子（「ＩＤ」）、例えば３２文字オブジェクト登録ＩＤ（第４図 のモデルテンプレートには図示せず）を含んでいる。また、データは、第４図の モデルテンプレート１４０と関連して上記に述べた「Ｅｘａｍｐｌｅ ｔｅｍｐ ｌａｔｅ」などの自然言語（例えば、英語）名を含んでいる。この説明には、ま た、独自の言語名（第４図の例モデルテンプレート１４０の中央のコラムで述べ た）および第５図のＭｅｎｕ ｅｘａｍｐｌｅモデル１７０をタイプインジケー タと同様に含 み、オブジェクトはモデル、方法、ツール、データ要素、フィールド、ファイル または他のオブジェクトであると述べている。オブジェクトのデータはまた、開 発プロジェクトコントロールユニット（「ＤＰＣＵ」）ＩＤ、オブジェクトのオ ーサ、オブジェクトのＩＤおよび自然言語名を含み、オブジェクトと、レポジト リまたはライブラリのどちらにオブジェクトがあるかを示すステータスフラグを 交換または再定義するようにしてもよい。 ＤＰＣＵは開発ワークのロジックブロックを示し、アプリケーション開発プロ ジェクトのいかなるサブセットにすることもできる。本発明のアプリケーション 開発方法の一実施の形態によると、開発オブジェクトレジストリは、使用可能に なる前にそれにＤＰＣＵを割り当てる。ＤＰＣＵの割り当ては、オブジェクトを 特定のデベロッパまたは開発グループに関連付けて、開発オブジェクトの統合性 および品質を保証する。ＤＰＣＵのデータファイルは次のものを含んでも良い。 ・ オブジェクトのオーサまたはデベロッパのリスト ・ このＤＣＰＵが責任のある開発オブジェクトのリスト ・ ＤＰＣＵによってカバーされるワークオーダーのリスト ・ オブジェクトのためのワークの短い説明 ・ オブジェクトのためのワークの長い説明 ・ オブジェクトの登録日 ・ オブジェクトの開始日 ・ オブジェクト（以下述べる）のテストスイートのリスト ・ オブジェクトの組み込みの意図されたウェーブ テストスイートは、本質的には（以下に述べる）任意の「テスト セッション」に含まれる関連するオブジェクト、ＤＰＣＵのリストである。これ により、複数のアプリケーション開発プロジェクト（およびそれの関わるオブジ ェクト）を、同じソフトウェア処理が関わっていても、同時にテストすることが できる。本発明の実施の形態の開発テストスイートファイルは以下のものを含む 。 ・ ＤＰＣＵのリスト、およびスイートのテストに含まれるオブ ジェクトの暗示されるリスト ・ 他のテストスイートのリスト、もしあれば、任意のテストス イートによるテストにおいて結合されるもの ・ 登録済みテスタのリスト、例えば６文字のユーザ／アソシエ ートのコード ・ 公知のテストディレクトリ（以下に述べる）のリスト ・ テストスイートに責任のある品質保証人のアイデンティティ テストディレクトリは、テストセッションの出力をホールドするロケーション である。テストセッションはランタイムに呼び出されて任意のテストスイートを 呼び出す。テストセッションによって更新されたファイルはいずれもテストディ レクトリおよびそれに配置され、ファイルのプロダクションバージョンには配置 されない更新レコード／テーブルに複製される。この処理は第７図に関連して説 明する。複数のテストディレクトリを１つのテストスイートに適用することがで きるとすると、個々のテスタは、同じスイートをテストしてもよいその他から無 関係に操作オプションを有する。本発明の実施の形態のテストディレクトリは以 下のものを含む。 ・ テストディレクトリのＩＤ ・ テストスイート ・ 許可されたテスタのリスト テストティレクトリは、いくつの数であっても、１つのテストディレクトリし か任意のテストセッションに対応しないという条件で任意の時間にアクティブに してもよい。第７図に関連して以下に示されるテストディレクトリは、全ての書 き込み動作を捉え、データベースへ更新する。これは、テスト、環境というより もプロダクションにおいてオリジナルのレコードが書き込みされてもあてはまり 、テストセッションが進行していることを指定することでプロダクション環境に おいてテストできるようにする。 データベースアクセスコントローラ（第１図からのＤＢＡＣ２４、３０）は、 そのフォーマットまたは要素定義が変化しなくてもテストセッション中に読み出 されたプロダクションファイルレコードを自動的にコピーする。ＤＢＡＣ２４、 ３０は、まず、テストディレクトリの読み出しを試みるが、そうでないとデータ ベースのプロダクション部分から要求されるレコードを読み出す。テストディレ クトリを利用すると、テストセッション中にプロダクションデータの変更が排除 される。テストセッション中に読み出されたプロダクションファイルレコードが そのフォーマットまたは要素定義に関して変化すると、読み出されたまたは抽出 されたプロダクションレコードのいずれも通常の出力においてのみテストディレ クトリに書き込まれる。 ランタイムにおいて、アプリケーションの開発を行うオペレータは、メニュー スクリーンに出会った時にテストセッションを呼び出してもよい。テストスイー トがそのオペレータに関連するリストから選択される。次に所定のテストディレ クトリがそのスイートおよ びこのオペレータに添付されるリストから選択される。テストセッション中に以 下のものを含むがこれに限定されない様々なデータがトラックされる。 ・ 動作されたショブ ・ アクセスされたデータベースフィールド ・ オペレータキーストローク ・ 遭遇するエラー ・ オペレータが入力するテスティングコメント ・ オペレータが記録するテスト項目 任意の時間において消去およびリセットされるテストディレクトリがクリアさ れるが、セッションの結果は好ましくはレコードキープの目的で永続的な記憶装 置において記憶される。 全てのオブジェクトをテストすると、「プロダクションウェーブ」の一部にす ることができ、または単にローカルなアプリケーション環境において合法的に使 用することができる。 テストスイートが以下のテスティングを証明すると、それに関連するオブシェ クトはすべて「プロダクションステータス」に転送される。特定のアプリケーシ ョンコンテキストにおいて、このようなコンテキストに適した他の基準がテスト スイートに関連するオブシェクトヘプロダクションステータスを割り当てる前に 課されてもよい。 第６図を参照すると、ステップ２０４においてデベロッパは、ステップ２０６ からステップ２１６によってオブジェクトを構築し始め、第４図および第５図と 関連してその例を述べた適切なフォーマットを有するモデルを生成する。オブジ ェクトが構築されると、開 発レシストリの一部にしてもよい。開発レジストリのオブジェクトは「開発オブ ジェクト」ということができ、プロダクションレポジトリまたはライブラリで登 録される「プロダクションオブジェクト」と区別される。 登録処理２００の性質は、登録されるオブジェクトのタイプによってもよい。 モデル（パラダイムおよびバリアント）を方法およびツールというよりもいくら か異なる考慮によって登録する。 モデル（パラダイムおよびバリアントの両方）は、例えばモデルデザインツー ル２０８によって生成または修正されることができる。例えば現行の登録済みの モデルに修正が行われると、バリアントモデルの形態で変化が起こる。バリアン トモデルはどんな数でも生成することが可能であり、任意のパラダイムモデルに 対応する。 モデルデザインツール２０８の実施の形態のロジックフローチャートが第６Ａ 図に示される。モデルデザインツール２０８は、まず、ステップ２０８１におい てアプリケーションデベロッパが、現行のモデルのリストからモデルを選択した り、または、現行のリストに追加される新しいモデルを生成したりできるように する。現行のパラダイムモデルが選択されると、モデルに対する変化はパラダイ ムモデルへバリアントモデルとして記憶される。そして、モデルデザインツール ２０８は循環ループを初期化し、選択したモデルに関連するルールの全てを追加 する。このループの第１のステップにより、デザインオブジェクトのステップ２ ０８２において、タイプにより選択し、選択したモデルの一部にすることができ る。オブジェクトは登録済みのオブジェクトすなわちオブジェクトへの条件を満 たして、ここで述べるようにＲＴＥＭ１０によって処理されるもの からのみ選択されるようにしてもよい。ステップ２０８３では、アプリケーショ ンデベロッパは、モデルに対するオブジェクトを追加することができ、また選択 したオブジェクトに関連するパラメータを追加することもできる。モデルはコー ドを含まないため、オブジェクトは本当はモデルにあるのではなく、モデルは選 択したオブジェクトへのリファレンスを含むということを思い起す。モデルにオ ブジェクトを追加することに加え、アプリケーションデベロッパはモデルに関連 するオブジェクトを修正または削除してもよい。図示によって、アプリケーショ ンデベロッパは以下のものを選択することができる。 ・ データ定義 このモデルで使用されるデータを定義し、このデータ定義 がポイントするデータ辞書１２（つまり、ファイルまたはデータ要素からのフィ ールド）における要素に入力する。 ・ 入力 ユーザ入力と、ユーザエントリを記憶するデータと、異なる結果 コードを引き受ける特別アクション（ある場合）とを定義する。 ・ ボタン ボタン定義と、表示するラベルと、異なる考えられる結果コー ドを引き受ける特別アクション（ある場合）とを定義する。 ・ 方法 呼び出す方法と受け渡すパラメーク（ある場合）を選択し、異な る考えられる結果コードを引き受ける特別アクション（ある場合）を入力する。 ・ ツール利用 呼び出すツール利用と受け渡すパラメータを選択し、異な る考えられる結果コードを引き受ける特別アクション（ある場合）を入力する。 ・ モデル 呼び出すモデルと受け渡すパラメータ（ある場合）を選択し、 異なる考えられる結果コードを引き受ける特別アクション（ある場合）を入力す る。 ・ 決定 この決定ステップの条件（ある場合）および実行する特別アクシ ョン（ある場合）を入力する。 ・ 終了 ・ ロールスクリーン作動 視覚的ローリングスクリーン定義を入力して使 用し（ロールスクリーンとは、データエントリの際に自動的にスクロールし、特 に連続するレコードにおいてデータの繰り返されるエントリに関連する機能をい う）、異なる考えられる結果コード（ある場合）を引き受ける特別アクションを 入力する。 ・ ロールスクリーン視覚定義 「ロール」するための視覚的な行の数を定 義する。 ・ ボックスディスプレイ ボックス（ある場合）のタイトルを入力する。 ・ テキストディスプレイ 表示するテキストを入力する。 これまでのステップ２０８の処理の結果は、モデルに関連するオブジェクトの リストを作成するためにすぎなかった。しかし、このポイントに対してリストに おけるオブジェクトの順序は、モデルに追加されるオーダーに従うのみである。 次に、ステップ２０８４において、アプリケーションデベロッパはモデルに視覚 的オブジェクトを配置してもよい。例えば、デザインオブジェクトが使用可能な 視覚的コンポーネント（例えばスクリーンボタン）を選択した場合、またアプリ ケーションデベロッパがスクリーンボタンやその他の オブジェクトをモデルに追加しようとする場合、モデルを設計するアプリケーシ ョンテベロッパは、視覚的形態においてこのオブジェクトを「配置」する（すな わち、ボタン、またはサイズおよびボックスの位置を表示する場所を示す）よう 促される。オブジェクトは、一般的に当業者である使用可能なオプションのセッ トの間で選択される。 次に、アプリケーションデベロッパは、ステップ２０８５において、モデル内 のオブジェクトを再オーダし、そのシーケンスによってＲＴＥＭ１０により呼び 出された場合、設計されるモデルと関連する所望の処理を有効にするよう実行さ れるシーケンスに配置してもよい。上記で選択されたオブジェクトが処理オブジ ェクト（すなわち方法を呼び出す）である場合には、モデルを設計するアプリケ ーションデベロッパはこのオブジェクトを他の処理オブジェクトに関連する別の 位置に移動することができる。デフォルトは、ペアレントシーケンスの終わりに 新たな処理オブジェクトを全て追加する。モデルを設計するアプリケーションデ ベロッパが方法を（例えば）別のオブジェクトへのプレ処理に使用する場合、こ れはこのステップ２０８５において実行される。このように、例えば、オブジェ クトが方法であり特定のペアレントオブジェクトのためにプレ処理またはポスト 処理にされる場合、ステップ２０８５において適切な関連する順序が課される。 ステップ２０８５を通じた処理の結果は制御リストである。 フローチャートの部分Ａの特定のモデル設計処理が特定のモデル、モデルデザ インツール２０８のために完了すると、次にフローチャートの部分Ｂにおいて、 および公知の方法によって、ＲＴＥＭ１ ０はプレコンパイルされたデータバンク（ＰＣＤＢ）ポインタ（第３図の参照番 号９６を参照）を生成するモデルを呼び出し、これによりＲＴＥＭ１０は実際の モデルにアクセスすることができる。ＲＴＥＭ１０はモデルの呼び出し時にプレ コンパイルされたデータバンク９６へとデータをロードするため、ＲＴＥＭ１０ は、モデルの呼び出し時にモテル設計処理中に指定されたルールを実行すること かできる。維持されるモデルがバリアントモデルである場合、バリアントモデル 情報だけが記憶され、更新するパラダイムモデルに添付されるバリアントモデル テーブルが更新される（すなわち、バリアントモデルが存在し、どのようなデー タ条件の下でそれを呼び出すかを伝える）。モデルデザインツール２０８におけ る各ステップの機能は、既知の方法によって実施可能である。 第６図によると、方法またはツールを２１０で登録する場合、その方法または ツールのソースコードをステップ２１２において編集または維持する。次に、コ ード（ソースコードまたはオブジェクトコードのいずれか）をスキャンしてステ ップ２１４においてイリーガル（ｉｌｌｅｇａｌ）に動作する。本発明の実施の 形態における、イリーガルな動作のためのスキャンは、コードを読み出し、また コードを書き込む言語におけるイリーガルな動作の名前であるキーワードがある かどうかテストする。一般的に、制御の転送または入出力動作（例えば呼び出し または書き込みなど）を実行する言語に遭遇すると、こうした言語はイリーガル であると識別され、修正を行わなければならない。ビシネスベーシックでは、例 えば、イリーガルな動作には次のようなものがある。 ・ＣＡＬＬ ・ＥＸＴＲＡＣＴ ・ＰＥＲＦＯＲＭ ・ＰＲＩＮＴ ・ＷＲＩＴＥ ・ＲＵＮ ・ＲＥＡＤ ・ＩＮＰＵＴ ・ＦＩＮＤ ・ＯＢＴＡＩＮ ・ＣＬＯＳＥ ・ＯＰＥＮ 登録処理２００はまた、ステップ２１６において、スキャン処理中に導出した パラメータを識別する。値を割り当てられた変数はいずれも方法から戻る。他は すべて方法へ受け渡される。 次に、全てのオブシェクトは、オブジェクトのタイプを判断するステップ２１ ８において開始されるテストオブジェクトの手続きが必要である。モデルや変数 （２２０）について、ステップ２２２でまずテストベッド（ＴｅｓｔＢｅｄ）か セットアップされる。このテストベッドによって、実際のまたは「ライブ」であ るがそうしたデータの真のファイルに影響を及ぼさないデータを使用して、モデ ル（またはバリアントモデル）をテストすることができる。また、全てのデータ は、必要に応じてテストベッドに自動的に移動する。 第７Ａ図はテストベッド方法２４０の第１のフローチャートを示している。開 発およびテストを実行しているアプリケーション、特に作成または修正されてい るアプリケーションの一部であるモデルが入力または出力（「Ｉ／Ｏ」）動作を 要求する場合、テストベッド方法２４０が呼び出される。ステップ２４２におい て、テストベッド方法２４０は、リクエストが入力（読み出し）、出力（書き込 み）、または削除（除去）のどれであるか判断する。 要求が読み出し動作を実行するものである場合、ステップ２４４においてテス トベッド方法は、読み出されるデータがテストベッド にあるかどうかを判断する。テストベッドにある場合、ステップ２５０において 方法は要求されたデータを検索する。この点において、方法２４０は、「サマリ ーフィールド」といわれる複数のレコードの詳細を集合または合計するフィール ドの並行性を維持することを意図するいくつかのステップを実行する。こうした ステップ２５２から２５８は、方法２４０において１つ以上の分岐（ｂｒａｎｃ ｈ）から呼び出され、これは以下に詳述する。ステップ２６０において、処理は アプリケーションに戻る。 読み出し動作を通じて探し出されたデータがステップ２４４においてテストベ ッドにないと判断される場合、ステップＲ０１において、テストベッド方法は、 読み出されるデータがテストベッド削除（ＴｅｓｔＢｅｄ Ｄｅｌｅｔｉｏｎ） ファイル（または単に「テストベッド削除」ともいう）にあるかどうかを判断す る。テストベッド削除は次の理由によりテストセッション中に削除されたレコー ドを記憶する。(実際の、テストというよりもデータを含む、また単に「ライブ 」といってもよい)「ライブ」データベースは、テストセッション中には変更さ れない。さらに、レコードがテストベッドにない時にライブから検索される。従 って、メカニズムとしては、テストセッション中に削除されたレコードを知って 、テストセッション中にライブデータベースからテストベッドに削除したレコー ドが再び表示されないようにしなければならない。こうしたメカニズムは、テス トセッション中に削除されたレコードのテストベッド削除ファイルの記憶装置で 提供される。データがテストベッド削除に表示される場合、要求されたデータは 存在しないと考えられる。データは戻らず、ステップ２５４においてアプリケー ションに処理 が戻ることになる。 ステップＲ０１において、デークがテストベッド削除にないと判断される場合 、ステップＲ０２において、テストベッド方法は、読みこまれたファイルが、ペ アレント、チャイルド、またはスタンドアローンファイルなのかを判断する。「 ペアレント」は、１つまたは複数の「チャイルド」ファイルに関連情報を有する ファイルである。例えば、ロジスティックスのコンテキストにおいては「オーダ 」ファイルである。オーダヘッダデータはペアレントファイルに格納してもよく 、一方で詳細プロダクト行、リマーク行、および特別なチャージ行などの情報は 、そのペアレントファイルと関連する１つまたは複数のオーダディテールチャイ ルドファイルに格納されてもよい。ペアレントデータはチャイルドデータがなく ても存在することができるが、チャイルドデータはペアレントデータがないと存 在できない。スタンドアローンファイルとは、ペアレントとチャイルドとのデー タの関連がないものをいう。このファイルがペアレントファイルであるとステッ プＲ０１で判断されると、ステップＲ０５で処理が継続する。 ペアレントデータはステップＲ０５において「ライブ」から検索され、またス テップＲ０６においてテストベッドに書き込まれ、ロックされる。各チャイルド ファイルは、Ｒ０７において適切な「ライブ」ファイルから検索され、適切なテ ストベッドファイルに書き込まれたペアレントデータと関連するデータを有して いる。この処理か完了すると、ペアレントデータはステップＲ０８においてテス トベッドでロック解除され、要求されたデータがステップ２５０においてテスト ベッドから検索される。次のステップ２５２から２５ ８では、サマリーフィールドデータの並行性が（以下に述べるように）維持され ており、処理はステップ２５４においてアプリケーションに戻る。 ステップＲ０２においてファイルがスタンドアローンであると判断される場合 、ステップ２４６において、要求されたデータは適切な「ライブ」テータソース から検索される。データが検索されると、（以下に述べる）全てのサマリフィー ルドはステップ２４７においてクリアされる。ステップ２４８において、検索し たデータをテストベッドに書き込むことによりテストベッドが更新される。次に 、ステップ２５０においてデ−タがテストベッドから検索され、ライブおよびテ ストベッド間でデータの並行性を維持した後、ステップ２５２から２５８のサマ リフィールドにおいて、ステップ２５４で処理はアプリケーションに戻る。 ステップＲ０２において、ファイルがチャイルドであると判断された場合、ス テップＲ０３において、ペアレントデータかテストベッドに存在するかどうか判 断が下される。テストベッドに存在する場合、ステップ２５０においてデータが テストベッドから検索される。再び、サマリフィールドのデータ並行性がステッ プ２５４から２５８において（以下に述べるように）維持され、処理がステップ ２５４においてアプリケーションに戻る。このチャイルドファイルについて、ペ アレントデータがステップＲ０３においてテストベッドにないと判断される場合 、ステップＲ０４において、ステップＲ０４でペアレントデータがテストベッド 削除に存在するかどうか判断が下される。テストベッド削除に存在する場合、デ ータは存在しないと考えられ、ステップ２５４において処理がアプリケーション へ戻る。存在しない場合には、ステップＲ０５において「ライブ」からペアレン トデータが検索され、ステップＲ０６においてテストペッドへ書き込みおよびロ ックされる。各チャイルドファイルは、適切な「ライブ」ファイルから検索され 、ステップＲ０７において適切なテストベッドファイルに書き込まれたペアレン トデータと関連するデータを有している。この処理が完了すると、ペアレントデ ータはステップＲ０８においてテストベッドでロック解除され、要求されたデー タはステップ２５０においてテストベッドから検索される。そして、処理はステ ップ２５４においてアプリケーションに戻る。 第７Ｂ図はテストベッドの方法２４０の第２のフローチャートを示している。 ステップ２４２において判断されているように、要求がデータを書き込むもので ある場合、ステップ２６２において、テストベッドのサマリフィールドに関連す る値がライブデータベースのサマリフィールド値から減算される。ステップ２６ ４において、書き込まれるデータはテストベッドデータベースに更新される。次 に、ステップＲ０９において、テストベッド削除のデータが除去される。ステッ プ２６６において、次に、処理はアプリケーションに戻る。 ステップ２４２において、入出力要求のタイプが「除去」であると判断される と、ステップＲ１０においてデータはテストベッド削除へ更新される。ステップ Ｒ１１において、テストベッドデータベースからデータが除去される。最後に、 ステップ２６６において、処理がアプリケーションに戻る。 図７Ａ図を再び参照すると、ステップ２５２から２５８が本発明 による集合体変数のライブデータとテストベッドの間で並行性を維持するよう指 向される。本発明のこの実施の形態において、この変数は、詳細なデータを含む 複数のレコードの合計を保持する量的（ｑｕａｎｔｉｔｙ）フィールドである、 「サマリフィールド」である。ロジスティックスに関連する例では、サマリフィ ールドは、インベントリにある（すなわち「オンハンド（Ｏｎ−Ｈａｎｄ）」で ある）任意のプロダクトの全体の量を記憶する「プロダクトマスタ」レコードで ある。「オンハンド」であるものの詳細は、プロダクトロットに関連するレコー ドに記憶され、あるプロダクトレコードに適用するロットは、何千あってもよい 。任意の時期においてオンハンドであるプロダクトの全体量を迅速に判断するた めに、データベースはプロダクトマスタレコードにおける全体のオンハンド量を 記憶するよう設計されている。プロダクトロットに関連する詳細なレコードが変 更するたびに、その変更に関連する相違がプロダクトマスタレコートのサマリフ ィールトに追加される。 テストベッドを動作する際、バランスのとれていないまたは並行性でないライ ブデータベースおよびテストベッドデータベースのサマリフィールドへとつなが ることができるライブデータベースにおいて詳細なレコードは変化することがで きる（異なる値を不正確に反映する）。この問題は、詳細なレコードがすべてテ ストベッドにコピーされない場合に生じることがある。しかしながら、かなり不 十分であり、また時間がかかることがわかっているサマリフィールドの統合およ び並行性を維持するように、何千もの詳細なレコードをコピーすることが必要に なることがある。 ライブとテストベッドのデータベースのサマリフィールドとの間 に並行していないという問題を表すため、テストベッドは、テストセッション中 に生じた詳細なレコードの全ての相違の合計をサマリフィールドにおいて記憶す る。テストベッドサマリフィールドのこの量に、ライブデータベースのサマリフ ィールドの値が加えられる。テストベッドは、テストセッション中に生じる変化 のみを記憶する。サマリフィールドを含むレコードがテストベッドに書き込まれ てもテストセッション中にサマリフィールドに変化が生じない場合、テストベッ ドにおけるサマリフィールド値は、対応するライブテータベースのサマリフィー ルドの値にかかわらずゼロになる。 １つまたはそれ以上のサマリフィールドを含むレコードの読み出しをテストセ ッションが要求する場合、こうしたサマリフィールドはライブデータベースから 検索される。ライブデータベースからのこうしたフィールド値は、書き込み要求 中に使用するようにメモリに記憶される。同じレコードがこうした要求によりテ ストベッドデータベースから検索され、テストベッドのサマリフィールドの値が ライブデータベースの対応するサマリフィールドに追加される。この計算によっ て、現行のメモリ値を置換するテストセッションの現在の値を生成する。アプリ ケーションに戻るサマリフィールドは、こうしてテストベッドにおけるサマリフ ィールドの合計、およびライブデータベースにおいて対応するサマリフィールド のそれぞれである。 テストセッションがサマリフィールドを含むレコードの書き込みを要求する場 合、その要求の時点で現在の値が読み出し要求中にメモリに記憶された（前は現 在の）ライブデータベース値から除算される。これを含むレコードの除算によっ てテストセッション中に生 じる差の値が生まれる。サマリフィールドを含むレコードをライブデータベース から検索し、はじめてテストベッドに更新する場合、サマリフィールドはゼロに セットされる。サマリフィールドへの全ての将来的な変更は、テストセッション で生じる変更のみを記憶する。 第７Ａ図に戻って参照すると、ステップ２５０が達成する上記で述べた各例に おいて、ステップ２５２から２５８に関連する処理が実行される。ステップ２５ ２においては、サマリフィールドが存在しているかどうかに関しての判断が行わ れる。もし存在していない場合、ステップ２６０において処理がアプリケーショ ンに戻る。サマリフィールドがステップ２５４において存在する場合、ライブデ ータベースから検索される。ライブサマリフィールド値はステップ２５６におい てメモリに記憶され、ライブサマリフィールド値はステップ２５８においてテス トベッドサマリフィールド値に加えられる。最後に、ステップ２６０において処 理がアプリケーションに戻る。 テストベッドがステップ２２２においてセットアップされる場合、第６図の登 録処理２００に戻り、モデル（またはバリアントモデル）はステップ２２４にお いてテストされる。ステップ２２４において、モデルがモデルテスト処理中にマ スタを受け渡さない場合、処理が繰り返され、デベロッパは例えばモデルデザイ ンツール２０８を用いてモデルを修正する必要があり、また（ステップ２１８か ら２２４へと）オブジェクトを再テストする必要がある。 ステップ２１８において、登録処理を現在終了したオブジェクトが方法または ツールであると判断されると（ステップ２２６）、ス テップ２２８において方法またはツールのパラメータ値がセットされる。パラメ ータがセットされると、方法またはツールがテストされる。（以下で述べる）Ｒ ＴＥＭ１０内部のサブルーチンを除くと、他のいずれかのコードのブロックを直 接呼び出すようにしてもよいようなコードのブロック（例えば方法またはツール ）はない。このルールにより、コードが作成されている間のランタイムにおいて も、各コードのブロックを独立してテストすることができる。 本発明の基本的な法則が破られるのは、登録処理においてであり、例示するこ とができない。登録処理中において探知またはフラグされる間違った方法のいく つかの例としては、プロテクトされた変数を修正するコードを含む方法や、別の 方法を呼び出す方法や、ＲＴＥＭ１０から制御を行う方法や、例えばデータベー ス、プレゼンテーション、および処理ドメインなどのドメインをクロスする方法 がある。 登録処理を実施する方法またはツールがテスト手続きに失敗した場合、アプリ ケーションのデベロッパが方法またはツールのソースコードを編集して、テスト の失敗につながることがある欠陥のいずれをも修正し、登録処理がそのステップ から繰り返されることができるステップ２１２に制御が戻る。 ステップ２２４（モデル用）またはステップ２３０（方法およびツール用）の いずれかでオブジェクトがテストをパスする場合、オブジェクトは、アプリケー ションの動作中にＲＴＥＭ１０にアクセス可能になる「パブリック」にすること ができる。オブジェクトをパブリックにするには、登録処理は、「どこで使用す るか」「どうやって使用するか」「いつ作成するか」「いつ削除するか」などの リンク情報を作成する。 第８図は本発明によるＲＴＥＭ１０の実施の形態の動作を記述するフローチャ ート３００を示す図である。ＲＴＥＭ１０は、ビシネスベーシック、Ｃ、Ｃ＋＋ などの第三世代プログラミング言語（「３ＧＬ」）、または他の適当な第三世代 言語で実現してもよい。 ＲＴＥＭ１０は、第６図で開始されるものと同様に、登録処理によって登録さ れるモデルのセットが指定するアプリケーションの動作を監督する。概観による と、ＲＴＥＭ１０は、方法、ツール、および他のモデルへの呼び出しを含む初期 動作を定義するアプリケーションの初期モデルをロードする。各モデルにリスト されるオブジェクトが読み出されると、そのオブジェクトに定義される条件がチ ェックされてそれらが適合するかどうかを判断し、適合する場合にオブジェクト が呼び出される。登録処理に関連して上記に述べられているように、登録済みの オブジェクトが別のオブジェクトを呼び出すことはできないとされると、処理さ れる現在のオブジェクトに関連する実行の完了時に、制御はＲＴＥＭ１０に必ず 戻る。各オブシェクト処理の間で、ＲＴＥＭ１０は特別な動作または外部条件を チェックし、条件を更新することができるため、アプリケーションを構成するモ デルは、発展すると、条件によってフレキシブルにアクセスすることが可能であ る。 フローチャート３００を参照すると、ステップ３０２において、第１のモデル がメモリにロードされる。第６Ａ図、第６Ｂ図、および第６Ｃ図で提供されるユ ーザインターフェースアプリケーションのメニューのモデルの例を参照すると、 モデルメニュ（ｍｏｄｅｌ＿ｍｅｎｕ）データはローカルメモリ（つまり第１図 におけるタス クメモリ９０）に、ステップ３０２で格納される。この処理は、（第３図の）Ｐ ＣＤＢポインタ９６を使用してモデルの読み出しを含んでもよい。これはさらに 、タスクメモリ９０のＶＴＡＢ９４にモデルのメモリブロックのプレコンパイル されたデータバンクポインタ９６をリンクすることを含む。 ステップ３１０において、ＲＴＥＭ１０は、ロードされたモデルと関連するバ リアントモデルがあるかどうかチェックする。バリアントモデル３１０があるか どうかのチェックに関連する処理は第９図において開始される。本来、ＲＴＥＭ １０は、チェック時に所定のデータ状態のモデルを現在適用するかどうかを確認 するため、ロードされたモデルに対して登録された全てのバリアントモデルの条 件をチェックし、バリアントモデルが現在適用している場合、現在メモリにある モデルデータで（ＰＣＤＢ９６にポインタを書き込むことで）ロードまたはマー ジされる。 第９図はこの処理のフローチャート４００を示す図である。ステップ３１０が ローチャート３００に達すると、ＲＴＥＭ１０はステップ４０２において、第８ 図のステップ３０２でロードされたモデルのバリアントモデルに関連する第１の （または、対話に応じて、次の）条件を検索する。条件はモデルのデータ値に基 づいている。例えば、 Condition 1:client$=「ACME」and product$=「BEACH-BALL」 Condition 2:product$=「NET」 テーブルは、各条件が存在する場合に呼び出されるバリアントモデルへの条件 に関連する。例えば、ｃｌｉｅｎｔ＄＝「ＡＣＭＥ」およびｐｒｏｄｕｃｔ＄＝ 「ＢＥＡＣＨ−ＢＡＬＬ」である場合に は、バリアントモデル「Ａ」およびバリアントモデル「Ｂ」が作動する。 バリアントモテル「Ｃ」は、ｐｒｏｄｕｃｔ＄＝「ＮＥＴ」である場合に作動 する。ＲＴＥＭ１０は、モデルのデータの現在値に対して全ての条件がチェック されるまで、例えば、条件１、次に条件２などにチェックされる「現在の条件」 をセットする。 ステップ４０４において検索された条件は、（第１図で示されるタスクメモリ ９０の動的変数テーブル９８に記憶される）現在のデータ値に対してチェックが 行われる。例えば、 if checking condition 1 and client$=「ACME」and product$=「BEACH-BALL」 then Models「A」and「B」are active； if client$ is not「ACME」or if product$ is not「BEACH-BALL」 then Models「A」and「B」are not active． ステップ４０４でチェックされる検索された条件が満たされるかまたは「パス 」すると（ステップ４０６）、検索された条件が満たされる時に呼び出されるす べてのバリアントモデルは、ステップ４１０において、ＲＴＥＭ１０に処理され るタスクメモリ９０において記憶されるアクティブなバリアントモデルのリスト に追加される。例えば、 active variant Models=「A」and「B」 ステップ４０４でチェックされる検索された条件がパスしないと、またはステ ップ４１０において現在の条件に対応する全てのバリアントモデルがリストに加 えられると、ＲＴＥＭ１０はステップ４ ０８において、より多くの条件が現在のモデルをチェックしなければならないか どうかをチェックする。チェックしなければならない場合、ＲＴＥＭ１０はステ ップ４０２に戻って、リストにおいて次の条件を検索する。チェックしなくてよ い場合、ステップ４１２においては、ステップ４１０においてリストに加えられ たバリアントモデルはすべて上記のロードの手続きごとにロードされる。フロー チャート４００の処理中に作成されるアクティブバリアントモデルのリストに存 在しない現在ロードされたバリアントモデルがいずれもアンロードされることに より、現在のパラダイムモデルのバリアントモデルがアクティブなバリアントモ デルのみを構成する。このバリアントモデルのロードおよびアンロードは、第１ ０図で示されるフローチャート５００により詳細に説明される。（フローチャー ト４００の手続き中に）アクティブバリアントモデルのリストが確立すると、ス テップ５０２において現在ロードされているバリアントモデルのリストと比較さ れる。この比較が行われると、どのバリアントモデルは作動（ロード）する必要 がなく、またどのバリアントモデルは休止（アンロード）する必要がないかがわ かる。 ステップ５０４において、アクティブバリアントモデルのリストにないロード されたバリアントモデルが現在あるかどうかのチェックが行われる。アクティブ バリアントモデルのリストにないこうした現在ロードされたバリアントモデルが ない場合、中断する必要はなく、以下に述べるステップ５１４に制御か受け渡さ れる。しかしながら、アクティブバリアントモデルのリストに１つまたはそれ以 上の複数の現在ロードされたバリアントモデルがない場合、ステップ５０６にお いて、中断する現在のバリアントモデルは、アクティ ブバリアントモデルのリストにない現在ロードされたバリアントモデルのリスト 日において次にセットされる。 ステップ５０８において、中断する現在のバリアントモデルのバリアントモデ ル情報は、制御変数のセットから取り除かれる。ＲＴＥＭ１０は、いくつかのこ うした制御変数を使用して、処理するオブシェクトおよび処理する適切なシーケ ンスを識別可能にする。制御変数はおもにオブジェクトのリストである。中断す る現在のバリアントモデルでリストされるオブジェクトを制御変数のリストのい ずれかで識別する場合、リストを修正してこうしたオブジェクトのこのような識 別を取り除く。例えば、オブジェクトＩＤが中断する現在のバリアントモデルに 対応する 「M020016TOR1＿ 0000000000400401_」(３２文字または他の適切なコード) がペアレントオブジェクトシーケンスリスト（すなわち制御変数） に存在する場合、このリストからは削除される。 次に、バリアントモデルの詳細なデータはすべて、ステップ５１０において、 ランタイムイベントマネージャ１０のローカルメモリ、すなわちタスクメモリ９ ０から取り除かれる。例えば、パラダイムモデルのバリアントモデルがパラダイ ムモデルにない方法を含む場合、この方法についての情報（例えばモジュール、 レポジトリ、方法名など）はバリアントモデルデータにある。そのバリアントモ デルが中断されるものである場合、方法についてのこの情報は、第３図に示すよ うなタスクメモリ９０から参照番号９６においてバリアントモデルＰＣＤＢポイ ンタのリンクを外すことでメモリから取り除かれる。 さらに多くのバリアントモデルを中断する必要があるかどうか、ステップ５１ ２においてチェックを行う。必要がある場合、ＲＴＥＭ１０は制御をステップ５ ０６に戻し、必要がない場合、またはステップ５０４において、中断するバリア ントモデルがないことを判断すると、現在ロードされたバリアントモデルのリス トにないアクティブなバリアントモデルがあるかどうかをステップ５１４におい てチェックする。テスト結果がポジティブである場合、ステップ５１６において 、ロードする現在のバリアントモデルを、ロードするバリアントモデルのリスト において次のバリアントモデルにセットする。 次に、現在のバリアントモデルがすでにロードされているかどうかについてス テップ５１８においてテストを行う。現在のバリアントモデルがすでにロードさ れている場合、何も行う必要はない。しかし、現在のバリアントモデルがまだロ ードされていない場合、ステップ５２２において現在の制御データでロードされ る。ＲＴＥＭ１０は、制御変数を使用して、処理するオブジェクトおよび処理す るシーケンスを識別する。バリアントモデルによって導入される新たなオブジェ クトはこうした制御変数でマージする必要がない。このマーシはステップ５２４ において実行される。ＲＴＥＭ１０がバリアントモデルによって導入された新し い方法を作動する時期を判断することができるように、新しい方法のオブジェク トＩＤが制御変数に加えられる。方法がプレ処理である場合、（例えば第６Ａ図 から第６Ｃ図の表記における｛ｐａｒｅｎｔ ｏｂｊｅｃｔ ＩＤ｝．ｐｒｅｐ ｒｏｃｅｓ＄）方法のペアレントであるオブジェクトのプレ処理のリストに加え られる。バリアントモデルに関連する新 たなオブシェクトが制御変数とマージされると、またはステップ５１８において 現在のバリアントモデルが既にロードされていると判断される場合、ＲＴＥＭ１ ０はさらなるバリアントモデルを処理する必要があるかどうかテストする。処理 する必要がある場合、ＲＴＥＭ１０はステップ５１６に戻って次のバリアントモ デルを検索する。処理する必要がない場合、またはアクティブなバリアントモデ ルがないとステップ５１４で判断された場合、５２６においてロジックが完了し 、ロジック的分岐がもともと生じた場所によって、第８図のステップ３１０か（ 以下に示す）ステップ３２２のいずれかに制御が戻る。 第８図の最上段のＲＴＥＭ１０のループのステップ３１０においてバリアント モデルのチェックに制御が戻ると考えると、現在のオブジェクトを識別する変数 は、そのモデルにおいて第１のオブジェクトへステップ３１２においてセットさ れる。上記のように、オブジェクトは別のモデル、方法、ツールまたは別のオブ ジェクトであってもよい。ＲＴＥＭ１０はモデルのペアレントオブジェクトのリ ストから第１のペアレントオブジェクトを検索する。第６Ａ図から第６Ｃ図から 、モデルメニュ（ｍｏｄｅｌ＿ｍｅｎｕ）を使用すると、 first_object=lvsequence$(1,32) - First Parent Object ＲＴＥＭ１０はオブジェクトにおいてプレ処理のチェックも行う。 例えば、 pre_processes={first_object}.preprocs$ - List of Pre-Processes for First Parent Object プレ処理が存在する場合には第１のオブジェクトをプレ処理リストの第１のオブ ジェクトに設定し、存在しない場合には第１のペアレントオブジェクトのままで ある。例えば、 first_object=pre_processes(1,32) - First Pre-Process Object current_object=first_object - Setting the current object to the first object ステップ３１４において、現在のオブジェクトに対応する条件が現在のデータ に対してチェックされ、オブジェクトを実行するかどうかを判断する。現在のオ ブジェクトに関連する条件がない場合、ＲＴＥＭ１０は、満たされたまたは「パ スされた」条件があると考える。例えば、第６Ａ図から第６Ｃ図のメニュモデル （ｍｅｎｕ＿ｍｏｄｅｌ）例を使用すると、 evaluate {current_object}.condition$ - Check Condition of Object 現在のオブシェクトの条件がステップ３１４において満たされると、ステップ ３１６において、ＲＴＥＭ１０は現在のオブジェクトにより要求されるユーザイ ンターフェース関連の情報をロードおよび表示する。このステップは、オブジェ クト指向プログラミングの分野において理解される用語のように、「ゴットフォ ーカス（Ｇｏｔ Ｆｏｃｕｓ）」処理に対応する。例えば、（シンボルカレント オブジェクト（ｃｕｒｒｅｎｔ＿ｏｂｊｅｃｔ）で表示してもよい）現在のオブ ジェクトが、ホタンまたは入力フィールドなどユーザ入力オブジェクトである場 合、ＲＴＥＭ１０は現在表示される視覚 的な形態を、現在のオブジェクトが表示される視覚的な形態と比較する。これら が異なる場合、新しい視覚的形態はロードおよび表示される。 現在のオブジェクトは、次に、ステップ３１８において呼び出される。ＲＴＥ Ｍ１０は、オブジェクトのタイプをチェックし、適切なロジックを実行して呼び 出しを行うか、またはそうでなければオブシェクトを利用する。例えば、 ｛ｃｕｒｒｅｎｔ＿ｏｂｊｅｃｔ｝．ｏｂｊｅｃｔｔｙｐｅ： １＝方法 パラメータをセットアップし、方法を呼び出す ２＝ツール利用 パラメータをセットアップし、ツール利用を呼び出す ３＝モデル パラメータをセットアップし、モデルを呼び出す このように、現在のオブジェクトがモデルである場合、３１８ａにおいてモデ ルをロードする。現在のオブジェクトが方法である場合、３１８ｂにおいて方法 を呼び出す。現在のオブジェクトがツールである場合、３１８ｃにおいてツール を呼び出す。 方法またはツールである場合に、オブシェクトが実行を終了すると、ステップ ３２０において適宜ユーザインターフェースを更新する。ＲＴＥＭ１０は、現在 の形態で表示されているデータのいずれかが変化したかどうかをチェックする。 現在の形態で表示される変化したデータが表示される。 オブジェクトの実行中に関連するデータの状態が変化することがあり、また変 化したデータは、こうした変数の状態からみて変数が「適用する」変化したデー タに影譬することがあるとすると、ＲＴＥＭ１０は、３２２においてフローチャ ート４００の処理によって バリアントモデルを再度チェックする。データのいずれかが変化する場合、第９ 図および第１０図のフローチャート４００および５００にそれぞれ関連して述べ られているように、現在ロードされている変数モデルに対して、新しく作動した バリアントモデルをアンロードおよびロードしなければならないかどうかを判断 する詳細な分析を実行する。 次に、ＲＴＥＭ１０は特別な動作を３２４にてチェックする。例えば、ツール 利用が呼び出されてデータベースから情報を読み出し、その情報が存在しない場 合、結果コードはＲＴＥＭ１０に戻る。特別な動作はこの結果コードに添付され 、この情報がデータベースにないということをオペレータに知らせるメッセージ のオブジェクトＩＤである、次の現在のオブジェクトをセットする。例えば、 {current_object}.result_code_000010=「jump」 {current_object}.result_code_000010.resultobj$=ObjectID of the message {current_object}.result_code_000010.descriptn$=「if record not on file，d isplay message」 この動作は、変数｛ｃｕｒｒｅｎｔ＿ｏｂｊｅｃｔ｝： ｒｅｓｕｌｔ ｃｏｄｅ ００００１０．ｒｅｓｕｌｔｏｂｊ＄で指定されるオ ブジェクトＩＤに対して現在のオブジェクトをセットする。 このイベントでは、次にステップ３２６をスキップしてステップ３１４へ制御 を移す。 現在のオブジェクトの条件を３１４でチェックすると、条件が満たされていな い場合、またはステップ３２４において特別な動作が 現在のオブジェクトをセットしていない場合、ステップ３２６のロシックを実行 する。ＲＴＥＭ１０がペアレントオブシェクトへのプレ処理リストを現在処理し ている場合、現在のオブジェクトをプレ処理リストの次のオブシェクトにセット する。それ以上プレ処理オブジェクトがない場合、現在のオブジェクトはペアレ ントオブジェクトにセットされる。処理が完了していない手段を処理するオブジ ェクトがある場合、制御はステップ３１４に戻る。 ＲＴＥＭ１０がペアレントオブジェクトを現在処理している場合、オブジェク ト（例えば｛ｃｕｒｒｅｎｔ＿ｏｂｊｅｃｔ｝．ｐｏｓｔｐｒｏｃｓ＄）に対す るポスト処理のチェックを行う。現在のオブジェクトに対するポスト処理がない 場合、ＲＴＥＭ１０は現在のオブジェクトをペアレントリストの次のオブジェク ト（ｌｖｓｅｑｕｅｎｃｅ＄）をセットする。オブジェクトをチェックして、プ レ処理がオブシェクトと関連するかどうか判断する。関連する場合、現在のオブ ジェクトはプレ処理リストの第１のオブジェクトを（例えば、ｃｕｒｒｅｎｔ＿ ｏｂｊｅｃｔ＝ｐｒｅｐｒｏｃ＄（１、３２））にセットする。関連しない場合 、現在のオブジェクトは次のペアレントオブジェクトのままである。ＲＴＥＭ１ ０が現在ペアレントオブジェクトを処理している場合、およびペアレントオブジ ェクトがそれと関連するポスト処理を有している場合、現在のオブジェクトは、 これらのポスト処理の第１のものにセットされる。ＲＴＥＭ１０が現在ポスト処 理を処理し、実行するポスト処理がこれ以上ない場合、現在のオブジェクトを、 （上記で説明したように）プレ処理をチェックする次のペアレントオブジェクト にセットする。任意の時間において、ポスト処理がそれ（第８図の参照番号３２ ４）に添付される特別な動作を有しないポジティブな結果コードを戻す場合、現 在のオブジェクトは現在のオブジェクトのペアレントオブジェクトにセットされ る。次に、このオブジェクトはプレ処理をチェックする。１つでも存在すると、 現在のオブジェクトは第１のプレ処理にセットされる。また、現在のオブジェク トがあるということは、ステップ３２８において、処理を実行するかどうかのテ ストをネガティブに評価するということであり、制御はステップ３１４へ戻る。 ３２６において、これ以上実行するオブジェクトが存在しない場合、またはス テップ３２４において、特別な動作がＲＴＥＭ１０を終了させる命令につながる 場合、ステップ３２８における評価はポジティブに評価され、ＲＴＥＭ１０はス テップ３３０において終了する。 モデルのランタイム情報を伴う付随ファイルは、全てのバリアントモデルを作 動させる全ての条件のテーブルを記憶する。パラダイムモデルに対して登録され たすべてのバリアントモデルがこのテーブルを更新する。第６図および第６Ａ図 に関連して述べられる種類のモデルデザインツールをオペレータが適用する場合 、登録処理中にバリアントモデルがパラダイムモデルに対して登録される。 この制御テーブルのフォーマットは以下の通りである。 LVRTEM.VAR_TABLE$ これはバリエーション毎の条件評価のリストである LVRTEM.VARIATIONS$ これはｌｖｒｔｅｍ．ｖａｒ＿ｔａｂｌｅ＄に対応するバ リエーション名のリストである 例えば、任意のパラダイムモデル（図示せず）の３つのバリアン トモデルはそれぞれ次の条件下で適用する。 バリアントモデル「variant1」:COUNTRY$=「US」 バリアントモテル「variant2」:COUNTRY$=「CA」 バリアントモデル「varjant3」:CLIENT$=「ACME」 バリアントモデルを作動するのに使用される各条件の値は、変数ｌｖｒｔｅｍ ．ｖａｒ＿ｔａｂｌｅに記憶される。全てのバリエーションで使用される各条件 のプレイスホルダがある。提供される例において３つの条件があるため、バリエ ーションテーブルにおいて３つのプレイスホルダがある。 アクティブであるｖａｒｉａｎｔ１では、ｖａｒｉａｎｔ１を作動させるのに 使用しないため（「０」で表される）、ＣＯＵＮＴＲＹ＄＝「ＵＳ」が真（「１ 」で表される）でなければならず、ＣＯＵＮＴＲＹ＄＝「ＣＡ」が偽（「０」で 表される）でなければならず、また、ＣＬＩＥＮＴ＄＝「ＡＣＭＥ」は真または 偽のいずれであってもよい。 ｖａｒｉａｎｔ１のバリエーションテーブルは、 ｌｖｒｔｅｍ．ｖａｒ＿ｔａｂｌｅ＄＝「１００」 のようにみえる。 アクティブであるｖａｒｉａｎｔ２では、ｖａｒｉａｎｔ２を作動させるのに 使用しないため（「０」で表される）、ＣＯＵＮＴＲＹ＄＝「ＵＳ」が偽でなけ ればならず（「０」で表される）、ＣＯＵＮＴＲＹ＄＝「ＣＡ」が真でなければ ならず（「１」で表される）、またＣＬＩＥＮＴ＄＝「ＡＣＭＥ」は真または偽 のいずれであってもよい。 Ｖａｒｉａｎｔ２のバリエーションテーブルは、 ｌｖｒｔｅｍ．ｖａｒ ｔａｂｌｅｓ＝「０１０」 のようにみえる。 アクテイブなｖａｒｉａｎｔ３では、ｖａｒｉａｎｔ３を作動させるのに使用 しないため（「０」で表される）ＣＯＵＮＴＲＹ＄＝「ＵＳ」は真または偽のい ずれであってもよく、ｖａｒｉａｎｔ３を作動させるのに使用しないため（「０ 」で表される）ＣＯＵＮＴＲＹ＄＝「ＣＡ」は真または偽のいずれであってもよ く、また、ＣＬＩＥＮＴ＄＝「ＡＣＭＥ」は真（「１」で表される）でなければ ならない。 Ｖａｒｉａｎｔ３のバリエーションテーブルは、 ｌｖｒｔｅｍ．ｖａｒ＿ｔａｂｌｅ＄＝「００１」 のようにみえる。 バリエーションが適用するものを知るのに使用されるバリエーションテーブル は、全ての条件テーブルを一緒に加えることで構築される。バリエーションテー ブルは、 lvrtem.var_table$=「100」+「010」+「001」 または lvrtem.var_table$=「100010001」 のようにみえる。 バリアントモデルのリストは可変のｌｖｒｔｅｍ．ｖａｒｉａｔｉｏｎｓに記 憶される。バリエーションのオーダは条件テーブルのオーダーと同じである。例 えば、 lvrtem.variations$=「variant1 variant2 variant3」 どんなバリエーションがアクティブであるかを確かめるためにチェックする条 件は、可変のｌｖｒｔｅｍ．ｖａｒ＿ｃｈｅｃｋに記 憶される。条件のオーダは条件テーブルの値と同じオーダである。 例えば、 lvrtem.var_check$=「(COUNTRY$=「US」)+(COUNTRY$=「CA」)+」(CLIENT$=「ACME」) ランタイムで変数をセットして、バリエーションが適用するものを知るために バリエーションテーブルに対する比較する。変数は１ｖｒｔｅｍ．ｖａｒ＿ｃｈ ｅｃｋとメモリの変数の現在の状態とを使用してセットされる。次のような例を 提供する。 ランタイムでＣＯＵＮＴＲＹ＄＝「ＵＳ」およびＣＬＩＥＮＴ＄＝「ＡＣＭＥ 」とすると、以下のようなランタイムテーブルが作成される。 lvrtem.varcurrent$=str(lvrtem.var_check$) これにより、次のようにバリエーションテーブルに対してメモリの変数を評価 する。 （ＣＯＵＮＴＲＹ＄＝「ＵＳ」） 真 「１」で表される （ＣＯＵＮＴＲＹ＄＝「ＣＡ」） 偽 「０」で表される （ＣＬＩＥＮＴ＄＝「ＡＣＭＥ」） 真 「１」で表される これにより、以下のランタイムテーブルが与えられる。 ｌｖｒｔｅｍ．ｖａｒｃｕｒｒｅｎｔ＄＝「１０１」 このランタイムテーブルは、ｌｖｒｔｅｍ．ｖａｒ＿ｔａｂｌｅ＄に記憶され るこのモデルのテーブルのそれぞれに対して比較される。 現在のタイムテーブルの長さは３文宇であることが公知であり、そのためバリ エーションテーブル３三つの部分においてチェックされる。 比較すると、 ＡＮＤ（ｌｖｒｔｅｍ．ｖａｒ＿ｔａｂｌｅ＄、ｌｖｒｔｅｍ．ｖａｒｃｕｒ ｒｅｎｔ＄（１，３）は真であり、従って、ｌｖｒｔｅｍ．ｖａｒｉａｔｉｏｎ ｓ（ｖａｒｉａｎｔ１）の第１のバリエーションはアクティブではない。 比較すると、 ＡＮＤ（ｌｖｒｔｅｍ．ｖａｒ＿ｔａｂｌｅ＄、ｌｖｒｔｅｍ．ｖａｒｃｕｒ ｒｅｎｔ＄（４，３）は偽であり、従ってｌｖｒｔｅｍ．ｖａｒｉａｔｉｏｎｓ （ｖａｒｉａｎｔ２）の第２のバリエーションはアクティブではない。 比較すると、 ＡＮＤ（ｌｖｒｔｅｍ．ｖａｒ＿ｔａｂｌｅ＄、ｌｖｒｔｅｍ．ｖａｒｃｕｒ ｒｅｎｔ＄（７，３）は真であり、従ってｌｖｒｔｅｍ．ｖａｒｉａｔｉｏｎｓ （ｖａｒｉａｎｔ３）の第３のバリエーションはアクティブである。 この例において、バリエーションテーブルのｌｖｒｔｅｍ．ｖａｒ＿ｔａｂｌ ｅの「１」がランタイムの現在のバリエーションテーブルのｌｖｒｔｅｍ．ｖａ ｒｃｕｒｒｅｎｔの対応する位置の「１」と一致する場合、バリエーションはア クティブだと考えられる。 本文書で用いられる用語の「エラスティックデータベース」は、動的な拡張性 というプロパティを有するデータベースのクラスを言及することを意図している 。従来のファイルおよびレコードの用語は、関連するデータベースの用語という よりも、以下の説明において使用される。以下に述べるエラスティックデータベ ースの実施の形態は、制限なくこうしたデータベースを提供する１つの方法の図 示例である。例では、エラスティックデ−タベースのベースレコードを拡張して 追加のフィールドを含み、またベースレコードのそれぞれは拡張フィールドの異 なるセットを有することができる。 エラスティックデータベースは、従来のデータベースファイルの形態であるベ ースファイルを含む。従来のデータベースにおいて、ベースファイルのレコード はすべて同じフィールドナンバを有し、各フィールドはレコードのセット全体に わたって同じ特徴を有している。エラスティックデータベースにおいて、これは ベースレコードと呼ばれる。エラスティックデータベースのベースファイルおよ びベースレコードの図示例を第１１図に示す。 エラスティックデータベースの第１の利点として、追加のフィールドでベース レコードの拡張を可能にすることができ、それによって各ベースレコードが異な る拡張フィールドのセットを有することができるという能力がある。こうした拡 張フィールドは、メンテナンスおよび利用をより容易にするために、「バリエー ションセット」（以下に述べる）でグループ化される。ベースレコードはいずれ も、それに適用するゼロまたはそれ以上のバリエーションセットを有してもよい 。任意のベースレコードに適用するバリエーションセットのリストは、異なる条 件においてベースレコードのデータとして動的に変化してもよい。第１２図は２ つのバリエーションセットの定義の例を図示する。ベースファイルと、ベースフ ァイルに適用するすべてのバリエーションセットとのコレクションを「ロジック ファイル」と呼ぶ。 データ辞書１２（第１図）でベースファイルを定義すると、バリエーションセ ットをロジックファイルの定義に追加してもよい。こ れは、データ辞書のメンテナンスを通じて行われる。第１３Ａ図、第１３Ｂ図、 および第１３Ｃ図は新しいバリエーションセットを定義することに関わるステッ プを示している。各バリエーションセットにはデータ辞書１２により識別子が割 り当てられる。以下で述べる第１２図で図示されるバリエーションセットでは、 識別子はそれぞれ「０００１」および「０００２」である。各バリエーションセ ットは、こうしたフィールドごとの属性に応じてバリエーションセットが有する フィールドのリストを含んでいる。さらに、各バリエーションセットはそれに関 連する条件を有してもよい。この条件はバリエーションセットが適用するベース レコードを判断する。バリエーションセットがそれに関連する条件を有しない場 合、こうしたバリエーションセットは全てのベースレコードに適用する。 各条件はベースレコードからフィールドのリストを開始し、これらのそれぞれ の値は適用するバリエーションセットを含む必要がある。例えば、ベースレコー ドが「クライアント」と呼ばれるフィールドを含む場合、バリエーションセット は、フィールド「クライアント」が値「ＢＥＮＪＡＭ」を含む場合にのみバリエ ーションセットが適用することを示す条件を有してもよい。 第１１図および第１２図はベースファイルおよびバリエーションセットの例を 提供する。第１１図では、ベースファイルは、クライアント名およびアドレスを 記憶し、第３図のデータベーステーブル／ファイル１２６に対応する、データソ ーステーブル名「ｓａｍ＿ｄｂｃｌｉｅｎｔ」への参照によってアクセス可能な ファイルであるロジックファイルの「サムクライアント（ｓａｍ＿ｃｌｉｅｎｔ ）」に対応する。ベースファイルのベースレコードは５つのフィー ルド、すなわちそれぞれ独自の説明、タイプおよびサイズを有する、クライアン ト、名前、国、通りおよび町を含む。第１２図は、第１１図で示されるロジック ファイル「サムクライアント」に対応し、添付されるバリエーションセットの２ つの例を示している。この第１の例として、「カナダ情報」という記述を含むバ リエーションセット０００１である。このバリエーションセットのアプリケーシ ョンの条件は、ベースレコードフィールド名「ｃｏｕｎｔｒｙ」はカナダを示す 値「ＣＡ」を有する。この条件において、ベースレコードは、ベースレコードに 対して第１１図でセットされる５つのフィールドを含むだけでなく、さらに２つ のフィールド、すなわち（６桁の郵便番号でいう）「ｐｏｓｔａｌ＿ｃｄ」と（ ２文字の地方コードでいう）「ｐｒｏｖｉｎｃｅ」をも含んでいる。つまり、こ のバリエーションセットは、この条件と適合する全てのベースレコードに適用し 、そのバリエーションセットに関連するバリエーションセットのレコードを追加 する。第１２図におけるバリエーションセットの第２の例はナンバ０００２とし て識別され、「米国情報」の記述を含む。このバリエーションセットのアプリケ ーションの条件とは、ベースレコードフィールド名の「ｃｏｕｎｔｒｙ」がベー スレコードファイル値の「ＵＳ」を有するということである。この場合、ベース レコードが拡張されて２つの新しいフィールド、つまり（米国のＺＩＰコードで いわれる）「ｚｉｐ＿ｃｏｄｅ」および（２文字の米国州コードまたは略名でい われる）州コードを含む。この例は、拡張して異なるデータ条件において新しい フィールドを作成するエラスティックデータベースの能力を示すものである。 各バリエーションセットのデータは、ベースファイルへの付随フ ァイルに記憶される。こうした付随ファイルは、データベースアクセスコントロ ーラ２４、３０（第１図）によってメンテナンス（および必要ならば作成）され る。各付随ファイルの第１のキーは、ベースファイルの第１のキーと一致してお り、いかなるベースレコードからもそのベースレコードに適用する各バリエーシ ョンセットのレコードへの１対１の関係が存在する。 ＤＢＡＣ２４、３０は、バリエーションセットランタイムマップ（ＶＲＴＭ） と呼ばれる小さなテーブルを使用して、ランタイムで適用するバリエーションセ ットを判断する。ＤＢＡＣ２４、３０、ランタイムバリエーションテーブルは、 第５図の説明と関連して上記で参照されるＲＴＥＭ１０のモデルバリエーション ランタイムテーブルと同じ構造である。 ３つのバリエーションをロジックファイルに適用する場合、例のバリエーショ ンセットランタイムマップは以下の通りである。 この例では、全ての評価コードは、１桁のみが１であるバイナリ形式である。 ランタイム表現テーブルは以下の通りである。 (COUNTRY$=「US」)+(COUNTRY$=「CA」)+(CLIENT$=「ACME」) 例として、次のデータがベースレコード後のメモリに常駐するとする。 ＣＬＩＥＮＴ＝「ＡＣＭＥ」 ＣＯＵＮＴＲＹ＝「ＵＳ」 評価コードテーブルを使用して任意の現行のデータに評価コードを取得し、ま たそうして取得した評価コードをランタイム表現テーブルへ挿入すると、 (COUNTRY$=「US」)+(COUNTRY$=「CA」)+(CLIENT$=「ACME」) ランタイム評価コードが生成される。「１０１」である。実際のバイナリの演算 動作を示すと、 position 1:COUNTRY$+「US」is TRUE represented as「1」 position 2:COUNTRY$+「CA」is FALSE represented as「0」 gives the result:「01」 表現テーブルの用語が適当でない場合（例えば、カナダ（ＣＡ）でない国にい る場合）、評価コードは０など、ゼロである。ＣＯＵＮＴＲＹ＝「ＣＡ」の評価 が第２の条件であるため、この条件の評価はバイナリ出力の第２の位置、１０１ に記憶される。 結果として得られたランタイム評価コードを、評価コード間の対応を表すテー ブルと比較する。バリエーションはアクティブな任意のコードである。アクティ ブなバリエーションとは、ランタイム評価テーブルと同じ位置に「１」を有する ものである。以下、こうし たテーブルの例を示す。 各ロジックファイルに対応するこのような１つのテーブルがある。バリエーシ ョンセットを、アクティブまたは非アクティブの１つの状態の１つにしてもよい 。新たに作成されたバリエーションセットは、明らかにアクティブになるまでは 非アクティブである。バリエーションセットがアクティブになると、バリエーシ ョンセットの情報がＶＲＴＭに加えられ、それによってＤＢＡＣ２４、３０はバ リエーションセットを認識し、適宜それを利用する。バリエーションセットを非 アクティブにすると、バリエーションセットの情報はＶＲＴＭから除かれるため 、ＤＢＡＣ２４、３０はバリエーションセットについて認識できなくなって関連 がなくなる。 次の情報はＶＲＴＭに記憶される。 １）コンディションフィールドリスト（ＣＦＬ） 全てのバリエーションセットの条件に関連する全てのフィールドのリスト。こ のリストは、バリエーションセットの条件に関連する全てのフィールドの現在値 を含むストリングを迅速に生成するのに使用される。生成されたストリングはコ ンディション値ストリング （ＣＶＳ）と呼ばれる。 ２）コンディショングループリスト（ＣＧＬ） 考えられるデータ値またはパターンを表すストリングのグループ。ランタイム でＣＶＳは順に各パターンと比較される。ＣＶＳがパターンと一致した場合、Ｃ ＧＬのパターンの位置をバリエーショングループリスト（以下参照）へのインデ ックスとして使用する。 ３）バリエーショングループリスト（ＶＧＬ） バリエーションセットナンバのグループのリスト。ＣＶＳが一致するＣＧＬの インデックスでこのリストを参照すると、現在メモリにあるベースレコードに適 用するバリエーションセットのリストが与えられる。 ＶＲＴＭは、その他の内部ハウスキーピングおよび状態の情報を含むこともでき る。 ＤＢＡＣ２４、３０がロジックファイルの機能を実行することができるように なる前に、データ辞書１２へのアクセスを得なければならない。ＤＢＡＣ２４、 ３０は、データ辞書１２からの情報を利用して、ロシックファイルとその物理的 なデータソースとを発見する。ＤＢＡＣ２４、３０が呼び出されてロジックファ イルの要求を満たす場合、そのデータ辞書がまだ開いていなければ、ＤＢＡＣ２ ４、３０はロジックファイルのモジュールのデータ辞書１２を開く。ベースデー タ辞書１２を開くと、ＤＢＡＣ２４、３０は、バリエーションレジストリとバリ エーションセットランタイムマップとをチェックする。上記のデータ辞書を開く 処理は、第１５図に示される。 エラスティックデータベースからレコードを読み出す処理は以下 のように進行する。すなわち、ランタイムでＤＢＡＣ２４、３０がベースファイ ルからベースレコードを読み出す。一旦これが実行されると、適用するバリエー ションセットを判断するため、バリエーションセットにおいてランタイムマップ を調べる。第１６Ａ図および第１６Ｂ図はＤＢＡＣ２４、３０がこのタスクのた めに使用するステップを示している。適用するバリエーションセットがある場合 、ＤＢＡＣ２４、３０は、次に、適切な付随ファイルから各バリエーションセッ トのデータを読み出す。レコードが適当な付随ファイルにおいて発見されない場 合、バリエーションセットのフィールドはヌル（ｎｕｌｌ）にセットされる。こ れは、バリエーションセットが追加される前にすでに存在するベースレコードの 場合と同じである。 ベースレコードに適用するバリエーションセットは、ベースレコードのデータ が変化すると動的に変化してもよいため、ＤＢＡＣ２４、３０は、ベースレコー ドとバリエーションセットのデータだけでなく、ベースレコードのフィールドの リストと適用されるバリエーションセットのいずれをもアプリケーションに戻す 。このことにより、ロジックレコードに存在するフィールドをアプリケーション が判断し、必要に応じて、オペレータへ情報を提示することができる。 エラスティックデータベースへのレコードの書き込み処理は以下の通りである 。つまり、ランタイムで、ＤＢＡＣ２４、３０は第１６Ａ図および第１６Ｂ図に よって、適用するバリエーションセットを確認するためにバリエーションセット ランタイムマップを調べる。ＤＢＡＣ２４、３０は、次に、適当な付随ファイル にバリエーシ ョンセットのデータを書き込み、そしてベースファイルにベースレコードデータ を書き込む。レコードが読み出させると適用されるいくつかのバリエーションセ ットが、レコードが再び書き込まれる際に適用できなくなった場合、ＤＢＡＣ２ ４、３０は適当な付随ファイルから期限切れ（ｏｕｔ ｏｆ ｄａｔｅ）のバリ エーションセットデータを除く。 エラスティックデータベースのレコードは以下の処理により除かれてもよい。 つまり、ランタイムで、ＤＢＡＣ２４、３０が取り除くレコードを読み出してロ ックし、第１６Ａ図および第１６Ｂ図によって、ある場合には、ベースレコード に適用するバリエーションセットを判断する。 ベースファイルがデータ辞書１２に定義されると、バリエーションセットはロ シックファイル定義に加えられてもよい。これは、データ辞書１２のメンテナン スによって行われる。各バリエーションセットはデータ辞書１２により識別子を 割り当てられる。各バリエーションセット定義は、各フィールドの属性によって バリエーションセットが含むフィールドのリストを含んでよい。 本発明の実施の形態において、第１３Ａ図を参照すると、バリエーションセッ トはステップ５６２で開始する手続き５６０によって定義されてもよい。まず、 ロジックファイルがステップ５６４において指定される。次に、バリエーション セットの記述がステップ５６６においてコメントと共にステップ５６８において 入力される。第１３Ｂ図を参照すると、ステップ５７０においてテストが行われ 、条件をバリエーションセットに指定しなければならないかどうかを判断する。 指定しなければならない場合、その条件をチェックす るベースレコードからのフィールドをステップ５７２において入力する。また、 ステップ５７４において、この条件が満たされるフィールドになければならない 値および適用するバリエーションセットが入力される。ステップ５７４において 、さらに条件フィールドが存在しているかどうかのチェックか行われる。存在し ている場合、処理がステップ５７２に戻る。存在していない場合、またはステッ プ５７０において条件を指定しなくてよい場合、処理は第１３Ｃ図のステップ５ ７８に進む。ステップ５７８において、フィールド情報はこのバリエーションセ ットに含まれる次のフィールドに入力される。ステップ５８０において、こうし たフィールドがさらに含まれているかどうかのチェックが行われる。さらに含ま れている場合には処理はステップ５７８に戻る。含まれていない場合には、バリ エーションセットはステップ５８２でセーブされ、手続き５６０はステップ５８ ４において終了する。 ＤＢＡＣ２４、３０は、ロジックファイルの機能を実行可能にする前にデータ 辞書１２へのアクセスを得なければならない。ＤＢＡＣ２４、３０はデータ辞書 １２の情報を使用してロジックファイルとその物理的なデータソースを発見する 。ＤＢＡＣ２４、３０が呼び出されてロジックファイルの要求を満たす場合、そ のデータ辞書がまだ開いていなければ、ＤＢＡＣ２４、３０はロジックファイル のモジュールでデータ辞書を開く。データ辞書を開くと、ＤＢＡＣ１２は、第１ ４図に示されるように、バリエーションレジストリとバリエーションセットラン タイムマップとをチェックする。 第１４図で示される手続き６００を参照すると、６０２で開始後に、バリエー ションレジストリファイルはステップ６０４において 開かれる。次に、こうしたファイルが存在するかどうかをステップ６０６におい てチェックする。存在する場合、手続き６００はステップ６０８においてバリエ ーションランタイムマップファイルを開く。欠に、ステップ６１０１こおいて、 バリエーションランタイムマップファイルが存在するかどうかをチェックする。 存在する場合、ステップ６１２においてフラグがセットされ、このモジュールに アクティブなバリエーションが存在することを示す。ステップ６０６またはステ ップ６１０のいずれかでテストが失敗すると、手続き６００はステップ６１４で 終了する。 ロジックファイルをアクセスして読み出しまたは書き込みする前に、まずそれ を開かなければならない。ロジックファイルを開くと、ＤＢＡＣ２４、３０は、 第１５図に示されるように、メモリに対してそのロジックファイルのバリエーシ ョンセットランタイムマップを直ちにロードする。次に、その図を参照すると、 ファイルは、ステップ６２２で開始される手続き６２０によって開かれてもよい 。ステップ６２４において、ロジックファイルにアクティブなバリエーションが 存在しているかどうかか判断される。存在している場合、このロジックファイル に関連するバリエーションセットランタイムマップのレコードはステップ６２６ によって読み出される。ステップ６２８で判断されるように、レコードを発見し た場合、ステップ６３０において、このファイルのバリエーションセットランタ イムマップがメモリに記憶される。ステップ６２８においてレコードが発見され ない場合、またはステップ６２４においてこロジックファイルにいかなるアクテ ィブなバリエーションも存在しないことがわかった場合、ステップ６３２におい て処理が停止する。 ランクイムで、ＤＢＡＣ２４、３０がベースファイルからベースレコードを読 み出す。一旦読み出されると、バリエーションセットランタイムマップを調べて 、適用するバリエーションセットを判断する。以下に述べる第１６Ａ図および第 １６Ｂ図は、ＤＢＡＣ２４、３０が使用してこのタスクを実行してもよいステッ プの例を示している。 バリエーションセットが適用する場合、ＤＢＡＣ２４、３０は適切な付随ファ イルからこのようなバリエーションセットそれぞれのデータを読み出す。レコー ドが適切な付随ファイルで発見されない場合、バリエーションセットのフィール ドはヌルにセットされる。これはバリエーションセットが追加される前にすでに 存在するベースレコードの場合と当てはまる。 ベースレコードに適用するバリエーションセットは、ベースレコードのデータ が変化すると動的に変化してもよいため、ＤＢＡＣ２４、３０は、ベースレコー ドとバリエーションセットのデータだけでなく、ベースレコードのフィールドの リストと適用されるバリエーションセットのいずれもをアプリケーションに戻す 。このことにより、ロジックレコードに存在するフィールドをアプリケーション が判断し、必要に応じて、オペレータへ情報を提示することができる。 ランタイムで、ＤＢＡＣ２４、３０は、バリエーションセットランタイムマッ プを調べて適用するバリエーションセットを確認する。こうした処理の例は、以 下に述べる第１６Ａ図および第１６Ｂ図に提供されている。次に、バリエーショ ンセットデータが適当な付随ファイルに書き込まれてベースレコードテータがベ ースファイル に書き込まれる。 レコードが読み出されると、適用されるいくつかのバリエーションセットが、 レコードが再び書き込まれる時に適用できなくなった場合、ＤＢＡＣ２４、３０ は適当な付随ファイルから期限切れのバリエーションセットデータを取り除く。 ランタイムで、ＤＢＡＣ２４、３０が取り除くレコードを読み出してロックし 、第１６Ａ図および第１６Ｂ図の例で図示されるように、もしある場合には、ベ ースレコードに適用するバリエーションセットを判断する。バリエーションセッ トデータが取り除かれると、ベースレコードも取り除かれる。 第１６Ａ図を参照すると、上記の手続き６４０の例が図示される０ステップ６ ４２で開始した後、手続き６４０は、ステップ６４４で適用するバリエーション のリストをクリアする。次に、ステップ６４６においてメモリから現在のファイ ルのバリエーションセットランタイムマップを検索する。ステップ６４８におい て現在のファイルのバリエーションセットランタイムマップが発見されると、ス テップ６５０においてベースレコードにＣＶＳ（現在のバリエーションセット） が生成される。ＣＶＳは、バリエーションが適用することを知るために使用され る条件の現在のランタイムビットマップ評価である。これは、上記のｌｖｒｔｅ ｍ．ｖａｒｃｕｒｒｅｎｔと類似するものであるが、この例ではｌｖｄｂａｃ． ｖａｒｃｕｒｒｅｎｔとも呼ばれる。つまり、ＣＶＳは、バリエーションテーブ ルをチェックして現在のデータの値をチェックし、現在適用するものを知る現在 のデータの値である。次に、ステップ６５２において、現在のＣＧＬ（条件グル ープリスト）は第１のＣＧＬ要素にセッ トされる。ＣＧＬは、上記に述べるように、ｌｖｒｔｅｍ．ｖａｒ＿ｔａｂｌｅ に類似しており、この例ではｌｖｄｂａｃ．ｖａｒ＿ｔａｂｌｅと呼ばれる。こ のＣＶＳはこのテーブルと比較され、バリエーションが適用するものを知る。 第１６Ｂ図を参照すると、ステップ６５４において、ＣＶＳと現在のＣＧＬ要 素との間で比較が行われる。ステップ６５６で判断されるように、一致する場合 、ステップ６５８において、適用するバリエーションのリストにＶＧＬ（バリエ ーショングループリスト）要素が追加される。ステップ６５６において一致が認 められない場合、ステップ６６０において、まだＣＧＬ要素があるかどうか判断 するためにチェックされる。ある場合には、現在のＣＧＬ要素を次のＣＧＬ要素 にステップ６６２においてセットし、処理をステップ６５４に戻す。これ以上Ｃ ＧＬ要素がステップ６６０において発見されない場合、処理はステップ６６４に おいて停止する。第１６Ａ図のステップ６４８において、バリエーションランタ イムマップが発見されない場合、このロジックファイルに対するバリエーション は現在アクティブではない。この場合も、処理はステップ６６４において停止す る。 第１図に関連して上記に述べたＤＢＡＣ２４、３０のスーパーツールキットは 、いくつかのエントリポイントを有する。各エントリポイントは、ＤＢＡＣ２４ 、３０が提供し、かつＲＴＥＭ１０がＤＢＡＣ２４、３０を呼び出して実行して もよい機能に対応する。−実施の形態において、ＤＢＡＣ２４、３０は１０個の エントリポイントを有しており、それぞれの例のロジックを次に述べる。 機能：ＲＥＡＤ ＲＥＡＤ１２００は、パラメータ１２０５、 １２０８を初期化および有効化することで開始される。次に、ＲＥＡＤはエイリ アス（ａｌｉａｓ）が１２１０で開いているかどうかを照会する。エイリアスが 開いている場合、ＲＥＡＤは、ＲＥＡＤへの現在の要求のロジックファイル名が エイリアス１２１５で既に開いているロジックファイル名と同じかどうかを照会 する。同じである場合にはＲＥＡＤは継続し、同じでない場合にはＲＥＡＤは障 害１２１８を示して終了する。エイリアスが開いていないとわかった時は、ＲＥ ＡＤはファイルを開き、必要に応じて１２２０でデータ辞書１２を開いて読み出 す。１２１５で開けた場合にはＲＥＡＤは継続し、そうでない場合には障害１２ ２８を示して終了する。ＲＴＥＭ１０がコードの第１のキーを構築するよう依頼 されてアンビエントデータ１２３０から読み込む場合、キーはアンビエントデー タ１２３５から生成され、１２４０でキー生成が成功する場合、ＲＥＡＤは継続 する。キー生成が成功しない場合、障害１２４２を示し、ＲＥＡＤは終了する。 より初期の場合、ＲＴＥＭ１０は、レコードの第１のキーを構築するよう求めら れ、アンビエントデータ１２３０からそれを読み出したりしないことがわかって おり、その後、ＲＥＡＤは継続するにすぎない。以前に存在しているのでない場 合、ＲＥＡＤはディスク１２４５からベースレコード情報を読み出す。レコード が１２５０で存在する場合にはＲＥＡＤは継続し、存在しない場合には「こうし たレコードのない」インジケータ１２５５をセットして継続する。「こうしたレ コードでない」１２６０以外の理由により読み出しが失敗する場合、障害１２６ ２を示し、ＲＥＡＤが終了する。読み出しが失敗しなければ、継続する。データ バリエーションランタイムマップが１２６５をチェックし、レコ ード１２７０に適用するデータバリエーションが存在する場合、バリエーション データはディスク１２７５から読み出される。こうしたデータバリエーションセ ットが存在しない場合、ＲＥＡＤが継続する。「こうしたレコードのない」イン ジケータが１２８０でセットされる場合、ＲＥＡＤは継続するが、そうでない場 合、ＲＥＡＤは、適切なバイナリの大きなオブジェクト（「ＢＬＯＢ」）または メモリフィールドテータをディスク１２８５から読み込む。こうした処理が完了 すると、成功または「こうしたレコードはない」を示し、ＲＥＡＤが終了する。 第１７Ａ図および第１７Ｂ図は図の形式で上記のステップを示している。 機能：ＥＸＴＲＡＣＴ ＥＸＴＲＡＣＴ １３００は、パラメータ１３０５ 、１３０８を初期化および有効化することで開始される。次に、ＥＸＴＲＡＣＴ は、エイリアスがすでに１３１０で開いているかどうかを照会する。エイリアス がすでに開いている場合、ＥＸＴＲＡＣＴは、ＥＸＴＲＡＣＴへの現在の要求の ロジックファイル名がエイリアス１３１５で既に開いているロジックファイル名 と同じかどうかを照会する。同じである場合にはＥＸＴＲＡＣＴは継続し、同じ でない場合には障害１３１８を示して終了する。エイリアスがまだ開いていない 時、ＥＸＴＲＡＣＴはファイルを開き、必要に応じて１３２０でデータ辞書１２ を開いて読み出す。首尾よく１３１５で開いた場合、ＥＸＴＲＡＣＴは継続し、 そうでない場合、障害１３２８を示して終了する。ＲＴＥＭ１０がレコードの第 １のキーを構築するように依頬されてアンビエントデータ１３３０から読み出さ れる場合、キーはアンビエントデータ１３３５から生成され、１３４０でキー生 成が成功する場合、ＥＸＴＲＡＣＴは継 続する。キー生成が成功しない場合、障害１３４２を示し、ＥＸＴＲＡＣＴは終 了する。より初期である場合には、ＲＴＥＭ１０は、レコードの第１のキーを構 築したり、アンビエントデータ１３３０からそれを読み出したりしないことがわ かり、それでＥＸＴＲＡＣＴは単に継続する。以前に存在していない場合、ＥＸ ＴＲＡＣＴはティスク１３４５からベースレコード情報を読み出す。レコードが １３５０で存在する場合にはＥＸＴＲＡＣＴは継続し、存在しない場合には「こ うしたレコードはない」インジケータ１３５５をセットして継続する。１３６０ で「こうしたレコードはない」という理由以外の理由により読み出しが失敗する 場合、障害１３６２を示し、ＥＸＴＲＡＣＴが終了する。読み出しが失敗しなけ れば、継続する。データバリエーションランタイムマップが１３６５をチェック し、レコード１３７０に適用するデータバリエーションが存在する場合、バリエ ーションデータはディスク１３７５から読み出される。こうしたデータバリエー ションセットが存在しない場合にはＥＸＴＲＡＣＴが継続する。「こうしたレコ ードはない」インジケータが１３８０でセットされている場合にはＥＸＴＲＡＣ Ｔは継続するが、そうでない場合には、ＥＸＴＲＡＣＴは適切なバイナリの大き なオブジェクト（「ＢＬＯＢ」）またはメモリフィールドデータをディスク１３ ８５から読み出す。この処理が完了すると、成功または「こうしたレコードはな い」ことを示し、ＥＸＴＲＡＣＴが終了する。 ＥＸＴＲＡＣＴ動作とＲＥＡＤ動作の違いは、ＥＸＴＲＡＣＴがＷＲＩＴＥを 目的としてデータをロックするということである。マルチユーザアプリケーショ ンであれば、同じデータを同時に複数の アプリケーションから要求することができる。データベースの破壊を防ぐために 、更新されるデータはいずれもまず「抽出」（ロック）されなければならない。 ＥＸＴＲＡＣＴ要求が生じる時にデータがすでに「抽出」（ロック）されている 場合、ＤＢＡＣ２４、３０は、処理を継続する前にデータがロック解除されるま で待機する。これは、１秒後に再びＥＸＴＲＡＣＴ要求を試行して行われる。オ ペレータにメッセージが表示され、この状態について警告する。こうして、オペ レータはＲＴＥＭ１０に戻す特別な結果コードを送るＥＸＴＲＡＣＴ要求の中止 を要求できる。 機能：ＶＥＲＩＦＹ ＫＥＹ ＶＥＲＩＦＹ ＫＥＹ １４００は、パラメ ータ１４０５、１４０８を初期化および有効化することで開始される。次に、Ｖ ＥＲＩＦＹ ＫＥＹは、エイリアスが１４１０ですでに開いているかどうかを照 会する。エイリアスが開いている場合、ＶＥＲＩＦＹ ＫＥＹは、ＶＥＲＩＦＹ ＫＥＹへの現在の要求のロジックファイル名がエイリアス１４１５で既に開い ているロジックファイル名と同じかどうかを照会する。同じである場合にはＶＥ ＲＩＦＹ ＫＥＹは継続し、同じでない場合には障害１４１８を示して終了する 。エイリアスがまだ開いていない時には、ＶＥＲＩＦＹ ＫＥＹはファイルを開 き、必要に応じて１４２０でデータ辞書１２を開いて読み出す。１４１５で首尾 良く開いた場合にはＶＥＲＩＦＹ ＫＥＹは継続し、そうでない場合には障害１ ４２８を示して終了する。ＲＴＥＭ１０がレコードの第１のキーを構築するよう に依頼されてアンビエントデータ１４３０から読み出される場合、キーはアンビ エントテータ１４３５から生成され、１４４０でキー生成が成功する場合、ＶＥ ＲＩＦＹ ＫＥＹは継続す る。キー生成が成功しない場合、障害１４４２を示し、ＶＥＲＩＦＹ ＫＥＹは 終了する。より初期の場合、ＲＴＥＭ１０は、レコードの第１のキーを構築した り、アンビエントデータ１４３０からそれを読み出したりしないことがわかり、 それでＶＥＲＩＦＹ ＫＥＹは継続するにすぎない。以前に存在しているのでな い場合、ＶＥＲＩＦＹ ＫＥＹはディスク１４４５からベースレコード情報を読 み出す。レコードが１４５０で存在する場合、ＶＥＲＩＦＹ ＫＥＹは継続し、 存在しない場合、「こうしたレコードはない」インジケータ１４６０をセットし て継続する。 機能：ＧＥＮＥＲＡＴＥ ＫＥＹ ＧＥＮＥＲＡＴＥ ＫＥＹ１５００は、 パラメータ１５０５、１５０８を初期化および有効化することで開始される。次 に、ＧＥＮＥＲＡＴＥ ＫＥＹは、エイリアスが１５１０ですでに開いているか どうかを照会する。エイリアスが開いている場合、ＧＥＮＥＲＡＴＥ ＫＥＹは 、ＧＥＮＥＲＡＴＥ ＫＥＹへの現在の要求のロシックファイル名がエイリアス １５１５で既に開いているロジックファイル名と同じかどうかを照会する。同じ である場合、ＧＥＮＥＲＡＴＥ ＫＥＹは継続し、同じでない場合、障害１５１ ８を示して終了する。エイリアスが開いていない時は、ＧＥＮＥＲＡＴＥ ＫＥ Ｙはファイルを開き、必要に応じて１５２０でデータ辞書１２を開いて読み出す 。首尾良く１５２５で開いた場合、ＧＥＮＥＲＡＴＥ ＫＥＹは継続し、そうで ない場合、障害１５２８を示して終了する。次に、ＧＥＮＥＲＡＴＥ ＫＥＹは アンビエントデータ１５３０からキーを生成する。キー生成が１５３５で成功す る場合、機能は成功を示し、１５４０を終了する。一方、キー生成が成功しない 場合、障害を示し、機能は １５４５を終了する。 機能：ＷＲＩＴＥ ＷＲＩＴＥ１６００は、パラメーク１６０５、１６０８ を初期化および有効化することで開始される。次に、ＷＲＩＴＥは、エイリアス が１６１０すでに開いているかどうかを照会する。エイリアスが開いている場合 、ＷＲＩＴＥ機能は、ＷＲＩＴＥ機能への現在の要求のロシックファイル名がエ イリアス１６１５で既に開いているロジックファイル名と同じかどうかを照会す る。同じである場合、ＷＲＩＴＥ機能は継続し、同じでない場合、障害１６１８ を示して終了する。エイリアスが開いていない時は、ＷＲＩＴＥ機能はファイル を開き、必要に応じて１６２０でデータ辞書１２を開いて読み出す。首尾良く１ ６２５で開いた場合、ＷＲＩＴＥ機能は継続し、そうでない場合、障害１６２８ を示して終了する。ＲＴＥＭ１０がレコードの第１のキーを構築するように依頼 されてアンビエントデータ１６３０から読みこまれる場合、ＷＲＩＴＥ機能は１ ６３５でそうするように試みる。１６４０でキー生成が成功する場合、ＷＲＩＴ Ｅ機能は継続し、そうでない場合、障害１６４２を示して終了する。しかし、Ｒ ＴＥＭ１０がアンビエントデータからレコードの第１のキーが構築されるように 要求しない場合は、ＷＲＩＴＥ機能は継続する。ヌルでない第１のキー１６４５ がある場合、ＷＲＩＴＥ機能は継続し、ない場合は障害を示して１６４８を終了 する。ＷＲＩＴＥ機能が継続すると仮定すると、ロジックファイル１６５０に書 き込みロックをセットする。次に、このエイリアス１６５５に現在抽出されたレ コードを再書き込みしている場合、ＷＲＩＴＥ機能は継続する。書き込みしてい ない場合、既に書き込まれているレコードが１６６０に存在しているかどうかを チェックする。レコードが存在する場合、ＷＲＩＴＥ機能は書き込みロックを外 し、障害１６６５を示して終了する。レコードが存在しない場合、ＷＲＩＴＥ機 能は継続する。ＷＲＩＴＥ機能が継続すると仮定すると、現在のレコード１６７ ０に現在適用する拡張子のリストを取得する。値をシーケンサフィールド１６７ ５に割り当てる。適当なＢＬＯＢまたはメモフィールドデータ、および適当な拡 張子セットデータをディスク１６８０に書き込む。ＷＲＩＴＥ機能はまた、ベー スレコードデータをディスク１６８５に書き込む。次に、レコード抽出時に適用 されるが１６９０がもはや適用されていない拡張子があるかどうかをチェックす る。ある場合は、ＷＲＩＴＥ機能はそれらを１６９２で取り除き、ない場合は１ ６９５で書き込みロックおよび終了をクリアすることにより継続する。 機能：ＲＥＭＯＶＥ ＲＥＭＯＶＥ機能１７００は、パラメータ１７０５、 １７０８を初期化および有効化することで開始される。次に、ＲＥＭＯＶＥ機能 は、エイリアスが１７１０ですでに開いているかどうかを照会する。エイリアス が開いている場合、ＲＥＭＯＶＥ機能は、ＲＥＭＯＶＥ機能への現在の要求のロ ジックファイル名がエイリアス１７１５で既に開いているロシックファイル名と 同じかどうかを照会する。同じである場合、ＲＥＭＯＶＥ機能は継続し、同じで ない場合、ＲＥＭＯＶＥ機能は障害１７１８を示して終了する。エイリアスがま だ開いていない時は、ＲＥＭＯＶＥ機能はファイルを開き、必要に応じて１７２ ０でデータ辞書１２を開いて読み出す。首尾良く１７１５で開いた場合、ＲＥＭ ＯＶＥ機能は継続し、そうでない場合、障害１７２８を示して終了する。ＲＴＥ Ｍ１０がレコードの第１のキーを構築するように依頼されてアンビ エントデータ１７３０から読み出される場合、ＲＥＭＯＶＥ機能は１７３５でそ うするように試みる。キーはアンビエントデータ１７３５から生成され、１７４ ０でキー生成が成功する場合、ＲＥＭＯＶＥは継続し、そうでない場合、障害１ ７４２を示して終了する。しかし、ＲＴＥＭ１０がアンビエントデータからレコ ードの第１のキーが構築されるように要求しない場合は、ＲＥＭＯＶＥ機能は継 続する。ＲＥＭＯＶＥ機能が継続すると仮定すると、現在のエイリアス１７４５ から現在抽出されたレコードを取り除いているかどうかをチエックする。取り除 いている場合、ＲＥＭＯＶＥ機能は継続するが、取り除いていない場合、ＲＥＭ ＯＶＥ機能はベースレコードデータ１７５０を抽出する。１７５５の次に抽出が 行われる場合には、ＲＥＭＯＶＥ機能は継続する。そうでない場合、障害１７５ ８を示して終了する。ＲＥＭＯＶＥ機能が継続すると仮定すると、ディスク１７ ６０からベースレコードデータを取り除き、ディスク１７６５から適当な拡張子 データセットデータを取り除き、またディスク１７７０から適当なＢＬＯＢまた はメモデータを取り除き、１７７５を終了する。 機能：ＣＬＯＳＥ ＣＬＯＳＥ機能１８００は、パラメータ１８０５、１８ ０８を初期化および有効化した後、全てのエイリアス１８１０をＲＴＥＭ１０が 閉じるように要求したかどうかを照会する。要求があった場合、ＣＬＯＳＥ機能 は開いたエイリアス１８１５のグローバルなリストを検索し、要求がなかった場 合、ＲＴＥＭ１０によって提供されたエイリアスのリストを１８２０で継続する 。前のステップで取得したリストの各エイリアスごとに、ＣＬＯＳＥ機能はベー スレコードの物理ファイルを閉じ、適用可能な拡張子 セット物理ファイルを閉じ、このエイリアス１８２５の記憶された状態情報を全 てクリアし、また成功を示して１８３０を終了する。 機能：ＳＨＵＴ ＤＯＷＮ パラメータ１８０５、１８０８を初期化および 有効化した後、ＳＨＵＴ ＤＯＷＮ機能１８５０はＣＬＯＤＥ機能１８００を呼 び出し、それに要求して全てのエイリアス１８６０を閉じる。このＳＨＵＴ Ｄ ＯＷＮ機能は次に、全ての開いたデータ辞書１８６５を閉じ、全てのキャッシュ したデータ辞書情報１８７０をクリアして成功を示し、１８７５を終了する。 機能：ＧＥＴ ＫＥＹ ＧＥＴ ＫＥＹ機能１９００はパラメータ１９０５ 、１９０８を初期化および有効化し、エイリアスがすでに１９１０で開いている かを照会する。開いている場合、ＧＥＴ ＫＥＹ機能は本エイリアスの最後の動 作が成功したＥＸＴＲＡＣＴ１９１５であるかどうかを照会する。そうである場 合、ＧＥＴ ＫＥＹは現在のキー１９２０を検索する。そうでない場合、ＧＥＴ ＫＥＹは次のキー１９２５を検索する。次のキーを検索しようとする試行が１ ９３０で成功した場合、ＧＥＴ ＫＥＹは成功を示して１９３５を終了し、成功 しない場合、またはこのエイリアスの最後の動作が成功した抽出でない場合、Ｇ ＥＴ ＫＥＹは障害を示し、１９４０、１９４２を終了する。 機能：ＧＥＴ ＦＩＲＳＴ ＫＥＹ ＧＥＴ ＦＩＲＳＴ ＫＥＹ機能１９ ５０は、パラメータ１９５５、１９５８を初期化および有効化した後、エイリア スが１９６０を開いているかどうかを照会する。開いている場合、ＧＥＴ ＦＩ ＲＳＴ ＫＥＹ機能は第１のキー１９６５を検索する。第１のキーの検索が１９ ７０で成功する場合、ＧＥＴ ＦＩＲＳＴ ＫＥＹは成功を示して１９７５を終 了し、成功しない場合、障害を示して１９８０を終了する。エイリアスがまだ開 いていないことがわかった場合、ＧＥＴ ＦＩＲＳＴ ＫＥＹは障害を示して１ ９８５を終了する。 いくつかの他の機能、特にＧＥＴ ＰＲＥＶＩＯＵＳ ＫＥＹ、ＧＥＴ ＣＵ ＲＲＥＮＴ ＫＥＹ、ＧＥＴ ＮＥＸＴ ＫＥＹ、ＧＥＴ ＬＡＳＴ ＫＥＹは 、ＧＥＴ ＦＩＲＳＴ ＫＥＹ機能とほぼ同一の機能をするが、これらが戻るキ ーであるという点で異なっている。 本発明の１つの利点として、現行のレガシーコードで作業することができると いうことがある。「レガシー」とは、本発明の教示に先だって存在するアプリケ ーションソフトウェアであり、本発明を使用して特に開発されたモデルとともに 、ＲＴＥＭ／モデル環境で動作するために、これに適合しなければならない。 レガシーソフトウェアを適応させるために、コードを変換してＤＢＡＣ２４、 ３０にアクセス可能にする。レガシーソフトウェアからハイブリッドレガシーソ フトウェア（ＲＴＥＭ１０と互換性のあるモデルおよび方法への呼び出しを行う レガシーソフトウェア）への初期変換を実現するために、全てのデータベースア クセスをＤＢＡＣ２４、３０へのリンクに変更する。有効性チェックがデータ辞 書１２の辞書セグメントのプレコンパイルされたデータバンクに基づいて「プレ ライトファイル要素認証」への呼び出しに代わる。ファイルへの書き込みは、有 効性テストルーチンでコンパイルされたファイルのリストを使用してシングルの ＤＢＡＣ２４、３０アクセスによって達成される。全ての表示入出力はＵＩＯ２ ６を使用するように変換される。また、コードもデータ辞書１２を使用するよう に変換される。ファイル利用情報（つまり、書き込まれたり、読み出されたり、 抽出されたり、削除されたファイル）はデータ辞書に格納される。レガシーコー ドの変数は、３２ビット識別（ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）など、データ辞 書１２で使用される文字識別に名前が変更される。場所（プログラム／行）およ び形態（評価、印刷（マスク値）、連結、転送、かすませる、入力、更新）への リファレンスである。レガシー変換処理中、エラー修正変更のみをレガシーソフ トウェアに行うことができ、新しいロジックは追加することができない。 レガシーエンシン（ライブラリ）はＲＴＥＭ１０によって利用可能なファイル のロシックオブシェクトに作成される。ＲＴＥＭ１０によって実現されるアプロ ーチと互換性のあるソフトウェアにレガシーソフトウエアを移行する間に作成さ れる「遷移オブジェクト」は、レガシーコードと結合されて「ハイブリッドルガ シープログラム」を作成する。この結合は「ゲート」の使用によって行われる。 上記のように、ゲートは、レガシー変換処理と関連して上記で述べられるように 、コードのステートメント間のギャップのレガシーコードに格納される。本発明 の実施の形態によって、新しいロジックはレガシーコードに追加されないとする と、新しいロジックと関連するコードへの変更は、こうした新しいロジックを許 可または禁止するゲートを挿入することで呼び出さなくてはならない。新しいオ ジック自体はモデルおよび／または方法において具体化される。ＲＴＥＭ１０で 使用するようにフォーマットしたロジックへの条件的なゲートとしては、以下の ものがある。 nnnnn DPCU-123456;Perform 「 Get_list_of_active_Gates」; IF ACTIVE_GATES>０THEN Perform"Gate_Control」 「Ｇｅｔ＿ｌｉｓｔ＿ｏｆ＿ａｃｔｉｖｅ＿ｇａｔｅｓ」への呼び出しは、現 在のユーザに有効な全てのゲート（または「ゲート制御された」ロジック）のリ ストを構築し、この評価には、このユーザが使用するように登録したテストオブ ジェクト同様、すべてのパブリックを含む。ロジック修正が生成に適用可能な場 合、オブジェクトはパブリックにされるにすぎず、アプリケーションへの変更は 必要ではない。 上記のアプローチによって、ハイブリットルガシーソフトウェアの現在進行中 の解析および「修復」が可能になる。例えば、このアプローチで、次の変化がハ イブリッドレガシーソフトウェアに生じる。 ・修理を実現するためのデータ辞書１２への修正 ・可変マスキングリストを作成可能 ・２０００年の日付変更可能 ・時間単位を修正可能 ・古いマスクを交換可能 ・可能な重ね打ち（例えば、修正されたリポート上に）をアドレス可能 さらに、次のようなハイブリッドレガシー修正が可能である。 １．入力フィールドおよびそれの関連ロジックを、ゲートの使用あるいは他の 手段を通じて追加、バイパス、または省略（ｄｅｆａｕｌｔｅｄ）可能である。 ２．新しいフィールドを現行のファイルレコードに追加してもよ い。 ａ．（ＤＢＡＣ２４、３０の機能に関連して述べる）エラスティックなデー タベースの能力の使用 ｂ．現行のファイルレコードのフィールドを除いてもよい。例えば、使えな くなったフィールドはＤＢＡＣ２４、３０による値に省略し、エラステ ィックデータベースを利用し、すぐにではなくしばらくして除かなけれ ばならない。 ３．新しいファイルは読み出し、書き込み、抽出を行い、また他の動作をテス ト中にさえも追加してもよく、この場合、条件的な呼出を使用する（新し いファイルを新しいオブジェクトとして定義する）。 ４．レガシーロジックは切断、非有効化、またはバイパスされてもよく、通常 条件のテストロジックを使用して分岐してもよい 上記は、本発明の基本理念を示すソフトウェアアプリケーション開発の方法、 システム、およびデータ構造の実施の形態を記載するものである。本発明のさら なる様態、特徴、および利点は、当業者に明らかであろう。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，Ｍ Ｗ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ， ＣＮ，ＣＵ，ＣＺ，ＥＥ，ＧＥ，ＧＨ，ＨＵ，ＩＬ，Ｉ Ｓ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ ，ＬＲ，ＬＳ，ＬＴ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ， ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＲＯ，ＲＵ，ＳＤ，Ｓ Ｇ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＷ (72)発明者 マックグイーク，フレッド カナダ国 オンタリオ エム２ジェイ ２ シー５，ノース ヨーク，エスターブルッ ク アヴェニュー ９，ユニット 156 (72)発明者 ベネット，ジェイムス カナダ国 オンタリオ エム１エル ４ア ール３，スカーボロ，ナンバー2505 バー ン ヒル ロード 50 (72)発明者 クラーク，マシュウ カナダ国 ブリティッシュ コロンビア ヴイ５エー １エム５，バーナビー，ハリ ファクス ストリート 1005―7376

Claims (1)

1. 【特許請求の範囲】 １．プロセッサと、メモリと、記憶媒体とを有しており、アプリケーションソフ トウェアを動作させるコンピュータ実装システムにおいて、 前記記憶媒体に記憶され、１つまたはそれ以上のオブジェクトへのリファレン スを含むデータをそれぞれ有する複数のモデルと、 前記複数のモデルのうち選択した１つを前記記憶媒体からメモリにロードし、 前記選択したモデルのデータを読み出し、オブジェクトへのリファレンスが読み 出された場合に前記オブジェクトを呼び出して実行するランタイムイベントマネ ージャとを備えたことを特徴とするコンピュータ実装システム。 ２．前記モデルは、登録処理によって作成されるモデルのセットの一部であり、 前記ランタイムイベントマネージャは、前記登録処理によって登録された前記モ デルのみをアクセスすることができることを特徴とする請求の範囲第１項に記載 のコンピュータ実装システム。 ３．前記モデルが他の方法を呼び出すことができる方法のリファレンスを有して いない場合にのみ前記モデルは登録されることを特徴とする請求の範囲第２項に 記載のコンピュータ実装システム。 ４．前記モデルは、 ａ．パラダイムを形成する第１のタイプのモデルと、 ｂ．パラダイムモデルのバリアントである第２のタイプのモデルとを有すること を特徴とする請求の範囲第１項に記載のコンピュータ実装システム。 ５．バリアントモデルは、前記ランタイムイベントマネージャによって処理され る前記バリアントモデルを満足しなければならない１つまたはそれ以上の関連す る条件を有することを特徴とする請求の範囲第４項に記載のコンピュータ実装シ ステム。 ６．前記ランタイムイベントマネージャは、さらに、 ａ．パラダイムモデルが呼び出されている場合に、このパラダイムモデルのため のバリアントモデルがあるかどうかをチェックし、 ｂ．バリアントモデルが存在する場合、このモデルを検索し、 ｃ．検索されたバリアントモデルに対する条件があるかどうかをチェックし、 ｄ．検索されたバリアントモデルに対する条件がある場合には、前記バリアント モデルを処理するようにしたことを特徴とする請求の範囲第５項に記載のコンピ ュータ実装システム。 ７．前記ランタイムイベントマネージャは、パラダイムモデルに関連するバリア ントモデルがこれ以上なくなるまで、関連した前記条件が存在するバリアントモ デルについてステップｂからｄを繰り返すようにしたことを特徴とする請求の範 囲第６項に記載のコンピュータ実装システム。 ８．前記ランタイムイベントマネージャは、モデルの各オブシェクトの処理後に 、前記モデルの外部の動作を処理するようにしたことを特徴とする請求の範囲第 １項に記載のコンピュータで実現されるシステム。 ９．外部入出力を通してコンピュータとコミュニケーションし、このコンピュー タの外部のイベントに対する指令および応答に関連する処理機能を実行するコン ピュータによって実行されるランタイム イベントマネージャであって、前記コンピュータは、前記ランタイムイベントマ ネージャにアクセス可能なモデルのセットが記憶されている記憶媒体を有し、 モデルのライブラリからモデルをロードする手段と、 ロードしたモデルが、前記コンピュータと前記ランタイムイベントマネージャ の所定の状態において適切に呼び出されるかどうかを判断する手段と、 前記コンピュータと前記ランタイムイベントマネージャの状態が適切な状態に なっていると判断される場合には、前記モデルを呼び出す手段とを備えたことを 特徴とするランタイムイベントマネージャ。 １０．前記モデルを実行する手段は、前記モデルの所定の要素が有効になる前に 外部イベントを検出してこれに応答する手段を含むことを特徴とする請求の範囲 第９項に記載のランタイムイベントマネージャ。 １１．ランタイムイベントマネージャを利用してコンピュータアプリケーション ソフトウェアを開発する方法において、 ａ． ｉ．モデルへのリファレンス、 ｉｉ．方法へのリファレンス、 ｉｉｉ．データ、および ｉｉｉｉ．入力命令または出力命令 の少なくとも１つをそれぞれ有する複数のモデルを作成するステップと、 ｂ．モデルによってリファレンスされる方法は別の方法を呼び出すことができな いことを確かめるために前記モデルをテストするステ ップと、 ｃ．前記ランタイムイベントマネージャによるアクセスを許可するために前記モ デルを登録するステップとを備えたことを特徴とするコンピュータアプリケーシ ョンソフトウェアを開発する方法。 １２．前記ステップは、モデルのセットと関連して前記ランタイムイベントマネ ージャを動作することによって実行されることを特徴とする請求の範囲第１項に 記載のコンピュータアプリケーションソフトウェアを開発する方法。 １３．コンピュータアプリケーションソフトウェアで使用され、コンピュータで 読み出し可能な媒体で具体化されるソフトウェアモデルにおいて、 モデル識別コードと、 ソフトウェアオブジェクトへの複数のリファレンスと、 データとを備えたことを特徴とするソフトウェアモデル。 １４．前記ソフトウェアオブジェクトへのリファレンスは、ペアレントオブジェ クトと、プレ処理オブジェクトおよびポスト処理オブジェクトからなるグループ から選択されたオブジェクトとを含むことを特徴とする請求の範囲第１３項に記 載のソフトウェアモデル。 １５．前記モデルは、ソフトウェアオブジェクトへのリファレンスのセットを有 するパラダイムモデルのバリアントモデルであり、前記バリアントモデルで参照 される前記ソフトウェアオブジェクトは、前記パラダイムモデルで参照される前 記オブジェクトと異なっていることを特徴とする請求の範囲第１３項に記載のソ フトウェアモデル。 １６．条件のセットが満たされている場合にのみ、前記モデルはラ ンタイムイベントマネージャによって呼び出し可能であることを特徴とする請求 の範囲第１５項に記載のソフトウェアモデル。 １７．ランタイムイベントマネージャによって使用するために登録されたオブジ ェクトのライブラリを作成する方法において、 ａ．前記モデルに固有の識別子に基づいてオブジェクトを呼び出すステップと、 ｂ．制限された内容があるかどうかについて前記オブジェクトの内容をスキャン するステップと、 ｃ．オブジェクトが制限された内容を含まない場合にのみ、前記ライブラリの一 部として前記オブジェクトを登録するステップとを備えたことを特徴とする方法 。 １８．前記制限された内容は登録されていないオブジェクトに対するオブジェク トへのリファレンスを含むことを特徴とする請求の範囲第１７項に記載の方法。 １９．制限される前記コンテンツは、別の方法オブジェクトへの参照を含む方法 オブジェクトへの参照を含むことを特徴とする請求の範囲第１７項に記載の方法 。 ２０．プロセッサと、メモリと、記憶媒体とを有するコンピュータ実装データベ ースシステムにおいて、 前記記憶媒体に記憶され、それぞれ１つまたはそれ以上のフィールドをそれぞ れ有する複数のベースレコートを含むベースファイルと、 前記ベースファイルに対応する前記記憶媒体に記憶されている少なくとも１つ のバリエーションセットと、 前記バリエーションセットを特定のベースレコードに適用するこ とを決定するようにしたバリエーションセットランタイムマップを実装するため にプログラムされたシステムとを備えたことを特徴とするコンピュータ実装デー タベースシステム。 ２１．前記バリエーションセットは、前記特定のベースレコードに適用される前 記バリエーションセットに対して満たさなければならない１つまたはそれ以上の 関連した条件を有することを特徴とする請求の範囲第２０項に記載のコンピュー タ実装データベースシステム。 ２２．前記バリエーションセットランタイムマップは、条件フィールドリストと 、条件グループリストと、バリエーショングループリストとを含むことを特徴と する請求の範囲第２１項に記載のコンピュータ実装データベースシステム。 ２３．データベースシステムを動作させる方法において、 ａ．ベースファイルから１つまたはそれ以上のフィールドを有するベースレコー ドをロードするステップと、 ｂ．前記ベースファイルに対応するバリエーションセットがあるかどうかについ てバリエーションセットランタイムマップをチェックするステップと、 ｃ．バリエーションセットが存在する場合、前記バリエーションセットからデー タを検索するステップとを備えたことを特徴とする方法。 ２４．前記バリエーションセットからデータを検索するステップは、 前記バリエーションセットのための条件が存在するかどうかをチェックするス テップと、 前記検索したバリエーションセットのための条件が存在し、これが満たされて いる場合、前記ベースレコードに適用する前記バリエーションセットから前記デ ータを検索するステップとをさらに含むことを特徴とする請求の範囲第２３項に 記載のデータベースを動作させる方法。