JPH09502034A - より少ない再コンパイル及び再リンケージ処理を可能にする目標プロセスのオブジェクト・コードの別形式を導入することにより、誤り位置とシステムへの新たな要求に起因する修正位置との自動的な識別を可能にする、コンピュータ・ソフトウェア・プロセスにおける不確実性最小化方法 - Google Patents

Abstract

(57)【要約】 本発明のシステム及び方法によれば、誤りの位置、又は、新たな結果の予測に起因する修正の箇所に関する不確実性を最小化することができる。これは、目標プロセスの帰納の認知的な理解と類似するプロセスの総合によって達成される。目標プロセスのモデルが、静的な解析を基礎にして構築され、目標プロセス知識の更なる集積が、その実行に対して疑似パラレルである目標プロセスの解析を実行する本発明によるＸＰＤ（ｅＸｐｅｒｔ Ｐｒｏｇｒａｍ Ｄｉａｇｎｏｓｉｓ）マシンによる動的な解析の間に実行される。本発明は、目標プロセスのアルゴリズムの制御成分を、単一の定義形式を有し、任意のプロセスの制御構造を表すのに必要十分なアルゴリズムのＸＰＤフレームの中に抽出する。連続的なビジョンを構築することによって、目標プロセスの任意の２つの要素の間のアクセス可能性すなわち潜在的な依存性を自動的に容易に評価し、たとえば、確実に終了不可能なプロセス構成すなわちデータ独立のエンドレス・ループを可能にするメカニズムが導入される。原因・効果関係に関する知識と、目標プロセスにおける及び本明細書で定義される「プロセス空間」と「プロセス時間」とによる座標系における個々の要素の正しさ及び不確実性の相対的で時間に独立な測定とを、構築する。本発明は、ＸＰＤマシンの「知識帰納」及び「知識演繹」プロセスと、ユーザと目標プロセスに関する集積された知識との間の非常に高レベルのインターフェースに対するメカニズムとを導入する。また、その診断のための別の媒体として、目標プロセスの行動の音声的な提供も行われる。本明細書で提供された「ＸＰＤオブジェクト・コード」は、その目標プロセスのメンテナンスだけでなく、静的及び動的に、その目標プロセスの解析するのに適している。これによれば、修正のための目標プロセスの再コンパイルと再リンケージとが短縮され、時には除去される。

Description

【発明の詳細な説明】 より少ない再コンパイル及び再リンケージ処理を可能にする目標プロセスのオブ ジェクト・コードの別形式を導入することにより、誤り位置とシステムへの新た な要求に起因する修正位置との自動的な識別を可能にする、コンピュータ・ソフ トウェア・プロセスにおける不確実性最小化方法 発明の背景 発明の分野 本発明は、コンピュータ・プログラムの静的及び動的な解析方法に関する。こ の解析方法により、プログラムの誤動作（故障、ｆａｉｌｕｒｅ）の原因となる 誤り（ｆａｕｌｔ）の位置と、仕様が変更された場合に必要となる修正の箇所と 、に関する不確実性を最小にすることができる。 本発明のプロセスは、また、目標（ｔａｒｇｅｔ）となるコンピュータ・ソフ トウェア・システムのユーザとその内部処理との間に、新規で非常に高レベルの インターフェースを提供する。このインターフェースによれば、目標となるソフ トウェアの解析を実行する非常に有効な方法が可能になる。 同じインターフェースによれば、システムの修正と更なる開発のための非常に 高レベルのプログラム言語の導入が可能になる。ここでは、それを、結果志向型 のプログラミング（Ｒｅｓｕｌｔ Ｏｒｉｅｎｔｅｄ Ｐｒｏｇｒａｍｍｉｎｇ ＝ＲＯＰ）と称する。 また、以下の説明では、ＸＰＤオブジェクト・コードを提案することにより、 コンピュータ・ソフトウェア処理のオブジェクト・コードの伝統的な形式に代わ る別の選択肢を提供する。ここで、ＸＰＤは、エキスパート・プログラム診断（ ｅＸｐｅｒｔ Ｐｒｏｇｒａｍ Ｄｉａｇｎｏｓｉｓ）の略である。 ＸＰＤオブジェクト・コードは、静的なもの及び動的なものの両方のプログラ ム解析と、プログラム・メンテナンスとに関して、より適切である。ＸＰＤオブ ジェクト・コードは、処理の修正の結果として生じる目標となる処理コードの再 コンパイル（ｒｅｃｏｍｐｉｌｉｎｇ）や再リンキング（ｒｅ−ｌｉｎｋｉｎｇ ） を、容易にし、時には不要にする。 関連技術の説明 数十年の間のコンピュータ・ソフトウェア工学が、以下の事柄を示している。 すなわち、ａ）コンピュータ・プログラム処理が正しい又は望ましい結果を常に 生じるということを証明する自動化された方法は存在しないこと、ｂ）エラーの ないソフトウェアはない、すなわち、ソフトウェアは、試験自体が正しかったと 仮定した上で、試験された限度でのみ正しいということ、ｃ）最も単純なソフト ウェアを除いては、完全に網羅的な試験などあり得ないこと、ｄ）現時点でのソ フトウェア工学では、ハードウェアの安全性の限度に類似のものは全く提供され ず、１つの誤りによってシステム全体が停止してしまうことも多いこと、ｅ）誤 動作の存在が試験又は製造の過程で認識されたとしても、その原因（誤り）の箇 所を特定することは、しばしば、余りに困難であること、である。 この理由は、ソフトウェアは、原因と結果とが近接しているという、ハードウ ェアと同じ単純な規則には従わないという点で、ハードウェアとは基本的に異な るからである。すなわち、ソフトウェアのエラー（誤り）は、その現れ（誤動作 ）に近い場所にあるとは限らず、システムの中のほとんど任意の場所に存在し得 るのである。 産業界での平均では、試験に合格し生産過程にあるシステムに対して、１００ 行（ライン）のコード当たり、５から１０の誤りがある。誤りの箇所を特定する ことが困難であるという理由により、多くの誤りは、我慢されている。プログラ マと彼らの管理者たちは、コードを改良又は修正しようとするどのような試みで も、むしろ、新たなエラーを導きシステムを更に破壊してしまいかねないので、 コードに触れることを恐れている。 １９８８年に言明された次の文章は、１９９３年でも依然として有効である。 すなわち、「原則的に、それは、こうである。注意深く作られたプログラムの欠 陥の割合は、１０００ラインについて誤りが約５つである。よって、１００万ラ インのプログラムでは、たったの５０００の問題点ということになる。ここで、 それぞれの誤りに対してただ１つの試験箇所が必要であると仮定しても、数千回 の試みというのは、非現実的ではない。誤りは、明白かも知れないが、我々が認 めようとする以上に、試験についての我々の直感の元に存在している。誤りの箇 所は少ないのかも知れないが、我々は、それらをどのように見つけるかを知らな いのである。更に悪いことに、我々は、どうやってサーチしたらよいのかも、選 択された箇所をどのように判断すべきかも、どの時点でやめたらいいのかも、知 らない。だから、５０００の箇所を試験してみてエラーが発見できなかった場合 でも、エラーは全くないのか、それとも、１０残っているのか、あるいは、まだ 、５０００も残っているのかなど、わからない。技術的な側面からいえば、試験 を最も必要としているのは、強固な基礎理論であり、・・・」（ＡＣＭのコミュ ニケーションの中のソフトウェア試験に関する特別セクション、１９８８年）で ある。 １９９０年代には、ソフトウェアの「リエンジニアリング」が、流行語（ｂｕ ｚｚｗｏｒｄ）となった。ＩＢＭシステム・ジャーナルの２８巻２号（１９８９ 年）には、「プログラム理解：１９９０年代への挑戦」という表題が付けられて いる。 ＩＢＭの研究によれば、世界中では、３億ドルがソフトウェアのメンテナンス に費やされ、この数字は、新たなソフトウェアの集積と古いソフトウェアの加齢 とによって、上昇している。 ＭＩＴの研究によれば、新たなソフトウェアのプロジェクトに配分される１ド ルに対して、そのプロジェクトのメンテナンスには、９ドルが費やされるとのこ とである。 １９９０年１１月号のソフトウェア・マガジン誌では、プライス・ウォーター ハウスによる研究が掲載されており、そこでは、既存のシステムの中のエラーを 訂正するシステム・ワークに対しては、１年当たり１０億ドルのマーケットが存 在すると評価されている。 ソフトウェアのデバッギングに関する現在の技術は、コントロール・ブレーク （ｃｏｎｔｒｏｌ ｂｒｅａｋ）技術に基づいている。これは、以下のように行 われる。以下のａ〜ｃの方法の中の１つを用いてコントロール・ブレークを設定 することにより、解析が、ソースから付勢される。 ａ）プログラマがソースを検討し、カーソル又はその他のポインティング・デ バイスを、特定のソース・コードのラインの上に位置させることにより、コント ロール・ブレークをマニュアルで設定する、又は、 ｂ）プログラマは、デバッギング・ツールに命じて、現時点でアクティブなソ ース・コードのラインを自動的にハイライトすることにより、その実行を視覚的 にトレースできる程度の遅い速度でコードを解釈することにより、コードを動か させる（トレースさせる）、又は、 ｃ）特定のタイプの命令（ｉｎｓｔｒｕｃｔｉｏｎ）ごとに、コントロール・ ブレークが設定されるように命じられる。たとえば、各入力ステートメントの後 で、又は、各コール（実行）ステートメントの前に、である。 コントロール・ブレークの目的は、プログラムの変数の値をマニュアルに確認 するために、実行プロセスを一時的に停止させることである。 コントロール・ブレーク技術が用いられるときには、次のことが仮定される。 すなわち、 （ｉ）プログラマは、コントロール・ブレークを、適切なソース・コードの位 置に設定する。 （ii）上の（ｉ）を仮定した上で、プログラマは、どの変数を調べるかを理解 している。 （iii）上の（ｉ）及び（ii）を仮定した上で、プログラマは、何が誤りの原 因であるかに関して正しい決定をする。 正確なマニュアルでの解析の確率は、したがって、（ｉ）、（ii）及び（iii ）の確率の積に等しい。たとえば、それぞれのステップにおける正しい決定の確 率が１０％であれば、マニュアルの解析で正しい結果が得られる確率は、０．１ ％である。 以上で見たように、誤りの原因の箇所を特定しようとする伝統的なコントロー ル・ブレーク技術は、全く自動化されておらず、チェックすべきか、何をチェッ クすべきか、それは何を意味するか、に関する認識上の決定の間の人的なエラー のあらゆる可能性を導入してしまう。 試験プロセスの実行の間に、どのソース・コードの命令がカバーされどれがカ バーされていないかを自動的に判断する領域で、いくらかの仕事がなされてきて いる。 米国特許第４８５３８５１号（Ｈｏｒｓｃｈ）は、「静的及び動的な解析記録 に基づいて試験済みプログラムのコード・カバレッジを判断するシステム」を開 示している。これは、試験の最中にコンピュータ・プログラムにおいて実行され た命令の数と、そのプログラムの中の命令全体の数との比率を測定する方法であ る。 一般的にはより多くの命令が試験の間にカバーされるほどよいが、あるプロセ スのステップが実行されたという事実は、その有効性に関しては情報を与えてく れない。すなわち、実行されたその特定のステートメントはそもそも間違って構 成されていたかも知れないし、その特定のステートメントは、間違った場所で間 違った時点で実行されるかも知れないし、更には、その特定のステートメントは 、プロセスの結果を変更しない又はそれに影響しないステートメントであるかも 知れない。 米国特許第４８０２１１６号（Ｗａｒｄ他）は、機械のプロセスを制御し、そ のデバッギングを容易にする「プログラムされたコントローラ」を開示している 。アプリケーションは、ここでは、１又は複数の個別のループに組織されること により、機械の各部分に対する特定の制御方式のシミュレーションをするように 設計されている。組み込み型（ビルトイン）の制御メカニズムが、これらのルー プの状態を、ループの間での移動の原因となる条件と共に、記録する。 この技術は、独立のループから構成されループの状態をトレースする手段がプ ロセスを制御するプログラムにおいて予めコード化されているような、非常に特 定の構文（ｓｙｎｔａｘ）規則によって特別にコード化されたプロセスだけに、 適用が制限される。プロセス履歴（ヒストリ）の記録は、ステートメントの各ブ ロックと異なるブロックを接続する各論理条件ステートメントとを表すシーケン スを記録することによって行われる。システムの誤り解析は、ＸＰＤマシンが与 える程度までには自動化されていないが、その理由は、ＸＰＤマシンの場合とは 異なり、解析が実際のプロセスの結果を参照することによってではなく、プログ ラム状態の記録されたシーケンスを解析することによってなされ、よって、ＸＰ Ｄマシンが行うような高レベルの推論とユーザ・インターフェースとを提供しな いことによる。 従来技術は、定義された領域内でのある程度の不確実さを有しながらであって も、コンピュータ・ソフトウェアにおける論理の誤りの位置を自動的に特定でき る汎用の（ジェネリックな）プロセスを提供していない。これは、そのような自 動化が、以下の２つの理由のために実現不可能である、と一般的に信じられてい ることが原因である。すなわち、 １）上述のように、ソフトウェアは、原因と結果とが近接しているというハー ドウェアと同じ規則には従わず、特定の誤動作の原因となるソフトウェア上の誤 りは、そのソフトウェア・システムの中の、ほとんどあらゆる場所に存在する可 能性がある。 ２）ソフトウェア・システムは、予測される結果がシステム内でコード化され ているのでなければ、そこから結果として何が予測されるのかを知っておらず、 よって、予測されない結果である誤動作を認識できない。プログラム仕様を事前 にコード化することは、その複雑性とエラーを有する傾向のある特徴とにおいて 、このソフトウェア機能をプログラムすることと異ならないことを示す仕事がな されている。 更に、システム仕様を事前にコード化することによってソフトウェアの誤動作 を回避しようとすることは、ソフトウェアの誤動作は絶対的には定義できないの であるから、ソフトウェアの誤動作の有する以下の特性を見過ごすことになりか ねない。すなわち、 ソフトウェアの誤動作は、入力及び出力における予測の変化に対して相対的で あり、 ソフトウェアの誤動作は、動作環境の変化に対して相対的であり、 ソフトウェアの誤動作は、システムの結果の個別の予測に対して、これらの予 測が明示的に文書化されていない場合には、相対的である。 我々は、ここで、ソフトウェアの誤りの箇所を特定する際の問題は、基本ソフ トウェア・プロセス（プログラムのソース・ステートメント）の正しさの相対性 そのものの中に存在することを付け加えたい。 基本プロセスは、三次元で存在する。最初の２つは、プログラムのアルゴリズ ム空間の２つの次元であり、これは、流れ図を見ることによって理解できる。静 的なプログラム解析は、この二次元空間で行われる。第３の次元は、プログラム 実行プロセスにおける時間である。動的な解析は、空間と時間とにおいてなされ なければならない。 プログラムの静的な解析と動的な解析との違いは、古典力学と現代力学との違 いと同じくらい大きい。 「誰も、ある時刻において、でなければ場所を認識したことがなく、又は、あ る場所において、でなければある時刻を認識したことがない」（Ｈ．ミンコフス キー『空間と時間』）ように、プログラムのアルゴリズム空間内にそれ自体のハ ードコード化された位置を有するプログラムの内部の基本プロセスは、プログラ ムの制御がその位置に至ったとき及びその場合にのみ、意味を有するのであり、 その意味は、そのプロセス内の別の時刻では異なっている。 基本プロセスの意味における違いは、このプロセス内の別の時刻においては、 この基本プロセス（ステートメント）の実行の前後の実行履歴の潜在的な違いに よって、条件付けられる。 従来技術は、コンピュータ・ソフトウェアにおける論理的な誤りの箇所を自動 的に特定しプログラムの動的な解析を全体的に向上させるために必要な以下の主 な技術的なステップを欠いていた。すなわち、 Ｉ）その相対性の属性（ａｔｔｒｉｂｕｔｅｓ）を導入し自動的な論理解析を 実行可能にする、自動化プログラム解析に関する新たな理論と、 II）この新たな理論に基づく技術であって、目標プロセスの要素である「正し さ」（ｃｏｒｒｅｃｔｎｅｓｓ）と「不確実性」（ｕｎｃｅｒｔａｉｎｔｙ）と に関する知識上で動作し、この不確実性を自動的に最小化するメカニズムを有し 、目標プロセスの要素の間で上述の知識を集積し伝搬することを可能にするプロ セスから構成され、よって、目標プロセス・モデルの「知能」（ｉｎｔｅｌｌｉ ｇｅｎｃｅ）を自動的に増加させる技術と（ただし、以下の説明では、我々は、 この「知識」の語を、目標プロセス内での特定の場合における「正しさ」又は「 不確実性」という目標プロセスの要素の理解を記述するものとして用いる）、 III）上述の新たな理論に基づく技術であって、解析ツールが解析の適切な目 標 に関して、すなわち、適切なプログラム・ステートメントと適切なシステムの動 作（ふるまい、ｂｅｈａｖｉｏｒ）とに関して、適切な場所と時刻で自動的に開 始されることを可能にする、ユーザと目標ソフトウェアとの間の高レベルインタ ーフェースを可能にする技術と、を欠いていた。 自動解析は、コントロール・ブレークをどの位置に設定すべきかを理解しよう とする認識上の試みの上には、構築できない。 我々は、上述の技術的なステップは、将来のオペレーティング・システムの不 可欠な部分であると考える。コンパイラの静的な構文解析と類似して、このオペ レーティング・システムは、目標システムの動作を、論理的な誤りの位置をます ます確実なレベルで特定できる程度まで、動的に解析できる。 コンパイラ診断には、異なる程度の不確実性のアナログが存在する。すなわち 、コンパイラは、文字ａの代わりに文字ｂがなければならないとはいわない。そ うではなく、特定のタイプの問題があるステートメント又はステートメント群の 特定の領域に存在すると、報告する。 コンパイラのこのような部分的に不確実な解析がなくでは、我々は、どのよう な相対的に複雑なコードの構文の誤りも扱うことができないだろう。 同じ自動化が、論理的誤りの解析の領域でも長く求められてきた。ＸＰＤマシ ンは、更にはるかに複雑で従来技術では自動化されていなかった領域、すなわち 、論理的誤りの位置とタイプとを特定する領域において、この種の自動化を提供 する。 以上で述べた技術的なステップは、プロセス・アルゴリズムを表す非常にジェ ネリックではあるが非常に厳密なモデルに基づいて構築されなければならなかっ た。このモデルは、任意の既存のソフトウェア・システムから取り出すことがで きた。 以下の説明では、ＸＰＤマシンの語を、次のプロセスの組み合わせとして理解 する。詳細は、後に更に詳細に述べる。すなわち、 ａ）伝統的なオブジェクト・コード実現（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ）に おけるＸＰＤモデルと目標プロセスとの「疑似パラレル」（ｐｓｅｕｄｏ ｐａ ｒａｌｌｅｌ）な（すなわち、「遅延シーケンシャル」（ｄｅｌａｙｅｄ ｓｅ ｑｕｅｎｔｉａｌ）又は「遅延パラレル」な）同期化された実行、又は、ＸＰＤ オブジェクト・コード実現における目標プロセスのオブジェクト・コードの要素 としてのＸＰＤモデルの実行と、 ｂ）システム入力及びシステム出力のプロセス同期化されたマップの構築と、 ｃ）１）原因の知識、すなわち、目標プロセスの要素の実行のイベントに対す る有効な関係とその正しさ、を作成し、２）この知識を目標プロセスの要素の間 に伝搬し、３）目標プロセスに関する集積された知識を用いて、誤り位置の領域 又はシステムの予測の変化の結果として修正されなければならない領域を定義す る、ＸＰＤ解析機関（ａｎａｌｙｔｉｃａｌ ｅｎｇｉｎｅ）を動作させること 、の組み合わせである。 ＸＰＤマシン技術の長所のエッセンスは、簡単には、次のように述べることが できる。 プログラムにおいて誤りの箇所を特定するためには、又は、一般的にそのプロ グラムを理解するためには、プログラマは、伝統的には、実質的な調査の作業を 行わなければならない。人的なエラーを引き起こす可能性がありしたがってマニ ュアルの解析に伴うエラーに起因する二次的な誤りを生じる潜在的な可能性を有 するのに加えて、このマニュアルのプログラム解析は、あまりに複雑すぎて実行 できないことが多い。 本発明では、この調査作業を行い、マニュアルの解析の大部分を自動化する。 ここでの解析は、正確さをもってなされ、目標となるプロセスの動作に関する知 識の集積に伴い、この正確さが増す。本発明の中核は、この知識を集積して用い ることである。本発明では、目標となるプロセスの内部のイベントとその効果と を調べる。 実質的な存在を有するものであるイベントが他のイベントによって生じる効果 であり原因まで追跡できる条件又は事件（ｏｃｃｕｒｒｅｎｃｅ）として理解さ れる場合には、本発明は、基本プロセスのイベントの効果、すなわち、目標プロ セスにおける原因・効果（ｃａｕｓｅ−ｅｆｆｅｃｔ）の関係を調べることによ り動作するといえる。 目標プロセスを伝統的な方法で解析する、すなわち、前進しながら目標プロセ スをトレースする代わりに、本発明では、効果から逆に戻ることによって自動的 に解析を行う。 このアプローチは、人間の精神がなれているそのものである。すなわち、我々 は、我々を取り巻く効果を目にして、それらの効果の原因となっている内的なプ ロセスの理解を構築しようとする、すなわち、効果から原因に向かって逆向きに 戻ることによって原因・効果の理解を構築しようとする。 コンピュータ・プログラムが人間によって構築されているという事実は、我々 がそれを理解しなければならない方法、すなわち、基本ステップから単純に前に 進みながらトレースするのではなく効果から解析を開始するという方法を変更す べきではない。 目標プロセスの結果は目標プロセスの最終的な効果なのだから、これらの最終 的な効果をその原因までトレースできるということは、プログラム解析がプログ ラムの出力から始まる場所である元のインターフェースを可能にする。 本発明においては、予測される結果を生じる効果が、中間的な効果を正当化す る、又は、予測される結果を生じるイベントが、中間的なイベントを正当化する 。 これによって、そもそもがその定義も相対的ではある非最適な計算を可能にす るが、しかし、計算に対する基本的な原理に承認（効果承認）を与え、したがっ て、既存のプロセスに基づく前方方向へのプログラム開発に基本的な原理をもた らす。 ＸＰＤマシンは、ＸＰＤ解析機関内に生じるプロセスを介して、背景にある目 標プログラム内の効果を調べる。 「解析機関」（ａｎａｌｙｔｉｃａｌ ｅｎｇｉｎｅ）の語は、およそ１５０ 年前にチャールズ・バベッジ（Ｃｈａｒｌｅｓ Ｂａｂｂａｇｅ）によって作り 出され、彼が取り組んでいた機械式のコンピュータの最初の基本的概念を指すも のとされた。人的なコンピュータを機械式のコンピュータによって置き換えよう とする彼のアイデアは、人的なコンピュータによって生じるエラーについての彼 の強迫観念からきていた。 ＸＰＤマシンに関する本発明は、現代的なコンピュータに対する人的なプログ ラミングにおけるエラーを触媒として引き起こされたものである。 ＸＰＤ解析機関は、目標プロセスの動作に関する経験を集積することによって 、何が正しい動作であったのか、何が間違った動作であったのか、どの動作が解 析すべきではなかったのか、どの動作が間違って解析されたのか、を学習する。 このプロセスは、人間の精神が連想（ａｓｓｏｃｉａｔｉｏｎｓ）や意識下の 行動様式（ｒｅｆｌｅｘｅｓ）を構築していく認知的な学習プロセスと比較でき るであろう。 この認知的な学習において、我々を正しい結果に導くステップが、我々の学習 プロセスにおいて特別の地位を達成する。これらのステップは、後に予測されな い結果が生じる場合でも、最も疑い得ないものである。解析によってこれらの既 に構築された行動様式又は連想を元に戻す（ｕｎｄｏ）ことを強制されるのなら ば、それは、通常は、幾分の痛みを伴うプロセスであり、我々に、最初に連想や 行動様式を構築した当初の結果を再び解析することを強制している。 ＸＰＤ解析機関においては、この反学習（ｕｎｌｅａｒｎｉｎｇ）は、「知識 を喪失すること」によって表され、システムの結果においてそれまでは正しいと 理解されていた誤動作が認識された場合に、生じる。 ＸＰＤマシンの学習プロセスは、目標プロセスの前方向の実行によって伝搬さ れ、正しいものとして受け入れられている（予測されている）システムの結果を 集積することによって付勢される。したがって、解析の結果は、人的なファクタ に依存し、しかし、人間の活動、したがって人的なエラーは、最終的な結果すな わち、可視的な結果と解析することに限定される。 この可撓性は、システム仕様の変更に対する異なる解析結果を許容し、また、 既存のプロセスに基づいてプログラム開発を前進させるためには、実際に、必要 である。ＸＰＤ解析機関は、それまでには見逃されていた誤動作が見つかったり 、システムの予測（仕様）が変更された場合には、従前の解析の一部を元に戻す ことを許容する。 ＸＰＤ解析機関の当初の特徴の１つは、プログラムの結果（効果）の集積を通 して、目標プロセスの時間が増加するにつれて可視的となるプログラム結果の計 算における、潜在的な誤りの位置に関する不確実性の領域を最小化することにあ る。 解析の精度の程度は、集積されたシステムの結果によって測定される上述のプ ロセス時間の座標系の中の、最初に認識された誤作動の位置、又は、仕様の変更 に依存する。 発明の概要 本発明の目的は、目標となるプロセスの中における誤りの位置又は要求される 修正の場所に関する不確実性を最小化する方法を提供することである、ここで、 誤りとは、誤作動（予期されない結果）の原因であり、コンパイラによっては発 見されず、修正は、新たな結果の予測に従わなければならない。 これは、目標プロセスの機能の認知的（ｃｏｇｎｉｔｉｖｅ）な理解に類似の プロセスを総合することによって達成される。 第１に、目標プロセスのモデルが、非常に厳密なしかし汎用的な規則による静 的な解析に基づいて構築され、その動的な解析の間の目標プロセスに関する知識 の更なる集積のための基礎を作成する。このモデルでは、すべての関係のある（ ｒｅｌｅｖａｎｔ）プログラム・ステートメントは、二次元のＸＰＤアルゴリズ ム空間の中にそれ自体の特定の位置を有する。 結果的な構成の厳密性により、連続的なビジョンを構築することを通じて目標 プロセスの任意の２つの要素の間のアクセス可能性（経路の存在）が容易に評価 できる。アクセス可能性は、潜在的な依存性を定める。ステートメント（ｂ）が ステートメント（ａ）からアクセス可能である場合には、そのときに限り、（ａ ）の正しさが（ｂ）の動作に影響を与え得る。 たとえば、要素のアクセス可能性の自動的な評価の１つの重要な結果は、終了 不可能（ｕｎ−ｔｅｒｍｉｎａｂｌｅ）なプロセス構成、すなわち、データに独 立のエンドレス・ループを確実に識別できることである。 目標プロセスのモデルを構築する際に、本発明は、目標プロセスのアルゴリズ ムの制御成分を抽出して、そのプロセスの制御構造を表す形式（アルゴリズムの ＸＰＤフレーム）を作る。アルゴリズムのＸＰＤフレームは、任意のプロセスの 制御構造を表すのに必要十分な、厳密で単一定義の形式である。 第２に、特定の動的な情報がすべての関係のある基本プロセス（プログラム・ ステートメント）に対して集積されることを可能にするメカニズムが導入される 。この情報は、基本プロセスの機能の理解に関係し、目標プロセスのモデルのこ れに先立つ静的な解析の間に構築されたものに付属される。我々は、更に、この 特定の情報を、基本プロセス知識と呼ぶ。上述のメカニズムは、原因・効果の関 係と、プロセスの要素の正しさに関する相対的で時間に依存する測定についての 情報が構築されることを可能にする。 したがって、本発明の更なる目的は、本発明で定義されるプロセス空間とプロ セス時間（プロセス・アドレスと局所的時間）との座標系と、本発明で定義され るプロセスの正しさと不確実性との測度とにおいて、プロセスのステップを、正 しい又は不確実である、と定義するメカニズムを提供することである。上述の基 本プロセスの知識は、連続的に集積され、異なるプロセス要素の間で伝搬される 。目標プロセスの誤動作や予測されたのとは異なる結果が認識されるときには、 この知識が、目標プロセスにおいて必要とされる修正の位置を識別するために用 いられる。 本発明の別の目的は、プロセスの正しい機能の知識ベースを作成することによ って、目標プロセスの正しい要素を、目標プロセスのメンテナンスの間の改変か ら保護する手段を提供することである。 本発明の更に別の目的は、ＸＰＤマシンを介して、ユーザと目標プロセスに関 する集積された知識との間の高レベルのインターフェースのためのメカニズムを 導入することである。 本発明の更に別の目的は、その診断を容易にするために、目標プロセスの動作 のマルチメディアでの提示を与えることである。 本発明の更に別の目的は、目標プロセスのオブジェクト・コードの新たな形式 であるＸＰＤオブジェクト・コードと、その実行方法とを導入することである。 ＸＰＤオブジェクト・コードは、静的及び動的なプログラム解析と、プログラム のメンテナンスとに、より適している。ＸＰＤオブジェクト・コードによれば、 プロセスを修正するために通常は行われなければならない目標プロセスのコード の伝統的な再コンパイルと再リンキングとを時として不要にする。 本発明のこれらの及びこれ以外の目的は、目標プロセスのソース・コードから モデルを構築するのに必要であり目標プロセスのアルゴリズムを表現している目 標プロセスの静的情報に対して特定のものを抽出し、目標プロセスのおける原因 ・結果関係の理解を構築するメカニズムを導入し、目標プロセスにおいて基本プ ロセスの時間依存的であり相対的が正しい・不確実な属性を構築するメカニズム を導入し、この目標プロセス実行の間に目標プロセスの要素の間の正しい・不確 実な知識を伝搬することによって目標プロセスのモデルの知能レベルを自動的に 増加させることによって、達成される。本発明は、また、以下の説明を参照する ことによって更に良く理解され得る他の特徴も備えている。 図面の簡単な説明 図１は、サンプルの目標プロセスの流れ図である。 図２は、図１のサンプルの目標プロセスのアルゴリズムのＸＰＤフレームであ る。 図３は、複雑な論理条件がどのようにして２つ又はそれより多くの縮小（ｒｅ ｄｕｃｅｄ）論理条件に縮小されるかを示す。 図４は、図１のサンプルの目標プロセスの縮小流れ図を表す。 図５（Ａ）は、図１のサンプルの目標プロセスのＸＰＤグラフであり、図５（ Ｂ）は、図５（Ａ）のＸＰＤグラフの対応する要素に指定されたバイナリ・アド レスを表す。 図６は、ＩＦ−ＴＨＥＮ−ＥＬＳＥ型の構成がＸＰＤフレームやＸＰＤグラフ においてどのように表されるかを示す。 図７は、ＸＰＤモデル、ＸＰＤリポジトリ、及びＸＰＤソース・コードを構築 するステップを示す。 図８は、ＸＰＤマシンの動作の主な成分を示す。 図９は、終了アクセス・インジケータを定義し、別のサンプル・プロセスの流 れ図の例に関して連続的なビジョンを作ることによって目標プロセスの任意の２ つの要素の間のアクセス可能性を定義するメカニズムを示す。 図１０は、プロセス・ターミナルの伝搬ビジョン・ポイント（ＰＶＰ）を定義 するメカニズムを示す。 図１１は、目標プロセス実現の間に潜在的に導入される誤動作の異なるソース を示す。 図１２は、３つのタイプの目標プロセス誤動作を示す図である。 図１３は、ＸＰＤマシンが、どのようにして目標プロセスの前方向への実行の 間に誤り位置の不確実性の領域を最小化するかを説明する図である。 図１４は、どのように、イベント定義空間が構築されるかを示す。 図１５は、どのように、正しいアルゴリズム空間が伝搬されるかを示す。 図１６は、プロセス要素の正しさに関する知識が、どのように、特定のプロセ ス・アドレス（ＰＡ）に中で集積されているかを示す。 図１７は、先祖（ａｎｃｅｓｔｏｒ）イベントを定義するメカニズムを示す。 図１８（Ａ）は、ＸＰＤオブジェクト・コードを実行するプロセスを示し、図 １８（Ｂ）は、ＸＰＤオブジェクト・コードの２つの成分を示し、図１８（Ｃ） は、ＸＰＤモデルによって制御されつつあるＸＰＤリポジトリを解釈するプロセ スを示す。 図１９は、ＡＣＢ（解析された計算ベース）構成の実現を示す。 図２０は、図２１（Ａ）に提示されるサンプル・プロセスの、ＸＰＤグラフ（ 図２０Ａ）と、ＸＰＤリポジトリ（図２０Ｂ）である。 図２１は、サンプル・プロセス（図２１Ａ）と、そのＸソース（図２１Ｂ）で ある。 好適実施例の説明 以下の説明では、次の順序で、本発明の主要なステップについて述べる。 １）目標プロセスのアルゴリズムのＸＰＤフレーム構築 ２）目標プロセスのＸＰＤグラフと縮小流れ図との構築 ３）目標プロセスにおける目標プロセスの正しさと不確実性とを、誤り又はシ ステムからの要求の変更に起因する修正箇所として評価する、ＸＰＤマシンの原 理の定義 ４）目標プロセスのＸＰＤマシン原理の定義、知識伝搬（知識帰納） ５）目標プロセスのＸＰＤモデルの構築、解析計算ベース（ＡＣＢ）の定義、 目標プロセスのＸＰＤリポジトリの構築 ６）Ｘソース・コードの構築、目標プロセスの動作履歴（ｂｅｈａｖｉｏｒ ｈｉｓｔｏｒｙ）を把握する最小のオーバヘッド編成、増分システム出力プロセ ス同期式（ＩＳＯＰＳ）マップによるユーザ・ＸＰＤマシン目標プロセス・イン ターフェースの構築、システム入力プロセス同期式（ＳＩＰＳ）マップ ７）目標プロセス、そのＸＰＤマシン、ＸＰＤリポジトリ、及びＸソース・コ ードの例 ８）目標プロセス・モデルの疑似パラレル同期式実行、遅延シーケンシャル及 び遅延パラレル型のＸＰＤモデルの実行 ９）ＸＰＤ解析機関の実行、目標プロセスにおける原因・効果関係の解析計算 ベースの構築及び伝搬、知識帰納 １０）誤り位置又は修正箇所の領域を一定に減少する不確実性をもって局所化 するための、ＩＳＯＰＳマップを参照することによる、ＸＰＤ解析機関の知識演 繹プロセスを付勢 １１）ＸＰＤグラフとＸＰＤリポジトリとの解釈 １２）ＸＰＤオブジェクト・コードとその実行、ＸＰＤモデルの目標プロセス のオブジェクト・コードの一部としての実行、 １３）ＸＰＤオブジェクト・コードの再コンパイル及び再リンケージ １４）テスト及び製造の全段階におけるＸＰＤマシン・プロセスの解釈 １５）結果志向型のプログラミング（ＲＯＰ） １６）プログラム・ステトスコープの解釈 １）目標プロセスのアルゴリズムのＸＰＤフレーム構築 以下の説明では、ＸＰＤモデルがどのようにしてＸＰＤグラフから構築される かを示す。目標プロセスのＸＰＤグラフの構成を先に述べて、次に、そのプロセ スのアルゴリズムのＸＰＤフレームを構築する。 アルゴリズムのフレームを構築するステップを全体としてバイパスしてしまう こともできるが、このフレームとＸＰＤグラフとが共有する幾つかの重要な属性 を示す便宜のために、このステップについて説明する。更に、アルゴリズムのＸ ＰＤフレームは、常に、目標プロセス制御構造の非常にコンパクトで厳密な（単 一定義）表現として、用いることができる。 以下の説明は、複数の定義と公理（ａｘｉｏｍｓ）とを含む。これらは、ＸＰ Ｄマシンがその上で動作するオブジェクトや用語の幾つかは、これまでに定義さ れていないために、必要である。 次のものは、ＸＰＤフレーム、ＸＰＤグラフ、及びＸＰＤモデルがその上で動 作するオブジェクトの集合（組、ｓｅｔ）である。すなわち、 ｛［，Ａ，Ｘ，Ｌ，Ｄ，Ｅ，Ｗ，Ｎ，＝，Ｒ，＊，Ｃ，＋，Ｓ，／，！，(，)， Ｖ，ｉ｝であり、ここで、 ［は、プロセス・エントリである。 Ａは、算術又は割り当てステートメントである。 Ｘは、グラフィクス・ライブラリ・サブルーチン又は関数以外の、関数又はサ ブルーチン呼び出しステートメントである。例として、ＣＡＬＬ、ＰＥＲＦＯＲ Ｍがある。 Ｌは、ＩＦステートメントである。（１つの入力、２つの出力） Ｄは、ループ・ステートメントである。例として、ＤＯ、ＦＯＲ、ＷＨＩＬＥ がある。 Ｅは、入力ステートメントである。例として、ＲＥＡＤがある。 Ｗは、出力ステートメント又はグラフィクス・ライブラリ・サブルーチン又は 関数である。例として、ＷＲＩＴＥ（）、ＣＡＬＬ ＭＯＶＥＴＯ（ｘ，ｙ，ｘ ｙ）がある。ただし、｛ｘ，ｙ｝は、スクリーンの座標系である。 Ｎは、ヌル（空、ｎｕｌｌ）ステートメントである。例として、ＣＯＮＴＩＮ ＵＥがある。 ＝は、ＳＴＯＰステートメントである。 Ｒは、ＲＥＴＵＲＮステートメントである。 ＊は、ＧＯ ＴＯステートメントである。 Ｃは、ループ・ターミナル・ステートメント、又は、仮定されている場合には 、その位置である。例として、ＣＯＮＴＩＮＵＥ、ＥＮＤＤＯがある。 ＋は、割り当てられたＧＯ ＴＯステートメントである。 Ｓは、ＡＳＳＩＧＮ（ＡＬＴＥＲ）ステートメントである。 ／は、ＧＯ ＴＯのエントリ、又は、その位置である。例として、何らかのＧ Ｏ ＴＯによって参照されたラベルの位置又はパラグラフ・ネームがある。 ！は、ＥＮＤＩＦ、又は、仮定されている場合には、その位置である。 （は、ＬＣフィールドのオープンである。 ）は、ＬＣフィールドのクローズである。 Ｖは、ＥＬＳＥである。 ｉは、（と）と以外のＸＰＤオブジェクトに対するそのオブジェクト・クラス 内のプロセス要素のインデックスであり、ＸＰＤオブジェクトである（と）とに 対するＬＣフィールドのレベルである。 以下の説明では、我々は、単一のモジュールであるコンピュータ・プログラム ・プロセスについて述べる。ただし、我々の結果は、複数のプログラムのシステ ムを表すプロセスにも容易に拡張できる。 このモジュールは、メイン・プログラム、又は、１つのエントリ・ポイントを 有する単一のサブプログラム（すなわち、サブルーチン、関数、又はパラグラフ ）であると理解する。以下に述べる例では１つの終了（ｅｘｉｔ）を有するプロ グラムを提示するが、ここで説明する実現方法（ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ）は、複数の終了を有するモジュールにも同じように適用できる。複数の終了を 有するモジュールに対するＸＰＤマシンの実現方法は、ここで説明する単一エン トリ・モジュールに対するＸＰＤマシンの実現方法から容易に得られる。図２は 、図１の流れ図によって図解されたサンプルの目標プロセスのＸＰＤフレームを 表す。 定義Ｆ１：縮小論理条件（Ｒｅｄｕｃｅｄ Ｌｏｇｉｃ Ｃｏｎｄｉｔｉｏｎ ）（ＬＣ）とは、そのブール（０又は１）解（Ｂｏｏｌｅａｎ ｓｏｌｕｔｉｏ ｎ）によってプロセスの将来の方向を決定する、１つの制御入力と２つの制御出 力とを有するプロセス要素である。 ＸＰＤオブジェクト集合では、ＬＣは、Ｌ又はＤのオブジェクトによって表さ れる。負の解を０解又はロー・ポテンシャルの解と呼び、正の解を１解又はハイ ・ポテンシャルの解と呼ぶ。 目標プロセスが２つよりも多くの出力を有する制御要素を含むときには、それ らの制御要素は、ＸＰＤフレーム及びＸＰＤグラフにおいて、その表現の間に、 ２つ又はそれより多くのＬＣに自動的に縮小される。図３を参照のこと。結果的 なＬＣの数は、制御出力から１を引いた数に等しいが、これは、各ＬＣが制御出 力の数を１だけ増加させているからである。 定義Ｆ２：メイン・ブランチ（Ｍａｉｎ Ｂｒａｎｃｈ）とは、すべての出会 った（ｍｅｔ）論理条件がそのロー・ポテンシャルを通過したときに、メイン・ ブランチの原点からプロセス・ターミナルへの実行の方向でのプロセスの通過を 表すブランチである。 メイン・ブランチの原点には、２つの種類がある。すなわち、 １）エントリ・メイン・ブランチを開始するプロセス・エントリ（図１及び図 ４において、ＳＴＡＲＴと表されている）と、 ２）ＬＣのハイ・ポテンシャル解である。 定義Ｆ３：プロセス・ターミナル（ｐｒｏｃｅｓｓ ｔｅｒｍｉｎａｌ）とは 、ＸＰＤオブジェクト集合の次のオブジェクトである。すなわち、 ＧＯ ＴＯ：これは、ＸＰＤフレームの表現では、＊と＋とである。 ループ・ターミナル：これは、ＸＰＤフレームの表現では、Ｃである。 ＲＥＴＵＲＮ：これは、ＸＰＤフレームの表現では、Ｒである。 ＳＴＯＰ：これは、ＸＰＤフレームの表現では、＝である。 プロセス・ターミナルには、２つの種類がある。すなわち、 定義Ｆ４：出口ターミナル（ｅｘｉｔ ｔｅｒｍｉｎａｌ）とは、プロセスか らの出口を結果的に生じるターミナル｛Ｒ，＝｝である。 定義Ｆ５：リワインド・ターミナル（ｒｅｗｉｎｄ ｔｅｒｍｉｎａｌ）とは 、プロセスを、同じメイン・ブランチ、又は、現在のメイン・ブランチから左側 のＸＰＤグラフにおいて定義されたメイン・ブランチにおいて既に定義されてい る要素に巻戻す（リワインドする）ターミナル｛＊，＋，Ｃ｝である。 したがって、メイン・ブランチの長さは、そのターミナルの位置に依存し、よ って、メイン・ブランチの定義の順序に依存する。 ＸＰＤフレーム及びＸＰＤグラフにおいてメイン・ブランチを提示する順序は 、「次に最低のポテンシャル」（Ｎｅｘｔ Ｌｏｗｅｓｔ Ｐｏｔｅｎｔｉａｌ ）の原理によって説明される。 アルゴリズムを解析する（ｐａｒｓｅ）「次に最低のポテンシャル」の順序と は、 ステップ１：ＳＴＡＲＴに位置する。 ステップ２：出会ったＬＣのロー・ポテンシャル解（０解）を通って、既に通 過したプロセス要素に至るまで、又は、ＥＸＩＴまで、プロセスの解析（ｐａｒ ｓｉｎｇ）を続ける。 ステップ３：そのロー・ポテンシャルを直前に通過したＬＣまで戻り、存在す る場合には、そのハイ・ポテンシャル解に位置する。すべてのＬＣがそのハイ・ ポテンシャル解を通って通過されている場合には、目標プロセスのアルゴリズム の解析は完了である。 ステップ１の各実行は、メイン・ブランチを構築し、これは、出口ターミナル 又はリワインド・ターミナルによって終了する。したがって、前向きに分岐（ｂ ｒａｎｃｈ）しているこれらのＧＯ ＴＯ構成は、ＸＰＤフレーム及びＸＰＤグ ラフから除去される。 公理：ｎの縮小されたＬＣを有するプロセスは、（ｎ＋１）のターミナルと、 （ｎ＋１）のメイン・ブランチとを含み、各メイン・ブランチは、そのターミナ ルによって十分に識別される。 公理：（ｎ＋１）のメイン・ブランチの全体は、プロセスのすべての要素を表 すのに必要かつ十分である。 解説：ＬＣのない、すなわち、条件制御のないプロセスには、ただ１つのブラ ンチ、すなわち、エントリ・メイン・ブランチだけしかない。各ＬＣは、そのハ イ・ポテンシャルを通過する新たなメイン・ブランチを開くことによって、メイ ン・ブランチの数を１だけ増加させる。 各メイン・ブランチとそのターミナルとは、そのｂ座標（図５Ａ）によって、 ＸＰＤグラフにおいては、同一視される。プロセス・アルゴリズムのフレームは 、次のブール代数表現に基づいて構築される。すなわち、 ＬＡ Ｖ ！ＬＢ これは、「ＬであればＡをせよ。そうでなければ（Ｌでなければ）Ｂをせよ。」 と読む。ＸＰＤフレームでは、我々は、カッコ（と）とを、サイクル｛＊，＋， Ｃ｝と出口｛Ｒ，＝｝とをイネーブルする論理レベルとターミナルとの範囲を表 すものとして導入した。我々は、また、！Ｌを省略したが、これは、特定のＬに 属するＥＬＳＥのサインであるＶの後には「Ｌでない」が続くのは明らかだから である。よって、われわれは、 （ｉＬＡＶＢ）ｉ という形式を得るが、ここでは、Ａ及びＢは、それぞれが、ＬＣＬのＯサブフィ ールドと１サブフィールドとであり、ｉは、ＬＣフィールドのレベルを表す。更 に定義を続ける。 定義Ｆ６：ｔパス（ｔ−ｐａｓｓ）とは、プロセス・エントリからプロセス・ ターミナルへの通過である。 公理：任意のプロセスには、（ｎ＋１）のｔパスがある。ここで、ｎは、この プロセスにおけるＬＣの数である。それぞれのｔパスは、そのターミナルによっ て、一意的に識別される（図５Ａ）。 定義Ｆ７：ＬＣのブランチとは、そのＬＣを通過し、そのＬＣに続くｔパスの 一部である。 各ＬＣは、１又は複数の０ブランチと、１又は複数の１ブランチとを有してい る。図１では、ＬＣＬ１は、ｄとｈで表される２つの１ブランチを有する。 定義Ｆ８：ＬＣの０サブフィールドとは、そのＬＣの０ブランチ上に位置する すべてのプロセス要素の組み合わせである。 定義Ｆ９：ＬＣの１サブフィールドとは、そのＬＣの１ブランチ上に位置する すべてのプロセス要素の組み合わせである。 定義Ｆ１０：ＬＣのフィールドとは、そのＬＣの０サブフィールドと１サブフ ィールドとの組み合わせである。 定義Ｆ１１：ＬＣフィールドのレベル（論理レベル）とは、そのＬＣを通過す るＴパスにおける、そのＬＣの次数（オーダー）である。 たとえば、図１では、次の論理レベルが存在する。すなわち、Ｌ１は、論理レ ベル１を開く。Ｌ２及びＬ３は、論理レベル２を開く。Ｄ１は、論理レベル３を 開く。 図１では、メイン・ブランチは、ａ、ｂ、ｃ、ｄ、ｅの線によって示されてい る。これらは、それぞれ図５Ａではｂ座標である１、２、３、４、５に見られる ターミナルによって識別される。ＬＣＬ１の０フィールドは、図１では、破線ｆ によって示され、ＬＣＬ１の１フィールドは、破線ｇによって示されている。 ＸＰＤフレームは、メイン・ブランチを、対応するレベルで提示されるＬＣと 共に、特別の順序で表すことによって構築される。図２を参照すると、ＸＰＤフ レームは、複数のレベルのカッコを含む代数的な表現の形式で構築されている。 すなわち、 （．．（．．（．．）．．）．．（．．）．．） １ ２ ３ ３ ２ ２ ２ １ である。 代数的表現の規則は、外側（より低いレベル）のカッコは、内側（より高いレ ベル）のカッコが閉じる前には閉じることができない、というものである。 ＸＰＤフレームでは、カッコは、論理レベルを表す。同じ規則が適用される。 すなわち、より低い（外側の）レベルの論理フィールドは、より高い（内側の） レベルの論理フィールドが閉じる前には閉じることができない。 定義Ｆ１２：ＬＣのフィールドが開かれる、とは、そのフィールドをフレーム において表現し始めるときである。 定義Ｆ１３：ＬＣのフィールドが閉じられる、とは、それがフレームにおいて 完全に表現されているときである。 定義Ｆ１４：ＬＣのアクティブ・フィールドとは、ＬＣの最も高いまだ開いて いるフィールドである。 定義Ｆ１５：プロセス・セグメントとは、プロセス・エントリ、プロセス・タ ーミナル、及びＬＣの間に位置するメイン・ブランチの一部である。 プロセス・ターミナルとＬＣとが、プロセス・セグメントを終了させ、その終 了させるセグメントに属する。プロセス・セグメントのターミナルでありながら 、各ＬＣは、同時に、２つの他のセグメントを有する。すなわち、（その０解を 通る）ＬＣの負のセグメントと、（その１解を通る）ＬＣの正のセグメントとで ある。 セグメントは、２つの属性、すなわち、１）論理レベルと、２）バイナリ・ア ドレス（後に説明する）とを有している。 定義Ｆ１６：プロセス・セグメントの論理レベルとは、そのセグメントが属す るＬＣの論理レベルに等しい。 定義Ｆ１７：エントリ・セグメントとは、そのプロセス・エントリによって所 有されるプロセス・セグメントである。 エントリ・セグメントの論理レベルは、０である。（２ｎ＋１）のプロセス・ セグメントがあり、ここで、ｎは、プロセスにおけるＬＣの数である。すなわち 、各ＬＣに対して２つのセグメントと、１つのエントリ・セグメントとがある。 たとえば、図１では、目標プロセスは、４つのＬＣと９つのプロセス・セグメン トとを含む。 目標プロセスのＸＰＤフレームとＸＰＤグラフとに対するプロセス・セグメン トのラベル付けは、ＸＰＤフレーム又はＸＰＤグラフを構築する順序でなされる 。 図１に提示されているサンプルの目標プロセスでは、次のようになる。 セグメント ＸＰＤオブジェクト集合によって表されたプロセス要素 １： Ａ１／１ Ａ２ Ｌ１ ２： ／２ Ａ３ Ｌ２ ３： ＊１ ４： Ａ４ Ｘ１ Ｄ１ ５： Ａ５ Ｃ１ ６： Ａ６ Ｗ１ ＊２ ７： Ｗ２ Ｅ１ Ｌ３ ８： Ａ７ ＝ ９： Ａ８ ＊１ 図２は、図１の流れ図によって表されたプロセスのＸＰＤフレームである。先 に定義された、次に最も低いポテンシャルのオーダーに従って、我々は、エント リ・メイン・ブランチから、アルゴリズムのフレームを構築し始める。 ｛＊，＋，Ｃ，Ｒ．＝｝のオブジェクトの中の任意のものによって終了された 際には、そのロー・ポテンシャル解（ＮＯ）を通過した直前のＬＣに戻り、その ＬＣのハイ・ポテンシャル解（ＹＥＳ）に属するメイン・ブランチを通過し始め る。このようにして、我々は、結果的に、プロセスのすべての（ｎ＋１）のメイ ン・ブランチを表す。ここで、ｎは、このプロセスの中のＬＣの数である。 図６は、ＸＰＤフレームとＸＰＤグラフにおける、ＩＦ−ＴＨＥＮ−ＥＬＳＥ 構成の提示を示している。Ｌ１（Ｐ３）の１フィールドは、０フィールドである Ｌ１（Ｐ２、Ｐ４）が閉じられた（すなわち、完全に表された）後でだけ表され る。 目標プロセスのアルゴリズムを抽出して、「次に最も低いポテンシャル」の規 則にによって構築された単一定義の汎用形式であるアルゴリズムのＸＰＤフレー ムにする方法を次に述べる。 ステップ１：０をアクティブな論理レベルに割り当てる。プロセス・エントリ に上におく。 ステップ２：メイン・ブランチを通過する。それぞれの通過した実行可能な要 素に、１だけ増加した対応するインデックスを有するＸＰＤのオブジェクト集合 から成る名前が割り当てられる。たとえば、Ａ１、Ａ２、Ｌ１、Ａ３、Ｌ２、＊ １は、エントリ・メイン・ブランチを表す。ステートメントが、次に、割り当て られた名前によって、ＸＰＤプロセス・リポジトリ（図７及び図８）に記憶され る。ＬＣに現在の通過されたメイン・ブランチにおいて出会った場合には、その ロー・ポテンシャル解（ＮＯ）を通過する。ＬＣが次の論理フィールドを開き、 アクティブな論理レベルを１だけ増加させる。すべての通過されたＬＣは、フレ ームにおいては、対応するインデックスを有するサインＬ又はＤが続く開かれた 論理フィールドのレベルを表す整数を伴う開くカッコによって表される。すなわ ち、（ｉＬｊ又は（ｉＤｊである。 ステップ３：プロセス・ターミナルに出会ったときには、セグメントは終了す る。ターミナルがリワインド・ターミナル｛（＊，＋｝である場合には、エント リが既に存在しないのならば、エントリ／ｉが、１だけ増加したインデックス（ ｉ）を伴う制御リターンの位置に挿入される。リワインド・ターミナルに、エン トリ（ｉ）のインデックスが割り当てられる。 ステップ４：アクティブな論理レベルを検査する。ＩＦ（もし）アクティブな 論理レベルが０であれば、ＸＰＤフレームの構成は終了する。すなわち、ＳＴＯ Ｐである。ＥＬＳＥ（そうでなければ）、アクティブな論理レベルのサブフィー ルドは閉じたものとしてアナウンスされる。ＥＮＤＩＦとなる。 ステップ５：閉じたサブフィールドを調査する。ＩＦ（もし）閉じたサブフィ ールドが０サブフィールドである場合には、サインＶ（ＥＬＳＥ）がフレームに 置かれる。解析（パーシング）が、そのＬＣのメイン・ブランチを構築するため に対応するＬＣのハイ・ポテンシャル（１解）から再開される。そのレベルの１ サブフィールドが開いているとアナウンスされる。ステップ２へ、ＧＯ ＴＯと なる。ＥＬＳＥ（そうでなければ、すなわち、閉じたサブフィールドが１サブフ ィールドであったならば）、アクティブな論理フィールドが閉じたものとしてア ナウンスするが、その理由は、その０サブフィールドと１サブフィールドとの両 方共に閉じているからである。論理フィールドを閉じることは、閉じられた論理 フィールドのレベルを指定する整数と共に閉じるカッコによってフレームにおい て、記述される。たとえば、）ｉである。 アクティブな論理レベルは１だけ減少する。ちょうど閉じた論理フィールドで ある（ｉ．．．．）ｉは、対応するＬＣによって終了されたセグメントに対する ターミナルと考えられている。ＬＣのフィールドが閉じられたときには、対応す るセグメントは、終了したとアナウンスされる。ステップ５にＧＯ ＴＯとなる 。ＥＮＤＩＦである。 この前の例は、ＸＰＤフレーム構成（図２）では、より高い論理レベルのＬＣ のフィールドは、より低い論理レベルのＬＣのフィールドの中に存在していたこ とを示している。任意のプロセスにおいて、最大で、レベルＮの論理フィールド は、最大で、Ｆ個があり得る。ここで、Ｆは、２の（Ｎ−１）乗である。 ２）ターゲット・プロセスのＸＰＤグラフと縮小流れ図との構築 次に、ターゲット・プロセス（図１）のＸＰＤグラフ（図５Ａ）と縮小流れ図 （図４）との構築を説明する。 定義Ｇ１：縮小（ｒｅｄｕｃｅｄ）流れ図（図４）とは、流れ図の形式でのＸ ＰＤグラフの表現である。 このグラフでは、ＸＰＤグラフと同じ原理によって、同じ座標軸であるｋ及び ｂの上に構築されている。ＸＰＤグラフを構築するための規則を説明する次に示 すプロセスは、縮小流れ図の構築にも応用される。 この流れ図が「縮小」と称されるのは、制御の方向におけるすべての可能な変 化が、右側に１に縮小されているからである。すなわち、ＬＣのハイ・ポテンシ ャル解である。ロー・ポテンシャル解は、制御が落ちる（ｆａｌｌｉｎｇ）のを 継続させることによって、制御の方向を変更しない。ジャンプは、後ろ向き（上 向き及び左向き）にのみ許容され、｛ターミナル・そのリワインド・エントリ｝ という基準の対によって表現される。例をあげれば、図５Ａにおける｛＊１ ／ １｝又は｛＊ ／２｝又は｛Ｃ１ Ｄ１｝である。 定義Ｇ２：ＬＣの負の状態（０状態）とは、評価される場合に、ＬＣがその０ 解を結果として生じる状態である。 ＬＣの状態は、その評価に関係する変数の状態によって定義される。 定義Ｇ３：ＬＣの正の状態（１状態）とは、評価される場合に、ＬＣがその１ 解を結果として生じる状態である。 定義Ｇ４：バイナリ・アドレス（ＢＡ）とは、そのプロセス要素に至るｔパス におけるＬＣの解である１と０との組み合わせである。ここで、プロセス・エン トリには、１のバイナリ・アドレスが割り当てられる。 同じセグメントに属するプロセス要素のＢＡは、同じである。ＬＣの０セグメ ントのＢＡは、それに２を乗じることによりＬＣのバイナリ・アドレスから計算 される（すなわち、右側に０をつければよい）。ＬＣの１セグメントのＢＡは、 それに２を乗じ１を加えることによりＬＣのバイナリ・アドレスから計算される （すなわち、右側に１をつければよい）。図４での例をあげれば、Ｌ３のＢＡは １１であり、Ａ７のＢＡは１１０であり、Ａ８のＢＡは１１１である。 ＸＰＤグラフは、２つの方向にのみ構築される。ここでの実現方法では、ＸＰ Ｄグラフは、垂直方向には下向きに、水平方向には右向きに作られている。 メイン・ブランチは、垂直方向に下向きに方向付けられ、トラックが道に沿っ て位置するＬＣの中の１つの正の状態によって変更されプロセスがそれによって 移動するトラックを表している。 すべてのトラックは、そのｂ座標に沿って構築され、トラックは決して交差し ない。 ＬＣは、そのハイ・ポテンシャル解に沿って、制御を、そのＬＣの正の状態に 付随するｂ座標を有し現在のトラックから右側に位置する他のトラックに切り換 えるポテンシャルを有する。この切り換えは、ＸＰＤグラフでは、右方向の水平 線によって表される。 ＸＰＤグラフは、ＸＰＤフレームから、又は、目標プロセスを解析することに よって、のどちらかにより同じ原理によって構築される。このグラフは、Ｋ及び Ｂの２つの座標上に構築される、これらの座標は、（１，１）から（ＭＫ，ＮＢ ）まで増大する。ＭＫは、最大のＫであり、ＮＢは最大のＢである。（ＭＫ，Ｎ Ｂ）は、また、メイン・ブランチの数でもある。ＸＰＤフレームから出発するこ との便利な点は、メイン・ブランチの集合が既にそこではＶのサインによって分 離されているフレームの部分として定義されていることである。メイン・ブラン チは、既に、正しい順序でＸＰＤフレームにおいて提示されている。 次に、目標プロセスのアルゴリズムを、双方向に終了している（ｂｉ−ｄｉｒ ｅｃｔｅｄ ｔｅｒｍｉｎａｔｅｄ）ＸＰＤグラフに「次に最も低いポテンシャ ルの規則」によって、抽出する方法を説明する。図５Ａを参照のこと。 ステップ１：ＸＰＤグラフは、（１，１）という（ｋ，ｂ）座標を与えられて いるプロセス・エントリから開始する。プロセス・エントリには、バイナリ・ア ドレス１が割り当てられている。エントリ・メイン・ブランチが開始される。 ステップ２：メイン・ブランチの各要素を通過することは、ＸＰＤグラフ上で は、ｋ座標の増加と一定のｂ座標とによって表される。各要素には、それが属す るセグメントのＢＡが割り当てられている。ＸＰＤグラフがＸＰＤフレームから 作られるのでなければ、次の（ａ）及び（ｂ）が行われなければならない。すな わち、（ａ）プロセス要素には、ＸＰＤオブジェクト集合の対応するメンバーと １だけ増加したインデックスとから成る名前が割り当てられる。（ｂ）ステート メントが割り当てられてた名前でプロセス・リポジトリに記録される（図７）。 ステップ３：ＬＣは、メイン・ブランチを通過しているのに出会ったら、その ０解を通過する。 ステップ４：メイン・ブランチの構成は、プロセス・ターミナルによって停止 される。もし（ＩＦ）すべてのＬＣが既にその１解を通過していたら、その場合 には（ＴＨＥＮ）、ＸＰＤグラフが構築される。おわり（ＳＴＯＰ）。そうでな ければ（ＥＬＳＥ）、現在のｔパスをプロセス実行の方向に対して、その０解を 通過したＬＣに出会うまで再びトレースせよ。ＸＰＤグラフ座標におけるそのＬ Ｃのメイン・ブランチを開始し（ｎｅｘｔ＿ｋ，ｎｅｘｔ＿ｂ），ここで、ｎｅ ｘｔ＿ｋ＝（ＬＣのｋ）＋１であり、ｎｅｘｔ＿ｂは、次に利用可能なトラック （座標ｂ）である。ステップ２に進む（ＧＯ ＴＯ ｓｔｅｐ２）。終了（ＥＮ ＤＩＦ）。 ２つのＸＰＤグラフの次元ＮＢは、まさに、プログラムの複雑性の測度（ｃｏ ｍｐｌｅｘｉｔｙ ｍｅａｓｕｒｅｓ）の１つとして受け入れられたものである 。ＭｃＣａｂｅの理論である「複雑性の測度」は、ＩＥＥＥ Ｔｒａｎｓａｃｔ ｉｏｎｓ ｏｎ Ｓｏｆｔｗａｒｅ Ｅｎｇｉｎｅｅｒｉｎｇ，Ｖｏｌ．ＳＥ− ２，Ｎｏ．４，Ｄｅｃ．１９７６，ｐｐ．３０８−３２０において公刊されてい る。 「サイクロマティック（ｃｙｃｌｏｍａｔｉｃ）な複雑性」は、ＭｃＣａｂｅ によって、線形独立な経路の最大数として定義され、単一のエントリ及び出口に 対しては、フレームによって、Ｖ（Ｇ）＝ｅ−ｎ＋２が定義される。ここで、Ｖ （Ｇ）はサイクロマティックな複雑性であり、ｅはエッジの数であり、ｎはノー ドの数（エントリ・ノード＋出口ノード＋ブランチ・ノード）である。われわれ は、このフレームを、サイクロマティックな複雑性のＭｃＣａｂｅのフレームと 称する。 エッジは我々のセグメントであり、エッジの数は、ｅ＝２ｑ＋１であり、ここ で、ｑはＬＣの数であり、すなわち、プロセス・セグメントの我々の数である。 ブランチ・ノードは、我々のＬＣであり、ブランチ・ノードの数はｑである。 ここで、ｑはＬＣの数である。すると、サイクロマティックな複雑性のＭｃＣａ ｂｅのフレームによると、単一のエントリと単一の出口ノードは、 ｅ＝（２ｑ＋１） ｎ＝１＋１＋ｑ＝（ｑ＋２） Ｖ（Ｇ）＝（２ｑ＋１）−（ｑ＋２）＋２＝ｑ＋１ よって、ｑをＬＣの数として、Ｖ（Ｇ）＝ｑ＋１である。 このように、ＭｃＣａｂｅによって定義されたサイクロマティックな複雑性の 数は、我々のＬＣの数に１を加えたものであり、メイン・ブランチの数である我 々のＮＢに等しい。 これまでのフレームは、米国特許第４８５３８５１号（１９８９年）に記載さ れている。線形独立の経路の数に等しいサイクロマティック数は、プログラムの 流れ図の最も幅の広い箇所でカウントされた経路の数である。サイクロマティッ ク数の計算に基づくこのアプローチは、ＭｃＣａｂｅによっては、まだ、説明さ れていない。 ＸＰＤアルゴリズム空間（ＭＫ）の第２の次元は、同じように、アルゴリズム の複雑性を記述するのに用いられ得る。ＭＫは、プロセス・エントリからターミ ナルへの最も長い道を表し、したがって、最も長いｔパスにおける基本プロセス の数を表す。次元を伴う矩形の空間［ＭＫ，ＮＢ］は、目標プロセスのアルゴリ ズムの複雑性をよく示しているように見える。我々は、この空間を、目標プロセ スのアルゴリズム空間と呼ぶ。たとえば、図１からの例のアルゴリズム空間は、 ［１４×５］である。 図５Ａは、次にあげるＸＰＤグラフの有用な特性を示す。 １．すべての要素は、２つの座標（ｋ，ｂ）によって一意的にアドレス指定す ることができる。 ２．グラフは、２つだけの方向に構築される。ここでの実現方法の例では、下 向き及び右向きである。下降は、ＬＣのハイ・ポテンシャル解によって右側にシ フトされることによってのみ、中断され得る。 ３．出口ターミナル（ＳＴＯＰ又はＲＥＴＵＲＮ）でないプロセス・ターミナ ルは、プロセスをリワインド（元に戻す）ことができる。このリワインドは、後 ろ向き、すなわち、上方向及び左方向にだけ許される。この理由は、前方向への ジャンプは、メイン・ブランチの定義により、ＸＰＤフレームとＸＰＤグラフと の構成の間は除去されるからである。 ４．すべてのセグメントには、目標プロセスにおいてそのセグメントの論理的 な位置を一意的に識別するバイナリ・アドレスが割り当てられている。 ５．ＸＰＤグラフは、プロセス要素の間のアクセス可能性の容易な判断を可能 にする。 定義Ｇ５：要素ｓ２は要素ｓ１からアクセス可能であるとは、ｓ１からｓ２へ の経路が存在する場合である。すなわち、何らかの入力データの組み合わせにつ いて、ｓ２がｓ１の実行の後にいくらか時間がたって実行され得る場合に、ｓ２ は、ｓ１からアクセス可能である。 ２つのプロセス要素の間のアクセス可能性の存在は、１つの要素の正しさが別 のプロセス要素のの結果に効果を有することの必要条件であり、すなわち、アク セス可能性は、２つのプロセス要素の間の原因・結果の関係のための必要条件で ある。 最近では、プログラムの依存性（従属性、ｄｅｐｅｎｄｅｎｃｙ）に関するい くつかの定義が、プログラムの内部での効果を調べるために提案されている。２ つの基本的なタイプのプログラム依存性は、「制御依存性」と「データ・フロー 依存性」とである。プログラム依存性は、ソフトウェアのテスト、デバッギング 、及びメンテナンスなどの重要な目的のために用いられる。最近まで、プログラ ム依存性のほとんどの提案された使用は、その使用の実現方法の困難さの観点か らみても、インフォーマルに正当化されているだけである。 Ａ．ＰｏｄｇｕｒｓｋｉとＬ．Ａ．Ｃｌａｒｋｅによる「プログラム依存性の フォーマルなモデルとソフトウェア・テスト、デバッギング、及びメンテナンス へのその適用」ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｆ Ｓｏｆｔｗａｒｅ Ｅｎｇｉｎｅｅｒｉｎｇ．１６，９，Ｓｅｐ．，１９９０，ｐｐ．９６５−９ ７９では、著者たちは、あるステートメントが別のステートメントの実行行動（ そして、したがって、結果）に潜在的に影響する必要条件である概念として、「 意味論的依存性（ｓｅｍａｎｔｉｃ ｄｅｐｅｎｄｅｎｃｅ）」の用語を提供し ている。しかし、この業績は、制御及びデータ・フロー依存性の異なる一般化は プログラムの誤りを自動的に識別するのに十分な情報ではなく、その理由は、そ の一般化は、プログラムの誤りを識別するのにどんな意味でも十分でない「意味 論的依存性」の存在を識別するのに十分ではないからである、ということを証明 している。 本発明で提示される要素のアクセス可能性の自動的な判断のための方法は、目 標プロセスの任意の２つの要素の間の意味論的な依存性の存在のための必要条件 を評価するための実際的な方法としての意味論的な依存性に関して定義され得る 。 換言すれば、提示されている方法は、 １．ｓ２の誤作動の原因であり得るステートメントｓ１と、 ２．ｓ１の修正によって影響されるステートメントｓ２と、 に対するポテンシャルを実際に評価する。 プロセス要素の間のアクセス可能性を判断できることによって、「確実な非終 端（終了）性（ｄｅｆｉｎｉｔｅ ｎｏｎ−ｔｅｒｍｉｎａｂｉｌｉｔｙ）」を 有するデータ独立なエンドレス・ループの存在に関する問題もまた、解かれる。 我々は、次に、図９の例に関して、ＸＰＤグラフのバイナリ・アドレス算術を用 いることにより、いかに容易に、ＳｉとＳｊとの間のアクセス可能性と、データ 独立なエンドレス・ループを作成するプロセスの部分との存在を定義できるかを 示す。 プログラムが終了（ターミネート）するかどうかの問題は解決不可能であるこ とが証明されていることが一般に受け入れられている。我々は、このプロセスの 終了可能性、すなわち、終了する能力の問題を、データ独立なエンドレス・ルー プと、データ従属（依存）のエンドレス・ループとの２つのカテゴリに分割する 。 データ独立なエンドレス・ループは、出口ターミナルへのアクセスを有しない プロセス要素から構成される。 データ従属のエンドレス・ループは、それに入ると、出口ターミナルへの制御 パスの不存在以外の理由で、制御が決して出口（ＳＴＯＰ又はＲＥＴＵＲＮ）に 到達しない構成を有している。この場合の理由は次のいずれかである。すなわち 、ａ）特定の制御パス上で、その制御パスを潜在的に変更するプログラム変数の 操作（ｍａｎｉｐｕｌａｔｉｏｎ）の不存在、又は、ｂ）ロー・ポテンシャル状 態とハイ・ポテンシャル状態との間で状態を変更することから、ＬＣの値を取っ てしまう方向へのこれらのプログラム変数の変更、のいずれかの理由による。 ａとｂとのいずれの場合でも、制御は、エンドレス・ループに陥り、同じシー ケンスの同じターミナルを、出口ターミナルに到達することができないままに、 通過する。 定義Ｇ６：＊ｂｎは、ｎに等しいｂ座標を有するターミナルを指す。この例と しては、図１０では、＊ｂ３は、ｂ＝３におけるＧＯ ＴＯターミナルを指し、 ＊ｂ５は、ｂ＝５における出口ターミナルを指す。 定義Ｇ７：ＭＢｎは、ｎに等しいｂ座標の上に構築されたメイン・ブランチを 指す。この例としては、図９のＭＢ３は、座標ｂ＝３上に構築されたメイン・ブ ランチを指す。 データ従属のエンドレス・ループの例をあげる。Ｌ２とＬ３とによって調べら れている値を再定義できる／１と＊１との間のパス上の要素がない場合には、タ ーミナル＊ｂは、Ｌ２とＬ３とが最初にそのロー・ポテンシャル解によって解消 されると直ちに、データ従属のエンドレス・ループを生じる。この理由は、Ｌ２ とＬ３との状態は、目標プロセスの前方向の実行の間は決して変化しないからで ある。 データ独立なエンドレス・ループの例をあげる。データ独立なエンドレス・ル ープ構成は、図９に、メイン・ブランチＭＢ２、ＭＢ３、ＭＢ４によって示され ている。Ｌ３が正には解かれない場合には、プロセスは、これらのブランチの中 にどのようなデータ操作ステートメントが符号化されている場合でも、無限ルー プの中に入る。 データ独立なエンドレス・ループ構成は、プロセスの非終了性（終了不可能性 、ｎｏｎ−ｔｅｒｍｉｎａｂｉｌｉｔｙ）に対するポテンシャルを示しているが 、必ずしも誤りのある構成ではない。その理由は、入力データがＬＣを無限ルー プの状態におくものでは決してないことも有り得るからである。 図９のエントリ／ｑは、どのターミナルにも対応せず、Ｌ２とＬ３とが／１か ら＊１への経路上でデータ従属ではない場合でも、プロセス制御を直接にＬ２の 前に戻すリワインド・ターミナル＊ｂ１を有するＬ２の負のサブフィールドにお けるＬ３の位置が必ずしも誤りではないという事実の例として示されているに過 ぎない。これは、Ｌ３がエントリ／ｑを通る制御を受け取ったとしても、制御を エントリ／１にリターンすることの結果としてＬ２が負に解かれエンドレス・ル ープを生成することには必ずしもならないからである。 データ独立なエンドレス・ループは、他方の側からは、プロセス構成における 確実な誤りである。 データ独立なエンドレス・ループの検出は、リワインド・ターミナルと出口タ ーミナルとの間のアクセス可能性を評価することによってなされる。同じプロセ スによれば、ＸＰＤグラフの任意の２つの要素（たとえば、図９のＳｉとＳｊ） の間のアクセス可能性の評価が可能になる。 ＸＰＤグラフによって、その要素の間のアクセス可能性の、次の３つのポテン シャルによって判断されるものとしての説明が可能になる。すなわち、メイン・ ブランチ内部での自由落下（フリーフォール）ポテンシャルと、ＬＣのシフト・ ポテンシャルと、ターミナルのリワインド・ポテンシャルと、の３つである。 自由落下ポテンシャルは、あるプロセス要素が別の要素の後でアクティブにな る際に、シーケンシャルな手順の性質によって決定される。 定義Ｇ８：ＬＣのシフト・ポテンシャルとは、ＬＣの正の解の結果として、ｂ 座標を増加させるＬＣのポテンシャルである。 例としては、図５ＡのＬＣでは、Ｌ２、Ｄ１、Ｄ３は、１のシフト・ポテンシ ャルを有し、Ｌ１は、３のシフト・ポテンシャルを有する。 定義Ｇ９：ターミナルのリワインド・ポテンシャルとは、ＢＡを減少させるタ ーミナルのポテンシャルである。 ＢＡの値は次のように決定される。ｂｂｂがビット・シーケンスであれば、ｂ ｂ０＞ｂｂｂ、ｂｂｂ１＞ｂｂｂ０、ｂｂｂ１＞ｂｂｂ００である。すなわち、 比較するために、ＢＡは、左側がジャスティファイされ、対応するビット位置が 、１＞０＞＿（ただし、＿は空の位置）である最初の不一致まで左から右に比較 される。ここで、左側のビット位置がより上位にある。図５における例としては 、１０＞１であるからＢＡ（Ｌ２）＞ＢＡ（Ｌ１）であり、１１＞１０であるか らＢＡ（Ｗ２）＞ＢＡ（Ａ３）であり、１１＞１０１０であるからＢＡ（Ｗ２） ＞ＢＡ（Ａ５）である。 定義Ｇ１０：セグメント・アドレス（ＳＡ）とは、｛ＢＡ，ｋ｝のカップル（ 対）である。ただしここで、ＢＡは、このセグメントのバイナリ・アドレスであ り、ｋは、このセグメントにおけるｋ座標である。 セグメント・アドレスは比較することができる。ＳＡ｛ＢＡ，ｋ｝を比較する 際には、ＢＡがより上位にある。すなわち、（１１，７）＞（１０，７）であり 、（１１，７）＞（１１，６）である。図９での例をあげると、／３のセグメン ト・アドレスは、｛１００１０，ｒｋ３｝である。 定義Ｇ１１：要素のビジョン（視野、ｖｉｓｉｏｎ）を定義する。要素ｓ２が 要素ｓ１のビジョン内にあるとは、ＳＡ（ｓ２）がＳＡ（ｓ１）のディセンデン ト（子孫）である場合に、ｓ２がｓ１から見られ、ｓ１がｓ２を見ることである 。 定義Ｇ１２：ＳＡ（ｓ２）がＳＡ（ｓ１）のディセンデント（子孫）であると は、ｓ２のＢＡがｓ１のＢＡから右側で２進数を連結（ｃｏｎｃａｔｅｎａｔｅ ）することによって構築される、又は、ＢＡ（ｓ１）がＢＡ（ｓ２）に等しく、 かつ、ｋ（ｓ２）がｋ（ｓ１）よりも大きいことである。 ｔパスの一部であるｓ１からｓ２への経路が存在するばあいには、ｓ２はｓ１ のビジョン内にある。ｔパスは、通過ターミナルをもっていないことを思い出し てほしい。 例をあげると、図４では、Ａ６は、Ａ３のビジョンの中にある。これは、１０ は、１０１１において左側がジャスティファイされているからである。Ａ６はＡ ３から見られているし、Ａ３はＡ６を見ている。 例をあげると、１０１は、左側がジャスティファイされた１０１１上にマップ され得る。、したがって、セグメント１０１１内の任意の要素である｛Ａ６，Ｗ １，＊ｂ３｝は、セグメント１０１の任意の要素は、制御１０１の任意の要素で ある｛Ａ４，Ｘ１，Ｄ１｝のビジョンの範囲内にある。 例をあげると、Ｘ１は、Ａ４のビジョンの範囲内にある。これは、これらのＢ Ａが共に、１０１であり、Ｘ１のｋがＡ４のｋよりも大きいからである。 定義Ｇ１３：リワインド・ターミナルのビジョンとは、リワインド・エントリ のビジョンである。出口ターミナルのビジョンは空である。 定義Ｇ１４：ｓ２がｓ１からアクセス可能であるとは、ｓ２がｓ１の「アクセ ス・フィールド」内に存在することである。 定義Ｇ１５：プロセス要素の「アクセス・フィールド」とは、そのプロセス要 素が連続的に所有するすべてのビジョンの組み合わせである。ここで、連続的と は、ビジョンがターミナル・ビジョンによって伝搬する意味である。 よって、プロセス要素のアクセス・フィールドとは、その要素のビジョンと、 それが見るターミナルのビジョンと、これらのターミナルから見られるターミナ ルのビジョンと、当の和である。 アクセス・フィールドの更に正確な定義は、以下で述べるが、定義Ｇ２２で与 えるプロセス・ターミナルの「伝搬ビジョン・ポイント」（ＰＶＰ）の定義を通 じて提供される。 図９は、ＸＰＤグラフの各ターミナルに対して構築される５つの属性を提示す る。あるターミナルの属性は、ターミナルのバイナリ・アドレス（ＢＡ）と、タ ーミナルのリワインド・バイナリ・アドレス（ＲＢＡ）と、ターミナルのｒｋと 、伝搬ビジョン・ポイント（ＰＶＰ）と、出口アクセス・インジケータ（ＥＡＩ ）と、である。 定義Ｇ１６：リワインド・バイナリ・アドレス（ＲＢＡ）とは、リワインド・ ターミナル・エントリのバイナリ・アドレスである。出口ターミナルのＲＢＡは 、０に等しい。ｒｋは、リワインド・ターミナル・エントリのｋ座標である。（ 出口ターミナルのｒｋは、０に等しい。 定義Ｇ１７：出口アクセス・インジケータ（ＥＡＩ）とは、閉じたターミナル に対しては０に設定され、開いたターミナルに対しては１に設定されるインジケ ータである。 定義Ｇ１８：開いたターミナルとは、出口ターミナル、又は、出口ターミナル の１つへのアクセスを有するリワインド・ターミナルである。 定義Ｇ１９：閉じたターミナルとは、出口ターミナルのどれにもアクセスをも たないリワインド・ターミナルである。 定義Ｇ２０：閉じた領域とは、閉じたターミナルによって定義される隣接する メイン・ブランチの組み合わせである。 プロセスの制御は、閉じた領域の内部にいったん入ると、脱出することはでき ない。すなわち、プロセスは、終了しない。図９での例をあげると、｛＊ｂ２， ＊ｂ３，＊ｂ４｝は、閉じた領域を定義する。 定義Ｇ２１：プロセス・ターミナルの伝搬ビジョン・ポイント（ＰＶＰ）の位 置は、図１０に記載されているものである。 図１０は、ターミナルのビジョン伝搬の原理を示しており、２つ又はそれより も多くのプロセス・ターミナルの伝搬ビジョン・ポイントを設定している。この 図においては、確立されたビジョンが破線で示され、ターミナルからそのリワイ ンド・エントリまでのパス実線で示されている。 図１０Ａを参照すると、上述の定義から、ターミナルのビジョンは、そのリワ インド・エントリのビジョンである。ターミナル＊ｎのリワインド・エントリ／ ｎが別のターミナル＊ｉを見ることができ、＊ｉのリワインド・エントリ／ｉが リワインド・エントリ／ｎを見ることができる場合には、＊ｎのビジョンが＊ｉ のビジョンによって伝搬され＊ｉのビジョンは両方のターミナル＊ｉ、＊ｎの伝 搬ビジョン・ポイントになるという。 あるターミナルの伝搬ビジョン・ポイントは、特定のリワインド・エントリの セグメント・アドレスによって表される／ ターミナルのビジョンが他のターミナルのビジョンによって伝搬されない場合 には、そのターミナルの伝搬ビジョン・ポイントはそれ自身のビジョン、すなわ ち、そのエントリのビジョンである。 ターミナル・ビジョンの伝搬の同じメカニズムが複数のターミナルの伝搬され たビジョンと別のターミナルのビジョンとの間でも有効である。 図１０Ａでは、ターミナル＊ｋのリワインド・エントリである／ｋは、ＰＶＰ ／ｉを有するターミナル＊ｎを見ることができる。したがって、＊ｋのＰＶＰは 、／ｉに伝搬される。たとえば、図９では、＊ｂ１のＰＶＰは／１であり、＊ｂ ２、＊ｂ３、＊ｂ４のＰＶＰは／２であり、＊ｂ５のＰＶＰは０すなわち空であ り、＊ｂ６のＰＶＰは／２であり、＊ｂ７のＰＶＰは／７である。 定義Ｇ２２：プロセス要素のアクセス・フィールドとは、それ自身のビジョン とこの要素の内部に位置するすべてのターミナルの伝搬されたビジョンとの組み 合わせである。 図９を参照すると、たとえば、要素Ｓｉのアクセス・フィールドは、エントリ ／１のビジョンであるが、その理由は、それが、Ｓｉのビジョンと、Ｓｉのビジ ョ ンの中にある＊ｂ１のＰＶＰと、＊ｂ２のＰＶＰと、＊ｂ３のＰＶＰと、＊ｂ４ のＰＶＰとの組み合わせだからである。 ＊ｂ１のＰＶＰが、偶然、Ｓｉのビジョンと、（＊ｂ２、＊ｂ３、＊ｂ４）の ＰＶＰである／２のビジョンとを有することがある。 たとえば、ＭＢ２に属しｋ座標を有する（すなわち、ｒｋ２）任意の要素Ｓｅ のアクセス・フィールドは、その要素のビジョンであるが、これは、それが、Ｓ ｅのビジョンの内部にある＊ｂ２、＊ｂ３、＊ｂ４のＰＶＰである／２のビジョ ンを有するからである。 たとえば、要素Ｌ５のアクセス・フィールドは、／２のビジョンであるが、こ の理由は、それが、Ｌ５のビジョンの中にある＊ｂ３及び＊ｂ４のＰＶＰであり 、Ｌ５のビジョンは／２のビジョンによって所有され、カウントされないからで ある。 あるリワインド・エントリのビジョンの中のすべてのターミナルがそのエント リをＰＶＰとして求めると、結果は、閉じた領域（データ独立なエンドレス・ル ープ）になる。 たとえば、＊ｂ２、＊ｂ３、＊ｂ４が／２をそのＰＶＰであることを求めると 、そのビジョンの中には何もターミナルがないことになる。これは、閉じた領域 、すなわち、データ独立なエンドレス・ループを定義する。 閉じたターミナル及び閉じた領域、すなわち、データ独立なエンドレス・ルー プを表す構成を見つけるためには、我々は、ＸＰＤグラフの各ターミナルに対し て出口アクセス・インジケータ（ＥＡＩ）を構築する。 出口アクセス・インジケータ（ＥＡＩ）の構築について述べる。図９を参照す ると、各ターミナルのＴＢＡ、ＲＢＡ、ｒｋを、ＸＰＤグラフの構成が終了した 後で知ることができる。 当初は、ＰＶＰの値は、ターミナルのリワインド・エントリ、すなわち、その ターミナルのｒｋ及びＲＢＡから構築される。 すべてのリワインド・ターミナルのＥＡＩには、当初は、０（閉じている）が 満たされており、すべての出口ターミナルのＥＡＩには１（開いている）が満た されている。 ｂ＝１からｂ＝ＮＢへと移動しながら、ターミナルのＰＶＰをＢＡとすべての 他のターミナルのＰＶＰとに対して、現在調べているターミナルのＰＶＰのＰＶ Ｐを伝搬し（増加させ）、それがもしまだ閉じている場合には、可能であれば、 そのターミナルを開く。我々は、ターミナル＊ｂｉのＰＶＰをＰＶＰ＊ｂｉと称 することにし、また、＊ｂｉのＥＡＩをＥＡＩ＊ｂｉと称することにする。図９ の例を参照のこと。 Ｉ）ターミナルのＰＶＰは、当初は、そのリワインド・エントリのＳＡに設定 される。すなわち、 ＰＶＰ＊ｂ１のＢＡは、１０に設定される。 ＰＶＰ＊ｂ２のＢＡは、１００１に設定される。 ＰＶＰ＊ｂ３のＢＡは、１００１０に設定される。 ＰＶＰ＊ｂ４のＢＡは、１００１１に設定される。 ＰＶＰ＊ｂ５のＢＡは、０に設定されるが、これは、＊ｂ５が出口ターミナル だからである。 ＰＶＰ＊ｂ６のＢＡは、１００１１に設定される。 ＰＶＰ＊ｂ７のＢＡは、１０に設定される。 II）ＰＶＰの伝搬及びＥＡＩの設定 （Ａ）＊ｂ１からｎがメイン・ブランチの数であるＮＢである＊ｂｎへのオー ダーでターミナルを通過し、各ターミナルを、ＸＰＤグラフの他のすべてのター ミナルとの関係で、ａ）先に説明した規則（Ｇ２１）によってターミナルＰＶＰ を伝搬させ、ｂ）そのＥＡＩを、次に述べる規則によって１に設定することによ ってそのターミナルを開くことを目的にして、調べる。 定義Ｇ２３：閉じたターミナルのＰＶＰが任意の開いたターミナルを見ること ができる場合には、調べられたターミナルは、そのＥＡＩを１に設定することに よって開いているとアナウンスされる。 １）ＰＶＰ＊ｂ１｛１０，ｒｋ１｝は、＊ｂ２、＊ｂ３、＊ｂ４、＊ｂ５を見 るが、これらのターミナルＰＶＰのどれもがＰＶＰ＊ｂ１を見ることはできない 。すなわち、 ＰＶＰ＊ｂ１は変更されない。 ＰＶＰ＊ｂ１｛１０，ｒｋ１｝は、開いた＊ｂ（１０１０）を見る。 ＊ｂ１を開くには、ＥＡＩ＊ｂ１を１に設定する。 ２）ＰＶＰ＊ｂ２｛１００１，ｒｋ２｝は、１００１１０、１００１１１であ る＊ｂ３、＊ｂ４を見るが、１００１０、１００１１であるこれらのターミナル ＰＶＰのどれもがＰＶＰ＊ｂ２を見ることはできない。すなわち、 ＰＶＰ＊ｂ２は変更されない。 ＰＶＰ＊ｂ２｛１００１，ｒｋ２｝は、その時点では＊ｂ１、＊ｂ５であるす なわち１０００、１０１０であるどの開いたも見ない。 ＥＡＩ＊ｂ２は０に設定される。 ３）ＰＶＰ＊ｂ３｛１００１０，ｒｋ３｝は、＊ｂ２（１００１０）を見るし 、ＰＶＰ＊ｂ２｛１００１，ｒｋ２｝は、｛１００１０，ｒｋ３｝であるＰＶＰ ＊ｂ３を見る。 ＰＶＰ＊ｂ３を、ＶＰ＊ｂ２｛１００１，ｒｋ２｝に設定する。 伝搬されたＰＶＰ＊ｂ３は、まだ、どの開いたターミナルも見ない。 ＥＡＩ＊ｂ３は、０に設定される。 ４）ＰＶＰ＊ｂ４｛１００１１，ｒｋ４｝は、＊ｂ３（１００１１０）を見る し、ＰＶＰ＊ｂ３｛１００１，ｒｋ３｝は、｛１００１１，ｒｋ４｝であるＰＶ Ｐ＊ｂ４を見ることができる。 ＰＶＰ＊ｂ４を、｛１００１，ｒｋ２｝に設定する。 伝搬されたＰＶＰ＊ｂ４は、まだ、どの開いたターミナルも見ない。 ＥＡＩ＊ｂ４は、０に設定される。 ５）ＰＶＰ＊ｂ５は変更されないが、これは、出口ターミナルだからである。 ６）ＰＶＰ＊ｂ６｛１００１１，ｒｋ６｝は、＊ｂ３と＊ｂ４とを見るし、そ の現在のＰＶＰである｛１００１，ｒｋ２｝は、ＰＶＰ＊ｂ６を見る。 ＰＶＰ＊ｂ６を、｛１００１，ｒｋ２｝に設定する。 伝搬されたＰＶＰ＊ｂ６は、まだ、どの開いたターミナルも見ない。 ＥＡＩ＊ｂ６は、０に設定される。 ７）ＰＶＰ＊ｂ７｛１０，ｒｋ７｝は、＊ｂ１から＊ｂ６までのターミナルを 見ることができるが、それらはどれもＰＶＰ＊ｂ７を見ることはできない。 ＰＶＰ＊ｂ７は変更されない。 ＰＶＰ＊ｂ７｛１０，ｒｋ７｝は、開いたターミナル（１０００及び１０１０ ）を見ることができる。 ＊ｂ７を開くには、ＥＡＩ＊ｂ７を１に設定する。 図１０Ｂを参照すると、＊ｎのビジョンによって伝搬されるターミナル＊１は 、＊ｎのＰＶＰが最終的に設定される前に調べられる。この理由は、＊ｎのＰＶ Ｐが、次に、他方のターミナルのビジョンによって更新されるからである。 したがって、ＰＶＰとＥＡＩとのすべての有り得る更新が行われることを確実 にするため唯一の方法は、＊ｂ１から＊ｂｎの順ですべてのターミナルを調べる ステップ（Ａ）を反復することである。最後のパスの中で更新が全くなされてい ない場合には、ＰＶＰ及びＥＡＩの更新のプロセスは終了する。 最悪の場合には、ターミナルを通過する要求されるパス、すなわち、ステップ （Ａ）の実行の数は、メイン・ブランチＮＢの数と等しい。この理由は、それぞ れのパスは、最終的に、少なくとも１つのターミナルのＰＶＰとＥＡＩとを設定 する。ここでの例では、すべての更新は、１つのパスにおいて行われ、＊ｂ１か ら＊ｂ７への第２のパスは、ＰＶＰ及びＥＡＩを変更しない。 結果として、我々は、ターミナル＊ｂ２、＊ｂ３、＊ｂ４、＊ｂ６のＥＡＩは ０であり、これらのターミナルは閉じていることが分かる。 ターミナル＊ｂ２、＊ｂ３、＊ｂ４は、閉じた領域（データ独立なエンドレス ・ループ）を構成する。ターミナル＊ｂ６もまた、閉じていて、そのリワインド ・エントリは、上述の閉じた領域［＊ｂ２−＊ｂ４］の中にある。 破線（ａ）は、エントリ／１のビジョン・フィールド｛１０，ｒｋ１｝を表す 。このエントリは、＊ｂ１のＰＶＰである。これは次のことを意味する。すなわ ち、メイン・ブランチｂ＝１の任意の要素は、｛１０，ｒｋ１｝のビジョンの内 部の任意の要素にアクセスできるということである。 （Ｓｉ）のアクセス・フィールドは、破線（ａ）によって表される。 破線（ｂ）は、エントリ／２のビジョン・フィールド｛１００１，ｒｋ２｝を 表す。このエントリは、＊ｂ２、＊ｂ３、＊ｂ４、＊ｂ６のＰＶＰである。これ は、次のことを意味する。すなわち、メイン・ブランチＭＢ２、ＭＢ３、ＭＢ４ の任意の要素は、｛１００１，ｒｋ２｝のビジョンの内部の任意の要素にアクセ スできるということである。 ここでの定義によれば、あるプロセス要素のアクセス・フィールドは、それが 連続的に所有するすべてのビジョンの組み合わせである。 したがって、Ｓｊのアクセス・フィールドは、破線（ｃ）と破線（ｄ）とによ って表されるフィールドの組み合わせであり、破線（ｃ）は、Ｓｊのビジョンで あり、破線（ｄ）はＳｊから見られる＊ｂ６のビジョンである。 図９では、（Ｓｉ）は（Ｓｊ）にアクセス可能であり、（Ｓｊ）は（Ｓｉ）に アクセス可能ではないことがわかる。 プロセス要素ｓ１からプロセス要素ｓ２へのアクセス可能性を確立するには、 ２つのステップがある。 １．ＳＡ（ｓ２）がＳＡ（ｓ１）のデセンダント（子孫）であるならば（これ は、バイナリ・アドレスを比較することによって確立され、バイナリ・アドレス が等しい場合にはｋ座標を比較することによる）、ｓ２は、ｓ１からアクセス可 能である。 ２．ステップ１が失敗した場合には、ＳＡ（ｓ２）が任意のターミナルのＰＶ Ｐの子孫であるならば、ｓ２はｓ１からアクセス可能である。 図９の例では、すべてのターミナルについて構築されている属性（ＢＡ、ＲＢ Ａ、ＰＶＰ）を調べることにより、以下のことを判断できる。すなわち、 ａ）１０１は１００から見えないので、ＳｉはＳｊを見ることはできない。し かし、ＳｉはＳｊにアクセス可能である。この理由は、Ｓｉから見えるターミナ ルの１つである＊ｂ１が、１０１が１０の子孫であることにより、そのＰＶＰ｛ １０，ｒｋ１｝を介してＳｊを見ることができるからである。 ｂ）１００は１０１の子孫ではないので、ＳｊはＳｉを見ることはできない。 Ｓｊから見えるターミナルは、ＢＡが１０１０及び１０１１を有するものである 。ターミナル1０１０は、出口ターミナルであるＲＢＡ又はＰＶＰを有していな い。ターミナル１０１１は、１００をやはり見ることのできないＰＶＰ｛１００ １，ｒｋ１｝を有する。したがって、ＳｊはＳｉにアクセス可能ではない。 ３）誤り又はシステムへの要求の変更に起因する修正箇所として、目標プロセ スにおける「正しさ」を評価し、「不確実性」の箇所を特定するＸＰＤマシンの 原理を定義する。 図１１は、任意のコンピュータ・ソフトウェア・プロセスに適用される原理を 表している。ここでは、我々は、その原点から、３つのクラスのプロセス・エラ ーを見ることができる。この３つのクラスは、すべての可能なプロセス誤りを含 む。 第１のクラス（ａ）は、プロセス設計の段階で入り込む誤りである。そのオリ ジンは、プロセス仕様の誤解にあり、又は、予測された入力から予測された出力 を生じなければならないステップの設計の間に入り込んだ誤りにある。これらは 、プロセス・アルゴリズムの中にある誤りである。 第２のクラス（ｃ）は、設計の実現化の際に入り込んだ誤りである。これらの 誤りは、設計されたアルゴリズムをコンパイラのプログラム言語によって理解可 能な形式にコード化する間に入り込む誤りである。 これらは、論理的なコード化の誤りである。結果的にはコンパイラによって位 置を特定される構文（シンタックス）の誤りは、ここではカウントされていない 。というのは、ＸＰＤマシンは、コンパイラによってチェックされた後で、コー ドに存在する論理的な誤りのアドレス指定をするからである。 目標プロセスの実行の間には、また、そのテストと製造との間には、無効であ るが予測されておらずしたがって考慮されておらずプロセスのアルゴリズムに捕 捉されていなかった入力の組み合わせが存在し得る。このクラスの誤りは、入力 にあるのであり、目標プロセスの外部のものであるということができる。これら が入力誤り（ｉ）である。 図１１の目的は、すべてのこれらの誤りが実現された（コード化された）目標 プロセスの中に存在し、ある条件で、これらの誤りは、プロセスの予測される出 力における誤動作（ｆ）として明白になることを示すことである。 以下の定義は、この点で重要である。 定義Ｐ１：（ｓ）は、基本プロセス（プログラム・ステートメント）を示すも のとする。 定義Ｐ２：要素のプロセス・アドレス（ＰＡ）である｛ｋ，ｂ｝とは、縮小流 れ図の内部のこの要素の位置であり、これは、このプロセスのＸＰＤグラフの内 部でも同じである。図５Ａ及び図４を参照すると、ＰＡは、２つの座標ｋ及びｂ によって定義される。このプロセスの内部の各ステートメントは、｛ｋ，ｂ｝に よって測定される（計量を与えられる）それ自身のＰＡを有する。 定義Ｐ３：局所（ローカル）時間｛ｐ｝は、プロセス実行の内部のステートメ ントの現在の発生ないし存在の整数値である。すなわち、ｐ＝１，２，・・・で ある。 ＸＰＤマシンは、物理的な時間と共には動かない。本発明では、時間の定義は 、（ｓ）の機能が、制御がその（ｓ）を通過する場合に限りプロセスに影響し、 一時的にアクティブになることも考慮している。したがって、我々は、（ｓ）の 実行の各イベントにそれ自身の時間パラメータを与える。局所時間は、プロセス の呼び出し（ｉｎｖｏｃａｔｉｏｎ）からカウントを開始する。 定義Ｐ４：プロセス・イベント｛ｋ，ｂ，ｐ｝は、（ｓ）実行のイベントであ る。 これは、ＸＰＤマシンでは、３つのパラメータ｛ｋ，ｂ，ｐ｝によって与えら れる。ここで、｛ｋ，ｂ｝は場所（プロセス・アドレス）を識別し、｛ｐ｝は局 所時間を識別する。 定義Ｐ５：プロセス時間は、プロセス・イベント｛ｋ，ｂ，ｐ｝によって表さ れる。 これによって、解析は、特定のプロセス要素の実行に必要であるハードウェア やオペレーティング・システムに従属する物理的な時間から独立になる。 プロセスの全体が「場所」と「時間」との組み合わせ、すなわち、プロセス・ アドレス｛ｋ，ｂ｝と局所時間｛ｐ｝とによって計量され得るという観点から見 れば、各基本要素（ｓ）は、それ自身の時間（ｐ）座標の中に住んでいるといえ る。 たとえば、図５Ａ及び図４におけるステートメントＡ５が３回目に実行された プロセス時間を参照したいとすれば、｛１２，２，３｝のイベントとして参照す ることになる。 プロセスの出力イベントは、第１に、プロセスが構築された理由であり、通常 は、これらの出力イベントが正しくない場合にのみ、プロセス自体が故障（誤動 作）であるという。 コンピュータ・プロセスは、複数の出力をもち得るのであり、たとえば、シス テムのターミナルに１つの出力があり、異なるファイルに別の出力が有り得る。 ＸＰＤ解析機関は、後に詳細に述べるように、ＩＳＯＰＳマップを用いて自動的 に付勢される。 プロセス時間は、特定の出力において、それに向けられた出力イベントのシー ケンスによってのみ提示される。たとえば、｛ｋｉ，ｂｉ，ｐｉ｝と、｛ｋｊ， ｂｊ，ｐｊ，｝と、｛ｋｌ，ｂｌ，ｐｌ，｝と、である。 出力からプロセスを眺めると、これらのプロセス・イベントは出力結果である ｒｉ、ｒｊ、ｒｌによって表されていることが分かる。ここで、ｒｊのプロセス 時間は、ｒｉの後であり、ｒｌの前である。 図１２は、プロセス時間（ｔ）において出力イベント（ｒ）を生じる際の可能 な３つタイプの故障（誤動作）を示している。 公理１：任意の出力に対して、３つのそして常に３つのタイプのプロセス誤動 作がある。すなわち、 （ｆ１）出力イベントが生じていない特定のプロセス時間で予測される。 （ｆ２）出力イベントが生じる特定のプロセス時間で予測されない。 （ｆ３）出力イベントが正しくない値をもって生じる特定のプロセス時間で予測 される。 ＸＰＤマシンのインターフェースは、これらの３つのタイプのプロセス誤動作 をアドレス指定するコマンドを含み、したがって、ＸＰＤマシンは、任意のプロ セス誤動作をアドレス指定できる。 図１３は、抽象的なレベルで、どのようにＸＰＤマシンが時間の経過と共に、 プロセスに関する知識を集積するかに関する原理を図解している。知識のこれら の集積は、図７、図８、図１４、図１５、図１６、図１７を参照して詳細に説明 される。 図１３を参照すると、次の定義が必要である。 定義Ｐ６：「正しいプロセス・アドレス」（ＣＰＡ）は、次のように定義され る。プロセス・アドレスが正しいとは、正しいイベントとして実行された、すな わち、正しい場所と時間とにおいて正しい結果を生じるプロセス要素を含む場合 をいう。 定義Ｐ７：「不確実なプロセス・アドレス」（ＵＰＡ）は、次のように定義さ れる。プロセス・アドレスが不確実であるとは、正しいイベントにおいてまだ実 行されていないプロセス要素を含む場合をいう。 プロセス・アドレスを正しいとして定義する場合には、その内容（コンテンツ ）が特定のイベントにおいて正しいと定義する。たとえば、ステートメントＡ＝ Ｂ＋Ｃは、そのプロセスの特定の場所と時間とにおいてのみ、正しい。 プロセス・アドレスの間の局所時間の分布は、プロセス実行の間に動的になさ れ、絶対的に次の２つのファクタによって決定されることを理解すべきである。 すなわち、 （１）ハード・コード化されたプロセス制御構造及び要素の内容と、 （２）変化する入力値の組み合わせと、である。 したがって、不変のプロセス構造とプロセス要素の内容とを条件として、局所 時間をプロセスにおいて定義するのは、入力値である。我々は、正しいプロセス 要素をすべての時間に亘って正しいものと強制はしない。 これが、「正しさの相対性」が役割を演じる場所である。換言すれば、（ｓ） は、場所及び時間（プロセス時間）と、予測される入力と、予測される出力と、 に対して、ただ相対的に、正しく有り得るのである。この相対性こそが、プログ ラムの正しさを証明する方法が不存在である理由である。我々の考えでは、誤り 位置を特定するプロセスの自動化問題への唯一の解答は、位置の不確実性を一定 に最小化することにある。 定義Ｐ８：イベントの正しさを定義する。出力イベントは、正しい、すなわち 、予測された結果を生じているときに正しいと定義される。 我々は、その正しい出力イベントを生じさせるのに寄与するイベントのつなが り（チェーン）に参加する場合には、出力イベントの他に、プロセス・イベント ｛ｋ，ｂ，ｐ｝が正しいと定義する。すなわち、出力イベントとは他のイベント は、正しい出力イベントによって正しいとされる。 イベントは、複数の出力イベントによって正しいとされる場合もある。たとえ ば、ｅ１、ｅ２、ｅ３、ｅ４、ｅ５、ｅ６、ｅ７がプロセス・イベントの何かの シーケンスを表すとする。ここで、ｅ７は正しい出力イベントであり、ｅ１とｅ ３とは、出力イベントであり、ｅ１、ｅ２、ｅ３、ｅ４、ｅ６はｅ７の値を生じ るのに関係しているとする。この場合には、ｅ５を除いて、ｅ１からｅ７のイベ ントは、正しいという。 イベントｅ５は、その計算の連鎖にｅ５が参加している他の何らかの正しい出 力イベントによって、正しいと定義され得る。しかし、それまでは、正しさは不 確実である。 プロセス要素に関するこの定義は、以下のことからの連想によって簡単に理解 し得る。コンピュータ・ボードがそれに付随するコード化されたプロセスを有し ており、そのボード上の各集積回路には、プログラム・ステートメントのような コード化された基本プロセスが付随している。この集積回路に欠陥がなく正しい スロットに配置されており、この集積回路が以前にテストされた入力信号の組み 合わせに関して正しい結果を生じるのに参加していたと仮定すると、この集積回 路は、将来にも、同じ入力の組み合わせに基づいて同じ正しい結果を生じること に参加するであろう。この集積回路は、したがって、正しい入力の組み合わせに 基づいて、コンピュータ・ボード上の正しい場所で、すなわち、正しい場所と時 間とにおいて、正しい結果を生じさせるポテンシャル（潜在性）のために、正し いと定義される。 公理２：プロセス機能の正しさは、その最適な実現方法（ｉｍｐｌｅｍｅｎｔ ａｔｉｏｎ）とは独立である。 公理３：正しいと定義されたプロセスの最適化は、ＸＰＤマシンによって定義 されるその正しさを破らない。 この簡単な証明は、均等な最適化は、機能を結果的に生じさせるプロセスを変 更するとは考えられないという事実にある。 定義Ｐ９：アルゴリズム空間とは、プロセス・アドレス｛ｋｉ，ｂｉ｝との組 み合わせから成る空間である。 図５と図４とを参照すると、プロセス構成が不変であるという条件では、アル ゴリズム空間は一定であり、目標プロセスのＸＰＤグラフの２つの次元であるＭ Ｋ及びＮＢによって、制限されることに留意することが重要である。 我々のサンプル・プロセスのＸＰＤグラフと縮小流れ図を表す図５Ａ及び図４ においては、次元（ＭＫ，ＮＢ）は、（１４，５）である。 定義Ｐ１０：正しいアルゴリズム空間とは、現時点でＣＰＡとして定義されて いるＰＡの組み合わせから成る空間である。 定義Ｐ１１：不確実なアルゴリズム空間とは、現時点でＵＰＡとして定義され ているＰＡの組み合わせから成る空間である。 ここで、現時点で定義されている、というのは、ＸＰＤマシンが、イベント及 びＰＡの正しさをアナウンスもデナウンスのする両方の能力を有しているからで ある。あらかじめ構築される知識の部分的な緩やかさ（ｐａｒｔｉａｌ ｌｏｏ ｓｉｎｇ）は、誤動作が既に正しいとして受け入れられたプロセス出力において 認識される際には、不可避である。 定義Ｐ１２：イベント（ｅ）のイベント定義空間は、先祖（アンセスタ）イベ ントである（ｅ）のＰＡから成る。 定義Ｐ１３：先祖（アンセスタ）イベントと、子孫（デセンダント）を定義す る。イベントｅ１がイベントｅ２の先祖である、又はｅ２がｅ１の子孫であると は、ｅ１がｅ２を生じるのに参加しており、それが、ｅ２の値を生じるのに参加 した（値先祖イベント）か、又は、ｅ２に至る過程で条件的な制御イベントに対 してパラメータを生じるのに参加した（制御先祖イベント）か、のいずれかによ る場合である。 図１４を参照すると、ｅ（ａ）は、そのブランチにおいてｅ（ａ）の下に示さ れているイベントの子孫である。ｅ（ｄ）は、ｅ（ｉ）、ｅ（ｊ）、ｅ（ｋ）、 ｅ（ｌ）、ｅ（ｍ）と、ｅ（ｊ）の先祖であるイベントとの子孫である。ｅ（ｂ ）は、ｅ（ｆ）及びｅ（ｇ）の直接の子孫である。ｅ（ｆ）及びｅ（ｇ）は、ｅ （ｂ）の直接の先祖である。 図１３を参照すると、この図の目的は、抽象的に、プロセスの不確実性が時間 経過と共にいかにして最小化されるかと、誤りの位置が時間経過と共にいかに局 所化できるかを単に示すものである。この図は、ＸＰＤマシンの全体的な理解を 助ける。ＸＰＤマシンに関する更に詳細な説明を、以下で行う。 この図には、４つのオブジェクトが表されている。左から右に、１）入力空間 であり、これは、入力パラメータのすべての可能な組み合わせである。すなわち 、プロセスが４つの入力パラメータを用いているとすれば、そのプロセスに対す る入力空間は４次元空間である。２）不確実なアルゴリズム空間。３）正しいア ルゴリズム空間。４）予測される出力空間であり、これは、検査されている出力 での予測される出力結果の組み合わせである。 ｔ０、ｔ１、ｔ２、ｔ３は、異なるプロセス時間を表し、ここでｔ０は、プロ セスの開始時点にある。ｔ１、ｔ２、ｔ３において出力結果がまだ何も生じてい なければ、プロセス出力は連続的に集積される。 第１の誤動作がプロセス時間ｔ３において認識されたと仮定する。この図は、 ＸＰＤマシンによる不確実性最小化方法が適用されれば、このプロセス時間ｔ３ における誤動作の原因である誤りの位置に付随する不確実性は、プロセス時間ｔ ２において生じた誤動作の場合よりも小さいことを示している。 目標プロセスの実行では、入力空間はじっらいの入力によって満たされ、出力 空間は実際の出力によって満たされている。 出力結果を集積することによって、以下で更に説明する方法によって構築され たＸＰＤマシンは、正しいアルゴリズム空間を拡張し、不確実なアルゴリズム空 間を縮小させる。この２つの和が、目標プロセスがコード化される際に定義され 目標プロセスが不変である間は同じままであるに止まるアルゴリズム空間である からである。 以下のことが、ＸＰＤマシンによって解析されている目標プロセスの前方向へ の実行の間は、有効であることが宣言できる。 ａ）不確実なアルゴリズム空間は、正しいアルゴリズム空間の増加と共に、一 定に減少する。 ｂ）任意のプロセス・イベントに対するイベント定義空間は、限定されている 。すなわち、この限定は、プロセスのアルゴリズム空間の全体である。したがっ て、イベント定義空間の連続的にますます少ない部分は、目標プロセスが前方向 に実行されて行く間に、不確実空間内に残ることになる。 図１３を参照すると、ｄ（ｅ２）がプロセス時間ｔ２における予測されない出 力結果（ｅ２）のイベント定義空間であり、ｄ（ｅ３）がプロセス時間ｔ３にお ける予測されない出力結果（ｅ３）のイベント定義空間である場合には、プロセ ス時間ｔ２及びｔ３における誤り位置の不確実性の（不確実である）領域は、斜 線によって陰の付けられたｄ（ｅ２）及びｄ（ｅ３）の部分によって表される。 誤り位置不確実性の領域は、プロセス時間ｔ３でのほうが、プロセス時間ｔ２ における対応する領域よりも小さい。 イベント定義空間は目標プロセスの前向きの実行に伴い潜在的に成長し、ＸＰ Ｄマシンは、誤り位置不確実性の一定の最小化を可能にする。 ＸＰＤマシンによる解析の結果は、正しいプロセス・アドレスに関する我々の 定義、すなわち、時間に関係し、出力結果の予測に関係する定義に関係する。 誤り位置の位置を特定する又は要求される修正箇所を特定するＸＰＤマシンの 原理を説明する。 出力結果の誤動作の原因となる誤り、又は、システムへの新たな要求に起因す る修正箇所は、不確実なアルゴリズム空間の領域内に存在する出力結果イベント 定義空間の一部において位置が特定される。 ここでは、誤り位置が複数のＵＰＡに限定されるという場合には、許容される 修正だけが、上述のＵＰＡの中に存在する。そうでなければ、新たなイベント定 義空間が、アルゴリズム空間を拡張することによってすなわち新たなＰＡを作成 することによって、構築されなければならない。したがって、ここでのプロセス 不確実性の定義は、目標プロセスの前方向の構成、すなわち、自動化された前方 向へのプログラム開発に基礎を与える。すなわち、ＸＰＤマシンを用いれば、既 存のプロセスの上での構築の領域を、プロセス・メンテナンス及び前方向へのプ ログラム開発の間に正しく動作しているものをやり直したり破壊したりすること なく、自動的に局所化することが可能になる。 たとえば、出力イベントｗ（ｋ，ｂ，ｐ）を得るのに、１２のプロセス・アド レスにおいて生じた５０のイベントが必要であったと仮定する。これらの中の４ ５のイベントは、正しいことが分かっている１０のプロセス・アドレスで生じた とする。すると、ｗ（ｋ，ｂ，ｐ）の生成に関係して、２つの不確実なプロセス ・ アドレスにおいて生じている５のイベントを有していることになる。 ｗ（ｋ，ｂ，ｐ）が正しい（予測された）のならば、これらの５つのイベント はＸＰＤマシンによって正しい（承認済み）として設定され、２つのステートメ ントは、正しい基本プロセスの状態として更新され、それらのプロセス・アドレ スは、ＣＰＡの状態に更新される。 ｗ（ｋ，ｂ，ｐ）が正しくない（予測されていない）結果である場合には、誤 り位置の不確実性の領域はこれらの２つのＰＡとなる。すなわち、予測された結 果が、これらの２つのステートメントを修正か、又はｗ（ｋ，ｂ，ｐ）に対する 新たな定義空間の構築かのどちらかによって達成される。 「知識伝搬」ないし「知識帰納」という目標プロセスは、それを実行すること によって結果的に適正アルゴリズム空間（Correct Algorithm Space）が拡張す るプロセスである。 ＸＰＤオブジェクト集合の、Ａ、Ｌ、Ｄ、Ｅ、Ｘ、＊、＋、Ｃ、！、／、Ｒ、 ＝、Ｓ、及びＷという夫々の要素の間の関係は、あるＷ要素の実行という事象が 「承認される」ことによって、一連の複数の二次的プロセスから成る二次的プロ セス・チェーンを起動させることができるような関係にしてある。それら複数の 二次的プロセスによって、その「承認された」Ｗ事象の発生に関与したＸＰＤグ ラフ要素の実行という事象が「承認」される。 定義Ｋ１；事象の「承認」 これは、ＸＰＤエンジンがある事象の「正しさ」を検証するプロセスであり、 ここでいう事象の正しさとは、Ｐ８によって定義されるものである。 定義Ｋ２：「制御事象」 これは、ＸＰＤグラフ及び縮小フローチャートに従ってプロセスの方向をフォ ールダウンから変更するための事象であり、その変更を絶対的に行う事象（「無 条件制御事象」）と、変更できる可能性を与える事象（「条件付制御事象」）と がある。 定義Ｋ３：「無条件制御事象」 これは、リワインド・ターミナルないしイグジット・ターミナル（＊、＋、Ｃ 、Ｒ、＝）の実行という事象である。 定義Ｋ４：「条件付制御事象」 これは、Ｌ要素の実行という事象、または、Ｄ要素のループ脱出条件の評価の 実行という事象である。 条件付制御事象の結果がポジティブであれば、ＸＰＤグラフ及び縮小フローチ ャートに従って、右方への制御シフトが行われことになる。条件制御事象の結果 がネガティブであれば、ＸＰＤグラフ及び縮小フローチャートに従って、フォー ルダウンへの制御が行えるようになる。 定義Ｋ５：「データ操作事象」 これは、ＸＰＤオプジェクト集合の要素のうちの、Ａ要素またはＥ要素の実行 という事象、または、Ｄ要素の計算部分の実行という事象である。 定義Ｋ６：「初期データ操作事象」 これは、次のいずれかの事象である。データ初期化におけるＥ事象ないしＡ事 象、または、ループ・インデクス初期化におけるＤ事象。 定義Ｋ７：「二次的データ操作事象」 これは、初期データ操作事象以外のデータ操作事象である。 ＸＰＤマシンは、ＡＣＢ（解析計算ベース：Analyzed Calculation Base）の 構築を通して、いかなる事象が「正しい」プロセス実行を構成するかという主題 についての知識を蓄積できるようにするものである。 ＡＣＢの基礎を成す基本原理は、「正しい」実行事象についての知識を保存せ ねばならないということである。 「正しさ」とは、入力事象が「正しい」ものである場合に、位置、タイム、及 び値に関して「正しい」事象を発生させることのできる潜在的能力のことを意味 している。従って、解析計算ベースは、「正しい」実行をもたらす潜在的能力を 保存できるようにするものである。 定義Ｋ８；基本的プロセスについての基本的「知識」 これは、基本的プロセスの実行という事象のうちの１つを我々が「承認」した ときに獲得される知識である。 従って、基本プロセスについての「知識」を蓄積することによって、基本的プ ロセスの様々な実行事象における「正しさ」またはその不確実性についての情報 が蓄積される。 従って、基本的プロセスについての基本的「知識」は、次の構成要素を含んで いる。 ａ．内容の正しさについての知識。 ｂ．ある実行事象が「正しい」事象を構成した場合、または構成しなかった 場合の、プロセス・タイム（プロセス位置及びローカル・タイム）についての知 識。 定義Ｋ９：「基本的知識の伝搬」即ち「基本的知識の帰納」 我々が、ａ）内容と、 ｂ）承認事象のプロセス・タイムと、 を知っているという事実によって、我々は、この事象の「基本的知識」を様々な プロセス・アドレスへ伝搬させることができ、それには「知識伝搬のターミナル 事象」に到達するまで、「アンセスタ」事象の位置決定及び解析が自動的に逆方 向に進められて行くようにすればよい。 定義Ｋ１０：「知識伝搬のターミナル」事象（ＫＰターミナル） これは、次の２種類の事象のうちのいずれかである。 １）その事象のアンセスタ事象が目標プロセスの中に存在していない事象、 即ち、初期データ操作事象。 ２）既に承認されている承認済事象。 既に承認されている承認済事象は、知識伝搬プロセスを安定化して、目標プロ セスの順方向実行の際にアンセスタ事象の蓄積によって知識伝搬プロセスが次第 に複雑化して行くのを防止する。「知識伝搬」プロセスが、ある承認済事象に到 達したならば、その時点で即座に、その承認済事象のアンセスタ事象の全てが既 に承認されているということを確認することができる。 目標プロセスの中の「不確実性」を評価することについての以下の説明では、 そこに説明するのは「知識帰納」プロセスの逆プロセスである「知識推論」プロ セスであり、そこでは「知識伝搬」ターミナルと呼ばれたものがそのまま「不確 実性」ターミナルになる。 図１４を参照されたい；図示例には、２つのＷ事象 e(a) と e(n) とが存在し ており、図にはそれらＷ事象が、それらＷ事象の幾つかのアンセスタ事象と共に 示されている。Ｗ事象が承認されるのは、この図１４に→で示したプロセス実行 方向においてである。それら２つのＷ事象の各々に対応した事象定義空間の一部 分だけを図示してある。 ここでは、初期データ操作事象である「ＫＰターミナル」事象を＊ｅで表し、 承認済事象である「ＫＰターミナル」を＃＊ｅで表している。 図示例では、Ｗ事象 e(a) の値は３つのパラメータから算出されており、それ ら３つのパラメータの値は、夫々事象 e(b)、e(c)、及びe(d) によって発生され ている。 更に事象 e(b) の債は、２つのパラメータから算出されており、それら２つの パラメータの値は、事象 e(f) と e(g) とによって発生されている。 事象 e(f) にはアンセスタ事象が存在せず、なぜならば、この事象 e(f) は初 期データ操作事象であり、即ち、ＫＰターミナルだからである。 事象 e(g) は既に承認されている承認済事象であり、従ってこれもＫＰターミ ナルである。 我々は、ＫＰターミナルのアンセスタ事象の位置特定を行わない。なぜならば、 ＫＰターミナルのアンセスタ事象は、事象 e(f) の場合のように存在していない か、或いは事象 e(g) の場合のように既に承認されているかの、いずれかだから である。「帰納終了」原理はこれに基づいている。 プロセス実行の向は、Ｗ事象 e(a) からＷ事象 e(n) への方向であるため、事象 e(i) は、後に実行されるプロセスであるＷ事象 e(n) から基本的知識を伝搬す るプロセスにおいては、そのＫＰターミナルになる。なぜならば、事象 e(i) 及 びそのアンセスタ事象は、事象 e(a) からの知識伝搬の実行中に既に承認されて いるからである。 知識伝搬におけるルール： ある１つの事象を承認するプロセスは、次の２つの場合を除いて、その事象の直 前のアンセスタ事象を承認するという二次的プロセスを発生する。 ａ）その事象の直前のアンセスタ事象が既に承認されている。 ｂ）その事象の直前のアンセスタ事象が存在していない（その事象が初期デ ータ操作事象である場合）。 従って、基本的知識の伝搬、即ち「知識帰納」は、チェーン・リアクションと なり、このチェーン・リアクションの拡大が、知識伝搬ターミナルによって制御 される。 図１７の具体例を参照されたい：プロセス・タイム（k0,b0,p0）における事象 （e0）は、(y) の値を計算するための（s0）の実行において最初に承認された承 認済事象であり、なぜならばこのステートメント（s0）のＰＡは、そのステータ スがＵＰＡに成っているからである。そのためこの（s0）のＰＡは、ＣＰＡへ格 上げされる。 直前のアンセスタ事象が幾つか存在しており、それらアンセスタ事象は、(y) の値の計算に関係したパラメータ x1、x2、x3 の夫々を計算する事象である。こ こでは、（k0,b0,t0）の事象の直前に x1 の値と x2 の値とがプロセス・タイム （k1,b1,p1）と（k2,b2,p2）とに発生されたものとする。またここでは、それら 事象は既に承認されているものとし、従って我々はそれら事象をＫＰターミナル として取扱い、それら事象のアンセスタ事象については調べないものとする。 またここでは（k0,b0,t0）の直前に x3 を計算するという事象が（k3,b3,p3） において発生しており、この事象が未承認であるものとする。ＣＰＡというステ ータスは、単にこのＰＡ実行事象以外の何らかの事象が、既に承認されていると いうことを意味しているに過ぎない。この後我々は、この事象の直前の複数のア ンセスタ事象を調べ、それらアンセスタ事象は、プロセス・タイム（k3,b3,p3） の直前に実行された x3 の複数のパラメータの夫々を計算している事象であり、 以下同様に更にそのアンセスタ事象を調べて行くようにする。 あるＷ事象が承認されたことによって起動されるこの知識伝搬のプロセスは、 目標プロセスの実行方向とは逆方向に実行されて行く。 定義Ｋ１１：事象の「直接的（直前）オーナー」： e2 によって el が承認された場合に、 e2 が el を所有する（e2 が el の オーナーである）という。 図１４において、 e(i) は e(d) に所有されているのであり、 e(o) に所有さ れてはいない。 定義Ｋ１２：事象の「Ｗオーナー」： 承認済事象(e) には、その各々に対応したＷオーナーが存在しており、Ｗオー ナーとは、その事象(e) からＷ事象系列を下って行った末端に存在する事象であ り、その事象(e) を承認した基本的知識伝搬のチェーンの発生源である。 いずれの事象も、その事象に対応したＷオーナー事象が２つ以上存在すること はあり得ず、その事象に対応した直接的（直前）オーナー事象が２つ以上存在す ることもあり得ない。ただし、ある事象のＷオーナー事象が、同時にその事象の 直接オーナーであるということはあり得る。 図１４において、 e(i) のＷオーナーは e(a) であって e(n) ではない。Ｗ事 象 e(a) は、 e(b)、e(f)、e(d)、e(i)、e(k)、e(m)、e(l) のいずれにとっても Ｗオーナーである。 図１５に示すように、ある１つの事象(e) が承認されたならば、その承認され た事象のＰＡのステータスが調べられ、もしそのステータスがＵＰＡ（不確実な プロセス・アドレス： Uncertain Process Addrcss）であったならば、そのステ ータスはＣＰＡ（正しいプロセス・アドレス： Correct Process Address）へと 格上げされる。プロセス・タイムが｛kW,bW,pW｝である事象(e) のＷオーナー事 象は、そのＣＰＡの、ＰＡステータスの格上げを担当する属性となる。 図１６は、様々に異なったプロセス・タイム t1、t2、t3、t4、t5 における、 同一のプロセス・アドレス(k,b) を示した図である。プロセス・タイム t1、t2 、t3、t4、t5 は、(k,b) の要素とは異なった、別の何らかの要素の実行を基準 としたものである。 プロセス・タイム t1 においてＰＡ(k,b) を見るならば、そのＰＡ(k,b) が状 態(k,b,0) にあることが見て取れる。この状態は、（k,b）を実行するという事 象が未だ一度も発生していないことを表している。 プロセス・タイム t2 においては、ＰＡ(k,b) が状態(k,b,2) になっているこ とが見て取れる。この状態は、（k,b）を実行するという事象が既に２回発生し たことを表している。それら２図の実行事象のいずれも、未だ承認されていない 。 ＰＡ(k,b) のステータスはＵＰＡになっている。 プロセス・タイム t3 においては、ＰＡ(k,b) が状態(k,b,3) になっているこ とが見て取れる。これは、このときまでに、(k,b) を実行するという事象が既に ３回（即ち、(k,b,1) 、(k,b,2) 、及び(k,b,3) の３回）発生したということに 他ならず、それらのうち事象(k,b,2) が承認されている。（k,b）のステータス はＵＰＡからＣＰＡへ格上げされており、またＷオーナー属性が付与されており 、これは(k,b,2) のＷオーナーであることを表している。 これ以外の(k,b) 実行事象が次々と承認されて行く間も、Ｗオーナー属性は変 化しておらず、(k,b,2) のＷオーナーのままである。 ＣＰＡのＷオーナー属性の働きによって、出力結果の承認状態に変化が発生し ているときにも、目標プロセスについての知識が、常に最新のものであり続ける ことが可能になっている。 一旦は承認された承認済Ｗ事象のうちの１つが非承認とされたならば、その目 標プロセスについての知識は、その目標プロセスのプロセス・タイム中における その非承認とされたＷオーナー事象の位置によって決定されるレベルにまで格下 げされる。ＸＰＤマシンのこのプロセスを我々は「知識喪失」プロセスと呼んで いる。 目標プロセスのＸＰＤモデルの構築 図７を参照されたい：ＸＰＤモデルはＸＰＤグラフに基づいて構築され、その 構造は３次元を基本とする。３次元を基本とするというのは、その３つの次元を 基本として更にその他の次元を追加し得るということであり、また、３次元のう ちの第３次元はＸＰＤグラフの２つの次元に基づいて構築される。 この第３次元はプロセス・アドレスの属性を包含した構造を表すものである。 様々な種類の属性が、様々なプロセス・アドレス（ＰＡ）に対して、即ち、様々 な｛ｋ，ｂ｝座標に対して付与され、また、付与される属性の種類は、そのプロ セス・アドレスに格納されている基本的プロセスの種類｛Ａ、Ｌ、Ｄ、Ｗ、Ｅ、 ＊、／、等々｝に応じたものとなる。 実行可能ステートメントに対応したＸＰＤモデルの各要素は、３つの属性を包 含しており、それら属性は夫々、 ａ）目標プロセスの中の対応するステートメントのレコード番号、 ｂ）ＸＰＤリポジトリの中の対応するステートメントのレコード番号、 ｃ）Ｘソース・コードの中の対応するステートメントのレコード番号、 への参照を表している。 これによって、目標プロセスと、その目標プロセスのＸＰＤモデル、ＸＰＤリ ポジトリ、及びＸソース・コードとの間の参照が確立されている。 ＸＰＤモデルには、実行可能ステートメントの各々に対応した、ローカル・タ イム属性が保持されている。 ＸＰＤモデルには、ＸＰＤグラフの要素の夫々に対応した、バイナリ・アドレ ス（ＢＡ）属性も装備されている。 全てのプロセス・ターミナルに対応した、リターン・バイナリ・アドレス（Ｒ ＢＡ）属性も装備されている。 リワインド・ターミナル(＊)、（Ｃ）または（＋）に対応したＰＡは、それら リワインド・ターミナルのリワインドＩＤ（ＩＤ／）属性を処理する。 ＩＤは、プロセス・アドレスの｛ｋ，ｂ｝形式の表示に代わる代替表示として 利用される。各々の対表示｛ｋ，ｂ｝は、このＩＤの１つの整数値によって表さ れ、その整数値はＸＰＤグラフ空間におけるそのＰＡの次数であり、このＸＰＤ グラフ空間を（ｋ＝１，ｂ＝１）から（ｋ＝ＭＫ，ｂ＝ＮＢ）へ通過して行くと きにｋパラメータを最初にインクリメントするときの次数である。 ＩＤ＝（ｂ−１）＊ＭＫ＋ｋであり、ここでＭＫは、ＸＰＤグラフにおけるｋ の最大値である。 従って図５（Ａ）において、ＰＡ（９，１）のグラフ要素＊１ではＩＤ＝９で あり、またＰＡ（９，２）のグラフ要素Ａ４ではＩＤ＝２３であり、なぜならば ＭＫ＝１４だからである。 次に、先ず、｛＊｜Ｃ｜＋｜Ｒ｜＝｝のうちのいずれかのプロセス・ターミナ ルに対応したＸＰＤモデルの第３次元を構成する構造の、実施態様の具体例を示 し、それに続いて、｛Ａ｜Ｌ｜Ｄ｜Ｅ｜Ｗ｜Ｘ｝のうちのいずれかの目的プロセ スの実行可能要索に対応し制御ステートメント｛Ｓ｝を変更する構造の実施態様 の具体例を示す。 それら構造のサイズ、及びそれらの構成要素のサイズは、実施態様がどのよう なものであるかに応じて異なるが、それら具体例には、ｘＰＤマシンを実施する 上で必要な構成要素だけを示した。 イグジット・ターミナル｛Ｒ，＝｝は、リワインド・ターミナルに装備されてい る属性のうち、次の属性を備えていない：｛ind，ID/，Repos.r.#｝。 ind は、ＸＰＤフレーム及びＸＰＤグラフの中の対応するプロセス要素のインデ クスである。 図５（Ａ）に示したＰＡ(14,3)に対応したＸＰＤ要素の具体例： ローカル・タイム属性は目標プロセスの実行時に記入される。 プロセス要素Ａ、Ｌ、Ｄ、Ｅを包含しているＰＡは、「ＡＣＢポインタ」属性を 備えており、ここでＡＣＢとは、解析計算ベースのことである。 更に加えて、Ｌ要素及びＤ要素は、ＬまたはＤの結果がポジティブであった場 合（ハイ・ポテンシャル・ソリューション）のｂ座標のインクリメント量を表す 値を規定する属性を有する： ＰＡのＡＣＢ−ｐｔｒ属性は、現在プロセス要素の「承認された」実行事象の ヒストリについての情報を包含している対応するＡＣＢ構造を指し示すポインタ である。 内部メモリ構造または外部メモリ構造の集合体であって、それらメモリ構造の 各々が、目標プロセスの夫々に異なった要素に対応していると共に、その要素の 挙動のその時点における「承認済」または「未承認」という形の既知のステータ スを構成している情報を包含しているものを、本発明では、目標プロセスの解析 計算ベース（ＡＣＢ）と呼んでいる。 ＡＣＢ構造の各々は、目標プロセスの実行可能ＰＡの１つずつに対応したもの であり、内部変数構造の形態で実現することもでき、また、ファイルの形態で実 現することもできる。 唯一のルールは、ＡＣＢ構造のどの構成要素も、日標プロセスの複数の要素の うちのそのＡＣＢ構造に対応している１つの要素の実行事象を表しているという ことである。その事象のローカル・タイムは、ＡＣＢ構造中における位置によっ て表される。 ＡＣＢ構造の要素の値は、「オン」と「オフ」という２つの状態のうちの１つ にセットすることができ、ここで「オン」は承認済事象に対応し、「オフ」は未 承認事象（即ち、不確実な事象）に対応するものである。 図１９を参照されたい： 本実施態様では、ＡＣＢ−ｐｔｒがバイナリ・ファイルを指し示すようにして あり、このバイナリ・ファイルは２つの部分に分けられている。第１の部分は制 御領域である。この制御領域は２種類の情報を保持しており、２種類の情報とは ネクスト・パラメータ・ワード（ＮＰＷ）と、不確実性ディスプレースメント・ ワード（ＵＤＷ）とである。第２の部分は情報領域を含んでおり、この領域は、 複数の「知識状態」ビットを保持している。幾つもの要素実行事象によってこの ＡＣＢ−ｐｔｒが作り上げられており、それら要素実行事象の各々が、情報領域 の中の１つのビットで表されており、そのビットが「知識状態」ビットである。 そのバイナリ・ファイルの情報領域の始点に対するそのビットの相対位置が、そ の事象のローカル・タイムに対応しており、またそのビットは、その事象の「正 しさ」のステータスについての「知識」の現在状態に応じて「オン」または「オ フ」にセットされている。 様々なファイル圧縮技法を利用することができる。本実施態様では、ＵＤＷに は、その状態が「０」の最初のビットの相対ディスプレースメントを保持させて ある。要素実行事象の承認が１つもなされていないときには、それに対応してＵ ＤＷは「０」になっており、また、情報領域の先頭のビットは、最初の要素実行 事象に対応しており、情報領域の圧縮は行われていない。 これより後のある時点に至ったときに、ＵＤＷが例えば「２０００」にセット されたとするならば、それは、情報領域の先頭のビット位量が、ローカル・タイ ム「２００１」に対応していることを表すものであり、また、それに先行して実 行された２０００回の要索実行事象の全てが承認されたことを表すものである。 そのため、上述のＡＣＢポインタに対応しているバイナリ・ファイルが、ビット 位置２０００個分の左方シフトによって圧縮される。このようにしているのは、 最初の２０００個までのビット位置が「１」で占められるべきビットであること が分かっているからである。 ＵＤＷの値は、現在目標プロセス要素を解析しているＸＰＤマシンの「知識帰 納」プロセスまたは「知識喪失」プロセスの実行中に、いずれの方向へも変化さ せることができる。これは、対応したＡＣＢ構造の情報領域の中で、ビットのシ フトを行うことによって達成することができる。 例えば、Ｄ１のＡＣＢの情報領域の、第１番ビット位置と第４番ビット位置と が、「知識帰納」プロセスの実行中にそれらのステータスが「オン」に変化させ たならば、そのＤ１のＵＤＷが１０進数の「７」にセットされ、その情報領域の ビットが、ビット位置７個分左方へシフトされる。 入力ステートメント｛Ｅ｝のパラメータと、コール・ステートメント｛Ｘ｝の パラメータとは、それらのパラメータの各々が、そのパラメータに専用の１つず つのＡＣＢ構造で表される。 対応するモデル要素のＡＣＢ−ｐｔｒは、先頭のパラメータに対応したＡＣＢ 構造を指し示している。そのＡＣＢ構造のネクスト・パラメータ・ワード（ＮＰ Ｗ）は、それ続く次のパラメータ（もし存在していれば）に対応したＡＣＢ構造 を指し示しており、以下同様である。続く次のパラメータが存在していない場合 には、そのＮＰＷは空になる。 ５つの実行可能要素｛Ａ１、Ａ２、Ｄ１、Ｅ１、Ｘ１｝を包含しており、その うちのＥ１が、２つの入力パラメータを持ち、またＸ１が、３つのコール・パラ メータを持っている目標プロセスでは、そのＡＣＢ構造が、例えば図１９に示し たような形を取る。 目標プロセスのＸＰＤリポジトリの構築： 図７を参照されたい：目標プロセスのＸＰＤリポジトリは、ＸＰＤグラフと同 時に構築される（ただし、ＸＰＤフレームを構築するステップが実施される場合 には、ＸＰＤフレームと同時に構築されることもある）。実行可能ステートメン ト（ＸＰＤオブジェクト集合の、Ａ、Ｌ，Ｄ、Ｅ，Ｘ、及びＳ要素）に対応した メイン・ブランチの各要素は、ＸＰＤリポジトリのファイルに格納される。 ＸＰＤリポジトリに包含されるコードの量は、それに対応した目標プロセスの ソース・コードより少ない。その理由は、ＸＰＤリポジトリは、プロセス制御ス テートメントを包含しないからであり、プロセス制御ステートメントは、それに よってプロセスのステートメントを理解するためのものであって、データの操作 や有効性の検証には関与しておらず、従ってＸＰＤリポジトリは、無条件分岐、 停止、リターン、then、else、endif、等々を包含しない。 またそれと共に、前述の「ネクスト・ローウェスト・ポテンシャル原理」によ って目標プロセスからアルゴリズムが抽出されているならば、その制御構造は、 ＸＰＤグラフ及びその基礎の上に構築されたＸＰＤモデル（図７）の構造の中に 保存される。 従ってＸＰＤリポジトリには、プロセス制御の定義を除いてその他全てのプロ セス要素が包含され、プロセス制御の定義はＸＰＤモデルの中に保存される。 例１：目標プロセスのステートメントが次のものである場合には： if（d<10）go to label リポジトリには次のものが包含される； if（d<10） 例２：目標プロセスのステートメントが次のものである場合には： if（a.gt.b）then c = d else e = f(g) endif return リポジトリには次のものが包含される： if（a.gt.b） c = d e = f(g) ＸＰＤリポジトリの各ステートメントは、ＸＰＤモデルの中の対応するプロセ ス・アドレス｛ｋ，ｂ｝の属性の中で参照される。例えば、そのリポジトリが、 ＲＲＤＳ（相対レコード・データ集合：Relative Record Data Set）として維持 されている場合には、対応した参照属性が、そのリポジトリの中の対応したステ ートメントのレコード番号を包含していなければならない。これについては、上 述の「目標プロセスのＸＰＤモデルの構築」のパラグラフの中の、リポジトリの レコード番号（Repos.r.#）の説明を参照されたい。 ６．Ｘソース・コードの構築； 目標プロセス実行履歴を入手するための最小オーバーヘッド命令 インクリメンタル・システム出力プロセス同期（ＩＳＯＰＳ）マップによるユ ーザーＸＰＤマシン目標プロセス・インターフェースの構築； システム入力プロセス同期（ＳＩＰＳ）マップの構築； Ｘソース・コードの構築 伝統的オブジェクト・コードから実行されている目標プロセスをＸＰＤマシン により分析（解析）するために、プログラムの目標システムの各目標プロセス（ 主プログラム、サブルーチンあるいは関数）のＸＰＤモデルおよびＸＰＤ格納部 （レポジトリ）からＸソース・コードを構築する。 Ｘソース・コードを生成する目的は、目標プロセスと、目標プロセスの挙動（ 行動）の知識を蓄積するＸＰＤマシン・プロセスとの間の同期の計測化にある。 計測化された同期信号を除いて、Ｘソース・コードは、このＸソース・コードが 「デッド・コード」即ち到達不能コードは含まない点と、第２の目標ソース・コ ードがＸＰＤモデル・ルールによって構成されなかった、即ち例えば余計なＧＯ ＴＯを持たなかったならば元のソース・コードに従って潜在的に再構成される 点とで、元の目標プロセスのソース・コードとは潜在的に異なる。 図７および図８について Ｘソース・コード発生器（図７の１７）により２つのオブジェクト、即ちＸＰ Ｄモデル（図７の８）とＸＰＤレポジトリ（図７の１０）から生成されるＸソー ス・コードは、更に、ＸＰＤインターフェースへ送られる同期信号（４）を介し てＸＰＤモデルを「動作」させ、このインターフェースが更に信号（６）を介し てコマンド（７）を介してＸＰＤモデルを「動作」させる分析エンジン（解析機 関）を付勢する。 Ｘソース・コードがＸＰＤモデルとＸＰＤレポジトリから構築され、これらは 更に目標プロセスのソースから構築されるので、目標プロセスとＸＰＤモデルと Ｘソース・コードとの間には１対１の機能的相等性が存在する。 Ｘソース・コードの生成のためには、下記のことが行われる。即ち、 −Ｘソースに対する各実行可能ステートメントの内容がＸＰＤレポジトリ（図 ７の１０）から得られ、 −制御ステートメントがＸＰＤモデル（図７の８）から構成され、 −目標モデル同期信号が計測化される（図２０と図２１における事例参照） 目標プロセスとＸＰＤ分析エンジン間の同期インターフェースの構築は、以下 の論題で定義される「遅延逐次」モデル同期の事例について説明する。 同期信号は、ここではＸＰＤインターフェース（ＸＰＤＩ）（１１）へ３つの パラメータ（ｋ、ｂ、ｍ）を送る「呼出し」ステートメント（図８の４）により 生成される。但し、（ｋ、ｂ）はプロセスのアドレスを定義する対であり、（ｍ ）は目標プロセスのモデルを定義する、即ち、どの目標プロセスがその時実行中 であるかを定義する。 ３つのプロセス（ｋ、ｂ、ｍ）の代わりに、２つのパラメータ、即ち（ＩＤＴ 、ｍ）によってインターフェースを実現することもできる。但し、ＩＤＴは要素 のプロセス・アドレスの代替的表示であり、先に述べた式によって対応する終端 （ターミナル）の座標（ｋ、ｂ）から計算される。 ＩＤＴ＝（ｂ−Ｉ）＊ＭＫ＋ｋ；（ＩＤ式） 但し、ＭＫは目標プロセスのモデルの最大ｋ座標である。 目標プロセス実行履歴を入手する最小オーバーヘッド命令 終端同期呼出しは、プロセス終端（定義Ｆ３）を表わす各ステートメントの前 に加えられる。 図４からの事例：ものとするとモデルによりプログラムのシステム内で識別さ れるプロセスに対するＸソースを構築しつつあるものとすると、ｍ＝２は、分岐 ｂ＝１の終端からＧＯ ＴＯ終端を表わす時、 ｃａｌｌ ＸＰＤ（９、１、２） ｇｏ ｔｏ ‘ＬＡＢＥＬ ａ’ また、分岐ｂ＝５の終端から ｃａｌｌ ＸＰＤ（１０、５、２） ｇｏ ｔｏ ‘ＬＡＢＥＬ ａ’ ‘ＬＡＢＥＬ ａ’の構文は、異なるプログラミング言語では異なる。プログ ラム実行履歴を記録するこの方法は、次に説明するように、最小オーバーヘッド （最小計装）を表わす。 ＸＰＤＩは、ＰＡがＸＰＤＩにより終端として識別される呼出しを受取る時、 このＰＡを（ｍ）と共にシステム実行履歴ファイル（図８の３）に記録する。 図８において、ＸＰＤインターフェース（ＸＰＤＩ）モジュールがＩＤＴを対 （ｋ、ｂ）で先に述べた「ＩＤ式」により変換する。 モデルにおける座標（ｋ、ｂ）を見出すことにより、ＸＰＤＩモジュールがど の終端が同期信号を送ったかを識別する。 実行されたプロセス終端のシーケンスは、１つの目標プロセスの所与のモデル に対する目標プロセスの挙動履歴を再現するために充分かつ必要な（最小オーバ ーヘッド）情報である。 説明：当該モデル内には、ＳＴＡＲＴと特定の終端（ターミナル）の間、ある いは前の終端と次の終端とのリワインドＩＤのエントリ間には１パスが存在する のみである。このリワインドＩＤ（ＩＤ／）は、モデルが構築される時、ＸＰＤ モデルの各終端の属性として格納されている。 ＸＰＤＩは、次に実行される目標についての情報を受取る時、目標プロセス内 でその時実行されるパスの部分、即ち前に実行された終端のリワインドＩＤ（即 ち、プロセスに入ってからその時実行される終端が最初のものであれば、ＳＴＡ ＲＴ）からその時の終端までを再トレースするように分析エンジンに指令する。 ＰＡを介する各パスは、その実行事象を表わし、その局所時間属性（ｐ）を１だ け増分する。 例えば、図４のＸＰＤグラフから構築されたＸソース・コードの実行中に下記 の信号がＸＰＤＩにより受取られたものと仮定しよう。即ち、４５、９、５５。 これらは、次のＰＡのＩＤＴである。即ち、｛１４，３｝、｛９，１｝、｛１ ０，４｝。これは、目標プロセスが下記の経路により実行されたことを示す。即 ち、 Ａ１ Ａ２ Ｌ１（−）Ａ３ Ｌ２（＋）Ａ４ Ｘ１（＋）Ａ６ Ｗ１ Ａ３ Ｌ２（−） Ａ２ Ｌ１（＋）Ｗ２ Ｅ１ Ｌ３（−）Ａ７ストップ しばしばＤＯ、ＦＯＲ、ＷＨＩＬＥなどにおける場合のように同じ終端の反復 を表わすため、負の数を使用する。例えば、２７ −５ ４２は、ＤＯサイクル から出る前に、ＤＯループＤ１が負の決定（主体を通る時）を６回した（ＩＤＴ ＝２７の終端に達した）ことを意味する。 前の事例では、プロセス挙動履歴の２９事象を表わすのに３つの同期信号４２ 、９、５２を用いた。プロセス履歴を表わす他の選択は、下記のいずれかである 。即ち、 −当該事例では２９信号を生成しなければならないあるデバッグ・パッケージ で行われるように、各実行要素の後に同期信号を送るか、あるいは −パスしたＬＣからなる対｛Ｌ１，０｝｛Ｌ２，１｝｛Ｄ１，１｝｛Ｌ２，０ ｝｛Ｌ１，１｝｛Ｌ３，０｝、即ち１２信号をその解と共に記録する。 実行されたプロセス終端のシーケンスを記録することによるプロセス実行履歴 の記録が目標プロセスのダイナミックスについての必要かつ充分な情報であるこ とを示したばかりである。これは、同期信号の数と、伝統的なオブジェクト・コ ード処理を用いて目標プロセスのダイナミックスを捕捉するために必要な計装挿 入数の双方における最小オーバーヘッドを実現する。更に示すように、この計装 は、ＸＰＤオブジェクト・コードを用いる時には必要ではない。 インクリメンタル・システム出力プロセス同期（ＩＳＯＰＳ）マップによるユー ザ−ＸＰＤマシン−目標プロセス・インターフェースの構築 以下は、ユーザと、ＸＰＤマシンを介する目標プロセスとの間のインターフェ ースについて記述する。このインターフェースは、本発明が確信する如く、目標 ソフトウエアの分析のためあり得る最も高レベルのインターフェースである。Ｘ ＰＤマシン分析は、システム出力の照合によって付勢される。 我々がプログラムを書く理由が、システム出力の結果である。プログラムを修 正しあるいは決定することを欲する理由がシステム出力結果である。現在あるプ ロセスを理解しようとするかあるいは新たなプロセスの構築を試みる時に記憶を 念頭に置くのは現在あるかまだ無いかの如何を問わずシステム出力結果である。 システムの結果を受入れるか、受入れないか、あるいはこれを照合するか、プロ セスの分析またはプロセス構成に対する外ならぬ「理由」として成り立つもので ある。 ここで堤案した手法は、ＸＰＤ分析エンジンに対して、この「理由」が分析を 活性化する方法として通信する、従ってこれ以上の中間ステップを排除すること を許容する。更に述べる方法は、ユーザとＸＰＤ分析エンジンとの間にインター フェースを構築すること、即ち、人間による認知分析を活性化するために直感的 に行われるように照合点としてシステムの結果を用いることを許容する。 インクリメンタル・システム出力プロセス同期マップ（ＩＳＯＰＳマップ）は 、出力信号とこれら信号を生じたプロセス事象との間の照合の具である。 以下は、ＩＳＯＰＳマップのサンプル・フォーマットである。これは、５つの タイプのエントリ｛１，２，３，４，５｝からなっている。 エントリ１：｛ｋ，ｂ，ｐ，ｍ｝プロセス・パラメータを介するＷ事象を定義 する エントリ２：システム出力スクリーン上のその時の出力信号の初めの位置｛ｓ ｌ，ｓｃ｝（スクリーン行、スクリーン欄）を定義する。 エントリ３：システム出力スクリーン上の矩形ブロック｛Ｉ１，ｃ１，Ｉ２， ｃ２｝上の矩形ブロック、即ちＷ事象の実行により変更されるスクリーン領域を 含む最も小さな矩形ブロックを定義する。 エントリ４：整数情報、即ち、変更されたイメージ情報を含むファイル（エン トリ５の組合わせファイル）の初めからの対応するエントリ５の変位を含む。 エントリ５：エントリ３の領域と対応するシステム出力スクリーン・バッファの 実際部分を含む。 エントリ５がスクリーン・バッファの変更領域および唯一つの変更可能サイズの 記録のイメージであるため、これを別のファイル−インクリメンタル・イメージ ・モニターに保持する（図８のＩＩＭファイル）。エントリ１、エントリ２、エ ントリ３およびエントリ４に対応する他の４つのＩＳＯＰＳマップ・パラメータ は、 ＩＳＯＰＳマップ・パラメータ・ファイル（図８のＩＳＯＰＳパラメータ）に保 持される。ＩＳＯＰＳパラメータ・ファイルおよびＩＩＭファイルの組合わせは 、システム結果の履歴（図８の２）と（図７の２）を表わす。 ＩＳＯＰＳマップのサンプル・フォーマット： 以下は、ＩＳＯＰＳマップの構築に用いた値について述べる。即ち、 エントリ１：Ｗ−事象｛ｋ，ｂ，ｐ，ｍ｝を記述し下記の如く得られる。即ち 、｛ｋ，ｂ，ｍ｝は目標プロセスによりＸＰＤＩ（図８の１１）へ送られる同期 パラメータ（図８の４）であり、ＸＰＤＩは、前記｛ｋ，ｂ｝プロセスのアドレ スと対応するプロセス要素構造のその時の時間属性として｛ｍ｝に対応するモデ ル（８）から｛ｐ｝を得る。この時間属性は、以降の節で述べるように、分析エ ンジン（９）によってカレントに保持される。 エントリ２：各システム出力信号の初めのスクリーン（行および欄）｛ｓｌ， ｓｃ｝位置で、下記の如く得られる。｛ｓｌ，ｓｃ｝エントリは、外ならぬ最初 のＷ−事象エントリに対して等しい｛１，１｝。ＸＰＤＩがＷ−事象により送ら れる同期信号を受取る時、ＸＰＤＩはその時、即ち実際にはこのＷ−事象の実行 後にスクリーン位置を得る。このスクリーン位置は、次のＷ−事象に対する｛ｓ ｌ，ｓｃ｝エントリとして用いられるように保持される。 エントリ３：スクリーン上に描写できる最も小さな矩形であり、前のＷ−事象 の処理時間から変更されたスクリーン領域を含む。この矩形は、前のＷ−事象後 の処理時間にセーブされる前のスクリーン・イメージ（図８の１５）と、その時 のシステム出力スクリーン・バッファ（図８の５）との比較によってインクリメ ンタル・イメージ抽出／解釈プログラム（図８の１２）により定義される。 エントリ４：ＩＩＭファイルにおけるインクリメンタル・イメージ・モニター のその時のエントリの相対的バイト位置であり、この位置はインクリメンタル・ イメージ抽出／解釈プログラム（ＩＩＥ／Ｃ）（図８の１２）によって知られる 。ＩＩＥ／Ｃは、ＩＩＭファイルに対する各エントリのバイト長さが判るので、 その時の位置を知る。 エントリ５：エントリ３の矩形と対応するシステム出力バッファの一部である ＩＩＭファイルに対するその時のエントリである。 システム入力プロセス同期（ＳＩＰＳ）マップの構築 ＳＩＰＳマップは、分析のためのアクセスを行い、あるいは特定の処理時間にお いて行われるシステムに対する特定の入力を再現すること可能にするために構築 される。ＳＩＰＳマップは、ＳＹＳＩＮ履歴ファイル（図８の１）および（図７ の１）に保持される。各システム入力事象毎に、エントリがＳＹＳＩＮ履歴ファ イルに対して行われる。このエントリは２つのレコードからなる。１つは実際の 入力ストリングであり、他方はその時の入力ストリングと対応する処理時間｛ｋ ，ｂ，ｐ｝とモデル｛ｍ｝を記述するパラメータ｛ｋ，ｂ，ｐ，ｍ｝の組である 。 ＸＰＤインターフェース・モジュール（図８の１１）は、同期パラメータ｛ｉ ｄｅ，ｍ｝（図８の４）とシステム入力バッファ（ｍ）（図８の１９）からのＳ ＹＳＩＮ履歴ファイルに対するエントリを生成する。｛ｋ，ｂ｝はＩＤの式によ り｛ｉｄｅ｝から計算される。パラメータ｛ｐ｝はＸＰＤモデル無いのその時の 処理時間からＸＰＤＩにより得られる。 図２１は、終端（図２０のＥ１）からの入力前に計測化される｛ｉｄｅ，ｍ｝ 同期呼出しＣＡＬＬ ＸＰＤＩ（２１，２）の一例を有する。システム入力が目 標プログラムから判ると直ちに、これは計測化された次のステートメント“ＷＲ ＩＴＥ（Ｍ，００２）ＣＨ”によりバッファ・ファイル（ｍ）（図７の１９）に 記録され、更に後でＸＰＤＩモジュールによりＳＹＳＩＮ履歴ファイルへ再記録 される。システム入力を記録する計測化ステートメントは、「ＲＥＡＤ」から「 ＷＲＩＴＥ」へのＩ／Ｏ動作をカバーすることにより構築され、これはモニター ・ファイル｛ｍ｝へ送られる。 ７．目標プロセス、そのＸＰＤモデル、ＸＰＤリポジトリおよびＸソース・コー ドの事例 図２０、図２１および図７を参照。 図２１Ａはサンプル・サブルーチンである。図２０ａはそのＸＰＤグラフで、 これはＸＰＤモデル（図７の８）が構築される基礎である。図２０Ｂは、図７の 先に述べたプロセス１８によりサンプル・サブルーチンから取出されるＸＰＤリ ポジトリ（図７の１０）である。図２１ＢはＸソース発生器（図７の１７）によ り図２１ＡサンプルのＸＰＤグラフおよびＸＰＤリポジトリから構築されるＸソ ース・コードである。ＸソースはＸＰＤインターフェース・モジュール（図７の １１）に対する呼出しを含み、この呼出しは、各プロセス終端（定義Ｆ３）前に 計測化される。 ＣＡＬＬ ＸＰＤＩ（６，２） ＣＡＬＬ ＸＰＤＩ（１４，２） ＣＡＬＬ ＸＰＤＩ（２４，２） ＣＡＬＬ ＸＰＤＩ（３１，２） ＣＡＬＬ ＸＰＤＩ（３５，２） 各システム入力信号前（終端からのＥｉ）：ＣＡＬＬ ＸＰＤＩ（２１，２） 各システム出力信号後（Ｗｉ）： ＣＡＬＬ ＸＰＤＩ（２０，２） 但し、６，１４，２４，３１および２５は、終端Ｃ２＊１，Ｃ１，＝およびこれ と対応してＲのｉｄｔであり、２０はＷ１のｉｄｗであり、２１はＥ１のｉｄｅ であり、２は本例では２に等しくなったモデルＩＤｍである。 モデルＩＤ，ｍは、そのモデルおよびリポジトリの図７のプロセス１８による 抽出中の各目標プロセス（主手順、関数またはサブルーチン）に対する１−増分 度で割当てられる整数である。 先に述べた｛ｉｄｔ，ｍ｝および｛ｉｄｗ，ｍ｝および｛ｉｄｅ，ｍ｝は、図 ８における同期パラメータ４である。 図２０Ａでは、リワインド終端エントリ／１（１０１０）のＢＡが値において 対応するリワインド・エントリ＊１（１００１）のＢＡより大きいことが判る。 このことは、依然として、先に定義した、即ちより下位の２進アドレスをもつプ ロセス・セグメントで既に表わされるプロセス要素へ制御を戻すリワインド終端 の原理に矛盾するものではないが、これはその場合の制御が下位の２進アドレス を持つＤＯループ（要素Ｄ１）のエントリへ実際に戻されつつあるためである。 しかし、プログラミング言語内のＤＯループの実現ルールに従えば、この制御の 戻しは更に制御をＤ１へ戻すＤＯ終端（要素Ｃ１）を通過する中間ステップを介 して行われなければならない。 目標プロセス・モデルの「疑似並列」実行：「遅延逐次」と「遅延並列」ＸＰ Ｄモデルの実行； 目標プロセスのＸＰＤモデルの実行によって、目標プロセスの実行経路に従って そのＸＰＤグラフを追跡するプロセスを理解する。 ＸＰＤモデルの遅延逐次実行； 「ＸＰＤモデルの遅延逐次実行」は、ＣＰＵ、即ち２つのタスク間で切換わる１ つまたは幾つかのＣＰＵによって実現されつつあり、この場合１つのタスクは目 標プロセスの「実行セグメント」であり、他のタスクは、ＸＰＤオブジェクトＳ ＥＴの以降の要素、即ち、プロセス・エントリ、システム入力点（同期｛ｉｄｅ ，ｍ｝および「プロセスの終端」（同期｛ｉｄｔ，ｍ｝））間に置かれる目標プ ロセスの一部として定義される「実行セグメント」を持つＸＰＤ分析エンジンに よる前記プロセスのＸＰＤモデルにおける最初のタスクのモデル化である。 ＸＰＤモデルの遅延並列実行 「ＸＰＤモデルの遅延並列実行」は１つ以上のＣＰＵにより実現されつつあり、 この場合目標プロセスの「実行セグメント」のタスクと、ＸＰＤ分析エンジンに より前に実行された「実行セグメント」のモデル化のタスクとは並列に行われる 。 ＸＰＤモデルの「疑似並列」実行の方法は共に、プロセス終端｛ｉｄｔ，ｍ｝ とシステム入力｛ｉｄｅ，ｍ｝からの同期信号によって実現されるが、最初の場 合は、ＸＰＤ分析エンジン・プロセスの実現はＣＡＬＬステートメントの形態で 行われ、この場合目標プロセスはＸＰＤＩモジュールから制御の返還を待ち、２ 番目の場合は、並列プロセスは同期信号によって得られる。前記同期信号｛ｉｄ ｅ，ｍ｝および｛ｉｄｔ，ｍ｝は、ＸＰＤモデルをして目標プロセスにより「更 新」させるように設計される。同期信号｛ｉｄｗ，ｍ｝は、目標プロセスおよび ＸＰＤモデル内の処理時間によりＩＳＯＰＳマップを「更新」させるように設計 される。 先に述べたようにプロセス終端からの信号が最小オーバーヘッド計測化を表わ すので、これら信号もまた目標プロセスによりモデルを更新するよう保持するた めに最小オーバーヘッド同期信号を表わす。システム入力の点における同期は、 「オペレータ思考時間」中に目標プロセスをなんらかの方法で割込まれるので便 利である。 ９ ＸＰＤ分析エンジンの実行 目標プロセス内の原因−効果関係の分析計算基 礎の構築および伝播；知識帰納； 図８を参照する。以降のプロセスは、ＸＰＤＩ（１１）が、形態｛ｉｄ，ｍ｝ または｛ｋ，ｂ，ｍ｝（図８の４）において実現される同期信号を受取る時に生 じる。形態｛ｉｄ，ｍ｝における実現を仮定する。ＸＰＤＩは、先に述べた「Ｉ Ｄ式」によりモデルｍのＭＫの値を知って、対応するモデル｛ｍ｝の｛ｋ，ｂ｝ における｛ｉｄ｝を変換する。 ｂ＝（ｉｄ−１）／ｍｋ＋１ ｋ＝ｉｄ−（ｂ−１）＊ｍｋ プロセス・アドレス｛ｋ，ｂ｝は、プロセスの終端（定義Ｆ３）を指示すると 、 ｛ｉｄ｝は｛ｉｄｔ｝となり、あるいはシステム出力信号（Ｗ）を指示すると、 ｛ｉｄ｝は｛ｉｄｗ｝となり、あるいは終端（Ｅ）からの入力を指示すると、ｉ ｄは｛ｉｄｅ｝となり、さもなければ、他の可能性が存在する。即ち、 ＸＰＤＩが｛ｉｄｔ｝同期パラメータを受取ったならば、この｛ｉｄｔ｝はシ ステム実行履歴ファイル（図８の３）へ書込まれる。 同期信号が｛ｉｄｅ，ｍ｝または｛ｉｄｔ，ｍ｝であるならば、ＸＰＤＩはＸ ＰＤ分析エンジンを始動して下記のプロセスが生じる。即ち、 −ＸＰＤ分析エンジンが前の同期信号｛ｋ，ｂ｝の点から、あるいはプロセス 実行履歴の記録のための最小オーバーヘッド計測計装を論議した時前に述べたよ うに、その時の同期信号の｛ｋ，ｂ｝の入力点からモデルを再トレースする。 −ＸＰＤモデルの各要素の通過中、その局所時間属性｛ｐ｝が１だけ増分され 、これによりカレントに保持される。 −システム出力である（Ｗｉ）要素が満たされると、ＸＰＤ分析エンジンが「 知識帰納」連鎖のサイクルを解する（請求の範囲第９項）（定義Ｋ１０：「知識 伝搬終端」事象（ＫＰ終端）および図１４参照。これにおいては、（Ｗｉ）が１ つ以上の出力パラメータを持つならば、各サイクルがシステム出力パラメータに より創成される） 知識伝搬終端は、「知識帰納」処理を安定化し、この処理はさもなければ長引 き、目標プロセスの前向き実行でのより長い２次プロセス連鎖となる。正しいア ルゴリズム・スペースは潜在的に伝搬され、ＰＡのＷ−オーナ事象が知識帰納プ ロセスによって確立される（定義Ｋ１２、「事象のＷ−オーナ」および図１４、 図１５、図１６、図１７、および先に述べた「知識伝搬ルール」を参照）。 実行事象の状態が「知識帰納プロセス」によって「不確実」から「適正な」へ 改善される毎に、対応するＡＣＢ規約における対応ビットが０から１へ向上され 、これによりＡＣＢの知識を増大する。（ＡＣＢの定義および図１９参照） ｛ｉｄｅ，ｍ｝同期信号の間、ＸＰＤＩが｛ｋ，ｂ，ｐ，ｍ｝レコードをＳＩ ＰＳマップ（図８の１）へ移し、ここで｛ｐ｝はその時同じ同期信号により更新 され、｛ｋ，ｂ｝が前に述べた「ＩＤ式」によって｛ｉｄｅ｝から得られる。 図２１のステートメントＣＡＬＬ ＸＰＤＩ（２１，２）を参照する。｛ｋ， ｂ，ｐ，ｍ｝エントリが｛５，３，ｐ，２｝を探す。ここで、｛ｐ｝はＸＰＤＩ がＸＰＤモデルから得ることになるその時更新される局所時間属性である。下記 のステートメント、即ち、ＷＲＩＴＥ（Ｍ，００２）ＣＨが、モニター・ファイ ル（ユニットＭ）（図７の１９）に実際の入力レコードを入れる。これは、次の 同期信号中にＸＰＤＩによって一時的モニター・ファイル（Ｍ）から同期パラメ ータ｛ｋ，ｂ，ｐ，ｍ｝の次のシステム入力履歴ファイルへ複写されることにな る。 同期信号がシステム出力要素｛ｉｄｗ，ｍ｝から到来するならば、ＸＰＤＩが ＩＳＯＰＳマップの更新のため先に述べたプロセスを開始し、次に制御を目標プ ロセスヘ戻す。ＩＳＯＰＳマップの｛ｋ，ｂ，ｐ，ｍ｝パラメータを生成する間 、ＸＰＤＩがＸＰＤ戻すの対応するＷｉ要素から局所時間パラメータ｛ｐ｝を用 いてこれを１だけ増分するが、これは｛ｉｄｗ，ｍ｝信号がＸＰＤ分析エンジン のモデル同期プロセスを実行しないからである。 １０ 常に低減する不確実さによる修正のための偽の位置または場所の領域を局 在化するために、ＩＳＯＰＳマップを照合することによりＸＰＤ分析エンジンの 「知識演繹」プロセスを活性化 システム出力からのプログラムのシステム内の事象を絶対的にアドレス指定す る能力が４つの座標｛ｋ，ｂ，ｐ，ｍ｝により確保される。プログラム・ソース ・コードを参照することなくシステム出力からのシステム内の事象−プログラム ・ユーザまたはプログラマから見える何かをアクセスして分析することができる ことは、分析ツールのユーザと目標プロセスとの間の本発明のインターフェース に対してオリジナルを表わす。 「知識の演繹」：図１３参照。不確実性アルゴリズム・スペースは、先に述べ たＸＰＤ分析エンジンの「知識の演繹」によって一貫して最小化される。「知識 の演繹」プロセスは下記の如く実現される。 ＸＰＤマシンのユーザは、インクリメンタ・イメージ抽出／解釈プログラムに よってシステム結果履歴から反復されるシステム出力を調べる。カーソル、マウ スその他のポインティング・デバイスをシステムの結果に置くことにより、ＩＳ ＯＰＳマップの｛ｋ，ｂ，ｐ，ｍ｝パラメータが付勢される。 参照されたシステム出力結果がＸＰＤマシンに対して「予期されない」、従っ て正しくないとして定義されるならば、ＸＰＤ分析エンジンが、ここでは「知識 演繹終端」と呼ばれる「知識伝搬終端」まで、目標プロセス実行と反対方向に事 象をトレースする「知識帰納」の同じルールに従う「知識演繹」プロセスを始動 することになる。唯一つの相違は、問題の出力事象の「事象定義スペース」の一 部である「不確実性アルゴリズム・スペース」を回復するプロセス中では、知識 の増加がＡＣＢ規約で行われないことである。この不確実性アルゴリズム・スペ ースは、「知識演繹終端」に対する連鎖におけるＵＰＡアドレスの組合わせであ る。図１３において、プロセス時間ｔ３におけるｄ（ｅ３）事象定義スペース内 の／／スペースによって記号的に表わされる。図１３で判るように、事象定義ス ペースの不確実部分は、目標プロセスの定常アルゴリズム・スペースおよび常に 増加する適正アルゴリズム・スペースによって常に最小化される。 ＣＰＡのＷ−オーナ属性は、出力結果の受入れにおける変動中も目標プロセス の知識を更新状態に保持させる。 先に受入れられたＷ−事象の１つが受入れられない時、目標プロセスの知識は 、目標プロセス時間における受入れられないＷ−オーナ事象の位置によって決定 されるレベルまで落とされる。このプロセスを「知識を低減する」ＸＰＤマシン と呼ぶ。図１３において、知識の喪失は下記のシナリオ内で理解することができ る。即ち、 １．目標プロセスは処理時間（ｔ３）まで実行され、これが適正アルゴリズム ・スペース（ＣＰＡは、同図では文字÷によって表わされる）を処理時間（ｔ３ ）で示されるレベルまで高める。 ２．後で、失敗（即ち、結果の修正を必要とする）は、処理時間（ｔ２）で結 果に関して確立される。知識レベル（適正アルゴリズム・スペース）は、処理時 間（ｔ２）で示されるレベルまで落とされる。これは、Ｗ−オーナ事象が処理時 間（ｔ２）後に生じたＰＡに対するＣＰＡからＵＰＡまでの状態の喪失により行 われる。 「知識の喪失」能力は、個々の予測に関し、あるいは個人の変更される予測に 関し、あるいは変更されたシステム仕様に関する失敗の定義に従って、ＸＰＤマ シン・プロセスを柔軟かつ現実的なものにする。 １１ ＸＰＤグラフおよびＸＰＤリポジトリの解釈 図２０を参照する。目標プロセスの制御は常に、目標プロセスのＸＰＤモデル が構築される２次元ベースであるＸＰＤグラフによって完全に表わされる。目標 プロセスは、そのＸＰＤグラフ（図１８Ｃ）をトレースすることによりＸＰＤモ デルを実行中ＸＰＤリポジトリのステートメントを解釈することによって実行さ れる。このような実現では、図７に示された伝統的なオブジェクト・コードの実 現の以下の要素は必要でない。即ち、 −Ｘソース発生器 −Ｘソース・コード −コンパイルおよびリンク −Ｘ−オブジェクト・コード 図１８Ｃを参照する。言語インタープリタ（２３）が、ＸＰＤモデルの実行（ 構文解析）中にＸＰＤリポジトリ・ステートメントを解釈する。インタープリタ からの信号（２４）が次の３つの値の１つであるコードを返す。即ち、 （ａ）論理ステートメントではない（ＬでもＤでもない）ＸＰＤリポジトリ・ ステートメントが実行され、 （ｂ）論理ステートメント（ＬかＤ）であるＸＰＤリポジトリ・ステートメン トが否定的に実行され、 （ｃ）論理ステートメント（ＬかＤ）であるＸＰＤリポジトリが肯定的に実行 される。 ＸＰＤドライバが、ＸＰＤモデルの構文解析（実行）中に返されるコードに従 う動作を生じる。 図２０および図２１参照。ＸＰＤドライバは、ＸＰＤモデルの実行中に、ＸＰ ＤＩモジュール｛ｉｄｔ，ｍ｝、｛ｉｄｅ，ｍ｝および｛ｉｄｗ，ｍ｝に対して 同期信号を生じる。ＸＰＤＩモジュールは更に、疑似並列ＸＰＤモデル実行中に 行われたと同じ方法でＸＰＤ分析エンジンを付勢する。相違は、疑似並列ＸＰＤ モデル実行中は、「実行セグメント」の後にＸＰＤモデルにおけると同じセグメ ントの再トレーシングのプロセスが続くことである。対照的に、ＸＰＤドライバ による目標プロセスの実行中は、目標プロセスの実行とそのＸＰＤモデルの実行 は実際には同じプロセスにより実現される。 図２０Ａにおいて、異なるプロセス時間に下記の信号を｛ｉｄ，ｍ｝フォーマ ットで生成することができる。即ち、 ＣＡＬＬ ＸＰＤＩ（６，２） ＣＡＬＬ ＸＰＤＩ（１４，２） ＣＡＬＬ ＸＰＤＩ（２０，２） ＣＡＬＬ ＸＰＤＩ（２１，２） ＣＡＬＬ ＸＰＤＩ（２４，２） ＣＡＬＬ ＸＰＤＩ（３１，２） ＣＡＬＬ ＸＰＤＩ（３５，２） または、｛ｋ，ｂ，ｍ｝フォーマットで同じもの ＣＡＬＬ ＸＰＤＩ（６，１，２） ＣＡＬＬ ＸＰＤＩ（６，２，２） ＣＡＬＬ ＸＰＤＩ（４，３，２） ＣＡＬＬ ＸＰＤＩ（５，３，２） ＣＡＬＬ ＸＰＤＩ（８，３，２） ＣＡＬＬ ＸＰＤＩ（７，４，２） ＣＡＬＬ ＸＰＤＩ（３，５，２） 解釈されたプロセスの場合と同様に、再コンパイルまたは再リンキングが要求 されないため、目標プロセスに対する修正がこの方法により更に容易に行われる 。更に、目標プロセスのロジックおよびに対するプロセスの実行可能な要素に対 する修正は、本例では個々に行うことができ、これもまた修正タスクを簡単にす る。 １２ ＸＰＤオブジェクト・コードおよびその実行； 目標プロセスのオブジェクト・コードの一部としてのＸＰＤモデルの実行 図１８Ａを参照する。ＸＰＤオブジェクト・コードは下記の２つの要素からな る。即ち、 １．ＸＰＤモデル内でＸＰＤグラフにより表わされる制御要素、および ２．マシン・コードのＸＰＤリポジトリ・ステートメントに変換されることに より表わされる実行可能な要素 前記構成においては、ＸＰＤグラフおよびＸＰＤリポジトリを解釈する場合に おけるように、図７に示された伝統的なオブジェクト・コード構成の下記の要素 は必要とされない。即ち、 −Ｘソース発生器 −コンパイルおよびリンク −Ｘオブジェクト・コード ＸＰＤオブジェクト・コードの実行は、下記の２つのプロセスからなる。即ち 、 １．ＸＰＤドライバ（２０）がＸＰＤモデルを実行する、即ち、ＸＰＤグラフ をトレースする ２．制御命令を含まないＸＰＤリポジトリのマシン・コード・ステートメント に予め変換されるマシン・コード部分が、ＸＰＤドライバによる実行のため提供 されるプロセス（２３）により実行される。 ＸＰＤリポジトリ・ステートメントの解釈の場合のように、ＸＰＤドライバが コードの部分実行の結果として信号を受取り、信号が論理ステートメント（ＸＰ Ｄオブジェクト・セットのＬまたはＤ要素）からくる時適切な方向を取る。 ＸＰＤドライバは、ＸＰＤモデルの実行中、ＸＰＤＩモジュール｛ｉｄｔ，ｍ ｝、｛ｉｄｅ，ｍ｝および｛ｉｄｗ，ｍ｝に対する同期信号を生じる。ＸＰＤモ ジュールは、更に、疑似並列ＸＰＤモデルの実行中に行われのと同じ方法でＸＰ Ｄ分析エンジンを付勢する。 相違点は、疑似並列ＸＰＤモデルの実行においては、「実行セグメント」の後 にＸＰＤモデルにおけると同じセグメントの再トレースが続くことにある。対照 的に、ＸＰＤドライバによる目標プロセスの実行中は、目標プロセスの実行およ びそのＸＰＤモデルの実行は、実際に同じプロセスによって実現される。 図２０Ａにおいて、下記の信号を異なるプロセス時間で｛ｉｄ，ｍ｝フォーマ ットで生成することができる。即ち、 ＣＡＬＬ ＸＰＤＩ（６，２） ＣＡＬＬ ＸＰＤＩ（１４，２） ＣＡＬＬ ＸＰＤＩ（２０，２） ＣＡＬＬ ＸＰＤＩ（２１，２） ＣＡＬＬ ＸＰＤＩ（２４，２） ＣＡＬＬ ＸＰＤＩ（３１，２） ＣＡＬＬ ＸＰＤＩ（３５，２） または、｛ｋ，ｂ，ｍ｝フォーマットにおける同じもの ＣＡＬＬ ＸＰＤＩ（６１，２） ＣＡＬＬ ＸＰＤＩ（６，２，２） ＣＡＬＬ ＸＰＤＩ（４，３，２） ＣＡＬＬ ＸＰＤＩ（５，３，２） ＣＡＬＬ ＸＰＤＩ（８，３，２） ＣＡＬＬ ＸＰＤＩ（７，４，２） ＣＡＬＬ ＸＰＤＩ（３，５，２） 図１８Ｂ参照 実行可能要素アドレス（ＥＣＡ）属性が、ＸＰＤモデルの各実行可能要素ＰＡ に加えられる。ＥＣＡは、変換されたＸＰＤリポジトリ・ステートメントと対応 するマシン・コードの部分のＸＰＤオブジェクト・コード（図１８Ａの２２）の 実行可能要素ファイル内の変位である。各部分の後には、ステートメント区切り バイト（ＳＳＢ）が続く。ＸＰＤドライバ（図１８の２０）が、ＸＰＤモデルか らのＥＣＡの値（図１８Ａの８）を読出し、マシン・コードの対応部分を読出し 、これをＸＰＤオブジェクト・コードの実行可能要素を実行するモジュール（図 １８Ａの２３）による実行のため送る。 システム入力の監視のための異なる方法の１つとして、下記のものが実現され る。即ち、図１８のモジュール２１がシステム端末からの入力をＸＰＤオブジェ クト・コードの実行可能要素に変換する時、入力の動作をモニター・バッファ・ ファイル（Ｍ）（図１８の１９）における出力へシステム端末から反転する次の ステートメントを加える。 例えば、図２１Ｂから： ＲＥＡＤ（＊，００２）ＣＨの後には ＷＲＩＴＥ（Ｍ，００２）ＣＨが続く ＸＰＤドライバは、実行プロセス（２３）へ送られるべき次のコード部分を選 択しながらシステム入力の制御監視のためにこの第２のステートメントを付勢あ るいは消勢する選択を有する。 １３ ＸＰＤオブジェクト・コードの再コンパイルおよび再リンキング 図１８Ａおよび図１８Ｂを参照 ２つの要素、即ち制御要素と実行可能要素からなるＸＰＤオブジェクト・コー ド・アーキテクチャが、目標プロセスの更に容易な修正を許容する。変更が単に 制御における時は、制御要素が変更される。この変更が実行可能要素の修正にお ける時は、新たなエントリが実行可能要素ファイルに作られ、制御要素における ＥＣＡ基準が更新される。 ＥＣＡを介して制御要素と実行可能要素との間リンクの解は実行時間に行われ る。従って、コンパイル、再コンパイルあるいは解釈は、ＸＰＤオブジェクト・ コードの実行可能要素の新たに生成されるか修正されるステートメントにのみ必 要とされる。 ＸＰＤオブジェクト・コードの制御要素は、新たに生成されたＸＰＤリポジト リ要素に対応するＸＰＤグラフ要素に対する挿入、削除あるいは修正により再構 成することができる。 ある状況においては、制御構造のみが再構成される必要がある時、ＸＰＤオブ ジェクト・コードに対する修正を、実行可能要素に対する変更なしに、単にＸＰ Ｄグラフ内の要素の順序を再構成することによって行うことができる。 ＸＰＤオブジェクト・コードに対する修正は、ある状況では、制御要素を消勢 して実行可能要素の対応要素をバイパスすることによって行うことができる。 制御および実行可能ＸＰＤオブジェクト・コード要素間のリンクの解が実行時 間に実現される時、ＸＰＤオブジェクト・コードにより実現される２つ以上の目 標プロセスのグループのリンキングあるいは再リンキングは、ＸＰＤオブジェク ト・コードの制御要素のみのリンキングによって行われるべきである。 ＸＰＤマシンはその高レベルのインターフェースを介してどんな基本プロセス 、即ち、システムの結果への照合によるステートメントおよびＸＰＤ分析エンジ ンの結果的な分析も指定することができるので、伝統的な再コンパイルのための コンパイラあるいは再リンキングのためのリンカの使用によらずに目標プロセス ・コードに対する自動的な修正の方法がある。制御要素は、順序の再構成、ある いはこれらの条件的あるいは無条件的な付勢または消勢の要求によりシステム出 力事象をユーザが指示することにより指令されるＸＰＤグラフ内の要素の挿入、 削除または再構成によって自動的に修正することができる。この条件は、「知識 演繹」法により行われるっりょうに、現在のシステム出力結果に対する指示し、 その後これらを事象の履歴を再トレースするＸＰＤ分析エンジンにより分析する 同じ方法によってこれら結果を分析する同じ方法により現在のシステム出力結果 から得ることができる。 これは、結果指向プログラミングの前向き開発のための非常に高水準言語であ る結果指向プログラミング（ＲＯＰ）の堤案される方法に対する基礎である。実 際に、本方法の水準は、分析しかつ再使用する更に多くの事象が存在するので、 目標プロセスの前向き開発と共に成長する。 呼出されたプロセスに対する外部照合が実行時に解かれてプロセスが一緒に予 めリンクされることがなければ、ＤＬＬ（ダイナミック・リンク・ライブラリ） は、ＸＰＤモデルおよびＸＰＤリポジトリが構築される唯一つのプロセスからな り、従って、 （ａ）新たなＸＰＤリポジトリ・ステートメントが付加されるならば、その時 のプロセス実行可能Ｅ構成要素に対して既に存在するものから選択され、あるい は実行可能構成要素中に見出すことができなければ、制御要素の対応する要素に より付勢される時に解釈され、 （ｂ）ＸＰＤオブジェクト・コードの制御要素が先に述べたＸＰＤグラフの修 正方法によってＸＰＤマシンにょり自動的に編集される時には、 プロセスの修正に対して再コンパイルあるいは再リンキングは要求されることが ない。 １４ 全てのテストおよび生産段階におけるＸＰＤマシン・プロセスの実現 下記の方法のいずれかにより実現されるテストまたは生産の段階におけるＸＰ Ｄマシンの使用を提案する。即ち、 ＸＰＤマシン・プロセスは、ＸＰＤマシン・プロセスが下記のプロセスの組合 わせである目標コンピュータ・プロセスの実行と共に実行される。即ち、 −伝統的なオブジェクト・コード構成内のＸＰＤモデルの目標プロセス実行に 対して「並列な疑似」、あるいは −ＸＰＤオブジェクト・コード構成内の目標プロセス・オブジェクト・コード の構成要素としてのＸＰＤモデルの実行 −目標プロセス要素間の当該知識を「知識伝搬端末」まで伝搬することにより 、システム出力事象により付勢される「基本的知識帰納」 −目標プロセスのＸＰＤモデル内の不確実性領域を定義する「知識演繹」プロ セス １５ 結果指向プログラミング（ＲＯＰ） 結果指向プログラミング（ＲＯＰ）法は、超高レベル・インターフェースを介 する前に生成されたプロセスを修正または構築を可能にし、下記のプロセス・ソ ース・コードとの相互作用は許容しない。即ち、 −ユーザ・インターフェースがＳＹＳＯＵＴ事象の照合能力により現在あるシ ステム結果の参照に制限されること −照合されたＳＹＳＯＵＴ事象の事象定義スペースを再使用するＸＰＤマシン ・プロセスにより追加または修正が自動的に行われること １６ プログラム聴診器の実現 伝統的なビデオ（グラフ）分析と組合わされた音響分析が、プログラムまたは プログラムのシステムのより優れた動的理解を可能にする。目標プロセスの実行 は、プロセス・アルゴリズムにより定義される「音楽」として見る（聴く）こと ができ、入力データの組合わせの関数である。 プログラムの理解の認知プロセスの間、「動作するコンピュータ」のタスクと 当面する。これは、定義によれば動的プロセスである。一方、グラフ（画像）は 定義によれば静的オブジェクトである。動的プロセスのグラフと音の表現間の相 違は、気分転換音楽の２つの方法を比較することにより−１つは楽譜（図形的表 現）を読み、他は音楽を実際に演奏することによって理解することができる。 優れた音楽家が楽譜を読むとき、この音楽を実際に聴くのである。楽譜の図形 的表現は次に、例えそれが楽譜を見ているエキスパートのみに聴こえる場合でも 、音によって増幅される。 目標プロセスのグラフの静的性質は、グラフの構成要素を介する制御の流れを 示すことにより変更することができる。これは、制御を受取る要素を強調するこ とにより、またこれによりグラフ内の最後のハイライト位置を動かすことによっ て実現することができる。プロセスとの音響的同期は、それ自体はプロセスの診 断機構としてそのままであり、またこれはビデオ効果診断と組合わせることもで きる。 プログラム分析中の音響効果は下記の如く得ることができる。即ち、 １．次の記録された端末アドレス｛ｋ，ｂ｝をプログラムのＸＰＤモデルに付 加することによる並列的プログラムまたはポスト・ライフ（死後）・プログラム のエミュレーションの間、プログラムのアルゴリズムのＸＰＤ−グラフについて のプログラム実行をトレースすることができる。 ２．プログラム実行プロセスのビデオ・トレーシングは、トレース中その時ア クティブであるＸＰＤグラフの要素を強調するだけで行われることになる。 ３．音響効果は、音響周波数を生成してそれをスピーカへ送ることを許容する ハードウエア内部機能を呼出すことにより付加される。ヘッドフォンは、先に述 べた方法によりシステムを分析する時コンピュータに対する更に適切な付加とな ろうが、他のプログラマには役立たない。 周波数は、２つのパラメータ、即ち（ｋ，ｂ）の関数として計算することがで き、ここで｛ｋ｝における１つの増分が周波数を１つの離散ステップだけ増分し 、 ｛ｂ｝の１つの増分が周波数をより大きなステップだけ、例えば１オクターブだ け増分する。従って、逆分岐は周波数を減分することになる。 ＸＰＤ−ＧＲＡＰＨの個別の１要素のトレーシングと対応するビープの期間は 、これが人間の耳に認識されるように設定することができる。 このような音響的実行のエミュレーション効果は、当該プロセスのハード・コ ード化構造と入力データの組合わせに応じて、プログラム実行の各プロセスがそ れ自体の「音楽」を持つ如きものである。多数の反復ループをエミュレートする 場合は、全ての反復をトレースする必要性を排除するためこのようなループを表 示するようにコード信号を設定することができる。 音響的分析の効果は、医者が患者の心拍を聴くようにユーザがプログラムの挙 動を聴くことができる如きものである。 １．特定の出力結果が長期にわたり観察されない時は、この分析は次のことを 聞き取るように付勢することができる。即ち、−システムが不動作である −プログラムがループ状態 −入力を待機中である （最後に実行された要素が入力ステートメントであった時、特殊な音響を生成す ることができる） ２．プログラムのアルゴリズムの最もストレスの大きな場所は、最も一般的な 周波数として聴くことができ、従って容易に識別することができる。 ３．異なる入力データの組合わせを持つプログラム挙動における相違は聴くこ とができる。 ４．特殊な音響が子供の機能に対する呼出しを表示し得、特殊音響がこの呼出 しからの返信を示すことができる。音響的分析は、もともとこれらの信号にのみ 限定され得、機能的に研究の範囲内にあるならば、任意に１つの特定機能内のプ ロセス実行を示すように拡張することができる。 ５．音響的分析は、プロセス・エミュレーション（生存あるいは死後）におい て記録することができ、次に順方向と逆方向の両方向で実際のモード・エミュレ ーションなしに再生することができる。 ６．これは、システム結果の再生と同期して再生することができ、これにより これら結果の達成のため必要な処理の強さの付加を生じることができる。 ７．これら異なる入力状況に対する計算の強さを分析するために、同じプロセ スに対する異なる入力データの組合わせのために記録し再生することができる。 プログラムの失敗の可能性は、含まれる基本的プロセス数の関数であるとすれ ば、この分析は選択において新たな仕様へのシステム展開におけるより簡単な（ 入力−プロセス−出力）組合わせを助けることになる。

【手続補正書】特許法第１８４条の８ 【提出日】１９９４年１２月９日 【補正内容】 明細書の請求の範囲を、次の通りに補正する。 『１．制御及び非制御成分を有する目標プロセス内に含まれる誤りの位置を決 定する知識帰納解析方法であって、前記解析が行われるメイン・メモリを有する コンピュータに対してオブジェクト・プログラムを発生する方法において、 第１に、前記ソース・プロセスを解析して、前記ソース・プロセスの前記制御 成分を有するモデルを発生するステップと、 第２に、前記ソース・プロセスを解析して、前記ソース・プロセスの前記非制 御成分を有するリポジトリを発生するステップと、 前記目標プロセスについての基本知識を記録する間に前記モデルと前記リポジ トリとを実行し、前記基本知識が前記目標プロセスの内部のプロセス要素の実行 の正しさを指示するようにする、ステップと、 を含むことを特徴とする方法。 ２．請求項１記載の方法において、 前記目標プロセスについての基本知識を記録する間に前記モデルと前記リポジ トリとを実行し、前記基本知識が前記目標プロセスの内部のプロセス要素の実行 の不確実性を指示するようにするステップを更に含むことを特徴とする方法。 ３．請求項２記載の方法において、前記基本知識は解析された計算ベースの中 に記録され、前記解析された計算ベースは、複数の解析された計算ワードを含み 、１つの解析された計算ワードは前記目標プロセスのステートメントの中の各パ ラメータに対するものであり、各解析された計算ワードは制御領域と情報領域と を含み、前記情報領域は異なる時点における目標ソフトウェアのプロセスのステ ートメント・パラメータのイベントの効果の正しさに関する知識を示す一連のイ ンジケータを含み、前記制御領域はイベントの効果の正しさに関する知識を有し ない前記情報領域において表された第１のイベント・インジケータを定義する値 を含むことを特徴とする方法。 ４．請求項１記載の方法において、前記第１の解析ステップは、２つの直交す る軸を有し双方向の終端されたｅＸグラフを生じ、一方の軸は論理条件のゼロ・ ポテンシャルを表し、他方の軸は論理条件の１ポテンシャルを表し、前記２つの 軸の座標対で記録された要素はその要素を一意的に識別するバイナリ・アドレス によって表されることを特徴とする方法。 ５．請求項１記載の方法において、 前記目標プロセスの要素の間の潜在的な依存性を識別するステップであって、 前記潜在的な依存性は前記目標プロセスの要素が前記目標プロセスの別の要素か らアクセス可能であるかどうかを確認することによって決定される、ステップを 更に含むことを特徴とする方法。 ６．請求項５記載の方法において、 前記目標プロセス内に含まれるデータ独立なエンドレス・テープを識別するス テップを更に含むことを特徴とする方法。 ７．請求項３記載の方法において、 目標ソフトウェア・プロセスのイベントの効果の正しさに関する記録された基 本知識を、知識伝搬ターミナルに至るアンセスタに伝搬するステップを更に含む ことを特徴とする方法。 ８．請求項１記載の方法において、 前記モデルの実行の間に複数の音声トーンを発生するステップであって、前記 複数のトーンの中の１つのトーンはあるプロセス要素の実行の間に発生され、前 記複数のトーンの中の別のトーンは別のプロセス要素の実行の間に発生され、そ れによって、前記モデルが各個別のプロセス要素を介して実行される際にトーン の連続的な出力を生じるようにするステップを更に含むことを特徴とする方法。 １０．請求項１記載の方法において、前記モデルの実行は、前記目標プロセス の実行と共にシーケンシャルに行われることを特徴とする方法。 １１．請求項１記載の方法において、前記モデルの実行は、前記目標プロセス の実行とパラレルに行われることを特徴とする方法。 １２．請求項５記載の方法において、 前記要素のバイナリ・アドレスを比較することによってプロセス要素のビジョ ンを識別するステップを更に含み、ある要素の前記バイナリ・アドレスは、前記 目標プロセスの論理解を表す２進数から構成されることを特徴とする方法。 １３．プロセッサとメモリと入力／出力とを有し、目標ソフトウェア・プロセ スを解析する知識帰納装置において、 前記目標ソフトウェア・プロセスの制御成分を有し、前記知識帰納装置の前記 メモリに含まれるモデルと、 前記目標ソフトウェア・プロセスの非制御成分を有し、前記知識帰納装置の前 記メモリに含まれるリポジトリと、 前記知識帰納装置のメモリの中に含まれる解析機関と、 前記知識帰納装置のメモリの中に含まれるシステムの実行履歴と、 システム入力プロセス同期化マップを有し、前記知識帰納装置の前記メモリに 含まれるシステム入力履歴と、 増加システム出力プロセス・マップを有し、前記知識帰納装置の前記メモリに 含まれるシステム結果履歴と、 前記知識帰納装置の前記メモリの中に含まれ、前記目標プロセスを前記解析機 関とインターフェースし、メモリの中に前記システム実行履歴と前記システム入 力履歴と前記システム結果履歴とを構成するｅｘインターフェースと、 前記知識帰納装置の前記メモリの中に含まれる増加画像エクストラクタ／コン ストラクタであって、以前のスクリーン画像を現在のスクリーン画像と比較し、 前記以前の画像と異なる前記現在の画像の部分を抽出（エクストラクト）し、そ のように抽出された該画像部分を、複数のプロセス同期化パラメータを用いて、 前記システムの結果履歴の中に配置する、増加画像エクストラクタ／コンストラ クタと、 前記知識帰納装置の前記メモリの中に含まれた解析計算ベースであって、複数 の解析計算ワードを含み、前記目標プロセスのステートメント内の各パラメータ に対して１つの解析計算ワードがあり、各解析計算ワードは制御領域と情報領域 とを含み、前記情報領域は異なる時刻において目標ソフトウェア・プロセスのス テートメント・パラメータのイベントの効果の正しさに関する知識を示す一連の インジケータを含み、前記制御領域はイベントの効果の正しさに関する知識を有 さない前記情報領域において表される第１のイベント・インジケータを定義する 値を含む、解析計算ベースと、を含み、 前記目標ソフトウェア・プロセスは、複数の同期信号を、前記システム実行履 歴とシステム入力履歴とシステム結果履歴とを構築するｅｘインターフェースに 送り、前記解析機関を開始させ、該解析機関は、リポジトリを調べる間に前記モ デルを実行し、前記解析計算ベースを構成する知識機能プロセスを開始させるこ とを特徴とする知識帰納装置。 １４．プロセッサとメモリと入力／出力とを有し、目標ソフトウェア・プロセ スを解析する知識帰納装置において、 前記目標ソフトウェア・プロセスの制御成分を有し、前記知識帰納装置の前記 メモリに含まれるモデルと、 前記目標ソフトウェア・プロセスの非制御成分を有し、前記知識帰納装置の前 記メモリに含まれるリポジトリと、 前記知識帰納装置のメモリの中に含まれる解析機関と、 前記知識帰納装置のメモリの中に含まれるシステムの実行履歴と、 システム入力プロセス同期化マップを有し、前記知識帰納装置の前記メモリに 含まれるシステム入力履歴と、 増加システム出力プロセス・マップを有し、前記知識帰納装置の前記メモリに 含まれるシステム結果履歴と、 前記知識帰納装置の前記メモリの中に含まれ、前記目標プロセスを前記解析機 関とインターフェースし、メモリの中に前記システム実行履歴と前記システム入 力履歴と前記システム結果履歴とを構成するｅｘインターフェースと、 前記知識帰納装置の前記メモリの中に含まれる言語インタープリタと、 前記知識帰納装置の前記メモリの中に含まれるドライバと、 前記知識帰納装置の前記メモリの中に含まれる増加画像エクストラクタ／コン ストラクタであって、以前のスクリーン画像を現在のスクリーン画像と比較し、 前記以前の画像と異なる前記現在の画像の部分を抽出（エクストラクト）し、そ のように抽出された該画像部分を、複数のプロセス同期化パラメータを用いて、 前記システムの結果履歴の中に配置する、増加画像エクストラクタ／コンストラ クタと、 前記知識帰納装置の前記メモリの中に含まれた解析計算ベースであって、複数 の解析計算ワードを含み、前記目標プロセスのステートメント内の各パラメータ に対して１つの解析計算ワードがあり、各解析計算ワードは制御領域と情報領域 とを含み、前記情報領域は異なる時刻において目標ソフトウェア・プロセスのス テートメント・パラメータのイベントの効果の正しさに関する知識を示す一連の インジケータを含み、前記制御領域はイベントの効果の正しさに関する知識を有 さない前記情報領域において表される第１のイベント・インジケータを定義する 値を含む、解析計算ベースと、を含み、 前記ドライバは、前記モデルを実行し、前記リポジトリから対応する成分を抽 出し、前記成分を前記成分が解釈される前記言語インタープリタに与え、前記ド ライバは、複数の同期信号を前記ｅｘインターフェースに更に送り、前記ｅｘイ ンターフェースは、前記システム実行履歴とシステム入力履歴とシステム結果履 歴とを構築し、リポジトリを調べる前記解析機関を開始させ、前記解析計算ベー スを構成する知識機能プロセスを開始させることを特徴とする知識帰納装置。 １５．プロセッサとメモリと入力／出力とを有し、目標ソフトウェア・プロセ スを解析する知識帰納装置において、 前記目標ソフトウェア・プロセスの制御成分を有し、前記知識帰納装置の前記 メモリに含まれるモデルと、 前記目標ソフトウェア・プロセスの非制御成分を有し、前記知識帰納装置の前 記メモリに含まれるリポジトリと、 前記知識帰納装置のメモリの中に含まれる解析機関と、 前記知識帰納装置のメモリの中に含まれるシステムの実行履歴と、 システム入力プロセス同期化マップを有し、前記知識帰納装置の前記メモリに 含まれるシステム入力履歴と、 増加システム出力プロセス・マップを有し、前記知識帰納装置の前記メモリに 含まれるシステム結果履歴と、 前記知識帰納装置の前記メモリの中に含まれ、前記目標プロセスを前記解析機 関とインターフェースし、メモリの中に前記システム実行履歴と前記システム入 力履歴と前記システム結果履歴とを構成するｅｘインターフェースと、 前記知識帰納装置の前記メモリの中に含まれるドライバと、 前記知識帰納装置の前記メモリの中に含まれるｅｘオブジェクト・コードと、 前記知識帰納装置の前記メモリの中に含まれる増加画像エクストラクタ／コン ストラクタであって、以前のスクリーン画像を現在のスクリーン画像と比較し、 前記以前の画像と異なる前記現在の画像の部分を抽出（エクストラクト）し、そ のように抽出された該画像部分を、複数のプロセス同期化パラメータを用いて、 前記システムの結果履歴の中に配置する、増加画像エクストラクタ／コンストラ クタと、 前記知識帰納装置の前記メモリの中に含まれた解析計算ベースであって、複数 の解析計算ワードを含み、前記目標プロセスのステートメント内の各パラメータ に対して１つの解析計算ワードがあり、各解析計算ワードは制御領域と情報領域 とを含み、前記情報領域は異なる時刻において目標ソフトウェア・プロセスのス テートメント・パラメータのイベントの効果の正しさに関する知識を示す一連の インジケータを含み、前記制御領域はイベントの効果の正しさに関する知識を有 さない前記情報領域において表される第１のイベント・インジケータを定義する 値を含む、解析計算ベースと、を含み、 前記ｅｘオブジェクト・コードは、目標プロセスのマシン・コードに翻訳され たリポジトリ・ステートメントを表し、前記ドライバは、前記モデルを実行し、 前記ｅｘオブジェクト・コードの対応する成分を抽出し、そのように抽出された 成分をコンピュータのオペレーティング・システムに実行のために与えることを 特徴とする知識帰納装置。』

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ， ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，Ｇ Ｂ，ＧＥ，ＨＵ，ＪＰ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ， ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＩ，Ｓ Ｋ，ＴＪ，ＴＴ，ＵＡ，ＵＳ，ＵＺ，ＶＮ (54)【発明の名称】 より少ない再コンパイル及び再リンケージ処理を可能にする目標プロセスのオブジェクト・コー ドの別形式を導入することにより、誤り位置とシステムへの新たな要求に起因する修正位置との 自動的な識別を可能にする、コンピュータ・ソフトウェア・プロセスにおける不確実性最小化方 法 【要約の続き】 定義される「プロセス空間」と「プロセス時間」とによ る座標系における個々の要素の正しさ及び不確実性の相 対的で時間に独立な測定とを、構築する。本発明は、Ｘ ＰＤマシンの「知識帰納」及び「知識演繹」プロセス と、ユーザと目標プロセスに関する集積された知識との 間の非常に高レベルのインターフェースに対するメカニ ズムとを導入する。また、その診断のための別の媒体と して、目標プロセスの行動の音声的な提供も行われる。 本明細書で提供された「ＸＰＤオブジェクト・コード」 は、その目標プロセスのメンテナンスだけでなく、静的 及び動的に、その目標プロセスの解析するのに適してい る。これによれば、修正のための目標プロセスの再コン パイルと再リンケージとが短縮され、時には除去され る。

Claims (1)

1. 【特許請求の範囲】 １．目標プロセスのアルゴリズムを、「次に最も低いポテンシャル」の規則に よって又は代替的に「次に最も高いポテンシャル」の規則によって構築された単 一定義の汎用形式であるアルゴリズムのＸＰＤフレームの中に抽出する方法にお いて、 プロセス要素のアルゴリズム・ポテンシャルは、そのバイナリ・アドレス（Ｂ Ａ）によって判断され、該バイナリ・アドレスは、バイナリ０とバイナリ１との 組み合わせであり、また、その要素を通過するｔパスの入力部分における「縮小 論理条件」（縮小ＬＣ）の解であり、 ｔパスは、「プロセス・ターミナル」へのプロセス・エントリからのパスであ り、 ＬＣの負の解（ＮＯ解）には「ロー・ポテンシャル」又は「０ポテンシャル」 が割り当てられてられ、ＬＣの正の解（ＹＥＳ解）には「ハイ・ポテンシャル」 又は「１ポテンシャル」が割り当てられてられており、 目標プロセスから「メイン・ブランチ」を抽出するステップと、 ２よりも多くの出力を有する論理条件（ＬＣ）を、２だけの論理出力を有する ２又はそれよりも多くの縮小ＬＣに縮小するステップと、 メイン・ブランチを構築するプロセスにおいて、前向きのＧＯ ＴＯを除去す るステップと、 「プロセス・ターミナル」を、ターゲット・プロセスを終了する「出口ターミ ナル」と、より低いバイナリ・アドレスと共にプロセス・セグメントにおいて既 に表されているプロセス要素に制御を戻す「リワインド・ターミナル」として、 識別するステップと、 プロセス・セグメントを識別するステップと、 ２つの異なるバイナリ・アドレスの間の関係を数量化するステップと、 を含むことを特徴とする方法。 ２．目標プロセスのアルゴリズムを「双方向に終了した」ＸＰＤグラフに抽出 する請求項１記載の方法において、 ＸＰＤグラフは、２だけの方向に構築され、その第１の方向はＬＣの０ポテン シャルによって定義され、別の方向はＬＣの１ポテンシャルによって定義され、 ＸＰＤグラフの各要素には、その要素の「プロセス・ポテンシャル」を記述す る「バイナリ・アドレス」（ＢＡ）が割り当てられることを特徴とする方法。 ３．目標プロセスのＸＰＤグラフの要素の間のアクセス可能性を識別すること を介して、目標プロセス要素の間の「潜在的（ポテンシャル）な依存性」を識別 する方法において、 （ａ）論理条件のフィールドを識別するステップと、 （ｂ）ＸＰＤグラフの「セグメント」の論理レベルを識別するステップと、 （ｃ）プロセス要素のアルゴリズム・アドレス（ＡＡ）とプロセス・アドレス （ＰＡ）とを識別するステップと、 （ｄ）プロセスのアルゴリズム空間を識別するステップと、 （ｅ）プロセス要素の「ビジョン」とプロセス・ターミナルの「共通のビジョ ン」とを識別することを介して、プロセス要素のアクセス・フィールドを識別す るステップと、 （ｆ）プロセス・ターミナルの共通ビジョンを伝搬する方法と、 を含むことを特徴とする方法。 ４．請求項３の方法において、プロセス要素のアクセス可能性を識別するステ ップは、各プロセス・ターミナルに対する出口アクセス・インジケータを識別す ることによってデータ独立なエンドレス・ループを識別するのに用いられ、 出口アクセス・インジケータは、ターミナルの共通ビジョンを伝搬するプロセ スの間にオフからオン状態へ潜在的に伝搬されることを特徴とする方法。 ５．請求項２のプロセスを実行する間に目標プロセスのＸＰＤリポジトリを構 築する方法において、ＸＰＤリポジトリはターゲット・プロセスの表現であって 、この表現は、プロセス制御命令を全く含まず、ＸＰＤリポジトリの各実行可能 なステートメントには、ＸＰＤグラフの対応する要素への参照が割り当てられる ことを特徴とする方法。 ６．属性をＸＰＤグラフ要素に割り当てることによってＸＰＤモデルを構築す る方法において、ターゲット・プロセスの実行可能なステートメントに対応する 要素には、「局所時間（ローカル・タイム）」の動的に更新された属性と、「解 析された計算ベース」（ＡＣＢ）の属性とが割り当てられており、 「局所時間」は、目標プロセスにおけるプロセス要素の現在の発生（ｃｕｒｒ ｅｎｔ ｏｃｃｕｒｒｅｎｃｅ）を表す整数であり、 「ＡＣＢ」は、対応するプロセス・イベントに関する正しさと不確実性につい ての知識の状態に対応する０と１とのバイナリ構造であり、イベントの正しさに 関する知識の状態は、アルゴリズム空間における局所時間とプロセス・アドレス とに相対的であり、知識の状態は、ＸＰＤマシン・プロセスによる変化を被るこ とを特徴とする方法。 ７．リエンジニアリングされＸＰＤインターフェース・モジュールへのインタ ーフェースが実現されている元の目標プロセスの機能に関するビジョンにおいて 同等であるターゲット・プロセスのＸソース・コードを構築する方法において、 （ａ）目標プロセスのターミナルにおいて、同期化信号を、目標プロセスの行 動履歴を記録するための最小のオーバヘッド実現（ｉｎｓｔｒｕｍｅｎｔａｔｉ ｏｎ）として実現するステップと、 （ｂ）目標プロセスのシステム出力要素において同期化信号を実現し、増加シ ステム出力プロセス同期化（ＩＳＯＰ）マップを構築する手段によって、ユーザ と目標プロセスの機能を理解するＸＰＤマシンのプロセスとの間に非常に高レベ ルのインターフェースを構築するステップと、 （ｃ）目標プロセスのシステム入力要素において同期化信号を実現し、システ ム入力プロセス同期化（ＳＩＰＳ）マップを構築するステップと、 を含むことを特徴とする方法。 ８．目標プロセスの基本知識を、基本プロセスすなわち目標プロセス内の実行 ステートメントを、その実行の特定のイベントにおいてすなわち前記目標プロセ スにおける場所と時間とであるプロセス時間において正しい又は不確実であると 識別することによって、構成する方法。 ９．目標プロセスにおける実行可能なステートメントである基本プロセスを、 その実行の特定のイベントにおいて、すなわち、目標プロセスの中の位置と時間 である「プロセス時間」において、正しい又は不確実であると識別することによ っ て、目標プロセスの基本知識を帰納する方法において、 （ａ）プロセス・イベントとプロセス時間とを識別するステップと、 （ｂ）システム出力プロセスイベントによって「知識伝搬」プロセスを付勢す るステップと、 （ｃ）システム出力イベントを、将来のシステム出力結果確認の間に又は新た なシステム要求に起因して「予測されていない」又は「不確実」と定義されない 限り、又は定義されるまでは、「正しい」と識別するステップと、 （ｄ）特定のプロセス時間にたいして、「正しいプロセス・アドレス（ＣＰＡ ）」と「不確実なプロセス・アドレス（ＵＰＡ）」とを識別するステップと、 （ｅ）「アンセスタ」（ａｎｃｅｓｔｏｒ）イベントを、現在のイベントの値 である「値アンセスタ・イベント」に寄与する、又は、現在のイベントに至るＬ Ｃの値である「制御アンセスタ・イベント」に寄与するイベントとして、識別す るステップと、を含み、 （ｆ）イベントを承認するプロセスはその直前のアンセスタを、その直前のア ンセスタが（１）既に承認されていない、又は（１）不存在でない場合に、更に ある場合には、イベントが「知識伝搬ターミナル・イベント」を表す（１）及び （２）を有するデータ操作イベントである場合に、承認する二次的なプロセスを 発生し、 （ｇ）「知識伝搬ターミナル」を現在のプロセスへの入力であるイベントとし て、又は、その基本知識の状態がこの請求項において先に定義された知識帰納プ ロセスによって「正しい」と現時点で定義されているイベントとして、識別する ステップと、 を含むことを特徴とする方法。 １０．伝統的なオブジェクト・コードによって実現された目標プロセスに対し て「疑似パラレル」であるＸＰＤモデルを、「遅延シーケンシャル」な又は「遅 延パラレル」のどちらかのＸＰＤモデル実行モデルとして実行する方法において 、 ＸＰＤモデルの実行は、目標プロセスの実行経路に従って、ＸＰＤグラフをト レースするプロセスであり、 「ＸＰＤモデルの遅延したシーケンシャルな実行」は、２つのタスクの間で切 り換わる複数のＣＰＵの中の１つであるＣＰＵによって実現され、一方のタスク は、目標プロセスの実行セグメントであり、他方のタスクは、ＸＰＤ解析機関に よるそのプロセスのＸＰＤモデル上で第１のタスクをモデル化することであり、 このＸＰＤ解析機関は、ＸＰＤオブジェクト集合であるプロセス・エントリと システム入力（同期化｛ｉｄｅ，ｍ｝）とプロセス・ターミナル（同期化｛ｉｄ ｔ，ｍ｝）との要素の間に位置する目標プロセスの一部として定義され、 「ＸＰＤモデルの遅延したシーケンシャルな実行」は、複数のＣＰＵによって 実現され、目標プロセスの実行セグメントのタスクとＸＰＤ解析機関による前に 実行された実行セグメントのモデル化のタスクとは、パラレルに行われることを 特徴とする方法。 １１．ＸＰＤオブジェクト・コードの実行によって目標プロセスを実行する方 法において、 請求項７に記載されたＸソース・コードを生じてコンパイルするステップは除 去され、 ＸＰＤオブジェクト・コードは、（１）どのプロセス制御コマンドも含まない マシン・コードＸＰＤリポジトリ・ステートメントに翻訳される実行可能な成分 と、（２）目標プロセスのＸＰＤグラフである制御成分との２つの成分の組み合 わせであり、 ＸＰＤオブジェクト・コードのどの実行可能な成分ステートメントが次に実行 されるべきかという判断は、ＸＰＤオブジェクト・コードの制御成分であるＸＰ Ｄグラフを解析（ｐａｒｓｅ）する間にＸＰＤドライバによって確立され、この プロセスは、実際には、目標プロセスのＸＰＤモデルを実行し、よって、請求項 １０に記載されているＸＰＤモデルの疑似パラレルな実行の必要性を除去するこ とを特徴とする方法。 １２．ＸＰＤグラフとＸＰＤリポジトリとを解釈することによって、請求項７ 記載のＸソース・コードを生じコンパイルするステップを除去する方法において 、 目標プロセスは、どのプロセス制御ステートメントも含まないプロセスのＸＰ Ｄリポジトリから一度にステートメントを、言語インタープリタによって、解釈 することによって実行され、 どのリポジトリ・ステートメントが次に実行されるべきかという判断は、目標 プロセスのＸＰＤグラフを解析（ｐａｒｓｅ）する間にＸＰＤドライバによって なされ、このプロセスは、実際には、目標プロセスのＸＰＤモデルを実行し、よ って、請求項１０に記載されているＸＰＤモデルの疑似パラレルな実行の必要性 を除去することを特徴とする方法。 １３．ＸＰＤモデルの実行の間にＸＰＤ解析機関によって付勢され、請求項１ ０の伝統的なオブジェクト・コード実現において疑似パラレルな実行によって実 行され、又は、請求項１２のＸＰＤグラフ及びＸＰＤリポジトリを又はＸＰＤオ ブジェクト・コードの一部として解釈することによって、プロセスを知識帰納す る方法において、 知識帰納プロセスは、ＸＰＤ解析機関がシステム出力に向けられたＷ要素を通 過する際に開始され、 請求項９に記載された原理による知識を伝搬するＸＰＤ解析機関は、Ｗ出力信 号の各パラメータにおいて開始されることを特徴とする方法。 １４．システム出力イベントへの参照を介して、一定に減少する不確実性をも って、知識演繹プロセスを付勢する方法において、 増加システム出力プロセス同期化マップであるＩＳＯＰＳマップから再生され たシステム出力上で、カーソル、マウス又はそれ以外のポインティング・デバイ スの位置を介して対応するシステム出力イベントを識別するステップと、 許容された修正のための場所は、対応するシステム出力のイベント定義空間の 一部により決定され、この空間は、ＵＰＡの状態を有するプロセス・アドレス（ ＰＡ）上に構築され、参照されたシステム出力イベントに対応するプロセス時間 における不確実なプロセス・アドレスであり、 イベント定義空間は、対応するシステム出力イベントへのアンセスタのプロセ ス・アドレスの組み合わせであり、 任意の方向への知識演繹プロセスは、請求項９記載の知識伝搬ターミナルと同 じ定義を有する知識演繹ターミナルによって終了されることを特徴とする方法。 １５．請求項１０、請求項１１、又は請求項１２に記載され、その試験又は生 産の任意の段階におけるコンピュータ・プロセスに応用されるＸＰＤモデルの実 行方法において、ＸＰＤマシン・プロセスは、目標となるコンピュータ・プロセ スの実行と共に実行され、 請求項１０記載の伝統的なオブジェクト・コード実現において、ＸＰＤモデル の目標プロセス実行に疑似パラレルなプロセス、又は、 請求項１１記載のＸＰＤオブジェクト・コードの制御成分としての、及び、Ｘ ＰＤドライバによる目標プロセス実行の一部としてのＸＰＤモデルの実行、又は 、 ＸＰＤドライバによってＸＰＤモデルとＸＰＤリポジトリとを解釈するプロセ スの間にＸＰＤモデルを実行すること、 請求項９記載の知識伝搬ターミナルまでの目標プロセス要素の間でこの知識を 伝搬することによって、システム出力イベントにより付勢される「基本知識帰納 」と、 請求項１４記載の目標プロセスのＸＰＤモデルにおいて不確実性の領域を定義 する「知識演繹」プロセスと、 を特徴とする方法。 １６．ＸＰＤオブジェクト・コードの１又は２の成分における限定された修正 によるＸＰＤオブジェクト・コードにより実現される目標プロセスへの修正の方 法において、 ＸＰＤオブジェクト・コードの実行可能な成分の新たに作成された又は修正さ れたステートメントだけをコンパイルし、再コンパイルし、又は解釈するステッ プと、 新たに作成されたＸＰＤリポジトリ要素に対応するＸＰＤグラフ要素への挿入 、削除、又は修正によって潜在的に再び配列されたＸＰＤオブジェクト・コード の制御要素と、 ＸＰＤグラフにおける要素の順序を単に再び配列することによって、すなわち 、ＸＰＤオブジェクト・コードの制御要素を再び配列することによって、実行可 能な成分へのどのような変更もなく、ＸＰＤオブジェクト・コードへの修正がな さ れ、 制御成分要素を消勢することによって、したがって、実行可能な成分の対応す る要素をバイパスすることによって、ある状況においてＸＰＤオブジェクト・コ ードへの修正がなされることを特徴とする方法。 １７．ＸＰＤオブジェクト・コードの制御成分だけのリンケージによってＸＰ Ｄオブジェクト・コードによって実現された２またはそれより多くの目標プロセ スのグループをリンク又は再リンクする方法において、制御及び実行可能なＸＰ Ｄオブジェクト・コード成分の間のリンクの解消は実行時間（ｒｕｎ ｔｉｍｅ ）に実現されることを特徴とする方法。 １８．ＸＰＤオブジェクト・コードによって表される目標プロセスへの修正を 実現する方法において、再リンケージは行われず、再コンパイルのステップはＸ ＰＤ解析機関により行われるＸＰＤオブジェクト・コードの自動的な修正によっ て除去され、 呼び出されたプロセスへの外部的な参照は、実行時間に解消され、予めリンク されたプロセスはなく、よって、ＤＬＬは、それに対してＸＰＤモデルとＸＰＤ リポジトリとが構築されたただ１つのプロセスから成り、 新たなＸＰＤリポジトリ・ステートメントが付加されるべき場合には、それは 、現在のプロセスの実行可能な成分要素にたいして既に存在するものから選択さ れ、実行可能な成分において見つからない場合には、制御成分の対応する要素に よって付勢される際に解釈され、 ＸＰＤオブジェクト・コードの制御成分は、ＸＰＤ解析機関によって自動的に 編集されることを特徴とする方法。 １９．非常に高レベルのインターフェースを介して、また、プロセスのソース ・コードへのマニュアルでの相互作用なく、先に作成されたプロセスを修正する 、又は、その上への構築を可能にする結果指向プログラミング（ＲＯＰ）の方法 において、 ユーザ・インターフェースは、請求項１４記載の方法によるＳＹＳＯＵＴイベ ントへの参照能力により既存のシステムの結果への参照に限定されており、 付加又は修正は、参照されたＳＹＳＯＵＴイベントのイベント定義を再び使用 するＸＰＤマシン・プロセスによって自動的になされることを特徴とする方法。 ２０．目標プロセスの音声的な解析を可能にする「プログラム・ステトスコー プ」を実現する方法において、 そのＸＰＤグラフのアルゴリズム空間におけるＸＰＤグラフの各要素の位置で あって、この位置は、その要素の｛ｋ，ｂ｝座標によって定義され、それ自体の 音声周波数を割り当たられ、この周波数は、ｋ座標の増加に伴って徐々に増加し 、ｂ座標の増加に伴ってたとえば、１オクターブだけの大きなステップで増加す る、位置と、 目標プロセスの実際の実行行動に対応する音声信号は、ＸＰＤモデルの疑似パ ラレルな実行によるＸＰＤグラフのトレースの間、又は、ＸＰＤドライバによる ＸＰＤオブジェクト・コードの実行の間に、発生され、 たとえばＸ要素だけすなわちＣＡＬＬステートメント要素であるＸＰＤのオブ ジェクト・コードの潜在的に選択されただけの要素は、音声信号を生じるように 設定され、したがって、ＣＡＬＬレベルだけに基づいて、又は、Ｉ／Ｏレベルだ けに基づいて、又はその他の音声的な解析を可能にし、 音声信号のベース周波数に異なる高周波を加えることによって異なるトーン品 質の音声信号を発生させ、各タイプにそれ自体のトーン品質が割り当てられてい るＸＰＤオブジェクト・コードにおいてアクティブな要素のタイプを区別する方 法と、 内部的なスピーカ又はヘッドフォンなどの外部的な音声デバイスを、プログラ ム・ステトスコープ方法による目標プロセスの解析の間に用いるステップと、 を含むことを特徴とする方法。