JPH10505178A - インターフェースを試験する方法と装置 - Google Patents

Abstract

(57)【要約】 インターフェースと共に第１および第２補助プログラムを作ることにより、インターフェースの基準モデルを提供する。第１補助プログラム（Ａ”）は、インターフェースの使用をシミュレートするモデルプログラムであり、第２補助プログラム（Ｂ”）は、インターフェース内の機能を提供することをシミュレートするモデルプログラムである。両プログラムは、インターフェースを通してすべての可能な許容できる動作を実行し、同時に、他のプログラムは許容できないことを一切しないように制御することができる。

Description

【発明の詳細な説明】 インターフェースを試験する方法と装置 発明の技術分野 この発明の第１態様は、インターフェースを試験する方法と装置に関し、第２ 態様は、通信システムの新しいプログラムウエアと共にインターフェースを試験 する方法と装置に関し、第３態様は、通信システムの基準モデルを与える方法と 装置に関するものである。プログラムウエアは、プロトコルを通して互いに通信 することができ、プロトコルは、インターフェースによりこれらのプログラムウ エアから各プログラムウエアに対して分離されている。 互いに独立に設計され維持されている２つのプログラムウエアユニットが互い に作用する場合、相互作用の規則は、インターフェースに記述される。このイン ターフェースは、一方のプログラムウエアユニットの設計者が他方のプログラム ウエアユニット内の機能を使用するのに必要なすべての知識を含んでいなければ ならない。これに反して、この他方のプログラムウエアユニットについて設計者 が知る必要がないようにするため、使用する機能をインターフェースで隠さなけ ればならない。その目的は、機能を提供するプログラムをインターフェースの枠 内で自由に変更できるようにすることである。 通常、インターフェースは構文的な用語で定義される。すなわち、第２プログ ラム内の機能を正しく呼び出すことのできる形で示される。一般に、このような 定義は形式的であり正確である。機能呼び出しプログラムの構文分析では、例え ば、つづりの誤りなどの形式上の誤りがある呼び出しは必ず発見される。これに 反して、機能呼び出しの使い方を示す意味論的な規則は、多くの場合は形式的で も完全でもない。具体例を挙げると、車のイグニションキーを時計回りに回すと いうのは構文的には常に正しい動作である。しかし、エンジンが既に回転してい る場合は、意味論的には正しくない。 従来の技術 ＥＰ ４７４，３３９は、アプリケーションの目的向き呼び出し用のクライア ントインターフェースを与える方法を開示している。不均一なネットワーク内で 、個々のアプリケーションが必要とする特定のインターフェースを使うことを強 制されたユーザから問題が起こらないようにすることが望ましい。この目的は、 プロセスの相互作用を目的向きにさせることである。クライアントのアプリケー ションは、パラメータを持つ広く知られたメッセージを送ることにより、他のア プリケーションを呼ぶことができる。クライアントは希望を出し、サーバはその 希望に応えるようなクライアント／サーバを用いる。 ＥＰ ５４０，１６６は、クライアント／サーバモデルに基づいた、目的向き 分散システムにおける方法を開示している。より詳しく言うと、第１サーバプロ セスと第２サーバプロセスによりそれぞれ実現された２つの目的が等しいかどう かをクライアントのプロセスが決定するという場合の問題がある。ただし各目的 を処理するために目的向きインターフェースが与えられている。これは分散形コ ンピュータシステム内の目的向きプログラミングで実行しなければならない。 ＥＰ ２７８，３１７では、クライアントプロセスシステム内のプロセスが、 サーバ内で修正されたクライアントキャッシュメモリ内のデータにアクセスする のを妨げる方法を記述している。前記データは、すでにサーバ内でアクセスされ てクライアントに送られている。サーバは、ディスク上に永久データファイルを 持ち、サーバのローカルプロセッサが使うキャッシュメモリを持っている。しか し、クライアントプロセスは、サーバとクライアントのキャッシュメモリを用い ている間に、このファイルにアクセスすることができる。ディスクからのファイ ルブロックはサーバのキャッシュメモリに記憶され、クライアントは、ネットワ ークを通してこれからファイルブロックを受けて、このブロックをクライアント キャッシュメモリ内に記憶する。後者のこのデータブロックは、クライアントプ ロセス内での妥当性をチェックし、データが妥当であれば、クライアントキャッ シュメモリからアクセスされる。 特開平５−１１９８３は、異なる宣言言語内のプログラムの間のインターフェ ースを検査する方法を開示している。インターフェースが定義するファイルを作 る手段内で、異なる記述言語に対応するプログラム間のインターフェースを定義 して、プログラム間インターフェース用の定義ファイルを与える、定義情報が与 えられる。一貫性試験手段では、インターフェースの一貫性を試験するための、 プログラム記述言語ソースファイルとプログラム間インターフェースを定義する ファイルが与えられる。さらに、一貫性試験の結果に基づいて、プログラム間イ ンターフェースを自動的に訂正する手段が与えられる。 特開昭６３−８６０３０は、異なるプログラミング言語の間を連結するシステ ムを開示している。ＣＰＵは、Ｃプログラムモジュールと、プロローグ解釈モジ ュールと、急速ノードアクセスモジュールを機能部分として備える。またＣＰＵ は、共通データ領域をプロローグスタックと、大データベースと、規定のメモリ 空間内に確保した情報ベースと共に備える。これらのモジュール間のデータ伝送 制御は、共通のデータ領域と２つの専用スタックにより行う。 特開昭６２−２９３３４７は、異なるプログラミング言語を持つプログラムを 接続する開発システムについて記述している。 ＥＰ ４９８ １３０は、コンピュータシステム内で互いに通信するプログラ ムモジュールの間の互換性を確認する方法について述べている。複数の互いに作 用するシステム要素のそれぞれは、バージョン識別子に関連している。バージョ ン識別子は、他の要素からアクセスできる場所に記憶する。各要素は、互いに作 用する各要素のバージョン識別子を独立に読み出し、この値と内部に記憶してい る互換性レジスタを比較して、他の要素が確認対象の要素との互換性の要件を満 たしているかどうか決定する。互換性がないことが分かった要素は、システムに 誤りの信号を出す。 ＥＰ ４９５ ２７９は、異なるプログラミング言語で書かれた２つの目的向 けプログラムの間の通信の方法を開示している。メッセージの交換を制御するた め、２つのプログラムの間に総称送信メッセージ機能を設ける。これを行うため 、総称送信メッセージ機能は、他のコンピュータプログラム内のクラスの記述に アクセスできる。この記述にアクセスすると、総称送信メッセージ機能は、異な るコンピュータプログラムの間で効率的にメッセージを送信して、新しい目的を 作る可能性を与えることができる。 ＥＰ ３７１ ９４２は、アプリケーションとデータベースマネージャとの間 のインターフェースについて述べている。インターフェースシステムは複数のア プリケーションプログラムインターフェースを、データベース核と実時間で通信 するのに必要なすべての機能性をもつプレコンパイラデベロッパを与える一組の 実時間サービスの形で持つ。 ＥＰ ３７１ ９４１は、異なるプログラミング言語で書かれたアプリケーシ ョンとデータベースマネージャまたは同等物との間のインターフェースについて 記述している。ソフトウエアで支援される複数の機能それぞれに対して、総称ア プリケーションプログラムインターフェース、すなわち入力点を定義する。これ は、機能を実行するためにシステムが要求する一貫した形式の複数のパラメータ を持つ。各入力点は、複数の言語のどれかで書かれたアプリケーションプログラ ムで呼び出して、呼び出しのパラメータをソフトウエアシステム機能が実行する 一貫した総称形式に変換することができる。 ＥＰ ３４３ ６８２は、ソフトウエアを開発し試験する方法を記述している 。設計と試験は互いに直接接続されていて、設計中に設計データを自動的に試験 に用いることができる。 ＥＰ ３１５ ４９３は、ハードウエアやオペレーティングシステムなどのコ ンピュータ環境から独立した、実際のインターフェース作成ソフトウエアについ て述べている。このシステムは、異種の、すなわち「宛先」コンピュータの１個 以上の分散プロセッサ内のアプリケーションソフトウエアが要求する１つまたは 複数のタスクを実行する複数のプロセスを含む。実時間プログラムでは、アプリ ケーションソフトウエアのコードを事前処理し、コンパイルし、システムインタ ーフェースモジュールと連結して、宛先コンピュータのオペレーティングシステ ムが実行可能なコードを作る。プロセスへの多数の機能呼び出しを含む実行可能 なコードはオペレーティングシステムにより走り、アプリケーションソフトウエ アが要求する測度をプロセスが実行できるようにする。 ＵＳ ５ ０４５ ９９４には、大きなプログラムシステムの開発と試験に関 するエミュレーションを行う方法が述べられている。エミュレーティングシステ ム環境を用いて、アプリケーションシステムの実際の入出力インターフェースを シミュレートする。この環境で入出力トランザクションを作り、ユーザはアプリ ケーションシステムから独立していて、その側にあるスクリーン・パワード自動 モードでアプリケイションシステムが後で実行する。 「分散システムにおける混合言語プログラミングを容易にする」、ロジャー・ ヘイズ(Roger Hayes)、リチャード・Ｄ・シュリヒティング(Richard D.Schlicht ing)、ＩＥＥＥ ＴＲＡＮＳＺＡＣＴＩＯＮＳ ＯＮ ＳＯＦＴＷＡＲＥ ＥＮ ＧＩＮＥＥＲＩＮＧ、ＶＯＬ．ＳＥ−１３、ＮＯ．１２、１９８７年１２月、ペ ージ１２５４−１２６４には、同じプログラム内の異なるプログラミング言語間 の手順呼び出しの方法が述べられている。これは、各言語に総称遠隔手順呼び出 しシステムを与えることと、手順インターフェースと共に手順の間で伝送するデ ータを記述するための型のシステムを用いることに基づいている。プログラミン グ言語毎に標準の写像を定義することにより、横断的な言語呼び出しに必要なデ ータ変換を、異なる言語で書かれたプログラム要素の間のインターフェースに含 まれる能動的要素により、ほとんどの場合、自動的に与えることができる。 要約 自分で設計したユーザプログラムの中で、他のプログラムへのインターフェー ス（他のプログラムの機能を用いるにはインターフェースを通す）を用いるプロ グラム設計者は現在多くの問題に直面している。 設計者がインターフェースについてインターフェース説明書に書かれてある以 上のことを知りたいと思えば、これまで他のユーザがそのインターフェースをど のように使っているかを知らなければならない。しかし、使い方が間違っている 場合もあるし、条件が異なる場合もある。 また設計者は他のプログラムの中を見て、機能がどのように設計されているか を見ることもできる。しかし、こうすることは、インターフェースを用いるとい う全体的な原理に反している。ユーザプログラムが他のプログラムの設計の中の 或る特性を用いていることを知らずに他のプログラムの設計者がプログラムを変 更した場合は、その後はそれが機能するかどうか分からない。 ユーザプログラムの設計者が自分のプログラムを試験し、またインターフェー スを通した使用を試験したい場合は、他のプログラムの使用可能なバージョンと 共に走らせる。設計者がこれらのプログラムを一緒に機能させることができたと しても、自分のプログラムが他のプログラムのこの特定の実施態様とだけ一緒に 機能することが分かったに過ぎない。他のプログラムが同じ機能を持つ別のプロ グラムに対して更新され、または変更された場合は、その後はそれが機能するか どうか分からない。 ユーザプログラムの設計者が他のプログラムを用いる場合は、ある誤りの事象 を作ることが難しいと言う点で問題が生じる可能性もある。簡単な例では、問題 の場合に作ったために、或る誤りが他のプログラムでは決して起こらないことが ある。この場合、設計者が他のプログラムを自分で少し書き変えると、インター フェースの機能についての自分の誤解を組み込む恐れがある。 インターフェースの設計に関する問題点のいくつかを以下に要約する。 ・ 通常、インターフェースの意味論的な定義が欠けている。あるとしても、完 全であったり厳密に定義されたりすることはほとんどない。正常とは異なった流 れの場合には特にそうである。 ・ インターフェースを使う人にとって、一緒に用いるプログラムの中が変更さ れても、インターフェース自身が影響を受けない限り、これを使用しても間違い ないことを確認することのできる試験プログラムがないことが多い。 ・ したがって１つのプログラムを単独で保証することはできない。保証できる のは、共に用いるプログラムの特定のバージョンと一諸のときだけである。プロ グラムを変更する度に、そのプログラムだけでなく、共に用いるプログラムをす べて保証し直さなければならない。この発明の一般的な目的は、インターフェー スの機能を完全に定義することである。すなわち、インターフェースの基準モデ ルを示し、次にこの定義を用いて、そのインターフェースをどのように使ったか 、または提供したかに関してプログラムを保証することである。インターフェー スを通して２つのソフトウエアユニットの間の相互作用が確立したとき、この発 明によりこの相互作用を記述し、相互作用の定義が確かに完全で一貫したものに なるよう支援することができる。 別の目的は、インターフェースの機能を、そのインターフェースを通して他の ソフトウエアと互いに作用するソフトウエアと共に試験する方法を示すことであ る。 さらに別の目的は、インターフェースの基準モデルを与えて、そのインターフ ェースの両側のソフトウエアが、相手側の行動に関する情報をそのインターフェ ースの構文的な定義に示されたものより多く得られるようにすることである。よ り詳しく言うと、この情報は、相手側から期待できる行動と、相手側を管理する 測度の範囲とを記述する意味論的な定義も含まなければならない。 この発明のさらに別の目的は、ソフトウエアユニットを保証できるようにする ことである。すなわち、共に動作するソフトウエアの許された行動パターンは、 すべて正しく再現するが、それ以外には内部構造について何も示さない試験プロ グラムを示すことにより、ソフトウエアユニットが正しく動作することと、イン ターフェースを通した他のプログラムと動作することを示すことである。 この発明の第１態様は、インターフェースの機能を、このインターフェースを 通して別のプログラムウエアと互いに作用するプログラムウエアと共に試験する 方法を含む。これは、機能性がインターフェースを通して提供されるプログラム ウエアの実行と、インターフェースを通して提供される機能を使用するプログラ ムウエアの実行とを、インターフェースと共にシミュレートすることにより行い 、そのためインターフェースを通してすべての可能な許容される動作を実行し、 同時にインターフェースと共に試験するプログラムウエアの動作は許容できない ことを一切しないようにチェックする。 この発明の第２態様は、インターフェースの機能を、このインターフェースを 通してその機能性を別のプログラムウエアに提供するプログラムウエアと共に試 験する方法を含む。これは、インターフェースと共に前記プログラムウエアを試 験することによりインターフェースの使用をシミュレートし、同時にインターフ ェースを通してすべての可能な許容される動作を実行し、またインターフェース と共に試験するプログラムウエアは許容できないことを一切しないようにチェッ クすることにより行う。 この発明の第３態様は、インターフェースの機能を、このインターフェースを 通して第２プログラムウエアから提供される機能を用いる第１プログラムと共に 試験する方法を含む。これは、インターフェースと共に前記第１プログラムウエ アを試験することによりインターフェース内の機能の提供をシミュレートし、同 時にインターフェースを通して受けたすべての可能な許容できる動作を処理し、 またすべての可能な応答を返し、同時に試験中のプログラムは許容できない方法 でインターフェースを使用しないよう監視することにより行う。 この発明の第４態様は、ユーザプログラムウエアが、対応するインターフェー スにより各ユーザプログラムウエアから分離されるプロトコルを通して互いに通 信することができる通信システム内で、既存のユーザプログラムウエアと通信す ることができる新しいユーザプログラムウエアを試験する方法を含む。第１およ び第２補助プログラムを提供し、これらは、ユーザプログラムウエアによるイン ターフェースとプロトコル機能の使用をそれぞれシミュレートするための、また 両補助プログラムがインターフェースを通してすべての可能な許容できる動作を 実行し、同時にインターフェースの反対側のプログラムは許容できないことを一 切しないようにチェックするためのコードを含む。第２補助プログラムを通して 新しいプログラムウエアを第１補助プログラムと通信接続させ、両補助プログラ ムに与えられる動作を実行する。 この発明の第５態様は、ユーザプログラムウエアが、対応するインターフェー スにより各ユーザプログラムウエアから分離されるプロトコルを通して互いに通 信することができる通信システム内で、新しいプロトコルプログラムウエアを試 験する方法を含む。補助プログラムを提供し、これは、インターフェースと共に 新しいプログラムウエアを試験することができるユーザプログラムウエアによる インターフェースの使用をシミュレートするための、また補助プログラムがイン ターフェースを通してすべての可能な許容できる動作を実行し、かつインターフ ェースにより試験するプロトコルプログラムウエアは許容できないことを一切し ないようにチェックするためのコードを含む。補助プログラムの２つの複写を作 り、新しいプログラムウエアを通してこれらを互いに通信接続させ、両複写に与 えられる動作を実行する。 この発明の第６態様は、ユーザプログラムウエアが、対応するインターフェー スにより各ユーザプログラムから分離されるプロトコルを通して互いに通信する ことができる通信システム内で、新しいユーザプログラムウエア試験する方法を 含む。補助プログラムを提供し、これは、インターフェースを通してプロトコル の機能を提供することをシミュレートし、同時にインターフェースと共に新しい ユーザプログラムウエアを試験するための、またインターフェースを通してすべ ての可能な許容できる動作を実行し、かつインターフェースの反対側のプログラ ムは許容できないことを一切しないようにチェックするためのコードを含む。新 しいユーザプログラムウエアの２つの複写を作り、補助プログラムを通して互い に通信接続させ、補助プログラムに与えられる動作を実行する。 この発明の第７態様は、プログラムウエアが、各プログラムウエアに対するイ ンターフェースによりこれらのプログラムウエアから分離されるプロトコルを通 して互いに通信することができる、通信システムの基準モデルを提供する方法を 含む。第１および第２補助プログラムを作り、このため第１補助プログラムが、 プロトコルを通して互いに通信しかつ通信において呼び出しも応答も行うことが できるプログラムウエアを表し、第２補助プログラムがプロトコルを表し、第１ 補助プログラムが通信において呼び出し事例と応答事例の両方の動作を行い、両 事例がインターフェースを通してすべての可能な許容できる動作を実行し、同時 にインターフェースの反対側のプログラムは許容できないことを一切しないよう にチェックするためのコードを導入する。 この発明の第８態様は、インターフェースの基準モデルを提供する方法を含む 。第１および第２補助プログラムを作り、このため第１補助プログラムがインタ ーフェースの使用をシミュレートし、第２補助プログラムがインターフェース内 で機能を提供することをシミュレートし、両プログラムがインターフェースを通 してすべての可能な許容できる動作を実行し、またインターフェースの反対側の プログラムは許容できないことを一切しないようにチェックするためのコードを 導入する。 この発明の第９態様は、インターフェースの機能を試験する装置を含む。この 装置は、インターフェースの使用をシミュレートする第１機能性とインターフェ ース内で機能を提供することをシミュレートする第２機能性を備え、インターフ ェースを通してすべての可能な許容できる動作を実行し、同時にインターフェー スの反対側のプログラムは許容できないことを一切しないようにチェックする。 この発明の第１０態様は、プログラムウエアが、各プログラムウエアに対する インターフェースを通してこれらのプログラムウエアから分離されるプロトコル により互いに通信することができる、通信システム内のインターフェースを試験 する装置を含む。第１補助機能性は、プロトコルを通して互いに通信するプログ ラムウエアを表し、第２補助機能性は、プロトコルを表す。第１補助機能性は、 通信において呼び出し事例および応答事例として動作することができる手段を備 える。両事例は、インターフェースを通してすべての可能な許容できる動作を実 行し、同時にインターフェースの反対側のプログラムは許容できないことを一切 しないようにチェックすることができる。 この発明の第１１態様は、ユーザプログラムウエアが、対応するインターフェ ースにより各ユーザプログラムウエアから分離されるプロトコルを通して互いに 通信することができる通信システム内で、既存のユーザプログラムウエアと通信 することができる新しいユーザプログラムウエアを試験する装置を含む。この装 置は、ユーザプログラムウエアによるインターフェースとプロトコル機能の使用 をそれぞれシミュレートする第１および第２補助プログラムを定義し、また両補 助プログラムが、インターフェースを通してすべての可能な許容できる動作を実 行し、同時にインターフェースの反対側のプログラムは許容できないことを一切 しないようにチェックするためのコードを含む。第２補助プログラムを通して新 しいプログラムウエアを第１補助プログラムと通信接続させ、両補助プログラム に与えられる動作を実行する手段を与える。 この発明の第１２態様は、ユーザプログラムウエアが、対応するインターフェ ースにより各ユーザプログラムから分離されるプロトコルを通して互いに通信す ることができる通信システム内で、新しいプロトコルプログラムウエアを試験す る装置を含む。この装置は、インターフェースと共に新しいユーザプログラムウ エアを試験することができるユーザプログラムウエアによるインターフェースの 使用をシミュレートする補助プログラムを定義し、また補助プログラムがインタ ーフェースを通してすべての可能な許容できる動作を実行し、かつインターフェ ースにより試験するプロトコルプログラムウエアは許容できないことを一切しな いようにチェックするためのコードを含む。新しいプログラムウエアを通して補 助プログラムの２つの複写を互いに通信接続させ、また両複写に与えられる動作 を実行する手段を与える。 この発明の第１３態様は、ユーザプログラムウエアが、対応するインターフェ ースにより各ユーザプログラムから分離されるプロトコルを通して互いに通信す ることができる通信システム内で、新しいユーザプログラムウエアを試験する装 置を含む。この装置は、インターフェースを通してプロトコルの機能を提供する ことをシミュレートし、同時にインターフェースと共に新しいユーザプログラム ウエアを試験する補助プログラムを定義し、またインターフェースを通してすべ ての可能な許容できる動作を実行し、かつインターフェースの反対側のプログラ ムは許容できないことを一切しないようにチェックするためのコードを含む。補 助プログラムを通して新しいユーザプログラムウエアの２つの複写を互いに通信 接続させ、補助プログラムに与えられる動作を実行する手段を与える。 異なる態様の実施態様は、各サブクレームに示されている特性を表す機能を持 つ。 インターフェースの基準モデルは、ここではインターフェースを構文的および 意味論的に定義したものとする。 全基準モデルは実行可能である。 インターフェースの設計は、インターフェース自身のソフトウエアを与えるだ けでなく、補助プログラムの設計も含む。 第１補助プログラムは、すべての許容できる使用事例を含むインターフェース の完全なユーザとして作る。第２補助プログラムは、すべての使用事例を処理し 、インターフェースの全体像から分かるように、インターフェースの機能性を実 際に提供するプログラム内で何か起こるかを示す。補助プログラムは、インター フェースと同様に見ることができ、インターフェースに関する完全な情報を含む 。補助プログラムは、常にインターフェースと共に扱われ、一諸に更新されまた 提供される。 補助プログラムとインターフェースは、必ず実行可能なユニットを作ることが できる。両補助プログラムは、互いに監視し合い、何か禁じられていることを相 手のプログラムが行った場合は、誤りであることをプリントアウトする。これは まず補助プログラムの試験中に用い、その後はどちらかの補助プログラムを試験 ツールとして用いるときに用いる。 インターフェースを用いるプログラムを設計するとき、設計者は、第１補助プ ログラムを学ぶことにより、用いる使用事例を知ることができる。さらに設計者 は、インターフェースのサービスを提供するプログラムがどのように機能するか をよよりく理解することができる。主として、これらはすべて第２補助プログラ ムとして機能する。 次にこのプログラムを試験するので、実行可能なユニットをインターフェース および第２補助プログラムと共に作る。この構成は次のような利点を持つ。 ・ 第２補助プログラムは、インターフェースと共に供給されるので、常に使用 可能である。 ・ 第２補助プログラムは、インターフェースの機能を提供する各設計の基準な ので機能する。 ・ 第２補助プログラムは、すでに作られているので明確に記述される。さらに 別のプログラムを必要とするような他のプログラムは一切必要としない。 ・ インターフェースの使用を誤った場合や、インターフェースのサービスを提 供する他のプログラムが許す場合は、第２補助プログラムは、はっきりと誤りで あることをプリントアウトする。 インターフェースの機能を提供するプログラムを設計するときは、どういう使 用事例があり得るかを第１補助プログラムから知ることができる。これらはすべ て処理できなければならない。しかし、ユーザソフトウエアは、これらの使用事 例を超えることはないと仮定してよい。これは、ユーザプログラムを第２補助プ ログラムと共に試験したときに分かる。 さらに、第２ソフトウエアがこれらを処理するすべての可能な方法を導入する 必要はない。したがって、インターフェースに記述される誤りの状況の中には、 当の設計では絶対に起こらないものがある。また考えられるすべての誤りの事例 に対して各ユーザプログラムを備えなければならないとしても、誤りのすべての 事例がその実現の際に起こる必要はない。 新しいプログラムを試験するときは、第１補助プログラムおよびインターフェ ースと一諸に実行可能なユニットを作る。第１補助プログラムにおけるすべての 使用事例を実行し、すべての機能性の実行が得られる。第１補助プログラムは、 第２プログラムからの各反応を監視する。 いわゆる適用度指標(covering degree indicator)により、新しいプログラム のコードの中で走った部分と走らなかった部分を見ることができる。他のどのイ ンターフェースとも関連がないコードや走らなかったコードは、誤りがあると疑 ってよい。 図面の簡単な説明 この発明について、添付の図面を参照して以下に詳細に説明する。 第１図は、この発明の簡単な実施態様を流れ図で示す。 第２図は、多くの異なる着信および発信の回線プロトコルがあるために電話交 換局において発生する問題を説明するためのブロック図である。 第３図は、第２図と同じブロック図であるが、問題を処理するこの発明の補助 プログラムを追加した図である。 第４図は、たとえば普通の電話呼び出しの場合に、この発明の補助プログラム により電話交換局の異なる動作を行い管理する方法を示す流れ図である。 第５図−第１０図は、第４図に示す例から出発して、異なる使用事例でのこの 発明の関わり方を示す図である。 実施態様の詳細な説明 この発明の１つの重要な態様は、インターフェースの基準モデルであって、こ れは、インターフェースの機能をインターフェースを通して他のソフトウエアと 互いに作用するソフトウエアと共に定義し試験するときに用いる。この基準モデ ルは、第１および第２補助プログラムを含む。第１補助プログラムは、インター フェースの使用をシミュレートするモデルプログラムであり、第２補助プログラ ムは、インターフェース内の機能を提供することをシミュレートするモデルプロ グラムである。両プログラムは、インターフェースを通してすべての可能な許容 できる動作を実行し、同時に他のプログラムは許容できないことを一切しないよ うにチェックできるように設計する。 以下に示す基準モデルの機能の異なる実施態様の説明は、主として簡単のため に、インターフェースを通して両補助プログラムが行う相互作用、すなわち補助 プログラムの保証だけに用いる基準モデルの動作を示す。 インターフェースのどちらかの側の新しいプログラムウエアを試験するときの 基準モデルの機能を理解するには、このプログラムウエアは、同じ側の補助プロ グラムを「置き換える」と考えるとよい。なぜなら、この場合に動作するのは相 手側の補助プログラムだからである。このように「置き換えられた」補助プログ ラムは、通常、当の試験には何の機能も持たないが、誤りが発生したときには説 明モデルとして用いることができる。 場合によっては、基準モデルを市販するときは、補助プログラムの一方だけに 限定することも考えられる。すなわち、実際の応用で補助プログラムの提供また は使用の機能が小さいまたは興味の少ないものである場合は、インターフェース の使用をシミュレートする補助プログラムだけか、またはインターフェースの提 供をシミュレートする補助プログラムだけにする。しかし、モデルに含まれる補 助プログラムを試験するには、モデルを設計するときに、この試験のためだけに モデルの試験バージョンを作り、またこのために補助プログラムを追加してもよ い。 場合によっては、第２補助プログラム、すなわち提供する補助プログラムが、 インターフェースを提供するプログラムが必要とするすべての機能を持つことも 考えられる。この場合は、第２補助プログラムは、全システムにも機能を提供す るプログラムになる。そして第２補助プログラムは、許容されない動作を検出す るためのチェックルーチンを含まずに設計してよい。チェックルーチンは、試験 の済んだオペレーティングシステムでは必要がないもので、プロセッサの容量を 消費するだけである。 第１図を参照して、この発明の簡単な実施態様を説明する。背景として、現在 の技術に基づいて考えた状況での測度をまず説明する。 プログラム（以後ＰＲＯＧと書く）には、データを臨時に記憶するためのバッ ファ領域が必要である。バッファ領域は、オペレーティングシステム（以後ＯＳ と書く）が持つ資源である。 ＰＲＯＧからこのバッファ領域にアクセスするには、インターフェースを通し てＯＳに要求しなければならない。 ＰＲＯＧは、プログラミング言語「Ｃ」で書かれているとする。「Ｃ」の一般 的な解説書には次のようなインターフェースの説明が与えられている。 「ｃｈａｒ ＊ｍａｌｌｏｃ（大きさ） は、大きさバイトの連続バッファ領域を占有し、占有が管理されている場合は、 占有領域の始めのポインタが返され、そうでない場合は、空白ポインタが返され る」。 また次のような説明もある。 「ボイド解放(voidfree)（ポインタ） は、ポインタで指され、かつ以前にｍａｌｌｏｃ呼び出しで占有されたバッファ 領域を解放する」。 経験を積んだプログラマにとっては、これで情報は十分である。 しかし、次の場合は、この情報では決して十分ではない。 ・ ｍａｌｌｏｃが空白ポインタを返したとする。これは、プログラムＰＲＯＧ が、要求したバッファ領域にアクセスできなかったことを意味する。オペレーテ ィングシステムの内部設計に従って、この後は次のどれかにつながる。 １） 再試行する。これは一時的である。 ２） これより先に進めない。制御された方法でＰＲＯＧを終わらせて、オペ レーティングシステムをアンロードする。 ３） 何もできない。オペレーティングシステムは、バッファ領域がなければ 動作することができず、システム全体が崩壊する。 ・ ＰＲＯＧがバッファ領域を自由に解放しない場合は消失するか。 ・ ｍａｌｌｏｃにより得た以前のバッファ領域以外をポインタが指したままＰ ＲＯＧを解放すると何が起こるか。 １） 何も起こらない。オペレーティングシステムは、間違いを発見し、ＰＲ ＯＧが終わると、ＰＲＯＧが使用したが解放するのを忘れたすべてのバッファ領 域は解放される。 ２） オペレーティングシステムがＰＲＯＧを信頼する。この場合は、全く予 測できない結果になる。 ・ ＰＲＯＧが大きさ０のバッファ領域を要求すると何が起こるか。 このバッファ領域は解放する必要はないか。 実際には、プログラムＰＲＯＧの設計者は、オペレーティングシステムの動作 を推測し、ＰＲＯＧが完成すると、設計者は、ＰＲＯＧをオペレーティングシス テムと共に実行させて、推測に誤りがあれば、訂正することができる。これがい わゆるデバッグである。しかし、この過程の問題は、ＰＲＯＧが正しく動作する のを確認したのはオペレーティングシステムのその特定のバージョンと共に用い た場合だけであるということである。ＰＲＯＧを別のオペレーティングシステム 、または古いバージョンを新しくしたものと共に用いた場合は、もう一度確認し て場合によっては、ＰＲＯＧを訂正する必要がある。 すべての機能を試験することができるかどうかも確かではない。したがって一 般に、まさに望ましい時点で「バッファ領域不足」とオペレーティングシステム に答えさせることは非常に困難である。したがって、バッファ領域が不足してい るかどうかについて、このプログラムを試験したければ、この場合のオペレーテ ィングシステムの測度をシミュレートする試験プログラムを作らなければならな い。このような試験プログラムの問題は、新しく設計しなければならないことで ある。もし誤りが起こった場合は、間違っているのは試験プログラムであると考 えて試験プログラムを訂正し勝ちである。このため、すべてが機能しているよう に見えるときは、試験プログラムが実際のオペレーティングシステムと同じよう に動作しているかどうか分からない。 これまでは、ＰＲＯＧの設計者の問題だけを取り上げた。しかし、オペレーテ ィングシステムの設計者も、新たに更新したオペレーティングシステムがユーザ プログラムに問題を起こさないことを確認しなければならない。ＰＲＯＧが新し いオペレーティングシステムと共に動作することを確認するだけでは恐らく十分 ではない。ＰＲＯＧは、変更された機能を使わないかも知れない。 ここで、この発明を用いたときに、当のメモリ割り当てインターフェースがど のような形をしているかを説明する。 第１図を参照して、この発明の１で示すインターフェースは、インターフェー スの使用をシミュレートするモデルプログラムＡと、インターフェース内の機能 を提供することをシミュレートするモデルプログラムＢと共に設計する。モデル プログラムＡおよびＢの機能の詳細について、この流れ図を用いて示す。 この例では、モデルプログラムＢは宣言された全体的に利用可能な領域からま ず始まる。この領域は、初めからブロックされないと宣言される。さらに、誰か が領域を要求するのを待っている。モデルプログラムＡが始まると、インターフ ェース１を通して（矢印２）バッファ領域にアクセスを要求する（矢印４）。バ ッファ領域は、モデルプログラムＢが持っているものとしてシミュレートする。 要求４は、呼び出しｍａｌｌｏｃ（大きさ）で送られる。「大きさ」という概念 は、要求されたバッファ領域の大きさを示すパラメータでＡを始めるときに値が 与えられる。 ステップ６で、前回はロックのために失敗したが、改めてバッファ領域を占有 しようとするのではないことをチェックする。失敗の場合であれば、流れはステ ップ８で終わる。そうでない場合は、流れはステップ１０に進み、ユーザプログ ラムが大きさ０のバッファ領域を要求した場合はロックする。このような要求が ある場合は、流れはステップ１２で終わる。そうでない場合は、流れはステップ １４に進み、解放された領域があるかどうか決める。ない場合は、ステップ１６ でロックを示し、空白ポインタをプログラムＡに返す（矢印１８）。領域が使用 可能な場合は、ステップ２０で占有し、ｍａｌｌｏｃ＝ポインタをプログラムＡ に返す（矢印２２）。領域を使用した後、解放（ポインタ）をプログラムＢに返 す（矢印２４）。次にモデルプログラムＢの中でステップ２６に進み、正しい領 域が返されたかどうかチェックする。正しい領域が返されない場合は、ステップ ２８で誤りであることを示す。そうでない場合は、ステップ３０で領域を解放す る。全体はプログラムＡの中で終わる（矢印３２）。プログラムを用いるバッフ ァが実行を終わると、モデルプログラムＢは停止する。次に、送られたバッファ 領域をすべて返したことをチェックする。返してなければ、誤りであることをプ リントアウトする。モデルプログラムＡもＢも、実行中に起こったことを記録す る。 もちろん、インターフェースはバッファ領域の書き込みおよび読み出しの動作 を含んでよい。ここでは、この発明の説明に関係がないので省略しただけである 。 第１図に示す基準モデルから、インターフェースについて次の結論が得られる 。 ユーザプログラムＡの観点から、 ・ ｍａｌｌｏｃ呼び出しですでに停止になっているユーザは再試行できない （ステップ６を参照）。 ・ 大きさ＝０のバッファを要求することはできない（ステップ１０を参照） 。 ・ 領域は解放して返さなければならない。ｍａｌｌｏｃにより得られた、ま だ返されていない領域だけで解放を用いることができる（矢印２４を参照）。 バッファを管理するプログラムＢの観点から、 ・ 要求されるバッファ領域は必ず０より大きい（ステップ１０を参照）。 ・ 解放されているポインタはチェックする必要がない。 ・ ユーザプログラムは得られたバッファ領域を返す。 ユーザプログラムがこれらの規則を破った場合は、モデルプログラムＢを試験 したときに発見される。 インターフェース用の基準モデルは、より複雑なインターフェースにも適用で きる。一例として、プロトコルに適用する方法を示す。以下の説明では、第２図 および第３図を参照して、公衆電話交換システムを処理するときに起こる問題を 取り上げ、この問題を主としてこの発明で解決する方法を示す。 電話交換の目的は、着信呼と別の発信呼とを相互接続することであると言って よい。 呼を設定するには、制御情報（たとえば、どの宛先に届けたいか、すなわち電 話番号）を伝送するためのプロトコルが必要である。歴史的および技術的理由か ら、第２図にＰ１、Ｐ２、．．．、Ｐｎで示すように、非常に多くの異なるプロ トコルがある。よく知られているプロトコルの１つ（たとえば第２図のＰ１）は 普通の押しボタン電話に用いられるもので、通話線のトーン信号が宛先の番号を 知らせる。別のよく知られている例（たとえば第２図のＰ２）はダイヤル信号で 、数字は割り込みパルス列で表す。たとえば、数字４は、４個の連続した割り込 みパルスで表す。 あるダイヤル装置から（第２図の矢印４６で示す着信）トーンダイヤル装置を 呼ぶ（矢印４８で示す発信）とする。これは、たとえばダイヤルインの会社の交 換機への呼び出しであって、内線番号は公衆交換局から会社の交換機へトーンコ ードの形で伝送される。 このためには、連続した割り込みパルスを数えるプログラム（第２図のブロッ ク５０）と、数字をトーンコードに変換して回線に送り出す別のプログラム（第 ２図のブロック５２）が必要である。プログラム５０と５２が互いに通信するに は、通信するための共通の「言語」、すなわちプロトコルを持たなければならな い。この言語では、割り込みパルスやトーンコードという概念は用いない。した がって、すべての電話交換局は、第２図の線５４で示す内部プロトコルを持ち、 すべての回線プロトコルは、この内部プロトコルへまたは内部プロトコルから変 換される。 この電話交換局で別のプロトコルを導入する必要が生じた場合は、この新しい プロトコルは、既存のすべてのプロトコルと協力できるようにしなければならな い。さらに、すべての既存のプロトコルは、この新しいプロトコルと協力できる ようにしなければならない。このように、既存のプロトコルの数が多くなるに従 って、新しいプロトコルを設計するときの複雑さが増す。 第２図の場合、内部プロトコル５４は、この発明に関する種類のインターフェ ースと見なしてよい。この発明に従って基準モデルを導入すると、第３図に示す ような構成になる。この基準モデルは、一方は発呼者（通信の分野の慣用語で言 うと「Ａ側」）を表すモデルプログラムＡと、他方は被呼者（「Ｂ側」）を表す モデルプログラムＢを含む。しかし、この例が前の例とは異なる重要な点が１つ ある。すなわち、一方のモデルは、他方のモデルを内部プロトコルを通して見る ことであり、したがって、相手側に対するインターフェースは、内部プロトコル に対するインターフェースであることである。ＡモデルとＢモデルは、内部プロ トコル５４を通して、すべての可能な許容できる動作を行い、同時にインターフ ェースを通して許容できない動作を行わないようにチェックできるよう設計する 。このチェックをインターフェースで行うために、内部プロトコルを内部プロト コルモデルで置き換える。内部プロトコルモデルは、許容できない動作があれば 、これを発見するためのプログラムウエアルーチンをさらに備える。 第３図に示す構成では、ＡとＢの間で「電話を掛ける」、すなわち呼を設定す ることはできるが会話はできない。会話は別のインターフェースで制御される。 しかし、どのプロトコルＰ１−ＰｎでもＡから「電話を掛ける」ことができ、ま たＢに「呼び出し」を受けることができる。 モデルプログラムＡとＢは、純粋なプログラムウエアユニットなので、自分の ハードウエアは必要ない。これらは常に内部プロトコル５４と共に使用可能であ る。たとえば、着信プロトコルＰｘが作動可能になった場合は、Ｂモデルに対し て、これをすぐ走らせることができる。 Ａモデルは、着信プロトコルができることはすべてできる。Ｂモデルは、発信 プロトコルができることはすべてできるし、また内部プロトコル５４を調停する ことができる。すなわち、 ・ 発信プロトコル、たとえばＰ２は、Ａモデルが与えるすべてを処理できるよ う備えなければならない。つまり、さらに送るか、または拒む、すなわち「でき ない」と知らせることができる。この発信プロトコルＰ２は、Ａモデルに関わる すべてを処理することができるので、新しい、試験されていない、または不測の 機能性を持つ他の着信プロトコルに驚かされることはない。 ・ 着信プロトコル、たとえばＰ２は、Ｐ２が持つ機能を発信プロトコル、たと えばＰ１が処理できない場合に備えなければならない。たとえば、この着信プロ トコルＰ２が押しボタン電話用の場合、発信プロトコルもＰ２であれば、再呼び 出しができるが、たとえば発信プロトコルＰ１へ長距離電話を掛ける場合は、Ｐ １はこの機能を持たないように見える。この場合は、着信側のＰ２がこれに備え なければならない。Ｂモデルは、再呼び出し機能があるかないか分かるようにし なければならない。 ・ 着信プロトコル、たとえばＰ２は、内部プロトコルが処理しない機能を持つ 場合がある。これはＡモデルから見えるので、これらの機能を処理してはならな い。 第４図は、第２図および第３図の電話交換局の異なる動作を、普通の電話で行 う例として、加入者によるモデルＡ’とＢ加入者によるＢモデルの間でどのよう に走らせて管理するかを示す流れ図である。モデルＡ’とＢ’は、それそれぞれ 各インターフェース５６と５８を通して内部プロトコル５５に接続する。 この例ではＡ側かＢ側の少数の使用事例を、特に発生したときを強調して示す 。 実際の内部プロトコルでは両側の間にはより多くの信号があり、またより多くの 事象がＡ側とＢ側それぞれだけでなく内部プロトコルにも起こるが、分かりやす くするために省略した。特に、内部プロトコルを簡単化した。これはプログラム ウエアでもそうであって、実際の事例では、たとえば一方の側に相手側との接触 がなくなったことを知らせるような自分自身の事象がある。 ここで、この発明の重要な特徴の１つを強調したい。それは、どの加入者モデ ルも、内部プロトコル５５の反対側にあるのがモデルであるか「実際の」プロト コルＰ１−Ｐｎであるかを全く知らないということである。第４図の流れ図につ いての以下の説明では、簡単化のために内部プロトコル５５を通して通信するの はに、主としてＡ’モデルとＢ’モデルであると述べているが、これは１つの過 程の問題ではなく、２つの完全に独立した過程がたまたま組み合わされていると いう意味である。これらの過程、すなわちＡ’過程とＢ’過程は「臨床的に」分 離されている。 Ｂ’モデルは、Ｔｂ１、Ｔｂ２、Ｔｂ３の値を持つパラメータと、Ｂ’加入者 に割り当てられた状態で開始し、６０で示すように呼び出しを待っている。Ｔｂ １は、呼び出しにかかる時間の長さを示す。Ｔｂ２は、Ｂ’が応答するまでにか かる時間の長さを示すが、Ｂ’が全く応答しないことも示す。Ｔｂ３は、Ｂ’が 電話を切るまでにかかる時間の長さを示す。Ｂ’加入者の状態は、話中か解放か ロックである。 ６２で示すように、Ａ’モデルは、Ｔａ１とＴａ２の値を持つパラメータで開 始する。Ｔａ１は、Ａ’モデルが電話を切る前に相手側からの応答を待つ時間の 長さを示し、Ｔａ２は、Ａ’モデルが電話を切る前に通話状態を維持する時間の 長さを示す。 実現の際に必要であれば、内部プロトコルは、両側の間のメッセージを調停で きるようにして開始する。この例では、内部プロトコルは自分では一切主導しな い。他のいっそう複雑な例の場合は、開始してからどのくらい時間が経った後で 内部プロトコルが両側に接続が切れれたことを知らせるかを示して、これにより 両側が制御された方法で接続を切ることができるようにするパラメータを持って 開始する。 待機中のモデルは、相手側からのメッセージが到着すると、待機を止めてこの メッセージに従う。これに関して、また以下の説明を完全に理解するために重要 なことは、各メッセージは、３つの部分を持つということである。すなわち、送 信側の希望と内部プロトコルの調停内容と受信側の解釈である。 Ａ’モデルは、まず呼を設定する要求を行い（矢印６４）、内部プロトコル内 の信号「呼び出しを送信」を経て（矢印６６）、Ｂ’モデルに呼を送る（矢印６ ８）。これによりＢ’モデルは、待機を止め、７０で時間Ｔｂ１の測定を開始す る。この後Ｂ’モデルは、上記のように開始時に割り当てられた加入者の状態に 従って継続する。 Ｂ’加入者の状態が話中または呼び出し不可(unobtainable)の場合は、Ｂ’モ デルの事象は７２に示すように停止し、内部プロトコル内の信号「話中」または 「呼び出し不可」（それぞれ矢印７４と７６）により、Ａ’モデルはメッセージ を「話中トーンを送信」（矢印７８）と「呼び出し不可トーンを送信」（矢印８ ０）と解釈する。もちろんＡ’モデルは、トーンを一切送信してはならない−− 送信することができない。しかし、実際のプロトコルは、この場合、トーンを送 信する場合がある。８２に示すように、Ａ’モデルの事象の流れは停止する。 事象６８、７４、７８および６８、７６、８０は、Ａ側の第１および第２使用 事例を表す。すなわち、Ｂ側はＡ側からの呼に対して「話中」および「呼び出し 不可」をそれぞれ返す。 Ｂ’加入者の状態が解放されている場合は、内部プロトコル内で信号「呼び出 し可」をＡ側に送信し（矢印８４）、Ａ’モデルは、これを「ダイヤルトーンを 送信」と解釈する（矢印８６）。もちろん、Ａ’モデルは、この場合もトーンを 送信することができない。上述の「話中トーンを送信」と「呼び出し不可トーン を送信」の場合と同様に、実際のプロトコルで何が行われるか示す記述だけの問 題がある。ダイヤルトーンがある場合はすぐに送信しなければならない。Ｂ’モ デルは、同時に８８で時間Ｔｂ２の測定を開始し、Ａ’モデルは、９０で時間Ｔ ａ１の測定を開始する。 パラメータＴｂ２で設定された時間が経った後、Ｂ’モデルは、Ａ’モデルに 応答を送信し（矢印９２）、これを内部プロトコルが調停して「Ｂ応答」とし （矢印９４）、Ａ’モデルは、これを「ダイヤルトーンを停止」と解釈する。要 求を実行した後、Ａ’モデルは、時間Ｔａ１の測定を止めて、９８で時間Ｔａ２ の測定を開始する。 パラメータＴａ１で設定した相手側からの応答を待つ時間か、パラメータＴａ ２で設定した通話状態の時間のどちらか時間測定が行われている方の時間が経過 した後、１００でＡ’モデルは電話を切る。 事象８４、８６、９０および９２、９４、９６、９８は、Ａ側の第３および第 ４使用事例をそれぞれ表す。すなわち、それぞれＡ側が呼んだときにＢ側は、解 放されているが応答しない場合と、Ｂ側は応答するが電話を切らない場合である 。これに対応して、Ｂ側では第１および第２使用事例がある。すなわち、それぞ れＡ側が呼び出しを掛けるがＢ側が応答する前に切る場合と、Ｂ側が応答した後 で切る場合である。 Ｂが応答のメッセージを送信する（矢印９４）とき、Ｂ’モデルは１０２で時 間Ｔｂ３の測定を始める。この時間が経過した後、Ｂ’モデルは電話を切る（矢 印１０４）。これはＡ側の第５使用事例を表す。すなわちＡ側が呼んだとき、Ｂ は応答してから切る。これに対応して、Ｂ側には第３使用事例がある。すなわち 、Ａ側は呼ぶが、Ｂ側が切る前には切らない。 第４図に関する上記の説明から、いくつかの意味論的な規則が得られる。たと えば、 ・ Ａ側は、Ｂ側が状態を返す前に切ることはできない。 ・ Ａ側もＢ側も、呼び出し不可／話中の後はさらにメッセージを送ることがで きない。 ・ Ｂの応答は、Ｂが解放された後だけ送信してよい。 Ａ’モデルでは停止のための切断は、内部プロトコル内の信号「Ａ切断」（矢 印１０６）、応答メッセージを要求するＢ側への信号（矢印１０８）、Ｂ側から の対応する応答「切断」（矢印１１０）、内部プロトコル内の信号「Ｂ実行可能 」（矢印１１２）、停止１１３への矢印１１４、により実行する。Ｂ’モデルの 切断は、内部プロトコル内の信号「Ｂ切断」（矢印１１６）、応答メッセージを 要求するＡ側への信号（矢印１１８）、Ａ側からの対応する応答メッセージ「切 断」 （矢印１２０）、内部プロトコル内の信号「Ａ実行可能」（矢印１２２）、停止 １２５への矢印１２４、により実行する。 上記から、どちら側も相手側が応答したことを確かめずに切断してはならない ことが分かる。図に示してはいないが、ステップ１０８と１１０の間とステップ １１８と１２０の間にそれぞれ遅れを入れてもよい。 第４図に示す例から通信の問題の場合に、この発明が一般に意味することをよ り詳細に分析する。 まず公衆電話局内に完全な回線インターフェースの問題があると仮定する。第 ４図を描き直して細部を省略すると、第５図のようになる。この図の特徴は、３ つの要素から成る基準モデルである。すなわち、Ａ’モデルとＢ’モデルと内部 プロトコルモードＩがあり、Ａ’モデルとＩモデルの間にはインターフェース５ ６があり、ＩモデルとＢ’モデルの間にはインターフェース５８がある。 Ｉモデルをよく調べると次のことが分かる。 最も簡単な事例では、Ａ’とＢ’またはそれが表す応用は、同じローカル局で 同じプロセッサ上で実行する。ローカル電話の通話に問題があることがある。 しかし、知られているように地球の裏側に電話を掛けるのには大きな差はない 。この場合は、同じＩモデルが極めて複雑な技術システムである全地球の電話網 の一部を表す。このような国際的な通話が行われるインターフェースの数は電話 網の経験を積んだ設計者にとっても巨大なものである。しかし、内部プロトコル モデルＩは、複雑な長距離電話の場合でも管理可能な抽象的なモデルである。 さらに実際のところ、送話にも受話にも同じ電話を用いることができる。この 観点から分かるように、Ａ’モデルとＢ’モデルには全く差がなく、２つの全く 同じ型の個体である。説明を続けるために、また第１図と第３図に示すような他 の実施態様とこの発明の関係を示すために、これらのモデルをそれぞれＡ”１お よびＡ”２と呼ぶことにする。同じ理由からＩモデルをＢ”と呼び変えると、第 ５図は第６図に示す形になる。図に示すように、第５図の２つのインターフェー ス線は１つのインターフェースになり、これが実際である。 上記のようにＡ”１は、Ａ”２と同等と見なすことができるので、これらをま とめて第７図のようにＡ”としてよい。その結果は、この発明で定義した内部基 準モデルになることが分かる。ここでＡ”は、インターフェースの使用をシミュ レートする第１補助プログラムであり、またＢ”は、インターフェース内の機能 を提供することをシミュレートする第２補助プログラムであると特徴付けること ができる。２つのプログラムは、インターフェースを通してすべての可能な許容 できる動作を実行し、同時に相手のプログラムが許容できないことを一切しない ようにチェックすることができる。第４図の実施態様では、「Ａ’モデル」と「 Ｂ’モデル」が第１補助プログラムを形成し、内部プロトコルモデル５５が第２ 補助プログラムを形成する。実際は、インターフェース５６と５８は、同じイン ターフェースである。すなわち、この発明の基準モデルが目的とするものである 。 より広い観点から、上に例示した同等性は、次のように解釈することができる 。 Ａ側はＢ側に情報を送り、後でそれを戻してもらう。それが１つの同じＡ個体 の場合は、第１図の実施態様のようにＢはメモリ機能である。Ａ個体が２つの場 合は、Ｂはたとえば第４図に示すように通信機能である。 このモデルから抽象できることは、そしてこれは重要なことであるが、Ｂ側が 情報を内部でどのように処理するかである。モデルＡから見ると、Ｂ側がメッセ ージを来た通りに受けてそのまま返しても、インターフェースに示されている方 法で変えても、またはＢ側が、たとえばメッセージを符号化して十分大きなパケ ットに分割し、回線などにより送信し、次にパケットを受け、パケットを合わせ てメッセージにして復号し、Ａに戻しても差は全くない。 第２補助プログラムがプロトコルを表す場合は、次のように基準モデルの使用 事例が３つある。 １） 通信インターフェースの使用（第８図を参照） この場合は、ユーザプログラムウエアの新しいバージョンａ”１の試験はイン ターフェース（これはＡ個体の１つを表してよい）と共に行わなければならない 。ａ”は「第２補助プログラムＢ」を通して第２のＡ個体であるＡ”２に「電話 を掛ける」ことができる。これは「第１補助プログラム」の能力により、新しい プログラムウエアが呼ぶことができる。この使用事例は、Ａ”２がａ”１を呼ぶ 場合も含む。 ２） 新しい通信システムの設計（第９図を参照） この場合は、Ｂ個体（ここではｂ”と書く）は、新しい通信システムで、２つ のＡ個体であるＡ”１とＡ”２から成る「第１補助プログラム」により、インタ ーフェースと共に試験しなければならない。新しい通信システムｂ”は、Ａ”１ とＡ”２があらゆる方法で互いに「電話を掛ける」ことができる場合を扱うこと ができる。 ３） ユーザ内の通信（第１０図を参照） この場合は、２つのＡ個体を新しいユーザプログラムウエアの「呼び出し」部 ａ”１と「応答」部ａ”２でそれぞれ置き換えて、「第２補助プログラム」Ｂ” によりインターフェースと共に試験しなければならない。実際は、自分の複写を 「呼び出し」て情報を伝送するという、１つの同じ新しいプログラムウエア機能 の問題がある。 ２つの複写ａ”１とａ”２は、必ずしも他のプログラムに理解できなくてもよ い方法で互いに通信する。この構成で確認しなければならないことは、メッセー ジがＢを通ってその内容が何らかの修正を受けたときも、相手を互いに理解する ということである。したがって自分自身と通信するプログラムウエアを設計して 保証するには、通信固有のＢモデルが必要である。このＢモデルは、この通信を 行う最も簡単な方法を表す。 実際に、この発明の方法を用いる実施態様をより詳細に以下に説明する。 出発点は従来の方法で指定された非常に簡単なインターフェースで、その目的 は基準モデルを用いてインターフェースの定義を厳密にしたときに何が起こるか を詳細に検討することである。 全欧州ディジタル移動電話システムＧＳＭ用のシステムでは、あるネットワー ク内にいる加入者は、このネットワークから離れて別のネットワークのカバレー ジ領域に入っても、元のネットワークと同じサービスを受けることができる。同 じ国内に、ネットワークが同じ地理的領域をカバーする複数の普通は競合関係に あるネットワーク運営者があってよい。したがって異なる運営者は異なる協力者 を持ち、自分の本拠地の領域外でもできるだけ大きなカバレージを自分の加入者 グループに提供する。しかし協力ネットワークに属していない加入者は、一方で は競合上の理由で、他方では協力規約がなければ料金の徴収ができないという理 由で断られる。したがって外部の加入者からサービスを要求された場合は、この 加入者が協力ネットワーク運営者に属しているかどうか知って、サービスを提供 するか断るかを決める必要がある。サービスを要求する加入者は、たとえばＰＬ ＭＮ（公衆陸上移動ネットワークの略）パラメータ（その加入者が属するネット ワーク運営者を示す）を用いて自分を識別する。ここで、自分のネットワークが このように示された運営者と協力するかどうかを決定する。 この機能は、例としてここに選択したインターフェースを通して提供される。 プログラムウエアを詳細に示す前に、この発明の基準モデル法は、特定のコン ピュータ環境に限定されないことを強調したい。したがって、ここに説明するプ ログラムウエアはプログラム言語やオペレーティングシステムやコンピュータ構 成などに関しては中立である。理解を助けるためにより詳しく言うと、このプロ グラムウエアは直感的理解が得られる、いわゆる疑似コードで書かれている。 インターフェースの構文的な定義は、疑似コードで書くと次のようになる。 ｍｅｔｈｏｄ ｃｈｅｃｋＶａｌｉｄＭＳ により、インターフェースは、移 動体加入者（ＭＳ）が協力ＰＬＭＮに属しているかどうかを知る可能性を定義す る。移動体加入者のＰＬＭＮは、付随のパラメータＰｌｍｎに示されており、そ の形式は、ＧｓｍＰｌｍｎＩｄである。この質問に対する回答は、ＧｓｍＰｌｍ ｎＲｅｓｕｌｔという形式の返却値で与えられる。 その結果は以下の３つのどれかである。ＧｓｍＰｌｍｎＶａｌｉｄＭＳは、そ の加入者にサービスを提供してよいことを示す。ＧｓｍＰｌｍｎＵｎＶａｌｉｄ ＭＳは、（ここには例として示していないが）その加入者を断るべきことを示す 。３番目のＧｓｍＰｌｍｎＤＢＮｆａｕｌｔは、残念なことに回答できないこと を示す。ＤＢＮｆａｕｌｔは、データ内に誤りがあることを示す。 ＧｓｍＰｌｍｎＩｄは、別のところで定義する。このように定義には、使用で きるしいずれ使用するが、実際にどのような形をしているかには関心がないもの がある。認められている定義を用いてもよいが、自分の定義を見つけてもよい。 基準モデルの原理は、次のようにしてこのインターフェースに適用することが できる。この発明で定義される第１補助プログラムは、次のようなものである。 この発明で定義される第２補助プログラムは、次のようなものである。 さらにＰｌｍｎステートメントの書式であるＧｓｍＰｌｍｎＩｄの定義が必要 である。この定義は、別のインターフェースの一部であって、３つの異なる場合 が考えられる。 １） Ｐｌｍｎステートメントの認められている書式を示す、準備された正し い定義がある。それが扱いやすいものであれば使ってよい（Ｐｌｍｎの正しい書 式は３＋２桁である）。 ２） インターフェースＧｓｍＰｌｍｎＩｄにも基準モデルがある。この場合 は、インターフェースＧｓｍＰｌｍｎＩｄの他に、その第２補助プログラムを用 いる。 ３） インターフェースに固有のものだけがある。すなわち、書式の型の名が ＧｓｍＰｌｍｎＩｄという場合である。この場合は、ＧｓｍＰｌｍｎＩｄの自分 の定義を準備しなければならない。これはどんな形でもよい。Ｐｌｍｎは１桁ま たは文字列で示してよい。１）または２）の型の定義がないときは、この定義を 用いる。 このようにして、完全な基準モデルが得られた。これは次のように用いる。 Ａ） インターフェースの意味論的なモデルもある。第１補助プログラムは、 インターフェースの一般的な使用を示す。実際は、これをテンプレートとしてユ ーザプログラムに複写してよい。補助プログラムから意味論的な規則がないこと は、情報が与えられない場合は、加入者にサービスを提供するかどうかを決める のはインターフェースはなく、使用するプログラムが自分で決めなければならな い、ということである。 第２補助プログラムは、意味論的な規則を含む。すなわち、ＧｓｍＰｌｍｎＤ ＢＮｆａｕｌｔを受信した場合はユーザとして再試行することはできない。イン ターフェースを提供するプログラムにとって、この意味は、データベース（また は困難を生じたものは何でも）が再試行を許す場合は、再試行するのは提供する プログラムであり、最初にそれが放棄したときはＧｓｍＰｌｍｎＤＢＮｆａｕｌ ｔと応答するということである。したがって、使用するプログラムが再試行する のは常に無意味である。 Ｂ） 新しく設計したユーザプログラムは試験しなければならない。これは第 ２補助プログラムから機能を提供されるインターフェースを呼び出す。システム アプリケーションにおいて、このインターフェースを提供するプログラムの代わ りに、この補助プログラムを用いると、次の利点がある。 ・ インターフェースと共に機能し容易に利用できる補助プログラムがある。 実行可能なものであっても、システムアプリケーションは、かなり複雑なので、 恐らく完全ではない。 ・ 試験を行うのに完全なデータベースを作る必要はない。見つけられる誤り の多くは、データベースの構成が間違っているため、またはデータベースを用い るプログラムに欠陥があるためである。このような場合は、自分のプログラムの 欠陥は見過ごしやすい。 ・ 機能するデータベースを何とか作った場合、機能を止める、すなわちＧｓ ｍＰｌｍｎＤＢＮｆａｕｌｔという応答を出すことは決して些細なことではない 。 ・ 補助プログラムは、問題になるＰｌｍｎを書き出す。途中でステートメン トが間違った場合は、試験するＰｌｍｎを補助プログラムが書き出すときに見つ けることができる。１つの動作中に要求が繰り返される場合も（これ自体は禁じ られているのではなく、不必要である）見つけられる。 Ｃ） インターフェースを提供する新しく設計したプログラムは、試験しなけ ればならない。これはインターフェースおよび第１補助プログラムと共に作る。 この場合、Ｐｌｍｎ値が受け入れられるかどうかという、データベースプログラ ムに対する問題がすぐ起こる。これを純粋なシステムアプリケーションにより行 う場合は、完全な移動電話システムがまず必要である。多数の異なるＰｌｍｎ値 がある場合でも速く走れるように、第１補助プログラムは制御が容易でなければ ならない。 この発明は多くの重要な利点を持つ。 この発明により、インターフェースは、完全に、すなわち構文的および意味論 的に定義される。意味構造は形式的に正確に定義される。 インターフェースは、意味構造を言語で記述できる場合もあるしできない場合 もあるが、これを用いる設計者は経験が必要である。したがって実験や間違いに より得られるのは経験であって、やはり正しくもなく完全でもなく、これをさら に他の設計者に単に伝えることはできない。 しかし、この発明に従ってインターフェースにモデルプログラムを与えること ができれば、すべての知識は、インターフェースに関連付けられ、インターフェ ースのユーザは、必要な知識をすべて得たことが分かる。さらに、すべての他の 設計者がインターフェースについて同じ知識を持っていることがユーザに分かる 。つまり他の関係者が違った意味に解釈する可能性があると考える必要がなく、 したがって常にチェックする必要があるのは、許容できないと自分が考えること を他の関係者が一切しないということである。これらの試験が、インターフェー スを用いるときの設計の負担や実行時間にかかるコストである。 インターフェースモデルにより、使用したり提供したりするインターフェース から見たプログラムウエアユニットの形式の保証を行うことができる。この保証 は、自分に含まれる、またはインターフェースの反対側に含まれる、プログラム ウエアユニットの異なるバージョン、変形、版、組み合わせのすべてに関係なく 行われる。 この方法により保証されたプログラムウエアユニットは、いつまでも保証され る。環境が変わったという理由で再保証を行う必要はない。プログラムウエアユ ニットは、基準モデルプログラムと共に供給され、だれでもこれらを実行するこ とができる。保証プロトコルは必要ない。必要なときは反復して保証を行うこと ができる。 この方法を用いるとき、モデルプログラムは、インターフェースと共に提供さ れる。モデルプログラムにより、顧客はインターフェースを容易に用いることが できる。 モデルプログラムは、供給されず、別の供給されたプログラムウエアの事前の 保証に用いられる場合もある。この場合は、このプログラムウエアの質がモデル プログラムにより保証されていることを保証プロトコルで確かめる。

Claims (1)

1. 【特許請求の範囲】 １． インターフェースの機能を、前記インターフェースを通して別のプログ ラムウエアと互いに作用するプログラムウエアと共に試験する方法であって、そ の機能性が前記インターフェースを通して提供されるプログラムウエアの実行と 、前記インターフェースを通して提供される機能を使用するプログラムウエアの 実行とを、前記インターフェースと共にシミュレートすることを特徴とし、前記 インターフェースを通してすべての可能な許容できる動作を実行し、同時に前記 インターフェースと共に試験するプログラムウエアは許容されないことを一切し ないようにチェックする、インターフェースの機能を試験する方法。 ２． すべての許容できる使用事例を含むものとして前記インターフェースの 使用の前記シミュレーションを行い、すべての使用事例を処理することにより前 記インターフェースを通して機能を提供することのシミュレーションを行い、実 際に前記インターフェースの機能性を提供するプログラムウエアに何が起こるか を示すことを特徴とする、請求項１記載のインターフェースの機能を試験する方 法。 ３． 前記インターフェースを含む実行可能なユニットにより前記処理を実行 することを特徴とする、請求項１または２記載のインターフェースの機能を試験 する方法。 ４． 前記シミュレーションを実行し、同時に前記インターフェースと共に試 験するプログラムウエアを監視して、何か許容できないことを行った場合は誤り であることをプリントアウトすることを特徴とする、請求項１−３のいずれかに 記載のインターフェースの機能を試験する方法。 ５． インターフェースの機能を、前記インターフェースを通してその機能性 を別のプログラムウエアに提供するプログラムウエアと共に試験する方法であっ て、前記インターフェースと共に前記プログラムウエアを試験することにより前 記インターフェースの使用をシミュレートし、同時に前記インターフェースを通 してすべての可能な許容できる動作を実行し、前記インターフェースを通して試 験するプログラムウエアは許容されないことを一切しないようにチェックするこ とを特徴とする、インターフェースの機能を試験する方法。 ６． すべての許容できる使用事例を含むものとして前記インターフェースの 使用の前記シミュレーションを行うことを特徴とする、請求項５記載のインター フェースの機能を試験する方法。 ７． シミュレートするプログラムと前記インターフェースと試験するプログ ラムを含む実行可能なユニットによりシミュレーションを行い、同時に、試験す るプログラム内の事象の流れを前記インターフェースを通して開始しまた制御す ることを特徴とする、請求項５または６記載のインターフェースの機能を試験す る方法。 ８． 前記インターフェースと共に試験するプログラムウエアを監視し、何か 許容できないことを行った場合は誤りであることをプリントアウトすることを特 徴とする、請求項５−７のいずれかに記載のインターフェースの機能を試験する 方法。 ９． インターフェースの機能を、前記インターフェースを通して第２プログ ラムウエアから提供される機能を用いる第１プログラムウエアと共に試験する方 法であって、前記インターフェースと共に前記第１プログラムウエアを試験する ことにより前記インターフェース内の機能を提供することをシミュレートし、同 時に前記インターフェースを通して受けたすべての可能な許容できる動作を処理 し、すべての可能な応答を返し、同時に試験中のプログラムは許容できない方法 で前記インターフェースを使用しないよう監視することを特徴とする、インター フェースの機能を試験する方法。 １０． すべての使用事例を処理することにより前記試験を行い、実際に前記 インターフェースの機能性を提供するプログラムウエアに何が起こるかを示すこ とを特徴とする、請求項９記載のインターフェースの機能を試験する方法。 １１． 前記インターフェースの完全な情報と定義に基づいて試験を行うこと を特徴とする、請求項９または１０記載のインターフェースの機能を試験する方 法。 １２． 試験中のプログラムを含む実行可能なユニットによるシミュレーショ ンを行い、同時にインターフェースを通して前記プログラムを離れる事象の流れ をとらえて前記プログラムに返すことを特徴とする、請求項９−１１のいずれか に記載のインターフェースの機能を試験する方法。 １３． 試験を実行し、同時に前記インターフェースと共に試験するプログラ ムを監視して、何か許容できないことを行った場合は誤りであることをプリント アウトすることを特徴とする、請求項９−１２のいずれかに記載のインターフェ ースの機能を試験する方法。 １４． 前記インターフェースと共に、前記インターフェースを通るすべての 可能な許容できる動作を実行して前記インターフェースの使用をシミュレートす ることにより前記インターフェース内の機能の提供のシミュレーションを試験し 、同時に前記インターフェース内の機能の提供のシミュレーションが許容できな い結果を一切生じないようにチェックすることを特徴とする、請求項９−１３の いずれかに記載のインターフェースの機能を試験する方法。 １５． ユーザプログラムウエアが、対応するインターフェースにより前記各 ユーザプログラムから分離されるプロトコルを通して互いに通信することができ る通信システム内で、 既存のユーザプログラムウエアと通信することができる新しいユーザプログラ ム試験する方法であって、 第１および第２補助プログラムを与え、これらは、ユーザプログラムウエアに よる前記インターフェースと前記プロトコル機能の使用をそれぞれシミュレート するための、また両補助プログラムが前記インターフェースを通してすべての可 能な許容できる動作を実行し、同時に前記インターフェースの反対側のプログラ ムが許容できないことを一切しないようチェックするためのコードを含み、 前記第２補助プログラムを通して前記新しいプログラムウエアを前記第１補助 プログラムと通信接続させ、前記両補助プログラムに与えられる動作を実行する ことを特徴とする、通信システムを試験する方法。 １６． ユーザプログラムウエアが、対応するインターフェースにより前記各 ユーザプログラムから分離されるプロトコルを通して互いに通信することができ る通信システム内で、 新しいプロトコルプログラムウエア試験する方法であって、 補助プログラムを提供し、これは、前記インターフェースと共に新しいプログ ラムウエアを試験することができるユーザプログラムウエアによるインターフェ ースの使用をシミュレートするためのまた前記補助プログラムが前記インターフ ェースを通してすべての可能な許容できる動作を実行し、かつ前記インターフェ ースにより試験するプロトコルプログラムは許容できないことを一切しないよう チェックするためのコードを含み、 前記補助プログラムの２つの複写を作り、前記新しいプログラムウエアを通し てこれらを互いに通信接続させ、 前記両複写に与えられる動作を実行する、 ことを特徴とする、通信システムを試験する方法。 １７． ユーザプログラムウエアが、対応するインターフェースにより前記各 ユーザプログラムから分離されるプロトコルを通して互いに通信することができ る通信システム内で、 新しいユーザプログラムを試験する方法であって、 補助プログラムを提供し、これは、前記インターフェースを通して前記プロト コルの機能を提供することをシミュレートし、同時に前記インターフェースと共 に新しいユーザプログラムを試験するための、また前記インターフェースを通し てすべての可能な許容できる動作とを実行し、かつ前記インターフェースの反対 側のプログラムは許容できないことを一切しないようチェックするためのコード を含み、 前記新しいユーザプログラムの２つの複写を、前記補助プログラムウエアを通 して互いに通信接続させ、 前記補助プログラムに与えられる動作を実行する、 ことを特徴とする通信システムを試験する方法。 １８． プログラムウエアが、前記各プログラムウエアに対するインターフェ ースにより、これらのプログラムウエアから分離されるプロトコルを通して互い に通信することができる、通信システムの基準モデルを提供する方法であって、 第１および第２補助プログラムを作り、このため、 前記第１補助プログラムが、前記プロトコルを通して互いに通信しかつ通信に おいて呼び出しも応答も行うことができるプログラムウエアを表し、 前記第２補助プログラムが前記プロトコルを表し、 前記第１補助プログラムが通信において呼び出し事例と応答事例の両方の動作 を行い、 両事例が前記インターフェースを通してすべての可能な許容できる動作を実行 し、同時に前記インターフェースの反対側のプログラムは許容できないことを一 切しないようにチェックする、 ためのコードを導入することを特徴とする、通信システムの基準モデルを提供す る方法。 １９． 前記インターフェースと共に２つのプログラムを作り、維持し、供給 することを特徴とする、請求項１８記載の通信システムの基準モデルを提供する 方法。 ２０． 前記第１補助プログラムが前記インターフェースの完全なユーザとし て動作し、呼び出し事例としての役目と応答事例としての役目においてすべての 許容できる使用事例を含み、 前記第２補助プログラムがすべての使用事例を処理し、使用事例の処理中に起 こり得る、また前記インターフェース内で定義される、すべての考えられる結果 と誤りを作り、また実際に前記インターフェースの機能性を提供する或る設計の プログラム内で何が起こり得るかを示す、 ためのコードを導入することを特徴とする、請求項１８または１９に記載の通信 システムの基準モデルを提供する方法。 ２１． 前記第１および第２補助プログラム内にコードを導入して、 前記２つの第１補助プログラム事例の間の通信を、前記第２補助プログラムを 通して実行することができ、 前記応答事例だけがアドレスされ、 前記第２補助プログラムは、実際にプロトコルに影響を与える可能性のあるす べての誤り事例を作ることができる、 ようにすることを特徴とする、請求項１８−２０のいずれかに記載の通信システ ムの基準モデルを提供する方法。 ２２． 前記第１および第２補助プログラムを前記インターフェースと同様に 見えるようにし、前記インターフェースの完全な情報と定義を含むコードを導入 することを特徴とする、請求項１８−２１のどれかに記載の通信システムの基準 モデルを提供する方法。 ２３． 前記インターフェースと共に前記第１および第２補助プログラムを作 って実行可能なユニットを形成し、また前記第１補助プログラムが２つの補助プ ログラム事例を作り、かつ、前記インターフェースを通して前記第２補助プログ ラムにより前記事例の間の通信を可能にするためのコードを導入することを特徴 とする、請求項１８−２２のいずれかに記載の通信システムの基準モデルを提供 する方法。 ２４． 前記第１および第２補助プログラムは、前記インターフェースの反対 側のプログラムを監視して、このプログラムが何か許容されないことをした場合 は誤りであることをプリントアウトし、 前記第１補助プログラムは、通信する相手のユーザプログラムが何か許容され ないことをしないようチェックする、 ためのコードを導入することを特徴とする、請求項２３記載の通信システムの基 準モデルを提供する方法。 ２５． インターフェースの基準モデルを提供する方法であって、 第１および第２補助プログラムを作り、 前記第１補助プログラムが前記インターフェースの使用をシミュレートし、 前記第２補助プログラムが前記インターフェース内の機能を提供することをシ ミュレートし、 両プログラムが前記インターフェースを通してすべての可能な許容できる動作 を実行し、また前記インターフェースの反対側のプログラムは許容できないこと を一切しないようにチェックする、 ためのコードを導入することを特徴とする、インターフェースの基準モデルを提 供する方法。 ２６． 前記インターフェースと共に前記両プログラムを作り、維持し、供給 することを特徴とする、請求項２５記載のインターフェースの基準モデルを提供 する方法。 ２７． 前記第１補助プログラムを前記インターフェースの完全なユーザにし て、すべての許容できる使用事例を含め、 前記第２補助プログラムがすべての使用事例を処理し、使用事例の処理中に起 こり得る、また前記インターフェース内で定義される、すべての考えられる結果 と誤りを作り、また実際に前記インターフェースの機能性を提供する或る設計の プログラム内で何が起こり得るかを示す、 ためのコードを作ることを特徴とする、請求項２５または２６記載のインターフ ェースの基準モデルを提供する方法。 ２８． 前記第１および第２補助プログラム内にコードを作って前記インター フェースと同様に見えるようにし、また前記インターフェースの完全な情報と定 義を含めることを特徴とする、請求項２５−２７のいずれかに記載のインターフ ェースの基準モデルを提供する方法。 ２９． 前記第１および第２補助プログラムとインターフェースを作って全部 で実行可能なユニットを形成することを特徴とする、請求項２５−２８のいずれ かに記載のインターフェースの基準モデルを提供する方法。 ３０． 前記第１および第２補助プログラム内にコードを導入して前記インタ ーフェースの反対側のプログラムを監視できるようにし、このプログラムが何か 許容できないことをした場合は誤りであることをプリントアウトすることを特徴 とする、請求項２５−２９のいずれかに記載のインターフェースの基準モデルを 提供する方法。 ３１． インターフェースの機能を試験する装置であって、 前記インターフェースの使用をシミュレートする第１機能性と、前記インター フェース内の機能を提供することをシミュレートする第２機能性を備え、前記イ ンターフェースを通してすべての可能な許容できる動作を実行し、同時に前記イ ンターフェースの反対側のプログラムは許容できないことを一切しないようにチ ェックすることを特徴とする、インターフェースの機能を試験する装置。 ３２． 前記インターフェースを提供しまたは使用する新しく設計または修正 したプログラムを、第１および第２補助機能性と共に前記インターフェースと前 記プログラムのコードをそれぞれ実行することにより保証する手段と、前記第１ または第２補助機能性内のすべての使用事例または処理を実行し、同時に保証に 反する許容できない性能を探す手段を特徴とする、請求項３１記載のインターフ ェースの機能を試験する装置。 ３３． 前記インターフェースにより影響され、かつ、保証されたプログラム に含まれるすべてのプログラムシーケンスを試験するコードを実行し、同時に許 容できない隠れた明記されない機能性を探す前記手段を特徴とする、請求項３１ または３２記載のインターフェースの機能を試験する装置。 ３４． 前記インターフェースの完全なユーザをシミュレートし、すべての許 容できる使用事例を含む前記第１補助機能性と、すべての使用事例の処理をシミ ュレートしまたプログラム内で何が起こり得るかを示し、かつ実際に前記インタ ーフェースの機能性を提供する前記第２補助機能性とを特徴とする、請求項３１ −３３記載のインターフェースの機能を試験する装置。 ３５． 前記第１および第２補助機能性は、前記インターフェースと同様に目 に見え、また前記インターフェースの完全な情報を含むことを特徴とする、請求 項３１−３４記載のインターフェースの機能を試験する装置。 ３６． 前記第１および第２補助プログラムは、前記インターフェースと共に 実行可能なユニットを形成することを特徴とする、請求項３１−３５記載のイン ターフェースの機能を試験する装置。 ３７． 前記第１および第２補助機能性は、前記インターフェースの反対側の プログラムを監視し、このプログラムが何か許容できないことをした場合は誤り であることをプリントアウトすることを特徴とする、請求項３１−３６記載のイ ンターフェースの機能を試験する装置。 ３８． プログラムウエアが、前記各プログラムウエアに対するインターフェ ースを通して、これらのプログラムウエアから分離されるプロトコルにより互い に通信することができる、通信システム内のインターフェースを試験する装置で あって、前記プロトコルを通して互いに通信するプログラムウエアを表す第１補 助機能性と前記プロトコルを表す第２補助機能性を特徴とし、前記第１補助機能 性は通信において呼び出し事例および応答事例として動作することができる手段 を備え、前記両事例は前記インターフェースを通してすべての可能な許容できる 動作を実行し、同時に前記インターフェースの反対側のプログラムは許容できな いことを一切しないようにチェックできる、通信システム内のインターフェース を試験する装置。 ３９． 前記第１補助機能性は、呼び出し事例の役目と応答事例の役目のすべ ての許容できる使用事例を含むインターフェースの完全なユーザとして動作する ことができる手段を備え、前記第２補助機能性は、すべての使用事例を処理し、 使用事例の処理中に起こり得るまた前記インターフェース内で定義されるすべて の考えられる結果および誤りを作り、また実際に前記インターフェースの機能性 を提供する或る設計のプログラム内で何が起こり得るかを示すための手段を備え る、請求項３８記載の通信システム内のインターフェースを試験する装置。 ４０． 前記２つの第１補助機能性の事例の間の通信を前記第２補助機能性に より実行し、 前記応答事例だけにアドレスし、 前記第２補助機能性が実際にプロトコルに影響を与える可能性があるすべての あり得る誤り事例を作る、 ための手段を特徴とする、請求項３８または３９記載の通信システム内のインタ ーフェースを試験する装置。 ４１． 前記第１および第２補助機能性は、前記インターフェースと同様に目 に見え、また前記インターフェースの完全な情報と定義を含むことを特徴とする 、請求項３８−４０のいずれかに記載の通信システム内のインターフェースを試 験する装置。 ４２． 前記インターフェースと共に実行可能なユニットを形成する前記第１ および第２補助プログラムと、前記第１補助プログラムにより前記両補助プログ ラム事例を作り、かつ前記インターフェースを通して前記第２補助プログラムに より互いに通信するための手段とを特徴とする、請求項３８−４１のいずれかに 記載の通信システム内のインターフェースを試験する方法。 ４３． 前記第１および第２補助プログラムは、前記インターフェースの反対 側のプログラムを監視して、このプログラムが何か許容できないことをした場合 は誤りであることをプリントアウトし、前記第１補助プログラムは、通信する相 手のユーザプログラムが何か許容できないことをしないようにチェックする手段 を備えることを特徴とする、請求項４２記載の通信システム内のインターフェー スを試験する方法。 ４４． ユーザプログラムウエアが、対応するインターフェースにより前記各 ユーザプログラムウエアから分離されるプロトコルを通して互いに通信すること ができる通信システム内で、 既存のユーザプログラムウエアと通信することができる新しいユーザプログラ ムウエアを試験する装置であって、 ユーザプログラムウエアによる前記インターフェースとプロトコル機能の使用 をそれぞれシミュレートする第１および第２補助プログラムを定義し、また前記 両補助プログラムが前記インターフェースを通してすべての可能な許容できる動 作を実行し、同時に前記インターフェースの反対側のプログラムは許容できない ことを一切しないようにチェックするためのコードと、 前記第２補助プログラムを通して前記新しいプログラムウエアを前記第１補助 プログラムと通信接続させる手段と、 両補助プログラムに与えられる動作を実行する手段と、 を特徴とする、通信システム内で試験する方法。 ４５． ユーザプログラムウエアが、対応するインターフェースにより前記各 ユーザプログラムから分離されるプロトコルを通して互いに通信することができ る通信システム内で、 新しいプロトコルプログラムウエアを試験する装置であって、 前記インターフェースと共に新しいユーザプログラムウエアを試験することが できるユーザプログラムウエアによるインターフェースの使用をシミュレートす る補助プログラムを定義し、また前記補助プログラムが、前記インターフェース を通してすべての可能な許容できる動作を実行し、かつ前記インターフェースに より試験するプロトコルプログラムウエアは許容できないことを一切しないよう にチェックするためのコードと、 前記新しいプログラムウエアを通して前記補助プログラムの２つの複写を互い に通信接続させる手段と、 前記両複写に与えられる動作を実行する手段、 を特徴とする、通信システム内で試験する装置。 ４６． ユーザプログラムウエアが、対応するインターフェースにより前記各 ユーザプログラムから分離されるプロトコルを通して互いに通信することができ る通信システム内で、 新しいユーザプログラムウエアを試験する装置であって、 前記インターフェースを通して前記プロトコルの機能を提供することをシミュ レートし、同時に前記インターフェースと共に新しいユーザプログラムウエアを 試験する補助プログラムを定義し、またインターフェースを通してすべての可能 な許容できる動作を実行し、かつ、前記インターフェースの反対側のプログラム は許容できないことを一切しないようにチェックするためのコードと、 前記補助プログラムを通して前記新しいユーザプログラムウエアの２つの複写 を互いに通信接続させる手段と、 前記補助プログラムに与えられる動作を実行する手段と、 を特徴とする、通信システム内で試験する装置。