JP3699154B2 - データを自己記述式に符号化するための方法および装置 - Google Patents
データを自己記述式に符号化するための方法および装置 Download PDFInfo
- Publication number
- JP3699154B2 JP3699154B2 JP12453195A JP12453195A JP3699154B2 JP 3699154 B2 JP3699154 B2 JP 3699154B2 JP 12453195 A JP12453195 A JP 12453195A JP 12453195 A JP12453195 A JP 12453195A JP 3699154 B2 JP3699154 B2 JP 3699154B2
- Authority
- JP
- Japan
- Prior art keywords
- record
- tag
- probe
- application program
- event
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3636—Software debugging by tracing the execution of the program
Description
【０００１】
【産業上の利用分野】
本発明はデータ処理システムに関する。より詳細には、データがそれ自体を記述し、その結果データが指示されたデータ・タイプに関連する所定の方式で処理できるように、データを符号化するための方法およびシステムに関する。
【０００２】
【従来の技術】
ソフトウェア開発がますます広がり、従来は離散的電子回路を使って所期の機能を実現していた状況で使用されてくるにつれて、ソフトウェアの機能性をテストし検証する必要が重要になってきている。ソフトウェアをテストする従来技術の方法の１つは、いわゆるプローブとトレースを使用するものである。プローブとは、コード中の点を区別し、他のことも行えるがおそらくは事象レコードを生成する手段である。トレースとは、１つまたは１組のプログラムの実行中に区別されたある１組の事象のレコードを時間順に（または少なくとも因果関係の順に）集めた集合体である。プローブは、回路のテスト点と同様に、開発者が実行中のプログラムの性能を評価できる場所である。ある種のプローブは、動作状況に応じて使用可能にまたは使用不能にすることができ、従ってプログラマがそのプログラムのソース・コードを修正する必要なしに、オブジェクト・コードがプローブ情報を生成できるようになる。すなわち、実行可能ルーチン内のプローブは、基礎となるソース・コードの修正なしに実行時にグループ内で選択的に使用可能にまたは使用不能にすることができる。従って、プログラマは、命令コードの内部について（これは確かに有用であるが）何も知らずに、プログラム内の障害を決定することができる。
【０００３】
プローブは、手動プローブと自動プローブの２つのクラスに分けることができる。手動プローブは、プログラマにより手動でプログラムのソース・コードに挿入される。これらのプローブは、プログラマにより、詳細なデバッグおよび性能分析に使用される。手動プローブのサブクラスは、プログラムまたはライブラリ・インタフェースの一部分としてドキュメントされる効果をもつ意味論プローブとして知られる。典型的な場合、これらのプローブは、外部デバッグまたは性能分析情報を提供するために使用される。自動プローブとは、プログラマによるソース・コードの直接操作なしでツールにより既存の実行時プログラムに挿入されるプローブである。自動プローブは、プレプロセッサにより、あるいは処理済み２進データに作用することによって挿入され、かかる情報を手順の出口点および入口点として提供することができる。自動プローブは、ある種の性能問題を具体的に分析するために実行時に選択的に使用可能にまた使用不能にすることができる。
【０００４】
【発明が解決しようとする課題】
従来技術のプローブおよびトレース処理に伴う１つの問題は、あるフォーマットでのみデータがテスト技術者によって予想されることである。典型的な場合、データは生の形で提示され、テスト技術者は、プローブから戻されるデータが何を表すかを決定しなければならない。従って、プローブから情報を生成する実行可能プログラムを評価するテスト技術者は、プログラムの実行時に提供されるプローブ情報を詳しく理解していなければならない。残念なことに、多くの例ではそのような情報は入手できず、あるいはテスト中のアプリケーション・プログラムの元のプログラマによって不明瞭にされることがある。従って、プローブを生成するプログラムが、プローブに関する情報を標準化された形で提供し、従ってテスト中のプログラムの内部機能の詳細な理解なしにテスト中のプログラムの診断が最も容易に実施できるようになることが望ましい。従来技術のテストなどの環境におけるプロセス間通信の技術では、通常、プログラムから戻されるデータのタイプを識別するために、データ外部の情報が必要である。
【０００５】
【課題を解決するための手段】
本発明によれば、コンピュータ・システムにおいて、第１のアプリケーション・プログラムによって生成されたデータを実行時に第２のアプリケーション・プログラムにおいて処理する、コンピュータ実施方法および装置が提供される。実行時に、第１のアプリケーション・プログラムは、複数のフィールドを含むレコードを生成し、その複数のフィールドのうち少なくとも１つが、第１のアプリケーション・プログラムによって生成されたデータを含む。他のフィールドは、そのデータに関する記述情報を含む。実際の実施例では、このレコードは、チェックポイントが発生した相対アドレスやチェックポイントに達した時間など、プログラム中のチェックポイントを表すフィールドを含む。このレコードはまた、タグ・レコードに対する参照（たとえば、相対または絶対的ポインタ）も含む。タグ・レコードは、レコードに含まれる複数のフィールド（たとえば、フィールドの名前とタイプ）を記述する。タグ・レコードはさらに、参照されるタグ・レコードのフィールドを識別する関連タグ・フィールドをそれぞれ参照する複数のタグ・レコードを繰り返し参照する。最終的に、ルート・レコードのフィールドを識別する自己参照タグを含むルート・レコードが参照されるまで、これが繰り返し継続する。その後、第２のアプリケーション・プログラムは、（たとえばコンピュータ・システムの実行時に、たとえばテスト・スートの実行中に）レコードを受け取り、ルート・レコードに達するまでタグ・レコードと複数のタグ・レコードのそれぞれとを繰り返し参照して、各タグ・レコードの複数のフィールドを参照することによりデータを識別することができる。このように、レコードに含まれるデータは自己記述式である。次いで第２のアプリケーション・プログラムは、たとえば、レコードに含まれテスト・スートで必要でないデータをフィルタすることにより、あるいはユーザもしくは後処理プログラムが検査するのにより適した形にデータをフォーマットし直すことにより、レコードとタグ・レコードと複数のタグ・レコードそれぞれとによって指定されるデータの識別に従って、データを操作する。
【０００６】
本発明を図面に非限定的な例によって示す。図で同じ参照番号は同一の要素を示す。
【０００７】
【実施例】
本明細書の開示の一部は、著作権保護の対象となり、著作権保護が請求されている資料を含んでいる。米国特許商標庁のファイルまたはレコードにある通りに本特許の開示を複製することには異議を申し立てないが、その他の点では、すべての著作権ならびに類似のいかなる権利をも留保する。
【０００８】
本発明は、プロセス間通信、ならびにテストなどの適用例のためのかかるプロセス間通信を容易にするデータの表現に関する。ここでは、いくつかの具体的実施例ならびにここで記述するテストの適用のためのデータ構造およびフォーマットを使用するその実例に関して本発明を説明するが、このような自己記述式データ・フォーマットは、本発明の実施者が希望するいくつかの応用例に使用できることを当業者なら理解できよう。実際の実施例の他の利点および用途は、当業者には明らかになるであろう。また本発明の全体的趣旨および範囲から逸脱せずに、具体的詳細なしで実施できよう。
【０００９】
本発明は、一連のデータ構造、ならびにコンピュータ・システム内で動作するコンピュータ・プログラムとして実施される付随の命令として実施される。かかるデータ構造は、図１の構成図に示すようなコンピュータ・システムで作成できる。
【００１０】
図１を参照すると、本発明の一実施態様がその上で実施されるシステムが１００で示されている。システム１００は、情報通信用のバスまたは他の通信手段１０１と、バス１０１に結合された情報処理用の処理手段１０２を含む。システム１００はさらにバス１０１に結合された、情報とプロセッサ１０２で実行される命令とを記憶するためのランダム・アクセス・メモリ（ＲＡＭ）または他の揮発性記憶装置１０４（主記憶装置と称する）を含む。主記憶装置１０４は、プロセッサ１０２による命令の実行中に一時的変数や他の中間情報を記憶するのにも使用される。システム１００はまた、バス１０１に結合された、静的情報およびプロセッサ１０２用の命令を記憶するための読取り専用メモリ（ＲＯＭ）または他の静的記憶装置あるいはその両方１０６と、磁気ディスクや光ディスクおよびそれに対応するディスク駆動装置などのデータ記憶装置１０７をも含む。データ記憶装置１０７は、情報および命令を記憶するためバス１０１に結合されている。これは、市販のソフトウェア製品を使用して定義する問題記述に関する情報を維持する、後述のデータ・ベースを格納するために使用される。
【００１１】
システム１００はさらに、バス１０１に結合された、コンピュータ・ユーザに情報を表示するための陰極線管（ＣＲＴ）や液晶ディスプレイ（ＬＣＤ）などの表示装置１２１にも結合される。表示装置１２１はさらに、フレーム・バッファ１１０を介してバス１０１に結合することができる。フレーム・バッファ１１０は、表示装置１２１に表示する単一または複数のフレームやイメージなどの情報を格納する。英数字キーとその他のキーを含む英数字入力装置１２２も、情報およびコマンド選択をプロセッサ１０２に通信するため、バス１０１に結合することができる。追加のユーザ入力装置は、バス１０１に結合された、指示情報およびコマンド選択をプロセッサ１０２に通信し、表示装置１２１上でのカーソル移動を制御するための、マウス、トラックボール、スタイラス、カーソル方向キーなどのカーソル制御装置１２３である。
【００１２】
システム１００の構成要素および付随のハードウェアはすべて様々な実施例で使用できるが、どんなシステム構成も具体的実施態様に従って様々な目的に使用できることにも留意されたい。
【００１３】
一実施例では、システム１００は、米国カリフォルニア州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）製造のＳＰＡＲＣｓｔａｔｉｏｎワークステーションなど、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）ブランドのワークステーション・ファミリーの１つである。プロセッサ１０２は、米国カリフォルニア州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）製造のＳＰＡＲＣブランドのマイクロプロセッサの１つでよい。
【００１４】
ここで考察する様々な実施例についての以下の議論は、特に、高水準プログラミング言語（たとえばＣ言語）で生成され、コンパイルされ、リンクされ、次いでたとえば米国カリフォルニア州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）から市販のＳＰＡＲＣｏｍｐｉｌｅｒによって実行時にシステム１００内でオブジェクト・コードとして実行される、一連のルーチンに関するものである。具体的に言うと、本発明は、米国カリフォルニア州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＳｕｎＳｏｆｔ，Ｉｎｃから市販のＳｏｌａｒｉｓ（登録商標）スレッズ・パッケージなど様々なソフトウェア・ライブラリと共に機能する（Ｓｕｎ、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ、Ｓｏｌａｒｉｓは米国カリフォルニア州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）の商標、ＳＰＡＲＣとＳＰＡＲＣｓｔａｔｉｏｎはＳＰＡＲＣ Ｉｎｔｅｒｎａｔｉｏｎａｌ，Ｉｎｃ．の商標で、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓに独占的に実施許諾されている）。しかし、以下の方法および装置は、離散論理装置、大規模集積回路（ＬＳＩ）、特定用途向け集積回路（ＡＳＩＣ）、あるいはその他の専用ハードウェアなどの専用ハードウェア装置で実施できることが当業者には理解できよう。この記述は、類似の機能をもつ装置にも適用される。
【００１５】
本発明は、テスト中のプログラムを作成するアプリケーション・プログラマがプログラムのソース・コード中で「プローブ」を指定して、後で実行可能プログラムの呼出し中にある種のパラメータが指定されるのに応じてシステム実行時にプローブが活動化され、第２のアプリケーション・プログラムまたはユーザ（たとえばテスト技術者）が検査するレコードを生成する、というシステムを実施する。このようにして、テスト中のアプリケーション・プログラムは、テスト中のアプリケーション・プログラム自体から生成されるレコードに含まれる記述情報を含めて、処理中のデータに関する情報を提供することができる。その詳細については後でより詳しく論じるが、そのような機構の動作を図２を参照して説明する。
【００１６】
図２のシステム２００は、アプリケーション・プログラム２１０、典型的にはある種のプローブ・パラメータ２０１を使って呼び出されるテスト中のプログラムを有する。これは、テスト技術者２０２によって指定された引数、またはアプリケーション・プログラムの呼出し時に活動化されるいくつかのプローブまたはプローブ群を指定するその他の機構を含むことがある。次にアプリケーション・プログラムはプローブ事象２２０を生成し、それがトレース・ファイル２２１に入れられる。トレース・ファイル２２１は、アプリケーション・プログラムに挿入された様々なプローブの状況を示すことができるトレース・レコード（後述）を含む。いくつかのプローブまたはプローブ群を活動化すべきであるとプローブ・パラメータ２０１が指定したことが検出されると、トレース・ファイル２２１に入れられたプローブ事象２２０が生成される。これは、第２のプログラム２３０、通常は、テスト・スートあるいはトレース・ファイル２２１を介してプローブ事象２２０を受け取り処理することのできる他のアプリケーション・プログラムによって検査される。トレース・ファイル２２１は、何らかの識別情報と共にアプリケーション・プログラム２１０内からのデータ自体を含むレコードへの参照を含む。レコードの生成とトレース・ファイル２２１などのファイルへの挿入は、この実施例で使用されるＳｕｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍのメモリ・マッピング（ｍｍａｐ）機能によって、この実施例を用いて生成されたレコードの要求される仮想メモリがコンピュータ・システム１００のファイル・システム中でメモリ・イメージとして捕捉されるように行われる。他のコンピュータ・システム・プラットフォームでは、ファイル作成用に同様のメモリ・マッピング機能を使用することもでき、また非揮発性媒体（たとえば図１の１０７）中の記憶レコードの他の区域を使用してもよい。これについては次に論じる。
【００１７】
前述のように、プローブは、アプリケーション・プログラマによって、またはアプリケーション・プログラムのコード（ソース・コードまたはオブジェクト・コード）内の所定の点にこのプローブを挿入する役割をする何らかの自動ツールによって挿入される。アプリケーション・プログラマは、ヘッダ・ファイル「ｔｎｆ＿ｐｒｏｂｅ.ｈ」または単に「ｐｒｏｂｅ.ｈ」への参照を自分のソース・コードに挿入することにより、ここで論じるデータ構造を参照する。このヘッダ・ファイルは、プローブ作成用の「構造単位」の集合体または「ライブラリ」である。ｐｒｏｂｅ．ｈ中で定義されるタイプへの参照の例は、後述の記述プログラミング・セグメントに示す。プローブは、グループ別にまたは特定のプローブ名により選択的に使用可能または使用不能にすることができる。ある種の実施例では、テスト中のアプリケーション・プログラムの呼出し時に所与のプローブを活動化したいプログラマが、プローブを使用可能にしまたは使用不能にする手順を使用する。特定のプログラムのソース・コード内にあるプローブを活動化する他の方式は、具体的実施態様に応じてシステム実行時に活動化または非活動化することができる。
【００１８】
プローブが使用可能になると、プローブはトレース・ファイル２２１に記憶されたプローブ事象２２０等の事象によって情報を生成する。このトレース・ファイルは、単一の所定の実施態様依存のフォーマットによるトレース「レコード」の集合体である。本明細書の以下の部分では、本発明の実際の実施例で、「トレース・ノーマル・フォーム」（ＴＮＦ）と呼ばれるフォーマットでアプリケーション・プログラムのソース・コードに挿入されたプローブから得られるデータを表す標準の方法を使用する。このＴＮＦは、異なる実施態様依存アプリケーションのために読み取り、処理し、様々な方法で操作することができる。このファイル中のレコードは、マシン間で因果関係の順にあるいは特定のマシン内で時間順になるようにソートできる。これらのレコードはまた、トレース・ファイルが、ファイルの残り部分を解決するのに必要なすべての情報から始まるようにもソートできる。一実施例では、ＴＮＦファイルの生成機能は、特定のテスト技術者またはテスト・スートから見て関心のあるものだけを抽出するため、現在は関心のないプローブ・レコードをフィルタまたは除去することができる。
【００１９】
したがって、図２に示すようなアプリケーション２１０またはテスト中の他のプログラムなどからのトレース生成機能３０１は、トレース・ノーマル・フォームによるトレース・レコードなどの中間情報３０２を生成することができる。次いで、この中間情報３０２をテスト・プログラムまたは他のツールなどによって処理し、トレース・マージ・ファイル３０３にする。次いで、トレース・マージ機能３０３を実行するプロセスが、中間情報３０２を取り出し、それを因果関係その他の順序でソートし、すべての情報をトレース・ノーマル・フォーム３０４に入れる。トレース・ノーマル・フォームが生成されると、ある種のトレース・ツール３０５が、テスト技術やデータを検査する他の人などからの情報を使って、関心のある情報を抽出することができる。
【００２０】
本発明の実際の実施例は、レコードを、したがってプローブ事象によって生成されたレコード内に含まれるデータを識別する手段を提供する。このようにして、テスト・スートまたはテスト中のプログラムのテストを実施する技術者は、テスト中のプログラム内に含まれるデータに関する詳細な情報をもつ必要がない。その代わりに、特定のレコードが検査でき、トレース・ノーマル・フォームと呼ばれる、このデータ記憶方式によって、事象レコード内に含まれるデータを決定することができる。この方式の詳細と機構については次に考察する。
【００２１】
指定されたいくつかのプローブ・パラメータを含むテスト中のアプリケーション・プログラムの実行の結果、トレース・ファイルと呼ばれるトレース・レコードの集合体が得られる。トレース・ファイルは、トレース・ノーマル・フォーム（ＴＮＦ）中で表され、ＴＮＦ分析のブートストラップに使われるルート・レコードを含む。本発明の実際の実施例では、このブートストラップ処理が依存する、最小の１組のフォーマット依存関係が存在する。図４に示すように、４００などのルート・ファイルは、自己相対ポインタを含むフィールド４０１とフィールドの名前をレコード中の順序で提供するＡＳＣＩＩ文字列を含むレコード４２０を参照する第２のフィールド４０３とを有する。レコード４２０中の名前は、ヘッダ情報を含むレコード中で最初の２個のフィールドの後から始まる。実際の実施例では、文字列は空白で終わるが、たとえば長さフィールドが文字列の内容の前にくる他のフォーマットで文字列を表すこともできることを当業者なら理解できよう。レコードの名前を含む文字列への参照を含むＴＮＦレコード中のたとえば第１と第３のフィールド４０３以外のどのフィールドも固定する必要はない。その詳細については、後でいくつかの具体例に関して考察する。
【００２２】
図４および下記に示す記述セグメントに示すように、接頭辞ｔｎｆ＿ｒｏｏｔのついたルート・レコード名は、すべてルート・レコード中と同じ位置にｔｎｆ＿ｔａｇフィールドとｔｎｆ＿ｏｐｅｒａｔｉｏｎｓフィールドを含むタグ・レコード付きのファイルを示すために使用される。ｔｎｆ＿ｏｐｅｒａｔｉｏｎｓまたは単にｏｐｅｒａｔｉｏｎｓという名前をもつフィールドは、テスト・ルーチンによる分析中に関連タグ・レコードによって記述される種類のレコード用の解釈手順を指すポインタを保持するために使用される。今説明しているレコードは、そのタイプのすべてのレコードと同様にそのタグ・レコードを指す。ダグ・レコードのｏｐｅｒａｔｉｏｎｓフィールドは、たとえば強制動作や変換動作や分析中に頻繁に実行されるその他のタイプの動作を実行する目的で、その種類のレコードに迅速に作用する手順にアクセスするために使用される。
【００２３】
図４に４０１として示したレコード中の「ｔｎｆ＿ｔａｇ」フィールドは、その名前に接頭辞として「ｔｎｆ＿ｔａｇ」が含まれるフィールドである。４００などのルート・レコードは、そのレコードを記述する「タグ・レコード」を指す自己相対ポインタを保持する。すなわち、図４に示した４００などのルート・レコードは、それ自体を記述するが、ＴＮＦファイル構造中の他のタグ・レコードは、通常は他のレコードを記述する。ｔｎｆ＿ｒｏｏｔレコードの例は、図４に４００として示してあり、そのレコードを指定するために使用される記述コード・セグメントは以下に示す。「ｓｌｏｔｓ」フィールド４０３は、そのレコード中のすべてのフィールドを識別する文字列を指すポインタを含んでいる。それ自体を記述しない他のレコードとは異なり、この文字列はｔｎｆ＿ｒｏｏｔレコード４００内に含まれるすべてのレコードを記述する。すなわち、セミコロンで区切られた各文字列対が、ＴＮＦタイプとそのレコードに含まれるフィールドの名前とを示す。したがって、ルート・レコードに含まれる各フィールドと、フィールド４０３で参照されるセミコロンで区切られた各文字列対４２０との間に１対１の対応がある。このように、ルート・レコードに含まれるデータは自己記述式であり、したがって、ｓｌｏｔｓフィールドが参照された後は、それを使ってこの例ではＴＮＦルート・レコードの内容を決定することができる。他のタグ・レコードの場合は、このフィールドはタグ・レコードを参照するレコードを記述するのに使用される。それについては後で詳しく示す。
【００２４】
以下の記述セグメントでは、コロンで終わる名前は、フィールドの名前を示すがファイル中には現れないので、単に表記上の目的で使用される。それらの名前は図４の４００にも現れるが、実際のフィールドの内容はコロンの後にある。記述セグメント中の矢印は、別のレコードへの参照を示すのに使用され、その内容が矢印で指される。すなわち、この図で４０３や４０４などのフィールドは実際に、レコードを記述する文字列を含むレコードへの参照を含む。ｓｌｏｔｓフィールド４０３については既に論じたが、フィールド４０４は、レコード「ｔｎｆ＿ｒｏｏｔ＿１」の名前である文字列を含む別のレコード４３０への参照をも含む。下のコード・セグメントの内容は、名前レコードへの自己相対参照であり、この注記法でダブル・コロン終了記号によって識別される。
【００２５】
【００２６】
上記の例および図４に示した文字列はそれ自体がＴＮＦレコード（たとえば４２０と４３０）、すなわち単バイトＡＳＣＩＩ文字配列であるｔｎｆ＿ｓｔｒｉｎｇレコードである。この実施態様では、フィールドの名前とタイプの名前は、上記に示したように文字列で符号化され、ファイル中に厳密には何があるかを記述する。他の実施態様では、名前とタイプは以下で論じるように別々のフィールド中で符号化されることがある。ＴＮＦファイルは、既に論じたように、自己記述式データを保持し、したがって、分析ルーチンまたは他の後処理プログラムがＴＮＦファイルの内容を決定することができる。ｓｉｚｅフィールド４０５は、上記レコードのサイズをバイト単位で示す。各フィールドは長さ４バイトなので、この例のサイズはフィールド４０５に含まれる２８に等しい。ｏｂｊｅｃｔフィールド４０６は、この例では、指定された解釈を有するＴＮＦタイプの名前を名前とする手順を示す共用オブジェクトを示す。これらの手順は、指定されたタイプの１組の動作を供給する。ｐｌａｔｆｏｒｍフィールドは、ＴＮＦファイルに含まれるデータのソースであったプラットフォームのタイプを決定することが重要な場合、共用オブジェクトまたはその中の動作を修飾するのに使用できる。たとえば、大エンディアン／小エンディアン・バイト順序をサポートする様々なアーキテクチャでは、分析ルーチンによる処理の前にデータの強制を行うために、データが作成されたプラットフォームを知ることが重要である。
【００２７】
ＴＮＦファイル内には、ルート・レコードと、ＴＮＦファイルの基本ファイル・システムを定義するいくつかのレコードとが含まれる。トレース・ファイル中にトレース事象を記録するレコードはかなりの数に上る。そのような事象レコードと、事象レコードの内容を定義する関連レコードについては、図５および下記の記述セグメントに関して示す。この場合も、図にはいくつかのフィールド名が列挙してあるが、これは概念上かつ便宜上のものにすぎず、フィールドの実際の内容はフィールド名に応じて変わる。いずれにせよ、事象レコード５５０は３つのワード５５１〜５５３を含む。第１のフィールド５５１は、２つの部分５５１ａと５５１ｂに分かれ、それぞれ特定の意味を有する。ワードの前半部５５１ａは事象を記述するタグ・レコードを参照するタグ（たとえばポインタまたは他の参照）である。第１のワードの第２の部分５５１ｂは、事象レコードを修飾するスケジュール・レコードであるスケジュール・オフセットである。このスケジュール・レコードはそれ自体、図５に５６０として示す事象レコードであり、スレッドＩＤ、絶対時間その他の情報などの情報を含む。このようなレコードは、どんなタイプの情報を含むこともできるが、図ではわかりやすいように省略した。事象レコード中の次のフィールド５５２は、その事象に関して参照されるスケジュール・レコード５６０に含まれていた６４ビット絶対時間の上位ワードに対するナノ秒で表した時間を示す。またアドレス・フィールド５５３は、いくつかの実際の実施例でプローブされ事象を引き起こしたデータへの参照を含む。これは、プローブ中の変数があった場所などいくつかの情報を提供することができる。
【００２８】
この例では、図５に５００として示すｖｍ＿ｍｉｎｏｒ＿ｆａｕｌｔと呼ばれる参照タグが、下記の記述セグメントに示されている。
【００２９】
【００３０】
この実施態様における上記のタグ・レコード中のｏｐｅｒａｔｉｏｎｓフィールドは、事象レコードが指すタグ・レコードを事象レコードに対する指定の動作と結び付けるために分析ルーチンが使用する。事象用タグ・レコードはまた、事象レコード５５０の内容（タグ・レコードの「ｓｌｏｔｓ」フィールド中）、事象レコードのバイト数（「ｓｉｚｅ」フィールド中）を記述し、事象レコードのタイプに命名する文字列（タグ・レコードの「ｎａｍｅ」フィールド）への参照を含む。このタグ・レコードｖｍ＿ｍｉｎｏｒ＿ｆａｕｌｔは、タグ・レコード５１０によって記述され、タグ・レコード５１０はｖｍ＿ｍｉｎｏｒ＿ｆａｕｌｔタグ・レコード５００によりフィールド５０１を介して参照される。これらも下記の記述セグメントに示されている。したがって、タグ・レコード５００は、上記のセグメントのｓｌｏｔｓフィールドに示されているプローブ事象レコード５５０の内容を定義する。この場合も、これを簡潔に示すため、これらのレコードは単に便宜上かつ表記上の目的で図５に示したレコードのブロック図の詳細には示していないが、図４に示したレコードと同様にｓｌｏｔｓフィールドおよびｎａｍｅフィールドは実際にはタグ・レコードを識別する文字列を含む文字列レコードへの参照である。
【００３１】
他の実施態様では、ＴＮＦレコードは少し異なる形でフォーマットすることができる。この代替実施態様では、上記で論じたｖｍ＿ｍｉｎｏｒ＿ｆａｕｌｔレコードを下記の記述セグメントで示されるような形でフォーマットすることができる。
【００３２】
【００３３】
このレコードは、上記の記述セグメントに関して述べた図５に示すものと類似しているが、ｏｐｅｒａｔｉｏｎｓフィールドの名称が「ｔａｇ ｃｏｄｅ」となっており、ｎａｍｅフィールドがレコードの３番目のワードにある。さらに重要なことであるが、「ｓｌｏｔｓ」フィールドが、ｓｌｏｔ＿ｔｙｐｅｓフィールドとｓｌｏｔ＿ｎａｍｅｓフィールドの別々の２つのフィールドに分割されている。この例では、ｓｌｏｔ＿ｔｙｐｅｓは、レコード中の各名前付きフィールドのそれぞれのタイプへの参照を含む配列への参照である。次いで、ｓｌｏｔ＿ｔｙｐｅｓフィールドの後にｓｌｏｔ＿ｎａｍｅｓフィールドが続き、これはｓｌｏｔ＿ｔｙｐｅｓフィールドで指定されたタイプを有するそれぞれのフィールドの名前をリストする文字列を参照する。レコード中の残りのフィールドは、上述のような僅かな修正を除き基本的に図５に示したものと同じである。どちらの実施態様においても、いくつかのレコードがＴＮＦレコード中の所定の場所に現れ、したがってＴＮＦトレース・ファイル中のレコードを検査するルーチンは、その内部に含まれるデータの性質を決定することができる。上記のこの代替実施例で短い修正コード・セグメントに関して述べた特定のフォーマットは、下記の付録Ａに概略を示すより詳細なＴＮＦフォーマットの単一レコードを例示するものである。しかし、本明細書の残りの部分では、一貫性を保つため、本発明があいまいにならないように前述の実施態様について論じることにする。
【００３４】
既に述べたように、タグ・レコードはそれ自体は、プローブ事象レコードなどのレコード用のタグ・レコードの内容を記述するタグ・レコードを参照する。これは、「基本」ＴＮＦタイプと呼ばれ、図５に５１０〜５３０で全体的に示されている。タグ・レコードは、既に論じたように、やはりタグ・レコードを記述するレコードを参照するタグ・フィールドを有し、これが繰り返されてルート・レコード（たとえば、図４および図５の４００）までさかのぼる。ｖｍ＿ｍｉｎｏｒ＿ｆａｕｌｔタグ・レコード５００は、この例では、ｔｎｆ＿ｓｔｒｕｃｔ＿１の名前を有するタグ・レコード５１０によって記述される。タグ・レコード５１０はまた、ｏｐｅｒａｔｉｏｎｓ、ｓｌｏｔｓ、ｎａｍｅ、ｓｉｚｅをもつものとして特徴付けることができる。これは、下記の記述セグメントで示される。
【００３５】
【００３６】
レコード５１０はさらに、タグ・レコード５１０の内容を定義する別のタグ・レコード５２０を参照する。これが繰り返されて、レコード５３０にまで至る。最後に、レコード５３０ｔｎｆ＿ｂａｓｅ＿１は、先に図４に関して論じた図５に示されているルート・レコードｔｎｆ＿ｒｏｏｔ＿１ ４００を参照する参照をそのｔａｇフィールド５３１に含む。この場合も、４００はルート・レコードなので、そのｓｌｏｔｓフィールドに自己記述情報を含み、そのｔａｇフィールド４０１に自己参照タグを含む。このようにして、分析ルーチンはそれがルート・レコードであることを知る。さらに、レコードｔｎｆ＿ｂａｓｅ＿１は、ルート・レコード４００によって記述されるので、ルートと全く同じフォーマットでなければならない。この実施態様でこの要件が課されるレコードはこれだけである。ｔｎｆ＿ｓｔｒｕｃｔ＿１とｔｎｆ＿ｂａｓｅの記述セグメントを以下に示す。
【００３７】
【００３８】
ルートによって記述されるタグ・レコードは、ルートと同じ外観でなければならない。（ただし、この方式では、そうする必要があるのはこれだけである）
【００３９】
【００４０】
上述のＴＮＦタイプは、それ自体もＴＮＦタイプである。これらは、やはりタイプを記述するレコードを参照するタグを含むレコードによって記述される。その一例を図６に関して示す。図６のｔｎｆ＿ｔａｇレコード・タイプ６００は、ｔａｇフィールド６０１を含み、これは、この例では、レコードｔｎｆ＿ｂａｓｅ＿ｔｙｐｅ＿１を参照する。同様にｔｎｆ＿ｂｙｔｅ＿１タイプは、やはり図６に示すｔｎｆ＿ｂａｓｅ＿ｔｙｐｅ＿１ ６２０へのタグ参照６１１を含むレコード６１０によって表すことができる。ｔｎｆ＿ｂａｓｅ＿ｔｙｐｅ＿１レコード６２０はさらに図５に関して示したレコードの１つ、すなわち図５にタグ・レコード５２０として示したｔｎｆ＿ｓｔｒｕｃｔ＿１ベースタイプを逆参照できるタグ参照６２１を含む。その後、図５に関して先に論じたように参照が繰り返される。前述の３つのレコードの記述セグメントを以下に示す。ｔｎｆ＿ｔａｇレコード６００は以下のような形となる。
【００４１】
【００４２】
ｔｎｆ＿ｂｙｔｅ＿１レコード（たとえば、図６の６１０）は次のような形をとる。
【００４３】
【００４４】
これらのタイプ用のタグ・レコードは、その記述用のｔｎｆ＿ｂａｓｅ＿ｔｙｐｅタグ・レコードを参照する。
【００４５】
【００４６】
最後に、ここで説明する最後のレコード・タイプは、本発明の実際の実施例における配列および文字列の取扱いである。これを図７に関して示す。ｔｎｆ＿ｓｔｒｉｎｇはヘッダと、その後に続く、ゼロで終わる１バイト要素のワード埋込み配列から構成される。ヘッダは、図７に７０１と示すｔａｇフィールドをｏｐｅｒａｔｉｏｎｓフィールドと、レコードのバイト単位で表したサイズを含むフィールドとを含む。このレコードはまた、下記の記述セグメントに示されるように、使用されるある種の記号の他の記号に対する文字列突合わせの性能を向上させるための、文字列のハッシュ値をも含むことになる。
【００４７】
【００４８】
ｔｎｆ＿ｂｙｔｅは、図６に関して先に論じたように、タグ・レコードｔｎｆ＿ｂａｓｅ＿ｔｙｐｅ（たとえば６１０）を参照する。
配列は、タグ・レコードｔｎｆ＿ｂａｓｅ＿ａｒｒａｙによって記述される。
【００４９】
【００５０】
この２つのレコードの例を図７に示す。ｔｎｆ＿ｓｔｒｉｎｇレコード７００は、既に論じた図５に示すｔｎｆ＿ｓｔｒｕｃｔ＿１ ５２０を参照する第２のレコードｔｎｆ＿ｂａｓｅ＿ａｒｒａｙ＿１を参照するタグをフィールド７０１に有する。いずれにせよ、レコード７００と７１０を使用して、本発明の実際の実際例では配列または文字列を表すことができ、それから次にトレース・ファイルを介して後処理分析ルーチンに送られ、テスト中のプログラム中に存在する可能性のある文字列および配列が検査される。
【００５１】
本発明の具体的実施例で使用されるＴＮＦ構造の詳細なダンプを付録Ａに示す。付録Ａのファイル”ｔｒａｃｅ ＡＳＣＩＩ”中に示される各レコードはそれぞれ関連するフィールドｔｎｆ＿ｔａｇを有し、このフィールドは関連タグ・レコードへの１６進参照アドレスを含む。したがって、ＴＮＦ定義の前にあるアドレスと、ダンプ中の各レコードのｔｎｆ＿ｔａｇフィールドに記憶されているアドレスとを突き合わせることにより、ＴＮＦトレース・ファイル中で生成される種々のレコードの相互関係を示すことができる。
【００５２】
図３ないし７に示したＴＮＦファイルの例は、例示のために示したものにすぎず、本発明を限定するものではない。以上、テスト・アプリケーション用などのデータを表すため、第１のアプリケーション・プログラムにおいてデータを表現し、たとえば第２のアプリケーション・プログラムによって検査されるレコードおよび関連トレース・ファイルを生成するための総合的システム、ならびに分析ルーチンについて説明した。したがって、第１ルーチンから第２ルーチンへのデータの提供は、テスト中のプログラム中で表されるデータのタイプを分析プログラムまたはテスト技術者あるいはこの両方が知っている必要のある、従来技術の方法に比べて大きな利点である。というのは、本発明においては、データがデータ自体を記述するレコードによって緊密に符号化され、データとそのデータの記述との関係が、符号化の修正なしである処理アドレス空間から別の処理アドレス空間にマップできるようにこの符号化が、配列できるからである。これは従来技術に比べて大幅な改善であり、従来技術によって実現も教示もされていない独特の利益を有する。本発明を図１ないし７に示した特定の実施例および添付の付録Ａに関して説明してきたが、これは本発明を限定するものではなく、本発明は頭記の特許請求の範囲によってのみ限定されるものと解釈されるものとする。
【図面の簡単な説明】
【図１】 本発明の一実施例が実施されるシステムを示す図である。
【図２】 テスト中のアプリケーション・プログラムとテスト・マート・プログラムの関係、ならびにこの２つの実行可能プログラム間での通信を示す図である。
【図３】 本発明の実施例を実施するシステムにおいて実行される様々なトレース情報と中間情報の処理を示す図である。
【図４】 本発明の実際の実施例で作成され使用される各種データ構造を示す図である。
【図５】 本発明の実際の実施例で作成され使用される各種データ構造を示す図である。
【図６】 本発明の実際の実施例で作成され使用される各種データ構造を示す図である。
【図７】 本発明の実際の実施例で作成され使用される各種データ構造を示す図である。
【符号の説明】
１０１ バス、 １０２ プロセッサ、 １０４ メイン・メモリ
１０６ 読取り専用メモリ、 １０７ 大容量記憶装置、
１１０ フレーム・バッファ、 １２１ 表示装置、 １２２ キーボード、
１２３ カーソル制御装置、 １２４ ハードコピー装置、
２０１ プローブ・パラメータ、 ２０２ テスト技術者、
２１０ アプリケーション・プログラム、 ２２０ プローブ事象、
２２１ トレース・ファイル、 ２３０ テスト・プログラム
【産業上の利用分野】
本発明はデータ処理システムに関する。より詳細には、データがそれ自体を記述し、その結果データが指示されたデータ・タイプに関連する所定の方式で処理できるように、データを符号化するための方法およびシステムに関する。
【０００２】
【従来の技術】
ソフトウェア開発がますます広がり、従来は離散的電子回路を使って所期の機能を実現していた状況で使用されてくるにつれて、ソフトウェアの機能性をテストし検証する必要が重要になってきている。ソフトウェアをテストする従来技術の方法の１つは、いわゆるプローブとトレースを使用するものである。プローブとは、コード中の点を区別し、他のことも行えるがおそらくは事象レコードを生成する手段である。トレースとは、１つまたは１組のプログラムの実行中に区別されたある１組の事象のレコードを時間順に（または少なくとも因果関係の順に）集めた集合体である。プローブは、回路のテスト点と同様に、開発者が実行中のプログラムの性能を評価できる場所である。ある種のプローブは、動作状況に応じて使用可能にまたは使用不能にすることができ、従ってプログラマがそのプログラムのソース・コードを修正する必要なしに、オブジェクト・コードがプローブ情報を生成できるようになる。すなわち、実行可能ルーチン内のプローブは、基礎となるソース・コードの修正なしに実行時にグループ内で選択的に使用可能にまたは使用不能にすることができる。従って、プログラマは、命令コードの内部について（これは確かに有用であるが）何も知らずに、プログラム内の障害を決定することができる。
【０００３】
プローブは、手動プローブと自動プローブの２つのクラスに分けることができる。手動プローブは、プログラマにより手動でプログラムのソース・コードに挿入される。これらのプローブは、プログラマにより、詳細なデバッグおよび性能分析に使用される。手動プローブのサブクラスは、プログラムまたはライブラリ・インタフェースの一部分としてドキュメントされる効果をもつ意味論プローブとして知られる。典型的な場合、これらのプローブは、外部デバッグまたは性能分析情報を提供するために使用される。自動プローブとは、プログラマによるソース・コードの直接操作なしでツールにより既存の実行時プログラムに挿入されるプローブである。自動プローブは、プレプロセッサにより、あるいは処理済み２進データに作用することによって挿入され、かかる情報を手順の出口点および入口点として提供することができる。自動プローブは、ある種の性能問題を具体的に分析するために実行時に選択的に使用可能にまた使用不能にすることができる。
【０００４】
【発明が解決しようとする課題】
従来技術のプローブおよびトレース処理に伴う１つの問題は、あるフォーマットでのみデータがテスト技術者によって予想されることである。典型的な場合、データは生の形で提示され、テスト技術者は、プローブから戻されるデータが何を表すかを決定しなければならない。従って、プローブから情報を生成する実行可能プログラムを評価するテスト技術者は、プログラムの実行時に提供されるプローブ情報を詳しく理解していなければならない。残念なことに、多くの例ではそのような情報は入手できず、あるいはテスト中のアプリケーション・プログラムの元のプログラマによって不明瞭にされることがある。従って、プローブを生成するプログラムが、プローブに関する情報を標準化された形で提供し、従ってテスト中のプログラムの内部機能の詳細な理解なしにテスト中のプログラムの診断が最も容易に実施できるようになることが望ましい。従来技術のテストなどの環境におけるプロセス間通信の技術では、通常、プログラムから戻されるデータのタイプを識別するために、データ外部の情報が必要である。
【０００５】
【課題を解決するための手段】
本発明によれば、コンピュータ・システムにおいて、第１のアプリケーション・プログラムによって生成されたデータを実行時に第２のアプリケーション・プログラムにおいて処理する、コンピュータ実施方法および装置が提供される。実行時に、第１のアプリケーション・プログラムは、複数のフィールドを含むレコードを生成し、その複数のフィールドのうち少なくとも１つが、第１のアプリケーション・プログラムによって生成されたデータを含む。他のフィールドは、そのデータに関する記述情報を含む。実際の実施例では、このレコードは、チェックポイントが発生した相対アドレスやチェックポイントに達した時間など、プログラム中のチェックポイントを表すフィールドを含む。このレコードはまた、タグ・レコードに対する参照（たとえば、相対または絶対的ポインタ）も含む。タグ・レコードは、レコードに含まれる複数のフィールド（たとえば、フィールドの名前とタイプ）を記述する。タグ・レコードはさらに、参照されるタグ・レコードのフィールドを識別する関連タグ・フィールドをそれぞれ参照する複数のタグ・レコードを繰り返し参照する。最終的に、ルート・レコードのフィールドを識別する自己参照タグを含むルート・レコードが参照されるまで、これが繰り返し継続する。その後、第２のアプリケーション・プログラムは、（たとえばコンピュータ・システムの実行時に、たとえばテスト・スートの実行中に）レコードを受け取り、ルート・レコードに達するまでタグ・レコードと複数のタグ・レコードのそれぞれとを繰り返し参照して、各タグ・レコードの複数のフィールドを参照することによりデータを識別することができる。このように、レコードに含まれるデータは自己記述式である。次いで第２のアプリケーション・プログラムは、たとえば、レコードに含まれテスト・スートで必要でないデータをフィルタすることにより、あるいはユーザもしくは後処理プログラムが検査するのにより適した形にデータをフォーマットし直すことにより、レコードとタグ・レコードと複数のタグ・レコードそれぞれとによって指定されるデータの識別に従って、データを操作する。
【０００６】
本発明を図面に非限定的な例によって示す。図で同じ参照番号は同一の要素を示す。
【０００７】
【実施例】
本明細書の開示の一部は、著作権保護の対象となり、著作権保護が請求されている資料を含んでいる。米国特許商標庁のファイルまたはレコードにある通りに本特許の開示を複製することには異議を申し立てないが、その他の点では、すべての著作権ならびに類似のいかなる権利をも留保する。
【０００８】
本発明は、プロセス間通信、ならびにテストなどの適用例のためのかかるプロセス間通信を容易にするデータの表現に関する。ここでは、いくつかの具体的実施例ならびにここで記述するテストの適用のためのデータ構造およびフォーマットを使用するその実例に関して本発明を説明するが、このような自己記述式データ・フォーマットは、本発明の実施者が希望するいくつかの応用例に使用できることを当業者なら理解できよう。実際の実施例の他の利点および用途は、当業者には明らかになるであろう。また本発明の全体的趣旨および範囲から逸脱せずに、具体的詳細なしで実施できよう。
【０００９】
本発明は、一連のデータ構造、ならびにコンピュータ・システム内で動作するコンピュータ・プログラムとして実施される付随の命令として実施される。かかるデータ構造は、図１の構成図に示すようなコンピュータ・システムで作成できる。
【００１０】
図１を参照すると、本発明の一実施態様がその上で実施されるシステムが１００で示されている。システム１００は、情報通信用のバスまたは他の通信手段１０１と、バス１０１に結合された情報処理用の処理手段１０２を含む。システム１００はさらにバス１０１に結合された、情報とプロセッサ１０２で実行される命令とを記憶するためのランダム・アクセス・メモリ（ＲＡＭ）または他の揮発性記憶装置１０４（主記憶装置と称する）を含む。主記憶装置１０４は、プロセッサ１０２による命令の実行中に一時的変数や他の中間情報を記憶するのにも使用される。システム１００はまた、バス１０１に結合された、静的情報およびプロセッサ１０２用の命令を記憶するための読取り専用メモリ（ＲＯＭ）または他の静的記憶装置あるいはその両方１０６と、磁気ディスクや光ディスクおよびそれに対応するディスク駆動装置などのデータ記憶装置１０７をも含む。データ記憶装置１０７は、情報および命令を記憶するためバス１０１に結合されている。これは、市販のソフトウェア製品を使用して定義する問題記述に関する情報を維持する、後述のデータ・ベースを格納するために使用される。
【００１１】
システム１００はさらに、バス１０１に結合された、コンピュータ・ユーザに情報を表示するための陰極線管（ＣＲＴ）や液晶ディスプレイ（ＬＣＤ）などの表示装置１２１にも結合される。表示装置１２１はさらに、フレーム・バッファ１１０を介してバス１０１に結合することができる。フレーム・バッファ１１０は、表示装置１２１に表示する単一または複数のフレームやイメージなどの情報を格納する。英数字キーとその他のキーを含む英数字入力装置１２２も、情報およびコマンド選択をプロセッサ１０２に通信するため、バス１０１に結合することができる。追加のユーザ入力装置は、バス１０１に結合された、指示情報およびコマンド選択をプロセッサ１０２に通信し、表示装置１２１上でのカーソル移動を制御するための、マウス、トラックボール、スタイラス、カーソル方向キーなどのカーソル制御装置１２３である。
【００１２】
システム１００の構成要素および付随のハードウェアはすべて様々な実施例で使用できるが、どんなシステム構成も具体的実施態様に従って様々な目的に使用できることにも留意されたい。
【００１３】
一実施例では、システム１００は、米国カリフォルニア州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）製造のＳＰＡＲＣｓｔａｔｉｏｎワークステーションなど、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）ブランドのワークステーション・ファミリーの１つである。プロセッサ１０２は、米国カリフォルニア州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）製造のＳＰＡＲＣブランドのマイクロプロセッサの１つでよい。
【００１４】
ここで考察する様々な実施例についての以下の議論は、特に、高水準プログラミング言語（たとえばＣ言語）で生成され、コンパイルされ、リンクされ、次いでたとえば米国カリフォルニア州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）から市販のＳＰＡＲＣｏｍｐｉｌｅｒによって実行時にシステム１００内でオブジェクト・コードとして実行される、一連のルーチンに関するものである。具体的に言うと、本発明は、米国カリフォルニア州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＳｕｎＳｏｆｔ，Ｉｎｃから市販のＳｏｌａｒｉｓ（登録商標）スレッズ・パッケージなど様々なソフトウェア・ライブラリと共に機能する（Ｓｕｎ、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ、Ｓｏｌａｒｉｓは米国カリフォルニア州Ｍｏｕｎｔａｉｎ ＶｉｅｗのＳｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ（登録商標）の商標、ＳＰＡＲＣとＳＰＡＲＣｓｔａｔｉｏｎはＳＰＡＲＣ Ｉｎｔｅｒｎａｔｉｏｎａｌ，Ｉｎｃ．の商標で、Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓに独占的に実施許諾されている）。しかし、以下の方法および装置は、離散論理装置、大規模集積回路（ＬＳＩ）、特定用途向け集積回路（ＡＳＩＣ）、あるいはその他の専用ハードウェアなどの専用ハードウェア装置で実施できることが当業者には理解できよう。この記述は、類似の機能をもつ装置にも適用される。
【００１５】
本発明は、テスト中のプログラムを作成するアプリケーション・プログラマがプログラムのソース・コード中で「プローブ」を指定して、後で実行可能プログラムの呼出し中にある種のパラメータが指定されるのに応じてシステム実行時にプローブが活動化され、第２のアプリケーション・プログラムまたはユーザ（たとえばテスト技術者）が検査するレコードを生成する、というシステムを実施する。このようにして、テスト中のアプリケーション・プログラムは、テスト中のアプリケーション・プログラム自体から生成されるレコードに含まれる記述情報を含めて、処理中のデータに関する情報を提供することができる。その詳細については後でより詳しく論じるが、そのような機構の動作を図２を参照して説明する。
【００１６】
図２のシステム２００は、アプリケーション・プログラム２１０、典型的にはある種のプローブ・パラメータ２０１を使って呼び出されるテスト中のプログラムを有する。これは、テスト技術者２０２によって指定された引数、またはアプリケーション・プログラムの呼出し時に活動化されるいくつかのプローブまたはプローブ群を指定するその他の機構を含むことがある。次にアプリケーション・プログラムはプローブ事象２２０を生成し、それがトレース・ファイル２２１に入れられる。トレース・ファイル２２１は、アプリケーション・プログラムに挿入された様々なプローブの状況を示すことができるトレース・レコード（後述）を含む。いくつかのプローブまたはプローブ群を活動化すべきであるとプローブ・パラメータ２０１が指定したことが検出されると、トレース・ファイル２２１に入れられたプローブ事象２２０が生成される。これは、第２のプログラム２３０、通常は、テスト・スートあるいはトレース・ファイル２２１を介してプローブ事象２２０を受け取り処理することのできる他のアプリケーション・プログラムによって検査される。トレース・ファイル２２１は、何らかの識別情報と共にアプリケーション・プログラム２１０内からのデータ自体を含むレコードへの参照を含む。レコードの生成とトレース・ファイル２２１などのファイルへの挿入は、この実施例で使用されるＳｕｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍのメモリ・マッピング（ｍｍａｐ）機能によって、この実施例を用いて生成されたレコードの要求される仮想メモリがコンピュータ・システム１００のファイル・システム中でメモリ・イメージとして捕捉されるように行われる。他のコンピュータ・システム・プラットフォームでは、ファイル作成用に同様のメモリ・マッピング機能を使用することもでき、また非揮発性媒体（たとえば図１の１０７）中の記憶レコードの他の区域を使用してもよい。これについては次に論じる。
【００１７】
前述のように、プローブは、アプリケーション・プログラマによって、またはアプリケーション・プログラムのコード（ソース・コードまたはオブジェクト・コード）内の所定の点にこのプローブを挿入する役割をする何らかの自動ツールによって挿入される。アプリケーション・プログラマは、ヘッダ・ファイル「ｔｎｆ＿ｐｒｏｂｅ.ｈ」または単に「ｐｒｏｂｅ.ｈ」への参照を自分のソース・コードに挿入することにより、ここで論じるデータ構造を参照する。このヘッダ・ファイルは、プローブ作成用の「構造単位」の集合体または「ライブラリ」である。ｐｒｏｂｅ．ｈ中で定義されるタイプへの参照の例は、後述の記述プログラミング・セグメントに示す。プローブは、グループ別にまたは特定のプローブ名により選択的に使用可能または使用不能にすることができる。ある種の実施例では、テスト中のアプリケーション・プログラムの呼出し時に所与のプローブを活動化したいプログラマが、プローブを使用可能にしまたは使用不能にする手順を使用する。特定のプログラムのソース・コード内にあるプローブを活動化する他の方式は、具体的実施態様に応じてシステム実行時に活動化または非活動化することができる。
【００１８】
プローブが使用可能になると、プローブはトレース・ファイル２２１に記憶されたプローブ事象２２０等の事象によって情報を生成する。このトレース・ファイルは、単一の所定の実施態様依存のフォーマットによるトレース「レコード」の集合体である。本明細書の以下の部分では、本発明の実際の実施例で、「トレース・ノーマル・フォーム」（ＴＮＦ）と呼ばれるフォーマットでアプリケーション・プログラムのソース・コードに挿入されたプローブから得られるデータを表す標準の方法を使用する。このＴＮＦは、異なる実施態様依存アプリケーションのために読み取り、処理し、様々な方法で操作することができる。このファイル中のレコードは、マシン間で因果関係の順にあるいは特定のマシン内で時間順になるようにソートできる。これらのレコードはまた、トレース・ファイルが、ファイルの残り部分を解決するのに必要なすべての情報から始まるようにもソートできる。一実施例では、ＴＮＦファイルの生成機能は、特定のテスト技術者またはテスト・スートから見て関心のあるものだけを抽出するため、現在は関心のないプローブ・レコードをフィルタまたは除去することができる。
【００１９】
したがって、図２に示すようなアプリケーション２１０またはテスト中の他のプログラムなどからのトレース生成機能３０１は、トレース・ノーマル・フォームによるトレース・レコードなどの中間情報３０２を生成することができる。次いで、この中間情報３０２をテスト・プログラムまたは他のツールなどによって処理し、トレース・マージ・ファイル３０３にする。次いで、トレース・マージ機能３０３を実行するプロセスが、中間情報３０２を取り出し、それを因果関係その他の順序でソートし、すべての情報をトレース・ノーマル・フォーム３０４に入れる。トレース・ノーマル・フォームが生成されると、ある種のトレース・ツール３０５が、テスト技術やデータを検査する他の人などからの情報を使って、関心のある情報を抽出することができる。
【００２０】
本発明の実際の実施例は、レコードを、したがってプローブ事象によって生成されたレコード内に含まれるデータを識別する手段を提供する。このようにして、テスト・スートまたはテスト中のプログラムのテストを実施する技術者は、テスト中のプログラム内に含まれるデータに関する詳細な情報をもつ必要がない。その代わりに、特定のレコードが検査でき、トレース・ノーマル・フォームと呼ばれる、このデータ記憶方式によって、事象レコード内に含まれるデータを決定することができる。この方式の詳細と機構については次に考察する。
【００２１】
指定されたいくつかのプローブ・パラメータを含むテスト中のアプリケーション・プログラムの実行の結果、トレース・ファイルと呼ばれるトレース・レコードの集合体が得られる。トレース・ファイルは、トレース・ノーマル・フォーム（ＴＮＦ）中で表され、ＴＮＦ分析のブートストラップに使われるルート・レコードを含む。本発明の実際の実施例では、このブートストラップ処理が依存する、最小の１組のフォーマット依存関係が存在する。図４に示すように、４００などのルート・ファイルは、自己相対ポインタを含むフィールド４０１とフィールドの名前をレコード中の順序で提供するＡＳＣＩＩ文字列を含むレコード４２０を参照する第２のフィールド４０３とを有する。レコード４２０中の名前は、ヘッダ情報を含むレコード中で最初の２個のフィールドの後から始まる。実際の実施例では、文字列は空白で終わるが、たとえば長さフィールドが文字列の内容の前にくる他のフォーマットで文字列を表すこともできることを当業者なら理解できよう。レコードの名前を含む文字列への参照を含むＴＮＦレコード中のたとえば第１と第３のフィールド４０３以外のどのフィールドも固定する必要はない。その詳細については、後でいくつかの具体例に関して考察する。
【００２２】
図４および下記に示す記述セグメントに示すように、接頭辞ｔｎｆ＿ｒｏｏｔのついたルート・レコード名は、すべてルート・レコード中と同じ位置にｔｎｆ＿ｔａｇフィールドとｔｎｆ＿ｏｐｅｒａｔｉｏｎｓフィールドを含むタグ・レコード付きのファイルを示すために使用される。ｔｎｆ＿ｏｐｅｒａｔｉｏｎｓまたは単にｏｐｅｒａｔｉｏｎｓという名前をもつフィールドは、テスト・ルーチンによる分析中に関連タグ・レコードによって記述される種類のレコード用の解釈手順を指すポインタを保持するために使用される。今説明しているレコードは、そのタイプのすべてのレコードと同様にそのタグ・レコードを指す。ダグ・レコードのｏｐｅｒａｔｉｏｎｓフィールドは、たとえば強制動作や変換動作や分析中に頻繁に実行されるその他のタイプの動作を実行する目的で、その種類のレコードに迅速に作用する手順にアクセスするために使用される。
【００２３】
図４に４０１として示したレコード中の「ｔｎｆ＿ｔａｇ」フィールドは、その名前に接頭辞として「ｔｎｆ＿ｔａｇ」が含まれるフィールドである。４００などのルート・レコードは、そのレコードを記述する「タグ・レコード」を指す自己相対ポインタを保持する。すなわち、図４に示した４００などのルート・レコードは、それ自体を記述するが、ＴＮＦファイル構造中の他のタグ・レコードは、通常は他のレコードを記述する。ｔｎｆ＿ｒｏｏｔレコードの例は、図４に４００として示してあり、そのレコードを指定するために使用される記述コード・セグメントは以下に示す。「ｓｌｏｔｓ」フィールド４０３は、そのレコード中のすべてのフィールドを識別する文字列を指すポインタを含んでいる。それ自体を記述しない他のレコードとは異なり、この文字列はｔｎｆ＿ｒｏｏｔレコード４００内に含まれるすべてのレコードを記述する。すなわち、セミコロンで区切られた各文字列対が、ＴＮＦタイプとそのレコードに含まれるフィールドの名前とを示す。したがって、ルート・レコードに含まれる各フィールドと、フィールド４０３で参照されるセミコロンで区切られた各文字列対４２０との間に１対１の対応がある。このように、ルート・レコードに含まれるデータは自己記述式であり、したがって、ｓｌｏｔｓフィールドが参照された後は、それを使ってこの例ではＴＮＦルート・レコードの内容を決定することができる。他のタグ・レコードの場合は、このフィールドはタグ・レコードを参照するレコードを記述するのに使用される。それについては後で詳しく示す。
【００２４】
以下の記述セグメントでは、コロンで終わる名前は、フィールドの名前を示すがファイル中には現れないので、単に表記上の目的で使用される。それらの名前は図４の４００にも現れるが、実際のフィールドの内容はコロンの後にある。記述セグメント中の矢印は、別のレコードへの参照を示すのに使用され、その内容が矢印で指される。すなわち、この図で４０３や４０４などのフィールドは実際に、レコードを記述する文字列を含むレコードへの参照を含む。ｓｌｏｔｓフィールド４０３については既に論じたが、フィールド４０４は、レコード「ｔｎｆ＿ｒｏｏｔ＿１」の名前である文字列を含む別のレコード４３０への参照をも含む。下のコード・セグメントの内容は、名前レコードへの自己相対参照であり、この注記法でダブル・コロン終了記号によって識別される。
【００２５】
上記の例および図４に示した文字列はそれ自体がＴＮＦレコード（たとえば４２０と４３０）、すなわち単バイトＡＳＣＩＩ文字配列であるｔｎｆ＿ｓｔｒｉｎｇレコードである。この実施態様では、フィールドの名前とタイプの名前は、上記に示したように文字列で符号化され、ファイル中に厳密には何があるかを記述する。他の実施態様では、名前とタイプは以下で論じるように別々のフィールド中で符号化されることがある。ＴＮＦファイルは、既に論じたように、自己記述式データを保持し、したがって、分析ルーチンまたは他の後処理プログラムがＴＮＦファイルの内容を決定することができる。ｓｉｚｅフィールド４０５は、上記レコードのサイズをバイト単位で示す。各フィールドは長さ４バイトなので、この例のサイズはフィールド４０５に含まれる２８に等しい。ｏｂｊｅｃｔフィールド４０６は、この例では、指定された解釈を有するＴＮＦタイプの名前を名前とする手順を示す共用オブジェクトを示す。これらの手順は、指定されたタイプの１組の動作を供給する。ｐｌａｔｆｏｒｍフィールドは、ＴＮＦファイルに含まれるデータのソースであったプラットフォームのタイプを決定することが重要な場合、共用オブジェクトまたはその中の動作を修飾するのに使用できる。たとえば、大エンディアン／小エンディアン・バイト順序をサポートする様々なアーキテクチャでは、分析ルーチンによる処理の前にデータの強制を行うために、データが作成されたプラットフォームを知ることが重要である。
【００２７】
ＴＮＦファイル内には、ルート・レコードと、ＴＮＦファイルの基本ファイル・システムを定義するいくつかのレコードとが含まれる。トレース・ファイル中にトレース事象を記録するレコードはかなりの数に上る。そのような事象レコードと、事象レコードの内容を定義する関連レコードについては、図５および下記の記述セグメントに関して示す。この場合も、図にはいくつかのフィールド名が列挙してあるが、これは概念上かつ便宜上のものにすぎず、フィールドの実際の内容はフィールド名に応じて変わる。いずれにせよ、事象レコード５５０は３つのワード５５１〜５５３を含む。第１のフィールド５５１は、２つの部分５５１ａと５５１ｂに分かれ、それぞれ特定の意味を有する。ワードの前半部５５１ａは事象を記述するタグ・レコードを参照するタグ（たとえばポインタまたは他の参照）である。第１のワードの第２の部分５５１ｂは、事象レコードを修飾するスケジュール・レコードであるスケジュール・オフセットである。このスケジュール・レコードはそれ自体、図５に５６０として示す事象レコードであり、スレッドＩＤ、絶対時間その他の情報などの情報を含む。このようなレコードは、どんなタイプの情報を含むこともできるが、図ではわかりやすいように省略した。事象レコード中の次のフィールド５５２は、その事象に関して参照されるスケジュール・レコード５６０に含まれていた６４ビット絶対時間の上位ワードに対するナノ秒で表した時間を示す。またアドレス・フィールド５５３は、いくつかの実際の実施例でプローブされ事象を引き起こしたデータへの参照を含む。これは、プローブ中の変数があった場所などいくつかの情報を提供することができる。
【００２８】
この例では、図５に５００として示すｖｍ＿ｍｉｎｏｒ＿ｆａｕｌｔと呼ばれる参照タグが、下記の記述セグメントに示されている。
【００２９】
この実施態様における上記のタグ・レコード中のｏｐｅｒａｔｉｏｎｓフィールドは、事象レコードが指すタグ・レコードを事象レコードに対する指定の動作と結び付けるために分析ルーチンが使用する。事象用タグ・レコードはまた、事象レコード５５０の内容（タグ・レコードの「ｓｌｏｔｓ」フィールド中）、事象レコードのバイト数（「ｓｉｚｅ」フィールド中）を記述し、事象レコードのタイプに命名する文字列（タグ・レコードの「ｎａｍｅ」フィールド）への参照を含む。このタグ・レコードｖｍ＿ｍｉｎｏｒ＿ｆａｕｌｔは、タグ・レコード５１０によって記述され、タグ・レコード５１０はｖｍ＿ｍｉｎｏｒ＿ｆａｕｌｔタグ・レコード５００によりフィールド５０１を介して参照される。これらも下記の記述セグメントに示されている。したがって、タグ・レコード５００は、上記のセグメントのｓｌｏｔｓフィールドに示されているプローブ事象レコード５５０の内容を定義する。この場合も、これを簡潔に示すため、これらのレコードは単に便宜上かつ表記上の目的で図５に示したレコードのブロック図の詳細には示していないが、図４に示したレコードと同様にｓｌｏｔｓフィールドおよびｎａｍｅフィールドは実際にはタグ・レコードを識別する文字列を含む文字列レコードへの参照である。
【００３１】
他の実施態様では、ＴＮＦレコードは少し異なる形でフォーマットすることができる。この代替実施態様では、上記で論じたｖｍ＿ｍｉｎｏｒ＿ｆａｕｌｔレコードを下記の記述セグメントで示されるような形でフォーマットすることができる。
【００３２】
このレコードは、上記の記述セグメントに関して述べた図５に示すものと類似しているが、ｏｐｅｒａｔｉｏｎｓフィールドの名称が「ｔａｇ ｃｏｄｅ」となっており、ｎａｍｅフィールドがレコードの３番目のワードにある。さらに重要なことであるが、「ｓｌｏｔｓ」フィールドが、ｓｌｏｔ＿ｔｙｐｅｓフィールドとｓｌｏｔ＿ｎａｍｅｓフィールドの別々の２つのフィールドに分割されている。この例では、ｓｌｏｔ＿ｔｙｐｅｓは、レコード中の各名前付きフィールドのそれぞれのタイプへの参照を含む配列への参照である。次いで、ｓｌｏｔ＿ｔｙｐｅｓフィールドの後にｓｌｏｔ＿ｎａｍｅｓフィールドが続き、これはｓｌｏｔ＿ｔｙｐｅｓフィールドで指定されたタイプを有するそれぞれのフィールドの名前をリストする文字列を参照する。レコード中の残りのフィールドは、上述のような僅かな修正を除き基本的に図５に示したものと同じである。どちらの実施態様においても、いくつかのレコードがＴＮＦレコード中の所定の場所に現れ、したがってＴＮＦトレース・ファイル中のレコードを検査するルーチンは、その内部に含まれるデータの性質を決定することができる。上記のこの代替実施例で短い修正コード・セグメントに関して述べた特定のフォーマットは、下記の付録Ａに概略を示すより詳細なＴＮＦフォーマットの単一レコードを例示するものである。しかし、本明細書の残りの部分では、一貫性を保つため、本発明があいまいにならないように前述の実施態様について論じることにする。
【００３４】
既に述べたように、タグ・レコードはそれ自体は、プローブ事象レコードなどのレコード用のタグ・レコードの内容を記述するタグ・レコードを参照する。これは、「基本」ＴＮＦタイプと呼ばれ、図５に５１０〜５３０で全体的に示されている。タグ・レコードは、既に論じたように、やはりタグ・レコードを記述するレコードを参照するタグ・フィールドを有し、これが繰り返されてルート・レコード（たとえば、図４および図５の４００）までさかのぼる。ｖｍ＿ｍｉｎｏｒ＿ｆａｕｌｔタグ・レコード５００は、この例では、ｔｎｆ＿ｓｔｒｕｃｔ＿１の名前を有するタグ・レコード５１０によって記述される。タグ・レコード５１０はまた、ｏｐｅｒａｔｉｏｎｓ、ｓｌｏｔｓ、ｎａｍｅ、ｓｉｚｅをもつものとして特徴付けることができる。これは、下記の記述セグメントで示される。
【００３５】
レコード５１０はさらに、タグ・レコード５１０の内容を定義する別のタグ・レコード５２０を参照する。これが繰り返されて、レコード５３０にまで至る。最後に、レコード５３０ｔｎｆ＿ｂａｓｅ＿１は、先に図４に関して論じた図５に示されているルート・レコードｔｎｆ＿ｒｏｏｔ＿１ ４００を参照する参照をそのｔａｇフィールド５３１に含む。この場合も、４００はルート・レコードなので、そのｓｌｏｔｓフィールドに自己記述情報を含み、そのｔａｇフィールド４０１に自己参照タグを含む。このようにして、分析ルーチンはそれがルート・レコードであることを知る。さらに、レコードｔｎｆ＿ｂａｓｅ＿１は、ルート・レコード４００によって記述されるので、ルートと全く同じフォーマットでなければならない。この実施態様でこの要件が課されるレコードはこれだけである。ｔｎｆ＿ｓｔｒｕｃｔ＿１とｔｎｆ＿ｂａｓｅの記述セグメントを以下に示す。
【００３７】
ルートによって記述されるタグ・レコードは、ルートと同じ外観でなければならない。（ただし、この方式では、そうする必要があるのはこれだけである）
【００３９】
上述のＴＮＦタイプは、それ自体もＴＮＦタイプである。これらは、やはりタイプを記述するレコードを参照するタグを含むレコードによって記述される。その一例を図６に関して示す。図６のｔｎｆ＿ｔａｇレコード・タイプ６００は、ｔａｇフィールド６０１を含み、これは、この例では、レコードｔｎｆ＿ｂａｓｅ＿ｔｙｐｅ＿１を参照する。同様にｔｎｆ＿ｂｙｔｅ＿１タイプは、やはり図６に示すｔｎｆ＿ｂａｓｅ＿ｔｙｐｅ＿１ ６２０へのタグ参照６１１を含むレコード６１０によって表すことができる。ｔｎｆ＿ｂａｓｅ＿ｔｙｐｅ＿１レコード６２０はさらに図５に関して示したレコードの１つ、すなわち図５にタグ・レコード５２０として示したｔｎｆ＿ｓｔｒｕｃｔ＿１ベースタイプを逆参照できるタグ参照６２１を含む。その後、図５に関して先に論じたように参照が繰り返される。前述の３つのレコードの記述セグメントを以下に示す。ｔｎｆ＿ｔａｇレコード６００は以下のような形となる。
【００４１】
ｔｎｆ＿ｂｙｔｅ＿１レコード（たとえば、図６の６１０）は次のような形をとる。
【００４３】
これらのタイプ用のタグ・レコードは、その記述用のｔｎｆ＿ｂａｓｅ＿ｔｙｐｅタグ・レコードを参照する。
【００４５】
最後に、ここで説明する最後のレコード・タイプは、本発明の実際の実施例における配列および文字列の取扱いである。これを図７に関して示す。ｔｎｆ＿ｓｔｒｉｎｇはヘッダと、その後に続く、ゼロで終わる１バイト要素のワード埋込み配列から構成される。ヘッダは、図７に７０１と示すｔａｇフィールドをｏｐｅｒａｔｉｏｎｓフィールドと、レコードのバイト単位で表したサイズを含むフィールドとを含む。このレコードはまた、下記の記述セグメントに示されるように、使用されるある種の記号の他の記号に対する文字列突合わせの性能を向上させるための、文字列のハッシュ値をも含むことになる。
【００４７】
ｔｎｆ＿ｂｙｔｅは、図６に関して先に論じたように、タグ・レコードｔｎｆ＿ｂａｓｅ＿ｔｙｐｅ（たとえば６１０）を参照する。
配列は、タグ・レコードｔｎｆ＿ｂａｓｅ＿ａｒｒａｙによって記述される。
【００４９】
この２つのレコードの例を図７に示す。ｔｎｆ＿ｓｔｒｉｎｇレコード７００は、既に論じた図５に示すｔｎｆ＿ｓｔｒｕｃｔ＿１ ５２０を参照する第２のレコードｔｎｆ＿ｂａｓｅ＿ａｒｒａｙ＿１を参照するタグをフィールド７０１に有する。いずれにせよ、レコード７００と７１０を使用して、本発明の実際の実際例では配列または文字列を表すことができ、それから次にトレース・ファイルを介して後処理分析ルーチンに送られ、テスト中のプログラム中に存在する可能性のある文字列および配列が検査される。
【００５１】
本発明の具体的実施例で使用されるＴＮＦ構造の詳細なダンプを付録Ａに示す。付録Ａのファイル”ｔｒａｃｅ ＡＳＣＩＩ”中に示される各レコードはそれぞれ関連するフィールドｔｎｆ＿ｔａｇを有し、このフィールドは関連タグ・レコードへの１６進参照アドレスを含む。したがって、ＴＮＦ定義の前にあるアドレスと、ダンプ中の各レコードのｔｎｆ＿ｔａｇフィールドに記憶されているアドレスとを突き合わせることにより、ＴＮＦトレース・ファイル中で生成される種々のレコードの相互関係を示すことができる。
【００５２】
図３ないし７に示したＴＮＦファイルの例は、例示のために示したものにすぎず、本発明を限定するものではない。以上、テスト・アプリケーション用などのデータを表すため、第１のアプリケーション・プログラムにおいてデータを表現し、たとえば第２のアプリケーション・プログラムによって検査されるレコードおよび関連トレース・ファイルを生成するための総合的システム、ならびに分析ルーチンについて説明した。したがって、第１ルーチンから第２ルーチンへのデータの提供は、テスト中のプログラム中で表されるデータのタイプを分析プログラムまたはテスト技術者あるいはこの両方が知っている必要のある、従来技術の方法に比べて大きな利点である。というのは、本発明においては、データがデータ自体を記述するレコードによって緊密に符号化され、データとそのデータの記述との関係が、符号化の修正なしである処理アドレス空間から別の処理アドレス空間にマップできるようにこの符号化が、配列できるからである。これは従来技術に比べて大幅な改善であり、従来技術によって実現も教示もされていない独特の利益を有する。本発明を図１ないし７に示した特定の実施例および添付の付録Ａに関して説明してきたが、これは本発明を限定するものではなく、本発明は頭記の特許請求の範囲によってのみ限定されるものと解釈されるものとする。
【図面の簡単な説明】
【図１】 本発明の一実施例が実施されるシステムを示す図である。
【図２】 テスト中のアプリケーション・プログラムとテスト・マート・プログラムの関係、ならびにこの２つの実行可能プログラム間での通信を示す図である。
【図３】 本発明の実施例を実施するシステムにおいて実行される様々なトレース情報と中間情報の処理を示す図である。
【図４】 本発明の実際の実施例で作成され使用される各種データ構造を示す図である。
【図５】 本発明の実際の実施例で作成され使用される各種データ構造を示す図である。
【図６】 本発明の実際の実施例で作成され使用される各種データ構造を示す図である。
【図７】 本発明の実際の実施例で作成され使用される各種データ構造を示す図である。
【符号の説明】
１０１ バス、 １０２ プロセッサ、 １０４ メイン・メモリ
１０６ 読取り専用メモリ、 １０７ 大容量記憶装置、
１１０ フレーム・バッファ、 １２１ 表示装置、 １２２ キーボード、
１２３ カーソル制御装置、 １２４ ハードコピー装置、
２０１ プローブ・パラメータ、 ２０２ テスト技術者、
２１０ アプリケーション・プログラム、 ２２０ プローブ事象、
２２１ トレース・ファイル、 ２３０ テスト・プログラム
Claims (2)
- プログラムの性能を評価するためのプローブが挿入されている第１のアプリケーション・プログラムを実行することによって生成された前記プローブに関するプローブ事象を第２のアプリケーション・プログラムにおいて処理するコンピュータ・システムでのコンピュータ実施方法において、
前記コンピュータ・システムは、
生成されたプローブ事象を記述するレコードを生成する第１の手段と、
前記プローブ事象の検査を行わせる第２の手段と
前記プローブ事象の検査結果にしたがって、当該プローブ事象を操作する第３の手段と
を有しており、
ａ．前記コンピュータ・システムの第１の手段によって、
実行される前記第１のアプリケーション・プログラムの前記プローブに関するプローブ事象を記述するレコードを生成する段階であって、この生成されるレコードが、
ｉ．少なくとも１つのフィールドが、前記第１のアプリケーション・プログラムの実行によって生成されたプローブ事象を含み、他のフィールドが、前記プローブ事象に関する記述情報を含む複数のフィールドと、
ｉｉ．タグ・レコードへの参照とを含み、前記タグ・レコードが、前記レコードに含まれる前記複数のフィールドそれぞれの名前をリストし、さらに前記タグ・レコードが、参照されるタグ・レコード内のフィールドを識別する関連タグ・レコードをそれぞれ参照する複数のタグ・レコードを繰り返し参照し、最後に、ルート・レコード内の前記フィールドを識別する自己参照タグを含むルート・レコードを参照する構成となっている、段階と、
ｂ．前記コンピュータ・システムの第２手段によって、
前記第２のアプリケーション・プログラムに前記レコードを提供し、前記第２のアプリケーション・プログラムを実行することにより、前記ルート・レコードに達するまで前記タグ・レコードと前記複数のタグ・レコードそれぞれとを繰り返し参照して、前記タグ・レコードそれぞれの中の前記複数のフィールドを参照することにより前記プローブ事象を検査する段階と、
ｃ．前記コンピュータ・システムの第３手段によって、
前記第２のアプリケーション・プログラムの実行中に、前記レコードと前記タグ・レコードと前記複数のタグ・レコードそれぞれとによって指定される前記プローブ事象の前記検査結果に従って当該プローブ事象を操作する段階とを含む方法。 - プログラムの性能を評価するためのプローブが挿入されている第１のアプリケーション・プログラムを実行することによって生成された前記プローブに関するプローブ事象を第２のアプリケーション・プログラムにおいて処理するコンピュータ・システムの装置において、
ａ．実行される前記第１のアプリケーション・プログラムの前記プローブに関するプローブ事象を記述するレコードを生成するための第１の手段であって、前記レコードが、
ｉ．少なくとも１つのフィールドが、前記第１のアプリケーション・プログラムの実行によって生成されたプローブ事象を含み、他のフィールドが、前記プローブ事象に関する記述情報を含む、複数のフィールドと、
ｉｉ．タグ・レコードへの参照とを含み、前記タグ・レコードが、前記レコードに含まれる前記複数のフィールドそれぞれの名前をリストし、さらに前記タグ・レコードが、参照されるタグ・レコード内のフィールドを識別する関連タグ・レコードをそれぞれ参照する複数のタグ・レコードを繰り返し参照し、最後に、ルート・レコード内の前記フィールドを識別する自己参照タグを含むルート・レコードを参照する構成となっている、第１の手段と、
ｂ．第２のアプリケーション・プログラムに前記レコードを提供し、前記第２のアプリケーション・プログラムを実行することによって、前記ルート・レコードに達するまで、前記タグ・レコードと前記複数のタグ・レコードそれぞれを繰り返し参照して、前記タグ・レコードそれぞれの中の前記複数のフィールドを参照することにより前記プローブ事象を検査する、第２の手段と、
ｃ．前記レコードと前記タグ・レコードと前記複数のタグ・レコードそれぞれとによって指定される前記プローブ事象の前記検査結果に従って、前記第２のアプリケーション・プログラムの実行中において前記プローブ事象を操作するための、第３の手段とを含む装置。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US23329794A | 1994-04-26 | 1994-04-26 | |
| US233297 | 1994-04-26 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH0855045A JPH0855045A (ja) | 1996-02-27 |
| JP3699154B2 true JP3699154B2 (ja) | 2005-09-28 |
Family
ID=22876692
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP12453195A Expired - Lifetime JP3699154B2 (ja) | 1994-04-26 | 1995-04-26 | データを自己記述式に符号化するための方法および装置 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US5655121A (ja) |
| EP (1) | EP0679995B1 (ja) |
| JP (1) | JP3699154B2 (ja) |
| DE (1) | DE69518996T2 (ja) |
Families Citing this family (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5761510A (en) * | 1995-11-07 | 1998-06-02 | Microsoft Corporation | Method for error identification in a program interface |
| US5884315A (en) * | 1996-05-09 | 1999-03-16 | Philips Electronics North America Corporation | System and method for handling technical hardware related information |
| US5842213A (en) * | 1997-01-28 | 1998-11-24 | Odom; Paul S. | Method for modeling, storing, and transferring data in neutral form |
| US5911073A (en) * | 1997-12-23 | 1999-06-08 | Hewlett-Packard Company | Method and apparatus for dynamic process monitoring through an ancillary control code system |
| US6164841A (en) * | 1998-05-04 | 2000-12-26 | Hewlett-Packard Company | Method, apparatus, and product for dynamic software code translation system |
| US6189141B1 (en) | 1998-05-04 | 2001-02-13 | Hewlett-Packard Company | Control path evaluating trace designator with dynamically adjustable thresholds for activation of tracing for high (hot) activity and low (cold) activity of flow control |
| US6148437A (en) * | 1998-05-04 | 2000-11-14 | Hewlett-Packard Company | System and method for jump-evaluated trace designation |
| US6223339B1 (en) * | 1998-09-08 | 2001-04-24 | Hewlett-Packard Company | System, method, and product for memory management in a dynamic translator |
| JP2000235510A (ja) * | 1999-02-15 | 2000-08-29 | Hitachi Ltd | プロセッサおよびそのためのコンパイルプログラム記録媒体 |
| US7100152B1 (en) * | 2000-01-31 | 2006-08-29 | Freescale Semiconductor, Inc. | Software analysis system having an apparatus for selectively collecting analysis data from a target system executing software instrumented with tag statements and method for use thereof |
| US6742178B1 (en) * | 2000-07-20 | 2004-05-25 | International Business Machines Corporation | System and method for instrumenting application class files with correlation information to the instrumentation |
| US7334221B1 (en) * | 2003-11-14 | 2008-02-19 | Sun Microsystems, Inc. | System and method for encoding trace framework enabling in an object file |
| US7669186B2 (en) * | 2005-11-16 | 2010-02-23 | Sun Microsystems, Inc. | Debugging applications at resource constrained virtual machines using dynamically installable lightweight agents |
| US9323578B2 (en) | 2006-01-19 | 2016-04-26 | International Business Machines Corporation | Analyzing wait states in a data processing system |
| US7474991B2 (en) | 2006-01-19 | 2009-01-06 | International Business Machines Corporation | Method and apparatus for analyzing idle states in a data processing system |
| US7814465B2 (en) * | 2006-05-12 | 2010-10-12 | Oracle America, Inc. | Method and apparatus for application verification |
| US8898636B1 (en) * | 2007-02-14 | 2014-11-25 | Oracle America, Inc. | Method and apparatus for testing an application running in a virtual machine |
| US8825722B2 (en) | 2012-01-13 | 2014-09-02 | Microsoft Corporation | Calculation of properties of objects/shapes across versions of applications |
| JP5533935B2 (ja) * | 2012-05-10 | 2014-06-25 | トヨタ自動車株式会社 | ソフトウェア配信システム、ソフトウェア配信方法 |
| US20160019133A1 (en) * | 2014-07-15 | 2016-01-21 | 4D Soft Kft. | Method for tracing a computer software |
Family Cites Families (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR111574A (ja) * | 1973-12-13 | 1900-01-01 | ||
| US4025901A (en) * | 1975-06-19 | 1977-05-24 | Honeywell Information Systems, Inc. | Database instruction find owner |
| US4462077A (en) * | 1982-06-24 | 1984-07-24 | Bell Telephone Laboratories, Incorporated | Trace facility for use in multiprocessing environment |
| US4507752A (en) * | 1983-02-22 | 1985-03-26 | International Business Machines Corporation | In-place index compression |
| US4636940A (en) * | 1983-03-31 | 1987-01-13 | Hewlett-Packard Company | Logic analyzer using source program or other user defined symbols in the trace specification and the trace listing |
| US4821178A (en) * | 1986-08-15 | 1989-04-11 | International Business Machines Corporation | Internal performance monitoring by event sampling |
| US5101494A (en) * | 1986-09-26 | 1992-03-31 | Bull Hn Information Systems Inc. | System for producing memory maps by interpreting a descriptor file which identifies and describes the data structures present in memory |
| US4802165A (en) * | 1986-10-08 | 1989-01-31 | Enteleki, Inc. | Method and apparatus of debugging computer programs |
| EP0360387B1 (en) * | 1988-09-23 | 1996-05-08 | International Business Machines Corporation | Data base management system |
| US5129084A (en) * | 1989-06-29 | 1992-07-07 | Digital Equipment Corporation | Object container transfer system and method in an object based computer operating system |
| US5121501A (en) * | 1989-12-27 | 1992-06-09 | International Business Machines Corporation | First processor inserting hooks into software and sending unique identifications to output bus and second processor associating data frames and time with these unique identifications |
| US5313636A (en) * | 1990-09-27 | 1994-05-17 | Intellicorp, Inc. | Mosaic objects and method for optimizing object representation performance in an object-oriented representation system |
| AU4598593A (en) * | 1992-06-05 | 1994-01-04 | Convex Computer Corporation | Computer program debugging in the presence of compiler synthesized variables |
-
1995
- 1995-04-25 DE DE69518996T patent/DE69518996T2/de not_active Expired - Fee Related
- 1995-04-25 EP EP95400918A patent/EP0679995B1/en not_active Expired - Lifetime
- 1995-04-26 JP JP12453195A patent/JP3699154B2/ja not_active Expired - Lifetime
-
1996
- 1996-07-19 US US08/684,492 patent/US5655121A/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH0855045A (ja) | 1996-02-27 |
| US5655121A (en) | 1997-08-05 |
| DE69518996T2 (de) | 2001-03-29 |
| EP0679995A1 (en) | 1995-11-02 |
| DE69518996D1 (de) | 2000-11-09 |
| EP0679995B1 (en) | 2000-10-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3699154B2 (ja) | データを自己記述式に符号化するための方法および装置 | |
| Dallmeier et al. | Mining object behavior with ADABU | |
| EP0632377B1 (en) | Method for testing a message-driven operating system | |
| US5987250A (en) | Transparent instrumentation for computer program behavior analysis | |
| US5956479A (en) | Demand based generation of symbolic information | |
| US8132156B2 (en) | Methods and systems for testing tool with comparative testing | |
| US6026237A (en) | System and method for dynamic modification of class files | |
| US5528753A (en) | System and method for enabling stripped object software monitoring in a computer system | |
| US5758160A (en) | Method and apparatus for building a software program using dependencies derived from software component interfaces | |
| EP1113367B1 (en) | Automated regression testing of workstation software | |
| US5652835A (en) | Method and apparatus for generating test data for an automated software testing system | |
| US7945902B1 (en) | Detection of non-standard application programming interface usage via analysis of executable code | |
| US20020091968A1 (en) | Object-oriented data driven software GUI automated test harness | |
| EP0684557A2 (en) | System and method for selective regression testing | |
| US20010001882A1 (en) | Method and apparatus for software component analysis | |
| US5862382A (en) | Program analysis system and program analysis method | |
| US20100050159A1 (en) | System and process for debugging object-oriented programming code leveraging runtime metadata | |
| Robbes et al. | Characterizing and understanding development sessions | |
| US7086033B2 (en) | Software debugger having a monitor for monitoring conditional statements within a software program | |
| US6996516B1 (en) | Apparatus for analyzing software and method of the same | |
| Rosenberg et al. | Testing object-oriented programs: making it simple | |
| Siepmann et al. | TOBAC: a test case browser for testing object-oriented software | |
| Hartel et al. | Transacted memory for smart cards | |
| JPH0926897A (ja) | プログラム解析装置及びプログラム解析方法 | |
| Munger et al. | Coding concerns: do they matter |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20041203 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050104 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050404 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050607 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050707 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080715 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090715 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090715 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100715 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110715 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110715 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120715 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120715 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130715 Year of fee payment: 8 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |