(57)【要約】【課題】ソフトウェアの処理ログを容易に取得でき、かつ、バグの解析のための工数を削減することが可能なログ取得方法を提供する。【解決手段】関数（ＦｕｎｃＡＡ）を備えるプログラム９１において、実行中のログを取得するログ取得方法であって、ロードされた関数（ＦｕｎｃＡＡ）のアドレスを、ログ取得のための関数（９２）のアドレスに書き換える工程を備え、ログ取得のための関数（９２）は、関数（ＦｕｎｃＡＡ）のアドレスを呼び出し（９６）、該所定の処理を実行させ（９７）、受け取った実行結果（９８）をプログラム９１に受け渡す工程（１０１）と、関数（ＦｕｎｃＡＡ）のアドレスを呼び出す際の所定の情報を記録する工程（９５、１００））と、前記実行結果を受け取った際の所定の情報を記録する工程（９９、１００）とを備える。【選択図】　図４Ａ
2004038311.tif 000002
【特許請求の範囲】
【請求項１】
所定の処理を行う関数を備えるプログラムの実行中のログを取得するログ取得方法であって、
ロードされた前記所定の処理を行う関数のアドレスを、ログ取得のための関数のアドレスに書き換える工程を備え、
前記ログ取得のための関数は、
前記所定の処理を行う関数を呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記所定の処理を行う関数を呼び出す際の所定の情報を記録する工程と、
前記実行結果を受け取った際の所定の情報を記録する工程と
を備えることを特徴とするログ取得方法。
【請求項２】
前記所定の処理を行う関数を呼び出す際の所定の情報は、少なくとも、呼び出された関数の関数名、呼び出す際の時刻、呼び出す際のパラメータ、または呼び出す際のポインタ・パラメータの指すメモリ内容のいずれかを備えることを特徴とする請求項１に記載のログ取得方法。
【請求項３】
前記実行結果を受け取った際の所定の情報は、少なくとも、受け取った際の時刻、受け取った際のパラメータ、受け取った際の戻り値、または受け取った際のポインタ・パラメータの指すメモリ内容のいずれかを備えることを特徴とする請求項１に記載のログ取得方法。
【請求項４】
前記所定の処理を行う関数のアドレスは、該関数を提供するダイナミックリンクライブラリごとに、インポート関数アドレステーブルに記載されていることを特徴とする請求項１に記載のログ取得方法。
【請求項５】
前記所定の処理を行う関数のアドレスのうち、前記ログ取得のための関数のアドレスに書き換えるアドレスを選択する工程を更に備え、
前記書き換える工程は、前記選択する工程により選択された関数のアドレスを書き換えることを特徴とする請求項１に記載のログ取得方法。
【請求項６】
所定の処理を行うメソッドを備えるプログラムの実行中のログを取得するログ取得方法であって、
ロードされた前記所定の処理を行うメソッドのアドレスを、ログ取得のためのメソッドのアドレスに書き換える工程を備え、
前記ログ取得のためのメソッドは、
前記所定の処理を行うメソッドを呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記所定の処理を行うメソッドを呼び出す際の所定の情報を記録する工程と、
前記実行結果を受け取った際の所定の情報を記録する工程と
を備えることを特徴とするログ取得方法。
【請求項７】
前記所定の処理を行うメソッドを呼び出す際の所定の情報は、少なくとも、呼び出されたメソッドのメソッド名、呼び出す際の時刻、呼び出す際のパラメータ、または呼び出す際のポインタ・パラメータの指すメモリ内容のいずれかを備えることを特徴とする請求項６に記載のログ取得方法。
【請求項８】
前記実行結果を受け取った際の所定の情報は、少なくとも、受け取った際の時刻、受け取った際のパラメータ、受け取った際の戻り値、または受け取った際のポインタ・パラメータの指すメモリ内容のいずれかを備えることを特徴とする請求項６に記載のログ取得方法。
【請求項９】
前記所定の処理を行うメソッドのアドレスは、該メソッドを提供するインターフェースごとに、仮想アドレステーブルに記載されていることを特徴とする請求項６に記載のログ取得方法。
【請求項１０】
前記所定の処理を行うメソッドのアドレスのうち、前記ログ取得のためのメソッドのアドレスに書き換えるアドレスを選択する工程を更に備え、
前記書き換える工程は、前記選択する工程により選択されたメソッドのアドレスを書き換えることを特徴とする請求項６に記載のログ取得方法。
【請求項１１】
前記仮想アドレステーブル内のプレースギャップの有無を検知し、該プレースギャップがあった場合、該プレースギャップのオフセットをオペレーティングシステムから取得する工程を更に備え、
前記書き換える工程は、該取得する工程により取得されたオフセットに基づいて、前記プレースギャップの領域を、前記ログ取得のためのメソッドのアドレスに書き換えないことを特徴とする請求項９に記載のログ取得方法。
【請求項１２】
請求項１乃至１１のいずれか１つに記載のログ取得方法をコンピュータによって実現させるための制御プログラムを格納した記憶媒体。
【請求項１３】
請求項１乃至１１のいずれか１つに記載のログ取得方法をコンピュータによって実現させるための制御プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、複数にモジュール分けされたソフトウェアの処理ログを取得するための技術に関するものである。
【０００２】
【従来の技術】
従来より、再現率の低いソフトウェアの障害に対しては、ソフトウェアの処理ログを取得し、当該処理ログを解析することによって、障害の原因をつきとめ、その対策を講じてきた。
【０００３】
【発明が解決しようとする課題】
しかし、上記従来の処理ログの取得には以下のような問題点がある。
（１）ユーザの動作環境でもログを取得しつづけるためには、ソフトウェアのモジュール自体に手を加え、処理ログ取得ルーチンを追加しなければならず、処理ログ取得のための作業負荷が大きかった。
（２）処理ログ取得はモジュール毎に行うため、生成されたログはモジュール単位のものとなってしまい、ソフトウェア全体の処理を、完全に時間順のログとして取得するのが困難である。このため、全体の処理ログとしての見通しが悪く、ログを解析して障害の原因を発見するまでのプロセスに工数がかかっていた。
【０００４】
本発明は、上記課題を鑑みてなされたものであり、複数にモジュール分けされたソフトウェアの処理ログを容易に取得でき、かつ、ソフトウェアの障害の原因の解析のための工数を削減することが可能なログ取得方法、ならびに該方法をコンピュータによって実現させるためのプログラム、および該プログラムを格納した記憶媒体を提供することを目的とする。
【０００５】
【課題を解決するための手段】
上記の目的を達成するために本発明に係るログ取得方法は以下のような構成を備える。即ち、
所定の処理を行う関数を備えるプログラムの実行中のログを取得するログ取得方法であって、
ロードされた前記所定の処理を行う関数のアドレスを、ログ取得のための関数のアドレスに書き換える工程を備え、
前記ログ取得のための関数は、
前記所定の処理を行う関数を呼び出し、該所定の処理を実行させ、受け取った実行結果を前記プログラムに渡す工程と、
前記所定の処理を行う関数を呼び出す際の所定の情報を記録する工程と、
前記実行結果を受け取った際の所定の情報を記録する工程とを備える。
【０００６】
【発明の実施の形態】
【第１の実施形態】
本実施形態は、あるモジュールから別のモジュール内に存在する関数の呼び出しが行われる際の仕組みである、メモリに保持されたインポート関数アドレス、または仮想関数アドレステーブル（Ｖｉｒｔｕａｌ　Ａｄｄｒｅｓｓ　Ｔａｂｌｅ）を利用して、モジュール間の関数呼び出しをフックしてログに記録することで、ソフトウェアのモジュール自体に手を加えることなく、ソフトウエア全体の処理を、時間順のログとして取得することを可能にするものである。以下に具体的に説明する。
【０００７】
＜システム構成＞
図１は、本発明の各実施形態にかかるログ取得方法を実現するコンピュータ（ソフトウェア評価システム）の構成をあらわす図である。説明を簡略化するために、本実施形態では、本ソフトウェア評価システムが１台のＰＣ内部に構築されるものとするが、本発明のログ取得方法の特徴は１台のＰＣ内部に構築されるか、あるいは複数のＰＣにネットワークシステムとして構築されるかによらず有効である。
【０００８】
本ソフトウェア評価システムを搭載するコンピュータには、ＣＰＵ１、チップセット２、ＲＡＭ３、ハードディスクコントローラ４、ディスプレイコントローラ５、ハードディスクドライブ６、ＣＤ−ＲＯＭドライブ７、ディスプレイ８が搭載されている。また、ＣＰＵとチップセットを繋ぐ信号線１１、チップセット２とＲＡＭ３とを繋ぐ信号線１２、チップセット２と各種周辺機器とを繋ぐ周辺機器バス１３、ハードディスクコントローラ４とハードディスクドライブ６とを繋ぐ信号線１４、ハードディスクコントローラ４とＣＤ−ＲＯＭドライブ７とを繋ぐ信号線１５、ディスプレイコントローラ５とディスプレイ８とを繋ぐ信号線１６が搭載されている。
【０００９】
＜関数処理に対する処理ログ取得＞
本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムを説明するために、まず図２によって、複数のモジュールに分かれたソフトウェアが、通常の状態でどのようにメモリにロードされるかを説明する。
【００１０】
通常、複数のモジュールに分かれたソフトウェアは、全体の制御を行う実行ファイルＥＸＥ（２３）と、モジュールとして存在しＥＸＥの補完的な役割を担うダイナミックリンクライブラリＤＬＬ（２７）とに分かれており、メモリにはＥＸＥとＤＬＬの両方がロードされる。ＥＸＥはコードセグメント（２８）とデータセグメント（２９）、そしてインポート関数アドレステーブル（２２）から成っている。更に、インポート関数アドレステーブルは、関数の所属するＤＬＬによって分かれており（２１，　２４）、ＤＬＬごとにそれぞれの関数がロードされたアドレスが書かれている（３０〜３５）。ＤＬＬの関数の実体は、ＤＬＬごとに分かれて（２５，　２６）ロードされ、それぞれの関数は該当するＤＬＬの一部としてロードされる（３６〜４１）。この図では、１本のＥＸＥがＡ．ＤＬＬ及びＢ．ＤＬＬの２つのダイナミックリンクライブラリ内の関数を使用している例を示しており、実際に使用される関数はＦｕｎｃ　ＡＡ，　Ｆｕｎｃ　ＡＢ，　Ｆｕｎｃ　ＡＣ，　Ｆｕｎｃ　ＢＡ，　Ｆｕｎｃ　ＢＢ，　Ｆｕｎｃ　ＢＣの６個となっている。
【００１１】
ＥＸＥのコードセグメント内にあるコードが関数Ｆｕｎｃ　ＡＡを呼び出す場合には、まずインポート関数アドレステーブル内に書かれたＦｕｎｃ　ＡＡのアドレス（３０）が読み込まれる。ここには実際にはＡ．ＤＬＬの一部として読み込まれたＦｕｎｃ　ＡＡコード（３６）のアドレスが書かれており、そのアドレスをコールすることによって、ＥＸＥのコードはＡ．ＤＬＬのＦｕｎｃ　ＡＡを呼び出すことができる。
【００１２】
図３は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのメモリ構成をあらわす図であり、図２とは、ログ取得用のコードに対してＩＡＴ　Ｐａｔｃｈ（Ｉｍｐｏｒｔ　Ａｄｄｒｅｓｓ　Ｔａｂｌｅ　Ｐａｔｃｈ）という手法を用いて、関数呼び出しをリダイレクトしているという点で異なっている。
【００１３】
ログ取得が開始されると、メモリ内にはＩＡＴ　Ｐａｔｃｈ用のＤＬＬであるＣ．ＤＬＬ（５８）がロードされる。Ｃ．ＤＬＬはインポート関数アドレステーブル（５２）内に書かれた関数のアドレスを、Ｃ．ＤＬＬ内のログ取得コードであるＦｕｎｃ　ＣＡＡ，　Ｆｕｎｃ　ＣＡＢ，　Ｆｕｎｃ　ＣＡＣ，　Ｆｕｎｃ　ＣＢＡ，Ｆｕｎｃ　ＣＢＢ，　Ｆｕｎｃ　ＣＢＣのアドレスに書き換える（６１〜６６）。Ｃ．ＤＬＬ内のＦｕｎｃ　ＣＡＡ，　Ｆｕｎｃ　ＣＡＢ，　Ｆｕｎｃ　ＣＡＣ，　Ｆｕｎｃ　ＣＢＡ，　Ｆｕｎｃ　ＣＢＢ，　Ｆｕｎｃ　ＣＢＣのコード（７３〜７８）は、ログを記録すると共に、元々の関数呼び出しを受けるべくメモリにロードされている、該当する関数であるＦｕｎｃ　ＡＡ，　Ｆｕｎｃ　ＡＢ，　Ｆｕｎｃ　ＡＣ，　Ｆｕｎｃ　ＢＡ，　Ｆｕｎｃ　ＢＢ，　Ｆｕｎｃ　ＢＣ（６７〜７２）を呼び出す。
【００１４】
図４Ａは、図３におけるＩＡＴ　Ｐａｔｃｈの処理をあらわす図、図４Ｂはログ取得処理の流れを示すフローチャートである。説明を簡略化するために、この図ではＥＸＥがＡ．ＤＬＬ内のＦｕｎｃ　ＡＡを呼び出す際に、ＩＡＴ　Ｐａｔｃｈによるログ取得コードがどのように動作するかの例をあらわしている。
【００１５】
ＥＸＥ（図４Ａの９１）がＦｕｎｃ　ＡＡをコールすると（図４Ａの９４）、Ｃ．ＤＬＬ内にあるログ取得コードがＤＬＬ名／関数名をメモリに保存し（図４ＢのステップＳ４０２）、呼び出し時刻をメモリに保存し、呼び出し時のパラメータをメモリに保存し、呼び出し時のポインタパラメータの指すメモリ内容を、別メモリに保存する（図４Ａの９５、図４ＢのステップＳ４０３）。その後Ｃ．ＤＬＬは本来呼び出されるはずであった、Ａ．ＤＬＬ（図４Ａの９３）内のＦｕｎｃ　ＡＡをコールする（図４Ａの９６、図４ＢのステップＳ４０４）。Ａ．ＤＬＬのＦｕｎｃ　ＡＡ処理（図４Ａの９７）が終了し、Ｃ．ＤＬＬに制御がリターンすると（図４Ａの９８）、Ｃ．ＤＬＬはリターン時の時刻をメモリに保存し、戻り値をメモリに保存し、リターン時にポインタパラメータが指すメモリ内容を、別メモリに保存する（図４Ａの９９）。その後、Ｃ．ＤＬＬは保存したログ情報をファイルに書き込み（図４Ａの１００、図４ＢのステップＳ４０５）、あたかもＡ．ＤＬＬのＦｕｎｃ　ＡＡが通常通りに終了したかのように、ＥＸＥにリターンする（１０１）。
【００１６】
図５は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの内部構成をあらわす図である。通常は実行形式のＥＸＥ（１１３）が、ＤＬＬ−１（１１６）やＤＬＬ−２（１１７）内の関数を呼び出すが、ここではＡＰＩトレーサと呼ばれるログ取得コードを埋め込み（１１４）、処理ログを生成している（１１５）。ＡＰＩトレーサは、ＤＬＬ−１やＤＬＬ−２の関数定義を記述したファイル（１１１）と、どのＤＬＬのどの関数のインポート関数テーブルを書き換えてログを取得するかの設定シナリオ（トレースシナリオ１１２）を元に動作する。
【００１７】
＜メソッド処理に対する処理ログ取得＞
次に、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおいて、実行ファイルＥＸＥ（１１８）がＣＯＭ（Ｃｏｍｐｏｎｅｎｔ　Ｏｂｊｅｃｔ　Ｍｏｄｅｌ）サーバでエクスポートされているインターフェースのインスタンス作成時に、どのようにメモリにロードされるかを説明するために、まず、図６によって、通常の状態でどのようにメモリにロードされるかを説明する。
【００１８】
通常、インターフェースのインスタンス作成を行うと、ＣＯＭサーバ内で、要求されたインターフェース（１２１，　１２２）と、そのメソッド（：オブジェクト指向プログラミングにおいて、オブジェクトの実行する手続きを記述したプログラム、１３０〜１３５）が作成され、それらは、メモリ上に両方がロードされる。ここで、ｖｉｒｔｕａｌ　ａｄｄｒｅｓｓ　ｔａｂｌｅ（仮想アドレステーブル）は作成された各インターフェース毎に作られ（１１８，　１２０）、作成要求を行ったＥＸＥに渡される。このｖｉｒｔｕａｌ　ａｄｄｒｅｓ　ｔａｂｌｅには各メソッドの作成されたアドレスが書かれている（１２４〜１２９）。ＥＸＥはこれら情報を利用し、各インターフェースに対して呼び出しを行う。この図では、１本のＥＸＥがＩｎｔｅｒｆａｃｅ　Ａ及びＩｎｔｅｒｆａｃｅ　Ｂの２つのインターフェースのインスタンスを作成しており、そのインターフェース内部のメソッドを使用している例を示しており、実際に使用されているメソッドは、Ｍｅｔｈｏｄ　ＡＡ，　Ｍｅｔｈｏｄ　ＡＢ，　Ｍｅｔｈｏｄ　ＡＣ，　Ｍｅｔｈｏｄ　ＢＡ，　Ｍｅｔｈｏｄ　ＢＢ，　Ｍｅｔｈｏｄ　ＢＣとなっている。
【００１９】
ＥＸＥのコードが関数Ｍｅｔｈｏｄ　ＡＡを呼び出す場合には、まずｖｉｒｔｕａｌ　ａｄｄｒｅｓｓ　ｔａｂｌｅ内に書かれたＭｅｔｈｏｄ　ＡＡのアドレス（１２４）が読み込まれる。ここには実際にはＣＯＭサーバのＩｎｔｅｒｆａｃｅ　Ａの一部として作成されたＭｅｔｈｏｄ　ＡＡコード（１３０）のアドレスが書かれており、そのアドレスをコールすることによって、ＥＸＥのコードはＩｎｔｅｒｆａｃｅ　ＡのＭｅｔｈｏｄ　ＡＡを呼び出すことができる。
【００２０】
図７は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのメモリ構成をあらわす図であり、図６とは、ログ取得用のコードに対してＶＴａｂｌｅ　Ｐａｔｃｈ（ｖｉｒｔｕａｌ　ａｄｄｒｅｓｓ　ｔａｂｌｅ　Ｐａｔｃｈ）という手法を用いて、メソッド呼び出しをリダイレクトしているという点で異なっている。
【００２１】
ログ取得が開始されると、メモリ内にはＶＴａｂｌｅ　Ｐａｔｃｈ用のＤＬＬ（１４３）がロードされる。このＤＬＬはｖｉｒｔｕａｌ　ａｄｄｒｅｓｓ　ｔａｂｌｅ（１３６，　１３８）内に書かれたメソッドのアドレスを、ＤＬＬ内のログ取得コードであるＭｅｔｈｏｄ　Ａ’Ａ，　Ｍｅｔｈｏｄ　Ａ’Ｂ，　ＭｅｔｈｏｄＡ’Ｃ，　Ｍｅｔｈｏｄ　Ｂ’Ａ，　Ｍｅｔｈｏｄ　Ｂ’Ｂ，　Ｍｅｔｈｏｄ　Ｂ’Ｃのアドレスに書き換える（１４５〜１５０）。ＤＬＬ内のＭｅｔｈｏｄ　Ａ’Ａ，Ｍｅｔｈｏｄ　Ａ’Ｂ，　Ｍｅｔｈｏｄ　Ａ’Ｃ，　Ｍｅｔｈｏｄ　Ｂ’Ａ，　Ｍｅｔｈｏｄ　Ｂ’Ｂ，　Ｍｅｔｈｏｄ　Ｂ’Ｃのコード（１５７〜１６２）は、ログを記録すると共に、元々のメソッド呼び出しを受けるべくメモリにロードされている、該当するメソッドであるＭｅｔｈｏｄ　ＡＡ，　Ｍｅｔｈｏｄ　ＡＢ，　Ｍｅｔｈｏｄ　ＡＣ，　Ｍｅｔｈｏｄ　ＢＡ，　Ｍｅｔｈｏｄ　ＢＢ，　Ｍｅｔｈｏｄ
ＢＣ（１５７〜１６２）を呼び出す。
【００２２】
図８Ａは、図７におけるＶＴａｂｌｅ　Ｐａｔｃｈの処理をあらわす図、図８Ｂはログ取得処理の流れを示すフローチャートである。説明を簡略化するために、この図ではＥＸＥがＣＯＭサーバ内のＩｎｔｅｒｆａｃｅ　ＡのＭｅｔｈｏｄＡＡを呼び出す際に、ＶＴａｂｌｅ　Ｐａｔｃｈによるログ取得コードがどのように動作するかの例をあらわしている。
【００２３】
ＥＸＥ（図８Ａの１６３）がＭｅｔｈｏｄ　ＡＡをコールすると（図８Ａの１６６）、ＤＬＬ内にあるログ取得コードがモジュール名／インターフェース名／メソッド名をメモリに保存し（図８ＢのステップＳ８０２）、呼び出し時刻をメモリに保存し、呼び出し時のパラメータをメモリに保存し、呼び出し時のポインタパラメータの指すメモリ内容を、別メモリに保存する（図８Ａの１６７、図８ＢのステップＳ８０３））。その後ＤＬＬは本来呼び出されるはずであった、ＣＯＭサーバ（図８Ａの１６５）内のＭｅｔｈｏｄ　ＡＡをコールする（図８Ａの１６８、図８ＢのステップＳ８０４））。ＣＯＭサーバのＭｅｔｈｏｄ　ＡＡ処理（図８Ａの１６９）が終了し、ＤＬＬに制御がリターンすると（図８Ａの１７０）、ＤＬＬはリターン時の時刻をメモリに保存し、戻り値をメモリに保存し、リターン時にポインタパラメータが指すメモリ内容を、別メモリに保存する（図８Ａの１７１）。その後、ＤＬＬは保存したログ情報をファイルに書き込み（図８Ａの１７２、図８ＢのステップＳ８０５）、あたかもＣＯＭサーバのＭｅｔｈｏｄ　ＡＡが通常通りに終了したかのように、ＥＸＥにリターンする（図８Ａの１７３）。
【００２４】
図９は、本発明の第１の実施形態にかかるソフトウェア評価システムの内部構成をあらわす図である。通常は実行形式のＥＸＥ（１７６）が、ＣＯＭサーバ１（１７９）やＣＯＭサーバ２（１８０）内のメソッドを呼び出すが、ここではＡＰＩトレーサと呼ばれるログ取得コードを埋め込み（１７７）、処理ログを生成している（１７８）。ＡＰＩトレーサは、ＣＯＭサーバ１（１７９）やＣＯＭサーバ２の関数定義を記述したファイル（１７４）と、どのＣＯＭサーバのどのインターフェースのどのメソッドのｖｉｒｔｕａｌ　ａｄｄｒｅｓｓ　ｔａｂｌｅを書き換えてログを取得するかの設定シナリオ（１７５）を元に動作する。
【００２５】
＜実施例＞
図１０は、本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、それぞれの関数及びメソッドのパラメータの形式や、戻り値の形式を指示する、関数定義ファイルの例を示す図である。ＤＬＬ／インターフェース名及び関数／メソッド名を記述し（「関数／メソッド」とは、「関数またはメソッド」の意、以下同じ）、その関数／メソッドに対する、パラメータ及び戻り値の型が示されている。本実施形態にかかるログ取得方法を実現するソフトウェア評価システムは、この関数定義ファイルによって指示された内容を元に、それぞれの関数／メソッドがどのようなパラメータ／戻り値を有しているかを判断し、その内容をログとして取得する。
【００２６】
図１１は、図１０に示した関数定義ファイルを用いて、本発明の実施形態にかかるソフトウェア評価システムで取得した、ログの一例を示す図である。それぞれの呼び出しに対して、関数／メソッドが呼び出された時刻、及びその際のパラメータ／戻り値が、ログとして生成される。
【００２７】
以上の説明から明らかなように、本実施形態にかかるログ取得方法によれば、複数にモジュール分けされたソフトウエアの処理ログの取得において、モジュール自体に変更を加えることなく、モジュール内に用意された関数／メソッドの呼び出しをログとして記録することが可能となり、処理ログ取得のための作業負荷を低減することが可能となる。また、生成されるログは、時間順のログとして取得することができ、ログの解析が容易となるため、ソフトウェアの障害の原因の解析のための工数を削減することが可能となる。
【００２８】
【第２の実施形態】
本実施形態では、さらにｖｉｒｔｕａｌ　ａｄｄｒｅｓｓ　ｔａｂｌｅにプレースギャップ（Ｐｌａｃｅ　Ｇａｐ）が存在する場合の処理について説明する。
【００２９】
図１２は、本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、ｖｉｒｔｕａｌ　ａｄｄｒｅｓｓ　ｔａｂｌｅの内部にプレースギャップが存在する場合に、インターフェースのインスタンス作成時にどのようにメモリにロードされるかの例である。図１２は、図６と関連付けながら説明する。図６の例と異なるのは、Ｍｅｔｈｏｄ　ＢＢとＭｅｔｈｏｄ　ＢＣに関する部分である。Ｉｎｔｅｒｆａｃｅ　Ｂに対するＶＴａｂｌｅ（２０３）には、Ｍｅｔｈｏｄ　ＢＢが置かれているべき部分に、プレースギャップと呼ばれるダミールーチンへのアドレス（２１１）が置かれており、このＩｎｔｅｒｆａｃｅ　Ｂを派生させてＭｅｔｈｏｄ　ＢＢを実装した際にも、ＶＴａｂｌｅ上のＭｅｔｈｏｄ　ＢＣへのアドレス（２１２）のオフセットが変わらないようになっている。すなわちプレースギャップとは、仮想関数を持つインターフェースに対して、派生クラスのために予約されたＶＴａｂｌｅ上のエリアを指す。派生前のＩｎｔｅｒｆａｃｅ　Ｂにおいては、Ｍｅｔｈｏｄ　ＢＢは実装されていないため、実際のコードはＭｅｔｈｏｄ　ＢＡとＭｅｔｈｏｄ　ＢＣの間にはギャップは存在しない（２１６、２１７）。
【００３０】
図１３は、本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、ｖｉｒｔｕａｌ　ａｄｄｒｅｓｓ　ｔａｂｌｅの内部にプレースギャップが存在する場合に、ログ取得コードがどのようなメモリ配置で置かれるかをあらわす図であり、本実施形態を最もよくあらわすものである。図１３は、図７と関連付けながら説明する。
【００３１】
ログ取得が開始されると、メモリ内にはＶＴａｂｌｅ　Ｐａｔｃｈ用のＤＬＬ（２２８）がロードされる。このＤＬＬはｖｉｒｔｕａｌ　ａｄｄｒｅｓｓ　ｔａｂｌｅ（２２１、２２３）内に書かれたメソッドのアドレスを、ＤＬＬ内のログ取得コードであるＭｅｔｈｏｄ　Ａ’Ａ，　Ｍｅｔｈｏｄ　Ａ’Ｂ，　Ｍｅｔｈｏｄ　Ａ’Ｃ，　Ｍｅｔｈｏｄ　Ｂ’Ａ，　Ｍｅｔｈｏｄ　Ｂ’Ｃのアドレスに書き換える（２３０〜２３３、２３５）。図７と異なるのは、プレースギャップ（２３４）を自動検知して、その部分に関しては書き換えを行わないことであり、更に、Ｍｅｔｈｏｄ　Ｂ’Ｂのコードがメモリ上に配置されないことである。ＤＬＬ内のＭｅｔｈｏｄ　Ａ’Ａ，　Ｍｅｔｈｏｄ　Ａ’Ｂ，　Ｍｅｔｈｏｄ　Ａ’Ｃ，　Ｍｅｔｈｏｄ　Ｂ’Ａ，　Ｍｅｔｈｏｄ　Ｂ’Ｃのコード（２４１〜２４５）は、ログを記録すると共に、元々のメソッド呼び出しを受けるべくメモリにロードされている、該当するメソッドであるＭｅｔｈｏｄ　ＡＡ，　Ｍｅｔｈｏｄ　ＡＢ，　Ｍｅｔｈｏｄ　ＡＣ，　Ｍｅｔｈｏｄ　ＢＡ，　Ｍｅｔｈｏｄ　ＢＣ（２３６〜２４０）を呼び出す。
【００３２】
図１４は、本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける、メモリロード時の処理の流れを示す図であり、図１３と共に、本実施形態の特徴を最もよくあらわすものである。
【００３３】
処理が開始されると（ステップＳ１）、自らがＩｎｄｅｘとして参照するメモリエリアをゼロに初期化する（ステップＳ２）。このＩｎｄｅｘは、関数定義ファイルに記載されているメソッドの順番をあらわすものである。次に、関数定義ファイルに書かれたＩｎｄｅｘ　ｎのメソッドの属性をオペレーティングシステムから読み込み（ステップＳ３）、属性情報からその関数が仮想関数であるかどうかを判断する（ステップＳ４）。仮想関数である場合、オペレーティングシステム（ＯＳ）から、Ｉｎｄｅｘ　ｎのメソッドに対するプレースギャップのオフセットｐを読み込み（ステップＳ５）、ｐが真の値であるかどうか、すなわちヌルポインタでないかどうかを判断する（ステップＳ６）。ここではｐが真の値かによって、プレースギャップが存在するかどうかを判断しているが、例えば０ｘＦＦＦＦＦＦＦＦといった規定値を「プレースギャップが存在しない」という意味と定義しているオペレーティングシステムに対しては、同様に０ｘＦＦＦＦＦＦＦＦかどうかの判断を行う。
【００３４】
プレースギャップが存在しない場合、もしくはステップＳ４で仮想関数でないと判断した場合には、ログ取得コードを図７のように生成する。具体的には、メモリ上にログ取得コードを置き（ステップＳ７）、オペレーティングシステムからＩｎｄｅｘ　ｎのメソッドに対するＶＴａｂｌｅ上のオフセットｍを読み込み（ステップＳ８）、ステップＳ９にてオフセットｍのアドレスをログ取得コードのアドレスに書き換える。
【００３５】
ステップＳ９が終了した場合には、Ｉｎｄｅｘ　ｎをインクリメントする（ステップＳ１０）。また、ステップＳ６においてプレースギャップが存在すると判断された場合は、Ｉｎｄｅｘ　ｎをインクリメントする（ステップＳ１０）。つまり、この場合にはメモリ内のプレースギャップの領域は、ログ取得であるメソッドのアドレスに書き換えられないこととなる。この処理は、メモリロード処理が終了するまで（ステップＳ１１）続行される。
【００３６】
図１５は、本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、それぞれの関数及びメソッドのパラメータの形式や、戻り値の形式を指示する、関数定義ファイルの例である。ＤＬＬ／インターフェース名及び関数／メソッド名を記述し、その関数／メソッドに対する、パラメータ及び戻り値の型が示されている。本実施形態にかかるログ取得方法を実現するソフトウェア評価システムは、この関数定義ファイルによって指示された内容を元に、それぞれの関数／メソッドがどのようなパラメータ／戻り値を有しているかを判断し、その内容をログとして取得する。
【００３７】
なお、プレースギャップに関する定義は、通常オペレーティングシステムが提供している機能であるため、この関数定義ファイルには記述されない。このため、図１５は図１０と同様になる。
【００３８】
図１６は、図１５に示した関数定義ファイルを用いて、図１２に示したプレースギャップを持つインターフェースに対して、本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムで取得した、ログの一例である。それぞれの呼び出しに対して、関数／メソッドが呼び出された時刻、及びその際のパラメータ／戻り値が、ログとして生成される。なお、ＶＴａｂｌｅ上にプレースギャップがあるにも関わらず、プレースギャップの後に配置されたＭｅｔｈｏｄ　ＢＣの呼び出しに対するログが取得できているのは、図１４で示した流れ、すなわち本実施形態を施したことによるものであり、プレースギャップの検知が行われない限り、通常はＭｅｔｈｏｄ　ＢＣのようにプレースギャップの後に配置されたメソッドに関しては、ログを取得できない。
【００３９】
以上の説明から明らかなように、本実施形態によれば、ｖｉｒｔｕａｌ　ａｄｄｒｅｓｓ　ｔａｂｌｅのプレースギャップを、オペレーティングシステムから返される情報から自動的に判断することで、ｖｉｒｔｕａｌ　ａｄｄｒｅｓｓ　ｔａｂｌｅにプレースギャップがあっても、ログの取得が可能となる。
【００４０】
【第３の実施形態】
通常、プレースギャップは上記第２の実施形態のように、クラスの派生に伴う仮想関数の解決のために用いられるが、それ以外に使われるケースも存在する。
【００４１】
図１７は、本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける、メモリロード時の処理の流れを示す図であり、図１４とは別の一例である。
【００４２】
処理が開始されると（ステップＳ２１）、自らがＩｎｄｅｘとして参照するメモリエリアをゼロに初期化する（ステップＳ２２）。このＩｎｄｅｘは、関数定義ファイルに記載されているメソッドの順番をあらわすものである。次にオペレーティングシステムから、Ｉｎｄｅｘ　ｎのメソッドに対するプレースギャップのオフセットｐを読み込み（ステップＳ２３）、ｐが真の値であるかどうか、すなわちヌルポインタでないかどうかを判断する（ステップＳ２４）。ここではｐが真の値かによって、プレースギャップが存在するかどうかを判断しているが、例えば０ｘＦＦＦＦＦＦＦＦといった規定値を「プレースギャップが存在しない」という意味と定義しているオペレーティングシステムに対しては、同様に０ｘＦＦＦＦＦＦＦＦかどうかの判断を行う。
【００４３】
プレースギャップが存在しない場合、もしくはステップＳ２４で仮想関数でないと判断した場合には、ログ取得コードを図７のように生成する。具体的には、メモリ上にログ取得コードを置き（ステップＳ２５）、オペレーティングシステムからＩｎｄｅｘ　ｎのメソッドに対するＶＴａｂｌｅ上のオフセットｍを読み込み（ステップＳ２６）、オフセットｍのアドレスをログ取得コードのアドレスに書き換える（ステップＳ２７）。
【００４４】
ステップＳ２７が終了した場合には、Ｉｎｄｅｘ　ｎをインクリメントする（ステップＳ１０）。また、ステップＳ２４においてプレースギャップが存在すると判断された場合は、Ｉｎｄｅｘ　ｎをインクリメントする（ステップＳ２８）。つまり、この場合には、メモリ内のプレースギャップの領域は、ログ取得コードであるメソッドのアドレスに書き換えられないこととなる。この処理は、メモリロード処理が終了するまで（ステップＳ２９）続行される。
【００４５】
この処理によって、プレースギャップが仮想関数以外のためのものであった場合でも、図１６に示されるような、プレースギャップの後に配置されたメソッドの呼び出しに対するログを取得することが可能である。
【００４６】
【第４の実施形態】
本実施形態では、メソッド内部でインターフェースのインスタンスが生成された場合の処理について説明する。
【００４７】
本実施形態では、すべてのメソッド呼び出しにおけるパラメータ及び戻り値について、ログ取得対象のインターフェースのパラメータ乃至戻り値であるかどうかを判断し、判断した結果、ログ取得対象のインターフェースである場合に、別途ログ取得コードをメモリにロードしてそのログ取得コードのアドレスにパラメータ乃至戻り値を書き換えて関数をリターンさせることにより、メソッド内部でインターフェースのインスタンスが生成された場合であっても、そのインスタンス内部のメソッドに対する呼び出しに関するログを、自動的に記録できるようにする。以下に詳細を述べる。
【００４８】
図１８は、本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、それぞれの関数及びメソッドのパラメータの形式や、戻り値の形式を指示する、関数定義ファイルの例である。ＤＬＬ名及び関数／メソッド名を記述し、その関数／メソッドに対する、パラメータ及び戻り値の型が示されている。本発明の実施形態にかかるソフトウェア評価システムは、この関数定義ファイルによって指示された内容を元に、それぞれの関数／メソッドがどのようなパラメータ／戻り値を有しているかを判断し、その内容をログとして取得する。なお、本実施形態では、Ｉｎｔｅｒｆａｃｅ　ＡのＭｅｔｈｏｄ　ＡＢが、出力パラメータとして、Ｍｅｔｈｏｄ　ＡＢ内部で生成されたＩｎｔｅｒｆａｃｅ　Ｂのインスタンスへのポインタを返すようになっている。また、Ｉｎｔｅｒｆａｃｅ　ＡのＭｅｔｈｏｄ　ＡＣが、戻り値として、Ｍｅｔｈｏｄ　ＡＢ内部で生成されたＩｎｔｅｒｆａｃｅ　Ｂのインスタンスへのポインタを返すようになっている。ＤＬＬ内にコードとして記述されたＩｎｔｅｒｆａｃｅ　Ｂ内のメソッドを、ＥＸＥが呼び出すためには、先にＭｅｔｈｏｄ　ＡＢ乃至Ｍｅｔｈｏｄ　ＡＣを用いて、Ｉｎｔｅｒｆａｃｅ　Ｂのインスタンスを生成し、そのインスタンスのメモリアドレスを知っておく必要がある。
【００４９】
図１９は、図１８に示した関数定義ファイルを用いて、本発明の実施形態にかかるソフトウェア評価システムで取得した、ログの一例である。それぞれの呼び出しに対して、関数／メソッドが呼び出された時刻、及びその際のパラメータ／戻り値が、ログとして生成される。
【００５０】
図２０は、本発明の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける、処理の流れを示す図である。
【００５１】
処理が開始されると（ステップＳ２００１）、設定された関数／メソッドが呼び出されるたびに、ＤＬＬ名／インターフェース名／メソッド名／呼び出し時の時刻をＨＤＤに保存し（ステップＳ２００２）、その呼び出しに対してのパラメータをＨＤＤに保存して（ステップＳ２００３）。本体のメソッドを呼び出す（ステップＳ２００４）。
【００５２】
メソッド内部の処理が終了すると、ＤＬＬ名／インターフェース名／メソッド名／終了時の時刻をＨＤＤに保存し（ステップＳ２００５）、その呼び出しに対してのパラメータ及び戻り値をＨＤＤに保存する（ステップＳ２００６）。
【００５３】
次に、パラメータがインターフェースへのポインタとして定義されているかどうかを、図１８に示した関数定義ファイルに基づいて判断し（ステップＳ２００７）、定義されている場合は、メモリ上にそのポインタに対するログ取得コードを生成して（ステップＳ２００８）、該当するパラメータ乃至戻り値を、ログ取得コードのメモリアドレスに書き換える（ステップＳ２００９）。ステップＳ２００９の処理が終了するか、もしくはステップＳ２００７においてインターフェースポインタとして定義されていないことを判断した場合は、関数のリターン処理を行う（ステップＳ２０１０）。
【００５４】
この処理は、評価対象となるプログラムが終了するまで（ステップＳ２０１１）続行される。
【００５５】
メソッドがパラメータ乃至戻り値としてＥＸＥに返した、インターフェースのインスタンスへのポインタを、ログ取得コードにリダイレクトすることにより、以後そのポインタを用いて呼び出されたメソッドの呼び出し、例えば図１８のＩｎｔｅｒｆａｃｅ　ＢのＭｅｔｈｏｄ　ＢＡの呼び出しに対しても、図１９のようにパラメータ／戻り値／時刻などを記録することが可能となる。
【００５６】
【第５の実施形態】
図２１は、本発明の実施形態にかかるソフトウェア評価システムにおける、処理の流れを示す図であり、図２０とは別の一例である。
【００５７】
処理が開始されると（ステップＳ２１２１）、設定された関数／メソッドが呼び出されるたびに、ＤＬＬ名／インターフェース名／メソッド名／呼び出し時の時刻をＨＤＤに保存し（ステップＳ２１２２）、その呼び出しに対してのパラメータをＨＤＤに保存して（ステップＳ２１２３）。本体のメソッドを呼び出す（ステップＳ２１２４）。
【００５８】
メソッド内部の処理が終了すると、ＤＬＬ名／インターフェース名／メソッド名／終了時の時刻をＨＤＤに保存し（ステップＳ２１２５）、その呼び出しに対してのパラメータ及び戻り値をＨＤＤに保存する（ステップＳ２１２６）。次に、パラメータがインターフェースへのポインタとして定義されているかどうかを、図１８に示した関数定義ファイルに基づいて判断し（ステップＳ２１２７）、定義されている場合は、そのインターフェースがトレースシナリオに書かれる。
【００５９】
トレース対象（ログ取得対象）かどうかを判断する（ステップＳ２１２８、ステップＳ２１２９）。トレース対象であると判断した場合、メモリ上にそのポインタに対するログ取得コードを生成して（ステップＳ２１３０）、該当するパラメータ乃至戻り値を、ログ取得コードのメモリアドレスに書き換える（ステップＳ２１３１）。ステップＳ２１３１の処理が終了するか、もしくはステップＳ２１２７においてインターフェースポインタとして定義されていないことを判断した場合か、もしくはステップＳ２１２９でトレース対象でないことを判断した場合は、関数のリターン処理を行う（ステップＳ２１３２）。
【００６０】
この処理は、評価対象となるプログラムが終了するまで（ステップＳ２１３３）続行される。
【００６１】
上記第４の実施形態と異なり、第５の実施形態では、パラメータ乃至戻り値がトレース対象の場合のみ、ログ取得コードの生成とアドレスのリダイレクトを行うため、使用メモリの節約と、ログを取得したいＥＸＥ及びＤＬＬの処理速度低下防止に効果がある。
【００６２】
【他の実施形態】
なお、本発明は、複数の機器（例えばホストコンピュータ，インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。
【００６３】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【００６４】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００６５】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピ（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【００６６】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００６７】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００６８】
【発明の効果】
以上説明したように本発明によれば、複数にモジュール分けされたソフトウェアの処理ログを容易に取得でき、かつ、ソフトウェアの障害の原因の解析のための工数を削減することが可能となる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態にかかるログ取得方法を実現するコンピュータ（ソフトウェア評価システム）の構成をあらわす図である。
【図２】本発明の第１の実施形態にかかるログ取得方法を説明するためにあらわした、関数ロード時の通常のメモリ構成をあらわす図である。
【図３】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＩＡＴ　Ｐａｔｃｈ使用時のメモリ構成をあらわす図である。
【図４Ａ】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＩＡＴ　Ｐａｔｃｈを使用時の状態を示す図である。
【図４Ｂ】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのログ取得処理の流れを示す図である。
【図５】本発明の第１の実施形態にかかるソフトウェア評価システムのＩＡＴ　Ｐａｔｃｈを使用時の内部構成をあらわす図である。
【図６】本発明の第１の実施形態にかかるログ取得方法を説明するためにあらわした、ＣＯＭサーバのインターフェースのインスタンス作成時の通常のメモリ構成をあらわす図である。
【図７】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＶＴａｂｌｅ　Ｐａｔｃｈ使用時のメモリ構成をあらわす図である。
【図８Ａ】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのＶＴａｂｌｅ　Ｐａｔｃｈを使用時の状態を示す図である。
【図８Ｂ】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムのログ取得処理の流れを示す図である。
【図９】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムの、内部構成をあらわす図である。
【図１０】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、それぞれの関数及びメソッドのパラメータの形式や、戻り値の形式を指示する、関数定義ファイルの例を示す図である。
【図１１】本発明の第１の実施形態にかかるログ取得方法を実現するソフトウェア評価システムで取得した、ログの一例を示す図である。
【図１２】本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、ｖｉｒｔｕａｌ　ａｄｄｒｅｓｓ　ｔａｂｌｅの内部にプレースギャップが存在する場合に、インターフェースのインスタンス作成時にどのようにメモリにロードされるかの例を示す図である。
【図１３】本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、ｖｉｒｔｕａｌ　ａｄｄｒｅｓｓ　ｔａｂｌｅの内部にプレースギャップが存在する場合に、ログ取得コードがどのようなメモリ配置で置かれるかをあらわす図である。
【図１４】本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける、処理の流れを示す図である。
【図１５】本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、それぞれの関数及びメソッドのパラメータの形式や、戻り値の形式を指示する、関数定義ファイルの例を示す図である。
【図１６】本発明の第２の実施形態にかかるログ取得方法を実現するソフトウェア評価システムで取得した、ログの一例を示す図である。
【図１７】本発明の第３の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける、メモリロード時の処理の流れ図である。
【図１８】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムに対して、それぞれの関数及びメソッドのパラメータの形式や、戻り値の形式を指示する、関数定義ファイルの例を示す図である。
【図１９】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムで取得した、ログの一例を示す図である。
【図２０】本発明の第４の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける、処理の流れを示す図である。
【図２１】本発明の第５の実施形態にかかるログ取得方法を実現するソフトウェア評価システムにおける、処理の流れを示す図である。
【符号の説明】
１：ＣＰＵ
２：チップセット
３：ＲＡＭ
４：ハードディスクコントローラ
５：ディスプレイコントローラ
６：ハードディスクドライブ
７：ＣＤ−ＲＯＭドライブ
８：ディスプレイ
１１：ＣＰＵとチップセットを繋ぐ信号線
１２：チップセットとＲＡＭを繋ぐ信号線
１３：チップセットと各種周辺機器とを繋ぐ周辺機器バス
１４：ハードディスクコントローラとハードディスクドライブを繋ぐ信号線
１５：ハードディスクコントローラとＣＤ−ＲＯＭドライブを繋ぐ信号線
１６：ディスプレイコントローラとディスプレイを繋ぐ信号線
【図１】
2004038311.tif 000003
【図２】
2004038311.tif 000004
【図３】
2004038311.tif 000005
【図４Ａ】
2004038311.tif 000006
【図４Ｂ】
2004038311.tif 000007
【図５】
2004038311.tif 000008
【図６】
2004038311.tif 000009
【図７】
2004038311.tif 000010
【図８Ａ】
2004038311.tif 000011
【図８Ｂ】
2004038311.tif 000012
【図９】
2004038311.tif 000013
【図１０】
2004038311.tif 000014
【図１１】
2004038311.tif 000015
【図１２】
2004038311.tif 000016
【図１３】
2004038311.tif 000017
【図１４】
2004038311.tif 000018
【図１５】
2004038311.tif 000019
【図１６】
2004038311.tif 000020
【図１７】
2004038311.tif 000021
【図１８】
2004038311.tif 000022
【図１９】
2004038311.tif 000023
【図２０】
2004038311.tif 000024
【図２１】
2004038311.tif 000025