(57)【要約】【課題】  カラー属性が設定されているかを判別するシステムの拡張を容易にする。【解決手段】  Ｗｉｎｄｏｗｓ（登録商標）のＡＰＩ呼び出しログを取得するＰＡＴの機能に、カラー判別の機能を追加し、アプリケーションがＷｉｎｄｏｗｓ（登録商標）に対してカラーデータを渡している証拠を取り、カラーかモノクロかで異なる印刷料金の課金のユーザクレームの解決を図る。描画関数ごとに使用しているＧＤＩオブジェクトをグループ化してテーブル定義する。【選択図】  図１９
2006040021.tif 000002
【特許請求の範囲】
【請求項１】
複数にモジュール分けされているソフトウェアにおいて、あるモジュールから別のモジュール内に存在する関数への呼び出しを、ログ取得のためのルーチンにリダイレクトする手段を有し、リダイレクトしたログ取得ルーチン内部に計時手段を有し、リダイレクトしたログ取得ルーチン内部に呼び出し時のパラメータを判別する手段を有し、リダイレクトしたログ取得ルーチン内部で元の関数を呼び出す手段を有し、元の関数を呼び出す際に、その関数からの戻りをログ取得ルーチンにリダイレクトさせる手段を有し、リダイレクトしたログ取得ルーチン内部で関数からの戻り値を判別する手段を有する、ソフトウェア評価システム。
【請求項２】
上記ソフトウェア評価システムにおいて、あるモジュールから別のモジュール内に存在するCOMサーバのメソッドへの呼び出しを、ログ取得のためのルーチンにリダイレクトする手段を有し、リダイレクトしたログ取得ルーチン内部に計時手段を有し、リダイレクトしたログ取得ルーチン内部に呼び出し時のパラメータを判別する手段を有し、リダイレクトしたログ取得ルーチン内部で元のメソッドを呼び出す手段を有し、元のメソッドを呼び出す際に、そのメソッドからの戻りをログ取得ルーチンにリダイレクトさせる手段を有し、リダイレクトしたログ取得ルーチン内部でメソッドからの戻り値を判別する手段を有する、ソフトウェア評価システム。
【請求項３】
上記ソフトウェア評価システムにおいて、ログ取得のためのルーチンにリダイレクトする手段として、呼び出し元がメモリにロードするインポート関数アドレステーブルを、ログ取得のためのルーチンがロードされたメモリアドレスに書き換える手段を有する、ソフトウェア評価システム。
【請求項４】
上記ソフトウェア評価システムにおいて、ログ取得のためのルーチンにリダイレクトする手段として、呼び出し元がメモリにロードするVirtual Address Tableを、ログ取得のためのルーチンがロードされたメモリアドレスに書き換える手段を有する、ソフトウェア評価システム。
【請求項５】
上記ソフトウェア評価システムにおいて、ログ取得のためのルーチンが、呼び出された関数の情報を記録する手段を有し、書き換える前のインポート関数アドレステーブルに記載された元の関数を呼び出す手段を有する、ソフトウェア評価システム。
【請求項６】
上記ソフトウェア評価システムにおいて、ログ取得のためのルーチンが、呼び出されたメソッドの情報を記録する手段を有し、書き換える前のVirtual Address Tableに記載された元のメソッドを呼び出す手段を有する、ソフトウェア評価システム。
【請求項７】
上記ソフトウェア評価システムにおいて、ログ取得ルーチン内部で、関数/メソッドの呼び出された時刻、及び関数/メソッド呼び出し時のパラメータ、関数/メソッドから処理が戻った時刻、及び関数/メソッドからの戻り値をログとして記録する手段を有する、ソフトウェア評価システム。
【請求項８】
上記ソフトウェア評価システムにおいて、ログ取得ルーチン内部で、関数/メソッド呼び出し時のパラメータをメモリアドレスと判別する手段を有し、関数/メソッド呼び出し時の該当メモリアドレスの内容を保持する手段を有し、関数/メソッドから処理が戻った時点での該当メモリアドレスの内容を保持する手段を有し、関数/メソッド呼び出し時及び関数/メソッドから処理が戻った時点での該当メモリアドレスの内容を、ログとして記録する手段を有する、ソフトウェア評価システム。
【請求項９】
上記ソフトウェア評価システムにおいて、各モジュールのエクスポートする関数一覧を取得する手段を有し、メモリに配置されたインポート関数アドレステーブルのうち、何れの関数をログ取得ルーチンにリダイレクトするかの設定を、エクスポートする関数一覧から選択する手段を有する、ソフトウェア評価システム。
【請求項１０】
上記ソフトウェア評価システムにおいて、各COMサーバのエクスポートするインターフェース及びメソッド一覧を取得する手段を有し、メモリに配置されたVirtual Address Tableのうち、何れのメソッドをログ取得ルーチンにリダイレクトするかの設定を、エクスポートするインターフェース及びメソッド一覧から選択する手段を有する、ソフトウェア評価システム。
【請求項１１】
上記ソフトウェア評価システムにおいて、各モジュールのエクスポートする関数一覧、もしくは各COMサーバのエクスポートするインターフェース及びメソッド一覧をファイル形式で供給する手段を有し、そのファイル内に、エクスポートされたそれぞれの関数/メソッドにおけるパラメータ及び戻り値の定義を記述する手段を有し、その定義ファイルから、何れのモジュールの、何れの関数/メソッドの、何れのパラメータ、あるいは何れの戻り値をログ取得ルーチンにより記録するかの設定を、選択する手段を有する、ソフトウェア評価システム。
【請求項１２】
上記ソフトウェア評価システムにおいて、何れのモジュールの、何れの関数/メソッドの、何れのパラメータ、あるいは何れの戻り値をログ取得ルーチンにより記録するかの設定を、ファイルとして保存する手段を有し、そのファイルを読み込む手段を有し、エクスポートする関数一覧、もしくは各COMサーバのエクスポートするインターフェース及びメソッド一覧として供給されたファイルを読み込む手段を有し、その2つのファイルに示された情報を以って、インポート関数アドレステーブル、もしくはVirtual Address Tableの何れのアドレスを、ログ取得のためのルーチンがロードされたメモリアドレスに書き換えるか選択する手段を有する、ソフトウェア評価システム。
【請求項１３】
上記ソフトウェア評価システムにおいて、関数/メソッドがプリンタ装置への出力能力を有するか否かを定義する手段を有し、定義されたプリンタ装置への出力能力を有する関数/メソッドのパラメータとして得られる出力属性を保持する構造体/オブジェクト/描画オブジェクト群へのハンドルを読み出す手段を有する、ソフトウェア評価システム。
【請求項１４】
請求項１３のソフトウェア評価システムにおいて、プリンタ装置への出力能力を有する関数/メソッドが、出力属性を保持する構造体メンバのうちいずれのメンバを使用することでプリンタ装置へカラー指定出力する能力を持つかの関連をグループ化して定義する手段を有する、ソフトウェア評価システム。
【請求項１５】
請求項１４の評価システムにおいて、出力属性を保持する構造体のハンドルから、カラー指定能力を持つメンバを読み出す手段を有し、そのメンバが持つデータ内容からそれぞれの色要素に分解して取得する手段を有し、それぞれの色要素の強さを数値として取得する手段を有し、各色要素の強さの数値を比較する手段を有し、各色要素の強さの数値を比較するに際して、プリンタ装置へのカラー指定能力を持つ出力属性のデータ内容が有彩色であるのか否かを判別する手段を有し、有彩色であると判別したことを以って、カラー指定能力を持つ出力属性のデータ・ログを明示するためのキーをデータ・ログのファイルに保存する手段を有する、ソフトウェア評価システム。
【請求項１６】
請求項１３のソフトウェア評価システムにおいて、プリンタ装置への出力能力を有する関数/メソッドが、描画オブジェクトに存在する属性値/メソッドのうちいずれの属性値/メソッドを使用することでプリンタ装置へカラー指定出力する能力を持つかの関連をグループ化して定義する手段を有する、ソフトウェア評価システム。
【請求項１７】
請求項１６のソフトウェア評価システムにおいて、出力属性を保持するオブジェクトへのハンドルから、描画オブジェクトを読み出す手段を有し、その描画オブジェクトからカラー指定能力を持つ属性値を読み出す手段を有し、その描画オブジェクトからカラー指定能力を持つメソッドを呼び出す手段を有し、その属性値/メソッドから得られる出力属性のデータ内容からそれぞれの色要素に分解して取得する手段を有し、それぞれの色要素の強さを数値として取得する手段を有し、各色要素の強さの数値を比較する手段を有し、各色要素の強さの数値を比較するに際して、プリンタ装置へのカラー指定能力を持つ出力属性のデータ内容が有彩色であるのか否かを判別する手段を有し、有彩色であると判別したことを以って、カラー指定能力を持つ出力属性のデータ・ログを明示するためのキーをデータ・ログのファイルに保存する手段を有する、ソフトウェア評価システム。
【請求項１８】
請求項１３のソフトウェア評価システムにおいて、プリンタ装置への出力能力を有する関数/メソッドが、存在する描画オブジェクト群のうちいずれの描画オブジェクトを使用することでプリンタ装置へカラー指定出力する能力を持つかの関連をグループ化して定義する手段を有する、ソフトウェア評価システム。
【請求項１９】
請求項１８のソフトウェア評価システムにおいて、出力属性を保持するオブジェクトへのハンドルから、描画オブジェクト群を読み出す手段を有し、各描画オブジェクトからカラー指定能力を持つ属性値を読み出す手段を有し、各描画オブジェクトからカラー指定能力を持つメソッドを呼び出す手段を有し、それぞれの属性値/メソッドから得られる出力属性のデータ内容からそれぞれの色要素に分解して取得する手段を有し、それぞれの色要素の強さを数値として取得する手段を有し、各色要素の強さの数値を比較する手段を有し、各色要素の強さの数値を比較するに際して、プリンタ装置へのカラー指定能力を持つ出力属性のデータ内容が有彩色であるのか否かを判別する手段を有し、有彩色であると判別したことを以って、カラー指定能力を持つ出力属性のデータ・ログを明示するためのキーをデータ・ログのファイルに保存する手段を有する、ソフトウェア評価システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数にモジュール分けされたソフトウェアの動作確認、デバッグ及び評価において、モジュール自体に変更を加えることなく、モジュール内に用意された関数の呼び出しをログとして記録し、解析する手段を与えることで、ソフトウェアにおける再現率の低い障害の原因を特定し、開発の工数を削減する効果を与える。
【背景技術】
【０００２】
再現率の低いソフトウェアの障害に対しては、ソフトウェアの処理ログを取得することによって対処している場合が多いが、従来、処理ログの取得はソフトウェアのモジュール自体に手を加えて、処理ログ取得ルーチンを追加することによって行なわれている。プリンタ装置等の出力装置においても、例えば特定のカラーを意図して出力したデータに対して、出力結果が異なる、という障害が発生することがあるが、そういった障害の特定に際しても、モジュール自体に手を加えて、処理ログ取得ルーチンを追加し、ソフトウェアの各モジュールを通ったカラー・データのログをモジュール毎に取得して、それらを解析する、という手段が取られることが多い。
【特許文献１】特開２００２ー００７１０３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
上記従来の技術には8点の問題点がある。
【０００４】
１．ユーザの動作環境でもログを取得しつづけるためには、モジュール本体にログ取得用の変更が入ったものを使用する必要がある。
【０００５】
２．モジュール毎にログ取得を行なうため、生成されたログはモジュール単位の物となってしまい、ソフトウェア全体の処理を、完全に時間順のログとして取得するのが困難である。
【０００６】
３．全体の処理ログとしての見通しが悪いため、ログを解析して問題点を発見するまでのプロセスに工数がかかる。
【０００７】
４．カラー・データのすべてをログに保存すると、ログ取得に多大な時間がかかる。
【０００８】
５．カラー・データのすべてをログに保存すると、ログ・ファイルのサイズが膨大になる。
【０００９】
６．その結果、必要なデータを発見できず、あるいはすべて解析する時間が取れずに、障害の原因究明まで至らないことがある。
【００１０】
７．グラフィックライブラリのバージョンが異なる環境では、それぞれのバージョンに合わせたログ取得用モジュールを用意しなければならない。
【００１１】
８．ある描画データがカラーで描かれている可能性を調査するのは、ログ取得関数において多大な時間がかかる。
【課題を解決するための手段】
【００１２】
上記課題を解決するために、本発明においては、あるモジュールから別のモジュール内に存在する関数の呼び出しが行なわれる際の仕組みである、メモリに保持されたインポート関数アドレステーブル、もしくはvirtual address tableを利用して、モジュール間の関数呼び出しをフックし、モジュール名、関数名、インターフェース名、メソッド名、時刻、パラメータ、戻り値等をログに記録するという手段を持った、ログ記録の機能を設ける。また、関数定義ファイルに、カラー出力に関連する関数/メソッドを定義する手段を設け、カラー関連の障害に関わりのないログ記録を省く。また、カラー出力に関連する関数がどの描画オブジェクトを使用するかをグループ化して定義する手段を設け、拡張性を保持する。それらを使用することで、カラー出力に関連する障害の原因を迅速に特定することを可能とする。
【発明の効果】
【００１３】
本発明を施したソフトウェア評価システムを用いることで、ソフトウェアの問題点を解析する工数が削減される。特に、プリンタ装置にカラー出力を行なう際に、従来は取得が難しかった、アプリケーション・ソフトウェアとオペレーティングシステムとの間で描画コマンドがどのようにやり取りされているかの情報を、アプリケーション・ソフトウェア及びオペレーティングシステムのソースコード及びオブジェクトコードを、一切変更せずに取得する手段を提供し、拡張性を持たせることで、プリンタ装置のカラー出力に関連する障害の解決にかかる工数が削減される。
【発明を実施するための最良の形態】
【００１４】
＜実施形態１＞
図１は、本発明を施したソフトウェア評価システムの構成をあらわす図である。説明を簡略化するために、本実施例では、本ソフトウェア評価システムが1台のPC内部に構築されるものとするが、本発明の特徴は1台のPC内部に構築されるか、あるいは複数のPCにネットワークシステムとして構築されるかによらず有効である。
【００１５】
本ソフトウェア評価システムを搭載するコンピュータには、CPU1、チップセット2、RAM3、ハードディスクコントローラ4、ディスプレイコントローラ5、ハードディスクドライブ6、CD-ROMドライブ7、ディスプレイ8が搭載されている。また、CPUとチップセットを繋ぐ信号線11、チップセットとRAMを繋ぐ信号線12、チップセットと各種周辺機器とを繋ぐ周辺機器バス13、ハードディスクコントローラとハードディスクドライブを繋ぐ信号線14、ハードディスクコントローラとCD-ROMドライブを繋ぐ信号線15、ディスプレイコントローラとディスプレイを繋ぐ信号線16が搭載されている。
【００１６】
本発明を施したソフトウェア評価システムを説明するために、まず図２によって、複数のモジュールに分かれたソフトウェアが、通常の状態でどのようにメモリにロードされるかを説明する。
【００１７】
通常、複数のモジュールに分かれたソフトウェアは、全体の制御を行なう実行ファイルEXE(23)と、モジュールとして存在しEXEの補完的な役割を担うダイナミックリンクライブラリDLL(27)とに分かれており、メモリにはEXEとDLLの両方がロードされる。EXEはコードセグメント(28)とデータセグメント(29)、そしてインポート関数アドレステーブル(22)から成っている。更に、インポート関数アドレステーブルは、関数の所属するDLLによって分かれており(21,24)、DLLごとにそれぞれの関数がロードされたアドレスが書かれている(30〜35)。DLLの関数の実体は、DLLごとに分かれて(25,26)ロードされ、それぞれの関数は該当するDLLの一部としてロードされる(36〜41)。この図では、1本のEXEがA.DLL及びB.DLLの2つのダイナミックリンクライブラリ内の関数を使用している例を示しており、実際に使用される関数はFunc AA, Func AB, Func AC, Func BA, Func BB, Func BCの6個となっている。
【００１８】
EXEのコードセグメント内にあるコードが関数Func AAを呼び出す場合には、まずインポート関数アドレステーブル内に書かれたFunc AAのアドレス(30)が読み込まれる。ここには実際にはA.DLLの一部として読み込まれたFunc AAコード(36)のアドレスが書かれており、そのアドレスをコールすることによって、EXEのコードはA.DLLのFunc AAを呼び出すことができる。
【００１９】
図３は、本発明を施したソフトウェア評価システムのメモリ構成をあらわす図であり、図２とは、ログ取得用のコードに対してIAT Patch(Import Address Table Patch)という手法を用いて、関数呼び出しをリダイレクトしているという点で異なっている。
【００２０】
ログ取得が開始されると、メモリ内にはIAT Patch用のDLLであるC.DLL(58)がロードされる。C.DLLはインポート関数アドレステーブル(52)内に書かれた関数のアドレスを、C.DLL内のログ取得コードであるFunc CAA, Func CAB, Func CAC, Func CBA, Func CBB, Func CBCのアドレスに書き換える(61〜66)。C.DLL内のFunc CAA, Func CAB, Func CAC, Func CBA, Func CBB, Func CBCのコード(73〜78)は、ログを記録すると共に、元々関数呼び出しを受けるべくメモリにロードされている、該当する関数であるFunc AA, Func AB, Func AC, Func BA, Func BB, Func BC(67〜72)を呼び出す。
【００２１】
図４は、図３におけるIAT Patchの処理をあらわすタイミングチャートである。説明を簡略化するために、この図ではEXEがA.DLL内のFunc AAを呼び出す際に、IAT Patchによるログ取得コードがどのように動作するかの例をあらわしている。
【００２２】
EXE(91)がFunc AAをコールすると(94)、C.DLL内にあるログ取得コードがDLL名/関数名をメモリに保存し、呼び出し時刻をメモリに保存し、呼び出し時のパラメータをメモリに保存し、呼び出し時のポインタ・パラメータの指すメモリ内容を、メモリに保存する(95)。その後C.DLLは本来呼び出されるはずであった、A.DLL(93)内のFunc AAをコールする(96)。A.DLLのFunc AA処理(97)が終了し、C.DLLに制御がリターンすると(98)、C.DLLはリターン時の時刻をメモリに保存し、戻り値をメモリに保存し、リターン時にポインタ・パラメータが指すメモリ内容を、メモリに保存する(99)。その後、C.DLLは保存したログ情報をファイルに書き込み(100)、あたかもA.DLLのFunc AAが通常通りに終了したかのように、EXEにリターンする(101)。
【００２３】
図５は、本発明を施したソフトウェア評価システムの内部構成をあらわす図である。通常は実行形式のEXE(113)が、DLL-1(116)やDLL-2(117)内の関数を呼び出すが、ここではAPIトレーサと呼ばれるログ取得コードを埋め込み(114)、処理ログを生成している(115)。APIトレーサは、DLL-1やDLL-2の関数定義を記述したファイル(111)と、どのDLLのどの関数のインポート関数テーブルを書き換えてログを取得するかの設定シナリオ(112)を元に動作する。
【００２４】
図６は、本発明を施したソフトウェア評価システムにおいて、通常、実行ファイルEXE(118)がCOMサーバでエクスポートされているインターフェースのインスタンス作成時に、通常の状態でどのようにメモリにロードされるかを説明する。
【００２５】
通常、インターフェースのインスタンス作成を行なうと、COMサーバ内で、要求されたインターフェース(121,122)と、そのメソッド(130〜135)が作成され、それらは、メモリ上に両方がロードされる。ここで、virtual address tableは作成された各インターフェース毎に作られ(118,120)、作成要求を行ったEXEに渡される。このvirtual address tableには各メソッドの作成されたアドレスが書かれている(124〜129)。EXEはこれら情報を利用し、各インターフェースに対して呼び出しを行なう。この図では、1本のEXEがInterface A及びInterface Bの2つのインターフェースのインスタンスを作成しており、そのインターフェース内部のメソッドを使用している例を示しており、実際に使用されているメソッドは、Method AA, Method AB, Method AC, Method BA, Method BB, Method BCとなっている。
【００２６】
EXEのコードが関数Method AAを呼び出す場合には、まずvirtual address table内に書かれたMethod AAのアドレス(124)が読み込まれる。ここには実際にはCOMサーバのInterface Aの一部として作成されたMethod AAコード(130)のアドレスが書かれており、そのアドレスをコールすることによって、EXEのコードはInterface AのMethod AAを呼び出すことができる。
【００２７】
図７は、本発明を施したソフトウェア評価システムのメモリ構成をあらわす図であり、図６とは、ログ取得用のコードに対してVTable Patch(virtual address table Patch)という手法を用いて、メソッド呼び出しをリダイレクトしているという点で異なっている。
【００２８】
ログ取得が開始されると、メモリ内にはVTable Patch用のDLL(143)がロードされる。このDLLはvirtual address table(136, 138)内に書かれたメソッドのアドレスを、DLL内のログ取得コードであるMethod A'A, Method A'B, Method A'C, Method B'A, Method B'B, Method B'Cのアドレスに書き換える(145〜150)。DLL内のMethod A'A, Method A'B, Method A'C, Method B'A, Method B'B, Method B'Cのコード(157〜162)は、ログを記録すると共に、元々のメソッド呼び出しを受けるべくメモリにロードされている、該当するメソッドであるMethod AA, Method AB, Method AC, Method BA, Method BB, Method BC(157〜162)を呼び出す。
【００２９】
図８は、図７におけるVTable Patchの処理をあらわすタイミングチャートである。説明を簡略化するために、この図ではEXEがCOMサーバ内のInterface AのMethod AAを呼び出す際に、VTable Patchによるログ取得コードがどのように動作するかの例をあらわしている。
【００３０】
EXE(163)がMethod AAをコールすると(166)、DLL内にあるログ取得コードがモジュール名/インターフェース名/メソッド名をメモリに保存し、呼び出し時刻をメモリに保存し、呼び出し時のパラメータをメモリに保存し、呼び出し時のポインタ・パラメータの指すメモリ内容を、メモリに保存する(167)。その後DLLは本来呼び出されるはずであった、COMサーバ(165)内のMethod AAをコールする(168)。COMサーバのMethod AA処理(169)が終了し、DLLに制御がリターンすると(170)、DLLはリターン時の時刻をメモリに保存し、戻り値をメモリに保存し、リターン時にポインタ・パラメータが指すメモリ内容を、メモリに保存する(171)。その後、DLLは保存したログ情報をファイルに書き込み(172)、あたかもCOMサーバのMethod AAが通常通りに終了したかのように、EXEにリターンする(173)。
【００３１】
図９は、本発明を施したソフトウェア評価システムの内部構成をあらわす図である。通常は実行形式のEXE(176)が、COMサーバ-1(179)やCOMサーバ-2(180)内のメソッドを呼び出すが、ここではAPIトレーサと呼ばれるログ取得コードを埋め込み(177)、処理ログを生成している(178)。APIトレーサは、COMサーバ-1(179)やCOMサーバ-2の関数定義を記述したファイル(174)と、どのCOMサーバのどのインターフェースのどのメソッドのvirtual address tableを書き換えてログを取得するかの設定シナリオ(175)を元に動作する。
【００３２】
図１０は、本発明を施したソフトウェア評価システムの関数定義の一例であり、一般的に広く用いられているIDLにより、記述されている。本発明を施したソフトウェア評価システムに於いては、このIDLをトークン化したタイプライブラリファイルを関数定義ファイルとして使用する。なお、本発明は付加バイナリ情報取得のための定義手段を提供することを特徴とするものであり、関数定義はIDLでなくても構わない。例えば、通常のテキストファイルを用いることも可能であり、XMLなどのマークアップ言語を用いることも可能である。
【００３３】
図１１は、本発明を施したソフトウェア評価システムに於いて、プリンタ出力データのカラー判別を行なうための、関数定義ファイルの例である。
【００３４】
本実施例では、オペレーティングシステムにOSGraphicKernel.dllというダイナミックリンクライブラリファイルが用意されており、そのライブラリ内に、矩形描画を行なうためのRectangle関数(201)が用意されている。Rectangle関数の第一パラメータはデバイスコンテキスト(202)、すなわちオペレーティングシステムによって仮想化された「面」に対するハンドルである。デバイスコンテキストにはディスプレイ向けのものとプリンタ向けのものが用意されており、Rectangle関数の第一パラメータでプリンタ向けのハンドルを選択して、その他のパラメータを入力することにより、プリンタ装置に対して矩形の描画コマンドが発行される。同様に楕円描画のEllipse関数(203)には第一パラメータとしてデバイスコンテキスト(204)が、文字描画のText関数(205)には第二パラメータとしてデバイスコンテキスト(206)が渡される。
【００３５】
図１２は、本発明を施したソフトウェア評価システムに適用される、アプリケーション・ソフトウェアがプリンタ出力データを作成する例である。
【００３６】
この例を用いて、描画を行なう際にどのようにカラーの設定を行なうかを説明する。
【００３７】
アプリケーション・ソフトウェアでは、まずプリンタ出力へのデバイスコンテキスト得て(211)、ライブラリが固定で用意してあるライトグレイのブラシオブジェクトを取り出し(212)、そのブラシオブジェクトをデバイスコンテキストに渡す(213)。
【００３８】
また、赤いソリッドなペンオブジェクトを作成し(215)、デバイスコンテキストに渡す(215)。これらのオブジェクトへの関係を持つデバイスコンテキストを用いて矩形描画を行なう(214)。
【００３９】
また、211で得られたのと同じデバイスコンテキストに対し、背景のカラーを赤に設定し(217)、背景のモードを透明に設定して(218)、文字列を描画する(219)。
【００４０】
このように、デバイスコンテキストやブラシオブジェクトに対してカラーを設定しておいて、描画処理を行なう、という処理はごく一般的であり、RectangleやTextの描画処理関数そのものにカラーの属性をパラメータで渡すことはあまり行なわれない。
【００４１】
図１３は、本発明を施したソフトウェア評価システムに於いて、プリンタ出力データのカラー判別を行なう際に用いられる、定義テーブルの例である。ブラシオブジェクトに使われているカラーをチェックするローカル関数221、ペンオブジェクトに使われているカラーをチェックするローカル関数222、フォントカオブジェクトに使われているカラーをチェックするローカル関数223等が用意されている。
【００４２】
F2ColorCheckTableテーブル(224)はカラー属性を描画する可能性のある描画コマンドを発行する関数ごとに、どのカラーチェック用のローカル関数を使用してチェックすべきかを定義しているテーブルである。例えばRectangleであれば、ブラシオブジェクトチェックの関数221のアドレス、ペンオブジェクトチェックの関数222のアドレスをテーブルに持つ(225)。同様にEllipseであれば226, Textであれば227が定義されている。
【００４３】
図１４は、本発明を施したソフトウェア評価システムに於いて、IAT Patch及びVTable Patchを用いて、プリンタ装置に対応するデバイスコンテキストに対してアプリケーション・ソフトウェアが描画コマンドを発行する際に、その描画された色を判別する処理をあらわす流れ図である。
【００４４】
処理が開始されると(S1)、ログ取得を開始し、モジュール名、インターフェース名、関数/メソッド名をHDDに保存する(S2)。次にログ取得コードは、呼び出し時の時刻、パラメータ及びポインタ・パラメータの指すメモリの内容をHDDに保存する(S3)。次に、関数がカラーを描画する可能性のある関数であるかを判別し(S4)、もしカラー描画する可能性のある関数であれば、その関数のパラメータであるデバイスコンテキストから、カラー属性が実際に設定されているかどうかを調べる(S5)。その後、元の関数を呼び出し(S6)、関数からリターンすると、ログ取得コードはリターン時の時刻、戻り値及びポインタ・パラメータの指すメモリの内容をHDDに保存する(S7)。この処理はユーザから終了の命令があると(S8)終了する(S9)。
【００４５】
S4においてカラーを描画する設定でない場合、やはり元の関数を呼び出し(S10)、ユーザから終了の命令があると終了する(S9)。
【００４６】
この矩形描画の例では、S4においてRectangleが呼ばれた際に、S5でカラー属性の設定を調べ、元の関数を呼び出し、リターン時の時刻、戻り値、ポインタ・パラメータの指すメモリ内容をHDDに保存する。
【００４７】
図１５は、本発明を施したソフトウェア評価システムに於いて、カラーを描画する関数で実際にカラーの属性が設定されているかをチェックする流れ図である。図１４のS5をより詳細に記述したものである。
【００４８】
処理が開始されると(S11)、描画関数にパラメータとして渡されるデバイスコンテキストのハンドルから、デバイスコンテキストを得る(S12)。また、呼ばれた関数アドレスを元に、チェック関数定義テーブルF2ColorCheckTable 224を用いて、該当する関数の定義テーブルを見つける(S13)。
【００４９】
ループのインデクスiを1にして(S14)ループに入る。もし定義テーブルにi番目の要素があれば、i番目のオブジェクトチェック用のローカル関数を用いて、チェックを行なう(S16)。さらにインデクスiをインクリメントして(S17)、要素がなくなるまでループして、終了する(S18)。
【００５０】
図１６は、本発明を施したソフトウェア評価システムに於いて、各オブジェクト毎にカラー属性が設定されているかをチェックする流れ図である。図１５のS16をより詳細に記述したものである。
【００５１】
処理が開始されると(S21)、まずそのオブジェクトに対してチェック用ローカル関数のアドレスが定義されているかを調べ(S22)、もしNULLであれば終了する(S27)。
【００５２】
定義されていればそのチェック用関数を呼び(S23)、チェック用関数カラー属性を得て、Red値/Green値/Blue値に変換する(S24)。もしこれで有彩色であれば、チェックしたオブジェクトの名称と、変換したRed値/Green値/Blue値をHDに保存して(S26)、終了する。有彩色でなければ何もせず終了する。
【００５３】
図１７は、本発明を施したソフトウェア評価システムに於いて、複数存在するチェック用のローカル関数の一つの例である、ブラシオブジェクト用チェック関数の流れ図である。
【００５４】
処理が開始されると(S31)、いま処理している描画関数に渡されたデバイスコンテキストを得て(S32)、ブラシオブジェクトが使われているかを調べる(S33)。もし使っていなければ何もせず終了し(S36)、使っていればブラシオブジェクトを得る(S34)。ブラシオブジェクトからカラーの属性、例えばCMYK、Lab等の形式とその値を取得して返り値として上位に返し(S35)、終了する。
【００５５】
図１８は、本発明を施したソフトウェア評価システムにおいて、図１０、図１１、図１２、図１３の定義及び図１４、図１５、図１６、図１７の処理により取得されたログデータの図である。Rectangle関数の呼出に関しては、いずれのオブジェクトでもカラーは検知できなかったため、カラー属性は何もかかれておらず(231)、文字描画関数の際にはデバイスコンテキストに対して指定されていた背景色の情報が、別途カラー情報フィールドとして保存されている(232)。
【００５６】
図１９は、本発明を施したソフトウェア評価システムにおいて、ライブラリのバージョンアップに伴い、カラー描画用の関数EllipseArcが増えた場合の対応例である。EllipseArcは開図形であるので、ブラシを使った塗りは行なわれないが、輪郭線がカラーで塗られるため、checkPenColor関数へのアドレスを定義テーブルに用意すればよいことがわかる(228)。その他のテーブルや処理に一切手を入れる必要はない。
【００５７】
このように、IAT Patch及びVTable Patchを用いてカラー出力を検出することにより、プリンタ装置等へのカラー出力において発生した障害に対して、アプリケーション・ソフトウェアがオペレーティングシステムに対してどのような指示を行なった結果その障害が発生したのかを、明示的に知ることができる。また、カラー出力機能を持つ関数に対応するログ・レコードに対してのみ、カラー情報フィールドを含むようなログを生成することで、その後にカラー関連の処理のみを抽出することを容易なものとしている。このことは、カラー関連の障害の原因を特定する際に、より迅速な作業が可能であることを意味している。
【００５８】
またこのような仕組みを準備することで、例えばOSやグラフィックライブラリのバージョンが新しくなり、EllipseArc関数が追加になったような場合でも、評価システムの処理ロジックを変更することなく、定義テーブルの修正もしくは追加の作業だけで対応することが可能なことを意味する。
【００５９】
例えばMicrosoft Windows（登録商標）のGDIのように、描画関数ごとにAPIの仕様が異なるが、類似した描画関数では使用する描画オブジェクトが同じ、といったケースでは特に有用である。
【００６０】
＜実施形態２＞
実施例２において、図１から図１２までは、同様なので説明を省略する。
【００６１】
図２０は、本発明を施したソフトウェア評価システムに於いて、プリンタ出力データのカラー判別を行なう際に用いられる、定義テーブルの例である。
【００６２】
描画する図形によって、使用される描画オブジェクトは決まってくるため、描画関数において参照されるオブジェクトも、同様な特性をもつ。この点に着目してグループ分けした定義テーブルを作ることができる。テーブル(241)は、描画関数の数だけ用意され、描画関数のアドレスと図形の特性のグループとの組(242)からなる。
【００６３】
図２１は、本発明を施したソフトウェア評価システムに於いて、図形の特性のグループとチェック用の関数の定義テーブルの例である。テーブル(251)は、図２１で定義された図形グループそれぞれに対し、描画オブジェクト毎のチェック用関数のアドレスを持つ。例えば開図形のグループ(252)であれば、checkBrushColor, checkPenColor, ...のアドレスを持つ。
【００６４】
同様に閉図形のグループ(253)、文字のグループ(254)等がテーブル251に含まれる。
【００６５】
以下、流れ図を用いて処理を説明する。
【００６６】
カラーログ取得全体は図１４と全く同様の処理なので説明を省略する。
【００６７】
図１４のS5においてカラー属性が設定されているかを調べる処理の詳細を、図２２を用いて説明する。
【００６８】
処理が開始されると(S41)、描画関数にパラメータとして渡されるデバイスコンテキストのハンドルから、デバイスコンテキストを得る(S42)。また、呼ばれた関数アドレスを元に、グループ定義テーブルF2GroupTable 241を用いて、該当するグループを見つける(S43)。
【００６９】
ループのインデクスiを1にして(S44)ループに入る。定義テーブルの該当グループ内のi番目を見て(S45)、もし要素があれば(S46)、i番目のオブジェクトチェック用のローカル関数を用いてチェックを行なう(S47)。
【００７０】
さらにインデクスiをインクリメントして(S48)、要素がなくなるまでループして、終了する(S49)。
【００７１】
図２２のS47におけるオブジェクトのカラーチェックの処理は、図１６、図１７と全く同様であるため説明を省略する。
【００７２】
また、図２０、図２１の定義及び図２２の処理により取得されたログデータは図１８と同様である。
【００７３】
図２３は、本発明を施したソフトウェア評価システムにおいて、ライブラリのバージョンアップに伴い、カラー描画用の関数EllipseArcが増えた場合の対応例である。EllipseArcは開図形であるので、単に開図形を定義するOpenFigureとの組をテーブルに追加すればよい(243)。その他のテーブルや処理に一切手を入れる必要はなく、チェック処理は自動的に行なわれる。
【００７４】
このように、IAT Patch及びVTable Patchを用いてカラー出力を検出することにより、プリンタ装置等へのカラー出力において発生した障害に対して、アプリケーション・ソフトウェアがオペレーティングシステムに対してどのような指示を行なった結果その障害が発生したのかを、明示的に知ることができる。また、カラー出力機能を持つ関数に対応するログ・レコードに対してのみ、カラー情報フィールドを含むようなログを生成することで、その後にカラー関連の処理のみを抽出することを容易なものとしている。このことは、カラー関連の障害の原因を特定する際に、より迅速な作業が可能であることを意味している。
【００７５】
またこのような仕組みを準備することで、例えばOSやグラフィックライブラリのバージョンが新しくなり、EllipseArc関数が追加になったような場合でも、評価システムの処理ロジックを変更することなく、定義テーブルの追加の作業だけで対応することが可能なことを意味する。
【００７６】
例えばMicrosoft Windows（登録商標）のGDIのように、描画関数ごとにAPIの仕様が異なるが、使用する複数の描画オブジェクトが同じであるような描画関数のグループ分けが可能、といったケースでは特に有用である。
【図面の簡単な説明】
【００７７】
【図１】実施例１におけるソフトウェア評価システムを搭載した、コンピュータの構成をあらわす図である。
【図２】実施例１を説明するためにあらわした、関数ロード時の通常のメモリ構成をあらわす図である。
【図３】実施例１におけるソフトウェア評価システムを搭載した、コンピュータのIAT Patch使用時のメモリ構成をあらわす図である。
【図４】実施例１におけるソフトウェア評価システムのIAT Patchを使用時のタイミングチャートである。
【図５】実施例1におけるソフトウェア評価システムのIAT Patchを使用時の内部構成をあらわす図である。
【図６】実施例１を説明するためにあらわした、COMサーバのインターフェースのインスタンス作成時の通常のメモリ構成をあらわす図である。
【図７】実施例１におけるソフトウェア評価システムを搭載した、コンピュータのVTable Patch使用時のメモリ構成をあらわす図である。
【図８】実施例１におけるソフトウェア評価システムのVTable Patchを使用時のタイミングチャートである。
【図９】実施例１におけるソフトウェア評価システムのVTable Patchを使用時の内部構成をあらわす図である。
【図１０】実施例１におけるソフトウェア評価システムの関数定義ファイルの例をあらわす図である。
【図１１】実施例１におけるソフトウェア評価システムの関数定義ファイルの例をあらわす図である。
【図１２】実施例１におけるソフトウェア評価システムを用いるプリンタに出力するアプリケーション・ソフトウェアの例である。
【図１３】実施例１におけるソフトウェア評価システムの描画関数とチェック関数の定義テーブルの図である。
【図１４】実施例１におけるソフトウェア評価システムのカラーログ保存処理の流れ図である。
【図１５】実施例１におけるソフトウェア評価システムのカラー属性が設定されているかをチェックする処理の流れ図である。
【図１６】実施例１におけるソフトウェア評価システムのオブジェクトごとのカラー属性のチェック処理の流れ図である。
【図１７】実施例１におけるソフトウェア評価システムのブラシオブジェクトのカラーチェック処理の流れ図である。
【図１８】実施例１におけるソフトウェア評価システムのログデータの図である。
【図１９】実施例１におけるソフトウェア評価システムの定義テーブルへの新規描画関数追加の図である。
【図２０】実施例２におけるソフトウェア評価システムの描画関数と図形グループの定義テーブルの図である。
【図２１】実施例２におけるソフトウェア評価システムの図形グループとチェック関数の定義テーブルの図である。
【図２２】実施例２におけるソフトウェア評価システムのカラー属性が設定されているかをチェックする処理の流れ図である。
【図２３】実施例２におけるソフトウェア評価システムの描画関数と図形グループの定義テーブルへの新規描画関数追加の図である。
【符号の説明】
【００７８】
１  ＣＰＵ
２  チップセット
３  RAM
４  ハードディスクコントローラ
５  ディスプレイコントローラ
６  ハードディスクドライブ
７  CD-ROMドライブ
８  ディスプレイ
１１  CPUとチップセットを繋ぐ信号線
１２  チップセットとRAMを繋ぐ信号線
１３  チップセットと各種周辺機器とを繋ぐ周辺機器バス
１４  ハードディスクコントローラとハードディスクドライブを繋ぐ信号線
１５  ハードディスクコントローラとCD-ROMドライブを繋ぐ信号線
１６  ディスプレイコントローラとディスプレイを繋ぐ信号線
【図１】
2006040021.tif 000003
【図２】
2006040021.tif 000004
【図３】
2006040021.tif 000005
【図４】
2006040021.tif 000006
【図５】
2006040021.tif 000007
【図６】
2006040021.tif 000008
【図７】
2006040021.tif 000009
【図８】
2006040021.tif 000010
【図９】
2006040021.tif 000011
【図１０】
2006040021.tif 000012
【図１１】
2006040021.tif 000013
【図１２】
2006040021.tif 000014
【図１３】
2006040021.tif 000015
【図１４】
2006040021.tif 000016
【図１５】
2006040021.tif 000017
【図１６】
2006040021.tif 000018
【図１７】
2006040021.tif 000019
【図１８】
2006040021.tif 000020
【図１９】
2006040021.tif 000021
【図２０】
2006040021.tif 000022
【図２１】
2006040021.tif 000023
【図２２】
2006040021.tif 000024
【図２３】
2006040021.tif 000025