アプリケーションを解析するための方法であってコンピュータに実装される方法であり、コンピュータに実装される以下のステップ:アプリケーションのコードをコンピュータシステムのメモリ240にロードするステップ;このロードするステップは、計測されたメソッドC1-C7を含んでいる計測されたコンポーネントのベースラインの規定によってアプリケーションのコードを構成することを含み、このアプリケーションのコードは未計測メソッドC4Aも含む;メモリ内のアプリケーションのコードを実行している間に、計測されたメソッドからパフォーマンスデータを取得するステップ;パフォーマンスデータに基づいて、さらに詳細に解析するために計測されたメソッドC4Aの少なくとも一つを選択するステップ;前記選択に基づいて、前記少なくとも一つの選択された計測されたメソッドによって参照された未計測メソッドの一以上の参照メソッドC5を特定するステップ;当該一以上の参照メソッドを特定するステップは、メモリ内にロードされたクラス群の中から、前記少なくとも一つの選択された計測されたメソッドのクラス725を決定するステップ;リソースロケーション715からメモリへ前記クラスのバイトコード表現をロードするステップ;呼び出しバイトコードの一以上のインスタンスを特定するために前記クラスのバイトコード表現を構文解析するステップ;および前記呼び出しバイトコードの前記一以上のインスタンスに基づいて、前記一以上の参照メソッドを特定するステップ;を有し、前記特定するステップに対応して、前記一以上の参照メソッドに対する前記アプリケーションのコードをメモリへロードするステップ;当該ロードするステップは、前記一以上の参照メソッドに対する前記アプリケーションの前記コードを計測によって構成することを含む;を備える方法。前記一以上の参照メソッドに対する前記アプリケーションの前記コードを実行している間に、前記一以上の参照メソッドの計測からパフォーマンスデータを取得する、請求項1の方法。呼び出しバイトコードの前記一以上のインスタンスは、前記クラスのバイトコード表現における一以上の関連付けられたオペコード735、740、745および750から特定され;一以上のオペコードは、定数プールテーブル755内の一以上のエントリへの一以上のインデックスに関連付けられ;前記一以上の参照メソッドは、前記一以上のインデックスを使用して特定される、請求項2の方法。前記一以上の呼び出しバイトコードは、仮想呼び出し、特定呼び出し、静的呼び出し、および、インタフェース呼び出し、の中の一つ以上を含む、請求項3の方法。前記クラスは、JavaInstrumentAPIを使用して決定される、請求項4の方法。前記クラスの前記バイトコード表現の前記ロードするステップは、JavaクラスのClassLoader720を使用する、請求項5の方法。前記一以上の参照メソッドは、少なくとも一つのメソッドによって呼び出され得るメソッドであるが、前記一以上の参照メソッドを特定する時に前記一以上の参照メソッドが前記少なくとも一つの選択された計測されたメソッドによって呼び出されたかどうかは知られていない、請求項1から6のいずれか一項の方法。前記一以上の参照メソッドは、前記少なくとも一つの選択された計測されたメソッドの一以上の子の参照メソッドであり、当該コンピュータに実装される方法は、前記一以上の子の参照メソッドにより参照された未計測の一以上の孫の参照メソッドを特定することをさらに含み、前記一以上の孫の参照メソッドを特定することは:前記一以上の子の参照メソッドのクラスを決定すること;前記一以上の子の参照メソッドの前記クラスのバイトコード表現をリソースロケーションから前記メモリにロードすること;前記一以上の子の参照メソッドの呼び出しバイトコードの一以上のインスタンスを特定するために、前記一以上の子の参照メソッドの前記クラスの前記バイトコード表現を構文解析すること;前記一以上の子の参照メソッドの前記呼び出しバイトコードの前記一以上のインスタンスに基づいて、前記一以上の孫の参照メソッドを特定すること;および前記一以上の孫の参照メソッドを文字列として格納すること、を有する請求項1から7のいずれか一項の方法。前記一以上の未計測の参照メソッドを第1のアプリケーションサーバ106からセントラルマネージャ120へ報告すること、を含み、当該セントラルマネージャは、前記アプリケーションの他のインスタンスにおいて前記一以上の未計測の参照メソッドの前記他のインスタンスの計測について第2アプリケーションによる使用のために、前記第2アプリケーションサーバ110において前記アプリケーションの他のインスタンスへ前記一以上の未計測の参照メソッドの特定をプッシュする、ことをさらに有する請求項1から8のいずれか一項の方法。前記一以上の参照メソッドのために、前記一以上の参照メソッドに計測を付加するか否かの決定を助けるために情報を提供すること;ここで、前記情報は、前記アプリケーションの静的計測が一以上の参照メソッドが計測されるべきではないことを示しているか否かを示している;をさらに有する請求項1から9のいずれか一項の方法。前記一以上の参照メソッドのために、前記一以上の参照メソッドに計測を付加するか否かの決定を助けるために情報を提供すること;ここで、前記情報は、前記一以上の参照メソッドが既に計測されたか否かを示している;をさらに有する請求項1から10のいずれか一項の方法。前記一以上の参照メソッドのために、前記一以上の参照メソッドに計測を付加するか否かの決定を助けるために情報を提供すること;ここで、前記情報は、前記一以上の参照メソッドがインスタンスを参照しているか否かを示している;をさらに有する請求項1から11のいずれか一項の方法。前記一以上の参照メソッドのために、前記一以上の参照メソッドに計測を付加するか否かの決定を助けるために、JAVAReflectionAPIを用いた情報を提供すること;をさらに有する請求項1から11のいずれか一項の方法。アプリケーションを解析するための方法を実行するために、少なくとも一つのプロセッサをプログラムするために具現化されたソフトウエアであってコンピュータで読み取り可能なソフトウェアを有している有体のコンピュータで読み取り可能な記憶装置であり、当該方法は:アプリケーションのコードをコンピュータシステムのメモリ240にロードすること;このロードすることは、計測されたメソッドC1-C7を含んでいる計測されたコンポーネントのベースラインの規定によってアプリケーションのコードを構成することを含み、このアプリケーションのコードは未計測メソッドC4Aも含む;メモリ内のアプリケーションのコードを実行している間に、計測されたメソッドからパフォーマンスデータを取得すること;パフォーマンスデータに基づいて、さらに詳細に解析するために計測されたメソッドC4Aの少なくとも一つを選択すること;前記選択に基づいて、前記少なくとも一つの選択された計測されたメソッドによって参照された未計測メソッドの一以上の参照メソッドC5を特定すること;当該一以上の参照メソッドを特定することは、メモリ内にロードされたクラス群の中から、前記少なくとも一つの選択された計測されたメソッドのクラス725を決定すること;リソースロケーション715からメモリへ前記クラスのバイトコード表現をロードすること;呼び出しバイトコードの一以上のインスタンスを特定するために前記クラスのバイトコード表現を構文解析すること;および前記呼び出しバイトコードの前記一以上のインスタンスに基づいて、前記一以上の参照メソッドを特定すること;を有し、前記特定することに対応して、前記一以上の参照メソッドに対する前記アプリケーションのコードをメモリへロードすること;当該ロードすることは、前記一以上の参照メソッドに対する前記アプリケーションの前記コードを計測によって構成することを含む;ことを特徴とするコンピュータで読み取り可能な記憶装置。前記一以上の参照メソッドに対する前記アプリケーションの前記コードを実行している間に、前記一以上の参照メソッドの計測からパフォーマンスデータを取得する、請求項14の記憶装置。呼び出しバイトコードの前記一以上のインスタンスは、前記クラスのバイトコード表現における一以上の関連付けられたオペコード735、740、745および750から特定され;一以上のオペコードは、定数プールテーブル755内の一以上のエントリへの一以上のインデックスに関連付けられ;前記一以上の参照メソッドは、前記一以上のインデックスを使用して特定される、請求項14又は15の記憶装置。前記一以上の呼び出しバイトコードは、仮想呼び出し、特定呼び出し、静的呼び出し、および、インタフェース呼び出し、の中の一つ以上を含む、請求項14から16のいずれか一項の記憶装置。前記クラスは、JavaInstrumentAPIを使用して決定される、請求項14から17のいずれか一項の記憶装置。前記クラスの前記バイトコード表現の前記ロードするステップは、JavaクラスのClassLoader720を使用する、請求項14から18のいずれか一項のコンピュータに実装される方法。ソフトウェア命令を格納する記憶装置;前記記憶装置から前記ソフトウェア命令がロードされる作業メモリ;および前記ソフトウェア命令を実行するためのプロセッサ;を備えており、前記ソフトウェア命令は:アプリケーションのコードをコンピュータシステムの作業メモリ240にロードし;このロードすることは、計測されたメソッドC1-C7を含んでいる計測されたコンポーネントのベースラインの規定によってアプリケーションのコードを構成することを含み、このアプリケーションのコードは未計測メソッドC4Aも含む;作業メモリ内のアプリケーションのコードを実行している間に、計測されたメソッドからパフォーマンスデータを取得し;パフォーマンスデータに基づいて、さらに詳細に解析するために計測されたメソッドC4Aの少なくとも一つを選択し;前記選択に基づいて、前記少なくとも一つの選択された計測されたメソッドによって参照された未計測メソッドの一以上の参照メソッドC5を特定し;当該一以上の参照メソッドを特定する際に、当該ソフトウエア命令は、メモリ内にロードされたクラス群の中から、前記少なくとも一つの選択された計測されたメソッドのクラス725を決定し;リソースロケーション715から作業メモリへ前記クラスのバイトコード表現をロードし;呼び出しバイトコードの一以上のインスタンスを特定するために前記クラスのバイトコード表現を構文解析し;および前記呼び出しバイトコードの前記一以上のインスタンスに基づいて、前記一以上の参照メソッドを特定させることを有し、前記特定することに対応して、前記一以上の参照メソッドに対する前記アプリケーションのコードを作業メモリへロードすること;当該ロードすることは、前記一以上の参照メソッドに対する前記アプリケーションの前記コードを計測によって構成することを含む、コンピュータシステム。前記ソフトウエア命令は、前記一以上の参照メソッドに対する前記アプリケーションの前記コードが実行されている間に、前記一以上の参照メソッドの計測からパフォーマンスデータを取得する、請求項20のコンピュータシステム。呼び出しバイトコードの前記一以上のインスタンスは、前記クラスのバイトコード表現における一以上の関連付けられたオペコード735、740、745および750から特定され;一以上のオペコードは、定数プールテーブル755内の一以上のエントリへの一以上のインデックスに関連付けられ;前記一以上の参照メソッドは、前記一以上のインデックスを使用して特定される、請求項20又は21のコンピュータシステム。前記一以上の呼び出しバイトコードは、仮想呼び出し、特定呼び出し、静的呼び出し、および、インタフェース呼び出し、の中の一つ以上を含む、請求項20から22のいずれか一項のコンピュータシステム。前記クラスは、JavaInstrumentAPIを使用して決定される、請求項20から23のいずれか一項のコンピュータシステム。前記クラスの前記バイトコード表現の前記ロードするステップは、JavaクラスのClassLoader720を使用する、請求項20から24のいずれか一項のコンピュータシステム。本発明は、上記課題および他の課題を解決する解析ソフトウェアのための技術を提供する。一実施形態では、アプリケーションを解析するための方法であってコンピュータに実装される方法は、コンピュータに実装される以下のステップを含む。解析するためにアプリケーション内の少なくとも一つのメソッドを特定するステップ。メモリ内にロードされたクラス群の中から少なくとも一つのメソッドのクラスを決定するステップ。リソースロケーションからそのクラスのバイトコード表現をロードするステップ。呼び出しバイトコードの一以上のインスタンスを特定するためにそのクラスのバイトコード表現を構文解析するステップ。その呼び出しバイトコードの一以上のインスタンスに基づいて、一以上の参照されるメソッドを特定するステップ。この方法は、さらに、その一以上の参照されるメソッドを文字列として格納することを含む。別の実施形態では、アプリケーションを解析するための方法であってコンピュータに実装される方法は、以下を含む。第1のアプリケーションサーバにおいてアプリケーションの1番目のインスタンス内で解析するために、少なくとも一つの計測されたメソッドを特定すること。メモリ内にロードされたクラス群の中から、その少なくとも一つの計測されたメソッドのクラスを決定すること。リソースロケーションからそのクラスのバイトコード表現をロードすること。呼び出しバイトコードの一以上のインスタンスを特定するためにクラスのバイトコード表現を構文解析すること。呼び出しバイトコードの一以上のインスタンスに基づいて、一以上の未計測の参照されるメソッドを特定すること。この方法はさらに、第1のアプリケーションサーバからセントラルマネージャへその一以上の未計測の参照されるメソッドを報告することを含む。ここで、セントラルマネージャは、第2のアプリケーションサーバにおいて、そのアプリケーションの第2のインスタンスへ、上記一以上の未計測の参照されるメソッドの特定をプッシュする。他の実施形態では、アプリケーションの解析をするためのメソッドを実行するための少なくとも一つのプロセッサでプログラムするために具現化されてコンピュータ読み取り可能なソフトウェアを有している有体のコンピュータで読み取り可能な記憶装置を提供する。実行される方法は以下を含む。アプリケーション内のコンポーネントを計測すること。計測されたコンポーネントからパフォーマンスデータを取得すること。計測されたコンポーネント群の少なくとも一つのコンポーネントのパフォーマンスデータが閾値のパフォーマンスレベルを下回るか否かを判断すること。この判断に応じて、現在は未計測であって、少なくとも一つのコンポーネントによって呼び出し可能な一以上のコンポーネントを特定し計測するための処理を起動すること。対応する方法、システム、及び、コンピュータ若しくはプロセッサで読み取り可能な記憶装置であって本明細書が提示する方法を実現する命令を符号化している記憶媒体を含む記憶装置も提供される。本発明は、ソフトウェアの実行中に未計測のコンポーネントを発見して動的に計測し得る、ソフトウェアを解析する技術を提供する。最初に、アプリケーションのようなソフトウェアは、メソッドのような計測されたコンポーネントのベースラインの規定セットによって設定される。アプリケーションが動作すると、計測からパフォーマンスデータが集められ、いくつかのメソッドのパフォーマンスが期待値を下回っていること、あるいは問題があることがわかる。この問題を解析するため、問題の対象となっているメソッドから呼び出し可能な任意のメソッドを発見する技術が用いられ得る。ある特定の実装では、呼び出し可能なメソッドは、Java登録商標仮想マシンJVMにロードされたクラスのバイトコードを検査することによって見つけ出される。そして、この発見されたメソッドを計測および/または報告する決定がされ得る。選択的に計測を付加することによって、初期の包括的過ぎる計測を必要とすることなく、パフォーマンス問題の深い診断をするために発見されたコンポーネントから追加のパフォーマンスデータを得ることが可能となる。このように、必要に応じて深い診断を行う能力を伴うことにより、効率的で軽い計測が達成される。図1は、異なったコンピュータシステムがマネージャにデータを提供するネットワークを示す。例示のコンピュータシステムは、アプリケーションサーバ106および110、または所望の機能を実現するためにコードを実行するプロセッサを有する他の任意の種類のコンピュータシステムをも含み得る。アプリケーションサーバ群は、異なったアプリケーションを実行し、または同じアプリケーションの別々のインスタンスを実行することができる。アプリケーションサーバ群は、互いに離れて位置することができ、または同じ場所に位置することもできる。この例では、アプリケーションサーバ106および110は、ローカルマネージャコンピュータ120と通信している。マネージャコンピュータ120は、あるいは、アプリケーションサーバ106および110から離れていてもよく、そのような場合にはこれらの間の通信はネットワーククラウド104を介して行われる。例えば、webベースの電子商取引アプリケーションのようなエンタープライズアプリケーションを運営する会社は、負荷分散のために多くのアプリケーションサーバを一つの場所で使用する。ユーザからのリクエストは、ユーザのWebブラウザ102の例のように、インターネットのようなネットワーククラウド104経由で受信され、アプリケーションサーバ106および110のいずれかに送られる。Webブラウザ102は、通常、図示していないインターネットサービスプロバイダーを介してネットワーククラウド104にアクセスする。アプリケーションサーバ106および110上で実行するエージェントソフトウェアは、エージェントA1108およびエージェントA2112とそれぞれ表示されるが、それぞれアプリケーションサーバ106および110上で実行され、ある可能なアプローチで、アプリケーション、ミドルウェア、またはその他のソフトウェアからの情報を集める。例えば、そのような情報は、計測を用いることによって得ることができ、その一例は、バイトコード計測である。しかしながら、集められたデータは他の方法でも得ることができる。エージェント群は、監視されるコンピュータシステムに本質的に存在し、データの取得ポイントを提供する。エージェント群は、マネージャ120と通信してデータを編成し最適化する。ソフトウエアの実行を監視するためのソフトウエア計測について様々なアプローチが知られている。例えば、最初に述べたように、トレーシングはソフトウェアの実行を追跡するために用いられる。トレーシングの例が、2004年4月22日に公開された、TransactionTracerと題する米国特許出願公開No20040078691にて述べられており、それは参照により本明細書に組み込まれる。そこで述べられている一つのアプローチでは、監視されるべきアプリケーションのオブジェクトコードまたはバイトコードは、プローブにより計測、例えば変更、される。アプリケーションのジョブまたは他のロジックを変更することなくアプリケーションに関する特定の情報をそのプローブが測定する。一旦、そのプローブがアプリケーションのバイトコードにインストールされると、それは管理されたアプリケーションと呼ばれる。エージェントソフトウェアは、当該プローブからのパフォーマンスデータのような情報を受信し、その情報を、例えばマネージャ120において、別の処理へ通信する。エージェントソフトウエアは、あるいは、その情報が異常状況を示すか否かを判断するなど、情報を局所的に処理する。例えば、当該プローブからの情報は、トランザクションまたは他の実行フローの開始や停止の回数、またはトランザクション/実行フロー内の個々のコンポーネントの開始や停止の回数などのパフォーマンスデータを示す。この情報は、それが範囲内にあるかどうかを決定するために予め決められた基準と比較される。もし情報が範囲内にない場合には、エージェントは適切なトラブルシューティングが実行できるようにこの事実をマネージャに報告する。エージェント108、112および116は、それぞれが関連付けられているローカルアプリケーションサーバー106、110上でソフトウェアが実行中であるであることを通常認識している。マネージャ120は、ワークステーションなどの別のコンピュータシステムに備えられ、モニターのようなユーザインタフェース122と通信し、エージェントから受信したデータに基づいた情報を表示する。図4A-Cおよび図9の表示の例を参照されたい。マネージャは、また、データベース118にアクセスすることができ、エージェントから受信したデータを格納する。提示された例では、アプリケーションサーバは、ネットワーククラウド104にアクセスすることなく、マネージャ120と通信することができる。例えば、通信は、ローカルエリアネットワークを介して行われる。他の設計では、マネージャ120は、ネットワーククラウド104を介して複数のアプリケーションサーバのエージェントからデータを受信することが可能となる。例えば、大きな組織は、セントラルネットワークオペレーションセンターを採用し、そこでは、一つまたはそれ以上のマネージャが、地理的に異なる場所に分散している複数のエージェントからデータを取得する。説明すると、Webベースの電子商取引企業では、顧客の注文を受ける地理的に異なる場所にあるサーバからエージェントのデータを取得する可能性がある。そのサーバは、支払いを処理するサーバ、倉庫で在庫を調べたり、受注を受けたりするサーバなどである。マネージャ120およびユーザインタフェースディスプレィ122は、企業の本社の場所に備えられることがある。必ずしもWebベースまたは小売、若しくはその他の販売に関するものでなくともよい他のアプリケーションにおいて同様にシステムを管理するためにエージェントとマネージャを採用することができる。例えば、銀行では、小切手の処理やクレジットの口座用にアプリケーションを使用することがある。また、上述した複数のコンピュータシステム装置に加えて、一つまたはそれ以上のエージェントによって単一のコンピュータシステムを同様に監視することができる。図2は、図1のネットワークのコンピュータシステムを示す。コンピュータシステム200は、図1に関して説明したように、Webブラウザ102、ホストアプリケーションサーバ106および110など、セントラルマネージャ120および/またはユーザインタフェース122として使われているシステムを簡略化して表したものである。コンピュータシステム200は、ハードディスクまたはポータブルメディアのような記憶装置210、他のコンピュータシステムと通信するためのネットワークインタフェース220、ソフトウェアの命令を実行するためのプロセッサ230、例えば、記憶装置210からロードされた後にソフトウェアの命令を格納するためのRAMのような作業メモリ240、および、ユーザインタフェースディスプレィ250を含む。記憶装置210は、ここで説明する機能を提供するためのメソッドを実行するようにプロセッサ230をプログラムするために具体化されているプロセッサの読み取り可能なコードを有する、プロセッサにより読み取り可能な記憶装置と考えることができる。ユーザインタフェースディスプレィ250は、一つまたはそれ以上のエージェントから受信したデータに基づいて、人間のオペレータに情報を提供することが可能である。ユーザインタフェースディスプレィ250は、グラフィカルまたは表形式のような既知の任意の表示方式を使用することができる。画面上の表示に加え、プリンタからのハードコピーなどの出力も提供することができる。また、本明細書で説明する機能は、ハードウェア、ソフトウェアまたはハードウェアとソフトウェアの両方の組み合わせを使用して実装されてもよい。ソフトウェアについては、一つまたはそれ以上のプロセッサをプログラムするために具体化されているプロセッサの読み取り可能なコードを有する、一つまたはそれ以上のプロセッサにより読み取り可能な有体の記憶装置を使用することができる。プロセッサにより読み取り可能な有体の記憶装置は、揮発性および不揮発性媒体、リムーバブルおよび非リムーバブルメディアなどのコンピュータ読み取り可能な媒体を含むことが可能である。例えば、コンピュータにより読み取り可能な有体の媒体には、コンピュータにより読み取り可能な命令、データ構造やプログラムモジュールまたは他のデータといった情報を記憶するために、任意の方法や技術でインプリメントされた揮発性、不揮発性、リムーバブル、非リムーバブルの媒体が含まれ得る。コンピュータにより読み取り可能な有体の媒体の例としては、RAM、ROM、EEPROM、フラッシュメモリ、または他のメモリ技術、CD-ROM、デジタルバーサタイルディスクDVD、または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、他の磁気記憶装置、または所望の情報を格納したり、コンピュータによってアクセスしたりすることに用いられる他の媒体などがある。他の実施形態においては、一部またはすべてのソフトウェアは、カスタムIC、ゲートアレイ、FPGA、PLDや特殊用途向けプロセッサなど、専用のハードウェアに置き換えることができる。一実施形態では、一つまたはそれ以上の実施形態を実装するソフトウェア記憶装置に格納されているは、一つまたはそれ以上のプロセッサをプログラムするために用いられる。一つまたはそれ以上のプロセッサは、一つまたはそれ以上のコンピュータにより読み取り可能な有体の媒体/記憶装置、周辺機器、および/または通信インタフェースと通信することができる。図3は、実行パス内のコンポーネントの呼び出し関係を示す。図1のアプリケーションサーバ106、または110などのアプリケーションサーバ上で実行され得るアプリケーション内のコンポーネントが示されている。ここで提供されるコンポーネントのシーケンスは、実行パスの一つの可能なタイプの例である。呼び出される各コンポーネントは、実行パスの一部と考えられる。アプリケーションが計測されるときには、通常、このアプリケーションの開発者の理解や着目する対象となるであろうコンポーネントの選択に基づいて、選択されたコンポーネントのみが計測されることに留意されたい。このように、少なくとも最初は着目すべきとみなされていない多くのコンポーネントはアプリケーション内で呼び出され得るが、実行パスの中には含まれない。コンポーネント指向のプログラムモジュールは、コンポーネントと呼ばれる構成要素からアプリケーションや他のプログラムをプログラマに組ませるのに役に立つ。各コンポーネントは、ソフトウェアの全体的機能に適合するよう特定の機能を実行することができる。さらに、コンポーネントは、他のコンポーネントを呼び出し、また、再帰呼び出しによって自分自身を呼び出し、コンポーネントのシーケンスがプログラム内に呼び出される。コンポーネントは、消費されるコンピュータシステム内のリソースの例、或いは、プログラムの実行時に実行される作業workの例である。コンポーネント指向のプログラミングモデルの一例は、J2EEであり、それはJavaServerPage、EnterpriseJavaBean、サーブレットおよびJavaDatabaseConnectivityコンポーネントといったコンポーネントを用いることができる。しかしながら、その他のコンポーネント指向のプログラミングモデルが使用されてもよく、例えば、マイクロソフト社のNETコンポーネントが使用される。さらに、プログラミングモデルはオブジェクト指向である必要はない。一つのアプローチでは、コンポーネントはメソッドであると考えられている。ここで示されている特定の例は、ユーザがアイテムを注文するWebベースの電子商取引のアプリケーションを示している。コンポーネントは、アプリケーション内のビジネスロジックまたは電子商取引の手順に対応する。具体的には、コンポーネントC1312では、ユーザがアイテムを選び、購入し、クレジットカードの種類やクレジットカード番号といった支払い方法の情報、アイテムを発送する住所といった発送情報、陸送または翌朝配達の航空発送といった発送方法の情報を入力する、ショッピングカートを提供している。C1312は、コンポーネントC1A314を呼び出し、選択されたアイテムがストックにあるかどうかを決定するために在庫を調べる。一旦、選択されたアイテムがストックにあることが決定されると、C1312は、コンポーネントC2322を呼び出し、そこでトランザクションが保留にされている間、アイテムを予約し、そのアイテムが他のユーザに販売されないようにする。一旦、終了すると、C2322がコンポーネントC3324を呼び出し、そこでユーザのクレジットカード情報を調べ、購入の承認と認証が行われる。これは、通常、クレジットカード情報センターにより管理されている外部サーバと通信することを伴う。例えば、C3324は、クレジットカードサービスにコンタクトするコンポーネントC3A326を呼び出し得る。一旦、C3324が正常に終了すると、購入が承認され、コンポーネントC4330が呼び出され、購入されたアイテムの数量を減少させることによって在庫を調整する。C4330はコンポーネントC3342を呼び出し、これにより、出荷ラベルがプリントされたり、オペレータがアイテムを手作業で置いたり梱包したりすることが求められる場所である、例えば、倉庫にコンタクトをし、出荷されるアイテムの手配が行われる。例えば、C5342は、コンポーネントC5A344を呼び出すことができ倉庫Aにコンタクトし、および/またはコンポーネントC5B346を呼び出して倉庫Bにコンタクトする。一旦、コンポーネントC2-C5が実行されると、実行パスはC1312に戻り、発注完了コンポーネントC6316を呼び出し、例えば確認の電子メールまたはWebページで発注確認番号および追跡番号等を提供してユーザに購入を確認する。もし、C1A314で倉庫が在庫切れであったり、C3324でクレジットカード払いが失敗したりした場合には、実行パスは同様にC1312に戻る。可能性のある実装としては、C1およびC6はJavaServerPagesであり、C2-C5はEnterpriseJavaBeansである。1番目のコンポーネントは、非同期モードでマルチスレッドまたはマルチプロセスモードの実行を開始する別のコンポーネントを呼び出した後、実行を継続することができ、またはこの呼び出されたコンポーネントが同期モードでシングルスレッドまたはシングルプロセスモードの実行を終了するまで、このコンポーネントを一時的に休止することができる、ことに留意されたい。例えば、C2-C5のコンポーネントが実行している間、C1312は休止する。さらに、任意のコンポーネントは、トランザクションにおいて1回以上呼び出されることが可能である。例えば、異なる倉庫に保管されている複数のアイテムをユーザが購入すると仮定する。この場合、C5342は繰り返し実行されることがあり、異なる倉庫および/または各アイテム用の異なる倉庫部門にコンタクトする。図4Aは、図3の呼び出し関係に基づく1番目の呼び出しスタックの位置に対する時間のグラフを示す。時間の増分は、必ずしも等間隔ではない。この表現は、トランザクションのトレースであり、一つまたはそれ以上のホストによって提供される実行パス情報の種類の一例である。これは、ユーザインタフェース上で報告として提供されグラフィカルに表示し得るもので、例えばメソッドのようなコンポーネントの実行時間といった形式でパフォーマンスデータを表現したものである。実行パス情報では、アプリケーションのどのメソッドが呼び出されるか、および、呼び出された時間についても特定することができる。水平方向は時間を表し、垂直方向は呼び出しスタックの深さや位置を表す。呼び出しスタックは、一つまたはそれ以上のプログラムまたはスレッドの実行中に呼び出される或いは起動されるメソッドを特定する。実行パスは、通常、1秒から数秒程度に亘るものである。例えば、実行パスはシーケンス:C1412、C1A414、C1412、C2422、C3424、C3A426、C3424、C4430、C5442、C4430、C3424、C2422、C1412、C6416およびC1412を含む。ホストは、クライアントからのリクエストを受信して、C1がt1において実行を開始したことに気づく。このシーケンス内における各移行は、計測に基づいてエージェントによって把握される。C1がt2においてC1Aを呼び出す。C1Aがt4において実行を完了する。C1がt5においてC2を呼び出す。C2がt6においてC3を呼び出す。C3がt7においてC3Aを呼び出す。C3Aがt9において実行を完了する。C3がt10においてC4を呼び出す。C4がt11においてC5を呼び出す。C5がt16において実行を完了する。C4がt17において実行を完了する。t18において、C3が実行を完了する。C2がt19において実行を完了する。C1がt20においてC6を呼び出す。C6がt24において実行を完了する。C1がt25において実行を完了するとき、ホストがクライアントにレスポンスを出す。ホストは、定期的にセントラルマネージャに時間とトランザクションデータを報告する。図4Bは、コンポーネントC5Aが特定され計測された場合における図3の呼び出し関係に基づく2番目の呼び出しスタック位置に対する時間のグラフを示す。例として、t16-t11である、C5442の応答時間が長すぎて閾値レベルを超えることを、応答時間などのパフォーマンスデータが示すと仮定する。この場合、C5によって呼び出される可能性のあるメソッドに関して知らされる情報はない。この例では、ここに記載されている技術は、コンポーネント/メソッドのC5A444がC5から呼び出されることを見つけ出すために用いられる。呼び出し可能なコンポーネントは、必ずではないが、別のコンポーネントから呼び出される可能性がある。C5によって直接呼び出されるメソッドは子メソッドであると見なされる。一方、C5の子メソッドによって呼び出されるメソッドはC5の孫メソッドであると見なされる。以降も同様である。一旦、呼び出し可能なメソッドが特定されると、それからパフォーマンスデータを取得するために計測される。しかし、このような計測は、呼び出し可能なメソッドとして要求されるものではなく、他の手段によって解析したものも報告され得る。この場合、C5Aは、見つけ出された後に計測され、アプリケーションは実行を継続し、新しいパフォーマンスデータが集められる。図4Bの呼び出しスタック位置に対する時間のグラフは、単に図4Aと同じであると見ることもできるが、それは異なるメソッド呼び出しインスタンスを表しており、図4Aでの時間t1-t25の後に図4Bの時間t1-t25が発生している。このグラフは、C5Aの応答時間がt15-t12であるように、C5がt12においてC5A444を呼び出し、C5Aはt15まで実行することを示している。このことは、アプリケーションを診断したり解析したりするのに重要な助けを提供する。例えば、それは、C5Aが過剰な実行時間の原因であると結論づけられる可能性がある。このメソッドの発見処理は、C5BがC5から呼び出し可能であることもまた判定する。図4Bの例では、C5Bは、それに付加される計測を有すると仮定することができる。しかしながら、この例では呼び出されなかったのであるから、C5Bは過剰な実行時間の原因ではないと結論づけられる可能性がある。これは、他では入手し得ないであろう重要な診断情報である。図4Cは、Java実行環境を示している。Java実行環境484は、ハードウェア480の上に構築されているオペレーティングシステム482上に構築されている。Java実行環境は、JavaAPIクラス486とJVM488を含むいくつかの仮想部品を含む。JVMは、レジスタ490、オペランドスタック492、ヒープ494およびメソッド領域496を含む。JVMは、命令のシーケンスとして一連のバイトコードを処理する。JVMの命令は、実行すべきオペレーションを特定するオペコードからなり、そのオペレーションにおいて操作されるべき値を具現化するゼロ又はそれ以上のオペランドを伴う。オペランドスタック492、ヒープ494およびメソッド領域496は、指定可能なメモリ内にある。アドレスのサイズは32ビットで、各メモリロケーションは1バイトを含み、各レジスタは一つの32ビットアドレスを格納する。メソッド領域496は、バイトコードを含んでバイトバウンダリに配置され、オペランドスタック492とヒープ494は、ワード32ビットバウンダリに配置される。レジスタ490は、メモリ内で実行すべき命令を追跡するプログラムカウンタPCを含む。プログラムカウンタは、実行すべき次のバイトコードを特定する。フレームレジスタは、オペランドスタック内のカレントメソッドの実行環境に対するポインタを含む。オペランドトップoptopレジスタは、オペランドスタックの先頭へのポインタを含み、算術式を評価するのに用いられる。変数varsレジスタは、局所変数へのポインタを含む。オペランドスタック492は、メソッドと操作へパラメータを供給し、それらから結果を得る。すべてのバイトコード命令は、スタックからオペランドを取得してそれらの上で操作して、スタックに結果を戻す。オペランドスタックは、実行中のメソッドのスタックフレームを含む。スタックフレームは、例えば、局所変数、計算の中間結果など、メソッドの特定呼び出しのために、状態を保持する。具体的には、各JVMスレッドは、同時にスレッドとして生成された、専用のJVMスタックを有している。JVMスタックは、フレームを格納し、局所変数と部分的な結果を保持し、メソッド呼び出しと戻り値の役割を果たす。このようにフレームは、動的リンキングを実行し、メソッドのための値を戻したり、例外処理をディスパッチするために使用されると同様に、データおよび部分的な結果を格納するため使用される。新しいフレームは、メソッドが呼び出されるたびに生成される。フレームは、メソッドの呼び出しが終了すると、その完了が正常か中断受け取れない例外処理をスローしたかにかかわらず、破棄される。フレームは、フレームを生成するスレッドのJVMスタックから割り当てられる。各フレームは、局所変数の独自の配列、独自のオペランドスタック、および、カレントメソッドのクラスの実行時定数プールへの参照リファレンスを持っている。ヒープ494またはメモリ割り当てプールは、ガーベジコレクトされる。ヒープは、すべてのクラスのインスタンスに対するメモリと配列がそこから割り当てられる実行時データ領域である。ヒープは、起動した仮想マシン上に生成され、オブジェクトのためのヒープ記憶域は、ガーベジコレクタとして知られている自動記憶装置管理システムにより再生される。具体的には、Java実行環境で実行中の各プログラムが、それに割り当てられたガーベジコレクトされたヒープを持っている。また、ヒープ内の各クラスには、それに関連付けられた定数プールがある。定数は変更することはないから、通常、コンパイル時に生成される。定数プール内のアイテムは、特定のクラス内の任意のメソッドで使用されるすべての名前をエンコードする。クラスは、いくつの定数が存在するかのカウントを含み、クラスの記述内における定数の特定リストの始点を特定するオフセットを含む。メソッド領域496は、コンパイルされたコード内でメソッドと関連付けられたバイトコード命令、および、動的リンクのために実行環境が必要とするシンボルテーブルを格納する。メソッドと関連付けられる必要があるデバッグや付加的情報も、またこの領域内に格納される。プログラムカウンタは、常にメソッド領域の数バイトを示し、その数バイトには、例えば、メソッド領域のアドレスが含まれる。プログラムカウンタは、スレッドの実行を追跡するために使用される。バイトコード命令が実行された後、プログラムカウンタは、次に実行する命令のアドレスを保持する。メソッド領域496は、すべてのJVMスレッド間で共有され、実行時定数プール、フィールドおよびメソッドデータ、および、メソッドやコンストラクタのためのコードのようなクラスごとの構造体などを格納している。そのようなメソッドは、クラスおよびインスタンスの初期化やインタフェースタイプの初期化で使用される特別のメソッドを含む。メソッド領域は、起動した仮想マシン上に生成される。実行時定数プールは、クラスファイル内の定数プールテーブルの実行時間をクラスごとに、またはインタフェースごとに、表現したものである。これには、コンパイル時に知られている数値リテラルから実行時に解決されるべきメソッドやフィールドリファレンスに至るまでの範囲で、いくつかの種類の定数が含まれる。各実行時定数プールは、JVMのメソッド領域から割り当てられる。クラスまたはインタフェースの実行時定数プールは、JVMによってクラスまたはインタフェースが生成されるときに構築される。図5Aは、静的計測のための処理フローの例としてJavaベースのものを示す。この処理は、一つの可能性のあるアプローチにおいては、例えば、図1のエージェント108または112のようなエージェント500によって実装され得る。計測に対する一つのアプローチは、メソッドのような、どのコンポーネントを計測するべきかを決める静的なルールを提供することを含む。ルールは、コンポーネントがアプリケーションにロードされる時にアクセスされる。そのようなアプローチでは、クラスローダ520は、トランスフォーマ515にアプリケーションのバイトコードの生のデータバイトを提供するのに使用され、例えば、生のデータバイトをクラスに変換する。例えば、Javaでは、これは、クラスのロードに関与するClassLoaderオブジェクトのdefineClassメソッドを使用する可能性がある。ClassLoaderクラスは、抽象クラスである。クラスの名前を付与すると、クラスローダは、クラスの定義を構成するデータを配置したり生成したりしようとする。代表的な手順は、名前をファイル名に変換し、ファイルシステムからその名前のクラスファイルを読み込むことである。defineClassメソッドは、バイトの配列をClassクラスのインスタンスに変換する。Classクラスのインスタンスは、Javaアプリケーションを実行中にクラスおよびインタフェースを表す。トランスフォーマ515は、したがって、例えばクラスを変換することによって、計測を付加するためにバイトコードを変換することができるソフトウェアである。一つのアプローチでは、トランスフォーマ515の最小処理単位をクラスファイルおよびそのバイト配列とすることができる。アプリケーションのバイトコードが、判断ブロック510においてルール指令505に一致する場合、トランスフォーマ515はトレーサーバイトコードの形式でプローブを付加する。アプリケーションのバイトコードが、判断ブロック510においてルール505に一致しない場合、トランスフォーマ515はバイトコードに計測を付加しない。トランスフォーマ515と判断ブロック510は、プローブビルダ525の一部と考えることができる。この実装では、ルール505は、計測されるべき管理されたアプリケーションの一部を特定する代表的な静的ルールの規定である。ルールは、通常、最初に仮想マシン内でクラスが定義されるときに実装される。クラスは、たった一度の定義で複数回ロードすることができる。例えば、同じクラスをロードする複数のクラスローダが存在し得る。また、クラスなどのコンポーネントは、特定の方法で名前付けられるかどうか、特定のインタフェースを実装するかどうか、特定のサブクラスまたはスーパークラスを拡張するかどうか、等々に基づいて、計測され得る。そのようなコンポーネントは、有用な、あるいは着目するパフォーマンスデータを提供する可能性があると考えられるので、計測すべきものとして選択される。例えば、ルールは、少なくともいくつかのサーブレットは着目するデータを提供し得ると考えられているので、すべてのサーブレットが計測されるべきであることを示すことがある。この場合、ルール505が、JavaクラスのHttpServletのサブクラスであるすべてのコンポーネントを計測すべきであることを示す。HttpServletは、すべてのサーブレットが依存する抽象クラスである。しかしながら、すべてのコンポーネントが計測されるわけではなく、包括的過ぎる計測は過度にオーバーヘッドコストがかかる結果となり、アプリケーションの操作性が損なわれる可能性があるというおそれがある。その一方で、包括的でなさ過ぎる計測は、重要なパフォーマンスデータの欠落という結果に繋がるおそれがある。図5Bは、静的計測のための処理フローの例としてNETベースのものを示す。別の可能性のあるアプローチでは、管理されたアプリケーションのコンポーネントは、マイクロソフト社のNETフレームワークにより提供される。Javaとは異なりNETフレームワークはクラスローダを使用しない。代わりに、NETは、フレームワーク用に特別に書かれたプログラムの実行を管理する仮想マシンを含む。NETフレームワークの実行環境は、共通言語ランタイムCLRとして知られている。CLRは、プログラムを実行する特定のCPUの能力をプログラマが考慮する必要がないように、アプリケーションの仮想マシンの外観を呈している。CLRは、セキュリティ、メモリ管理および例外処理などの他のサービスの提供もしている。予めコード化されたソリューションのクラスライブラリとCLRは、共にNETフレームワークを構成している。さらに、CLRは、アプリケーションの開発および実行のための言語に中立的なプラットフォームを提供する共通言語基盤CLIの実装であり、例外処理、ガーベッジコレクション、セキュリティおよび相互運用のための各機能を果たしている。CLIは、コアクラスライブラリィ、コモンタイプシステムおよび共通中間言語CILを含む。Javaバイトコードと同様に、CILは中間バイトコードの他の例である。JavaとNETは、実装の一例にすぎず、他の実装もまた可能である。ここでは、一つの可能なアプローチとして、処理がエージェント550によって実装される。一つの可能性のある状況では、NETフレームワーク内では、名前によってクラスを参照し、CLR570がクラスを発見し、トランスフォーマ565もしあればにそれを示し、その結果CILを使用するという処理が行われる。特に、判定ブロック560でクラスがルール555に一致する場合、計測が付加される。判断ブロック560でクラスがルール555に一致しない場合は、計測は付加されない。トランスフォーマ565と判断ブロック560は、プローブビルダ575の一部であると考えることができる。図6は、呼び出し可能なメソッドを特定することによりソフトウェアを解析するためのメソッドを示す。上述したように、過度のオーバーヘッドを避けるために計測の量を制限しなければならず、そのため、アプリケーションの動作を把握する能力が制限される。時として、アプリケーションを診断しようとしてソースコードが利用可能であればソースコードは見直される可能性があるが、ソースコードは、通常、利用可能ではなく、殆どのユーザに容易には理解され得ない。その結果、ユーザは、アプリケーションを診断するための関連情報を得るため、いずれの付加されたメソッドを計測すべきかわからない。代わりに、現在は計測されておらずそれゆえ気付かれないであろう呼び出し可能なメソッドを選択的に発見することによって、アプリケーションのより深い理解と診断が可能となる。これらの付加メソッドは、診断のセッション中に計測され、その後、この計測は削除され得る。ここで提供される技術もまた、カスタムソフトウェアに計測を付加するのに有用ではあるが、標準的な計測パッケージは、計測するのが望ましいコードの一部を見落とす可能性がある。エージェントは、特定のメソッドまたは一連のメソッドによって呼び出され得るコードの一部をオンデマンドで発見するために技術を使用することができる。バイトコード解析が実装例で使用される。ステップ600は、アプリケーションにおける解析するための少なくとも一つのメソッドを特定することを含む。詳細は、図10に記載されている。これは、図5Aおよび5Bに関して記載した通り、コンポーネントがアプリケーション内にロードされる際、メソッドのようなどのコンポーネントを計測するべきかを決める静的なルールに基づくなどして、すでに計測された少なくとも一つのメソッドとなり得る。別のアプローチでは、アプリケーションにロードされた後に少なくとも一つのメソッドが計測され得る。この少なくとも一つのメソッドは、パフォーマンスデータに基づいて特定され、例えば、その少なくとも一つのメソッドのパフォーマンの問題を示す。この特定は、パフォーマンスデータを継続的に監視することによって達成され、例えば、ユーザインタフェース上に報告をユーザに提供する。例えば、図9を参照されたい。プリセット範囲との比較に基づいて、範囲外のパフォーマンスデータには自動的にフラグが設定される。ユーザは、次に、計測するために一つまたはそれ以上のメソッドを手動により選択することができる。他の可能なアプローチでは、処理は完全に自動化されており、ユーザの介入を必要とせず、それゆえ、特定されたメソッドは自動的に計測される。ステップ605は、少なくとも一つのメソッドのメソッド呼び出しが存在しているかどうかを決定するためにキャッシュを調べることを含む。キャッシュは、例えば、アプリケーションが実行中のアプリケーションサーバのエージェントの仮想マシン内に存在し得る。一般的に、キャッシュは実行性能のために提供され得る。アプリケーションが実行を開始するとき、キャッシュは空である。ステップ600内で特定される少なくとも一つのメソッドがdoSomethingメソッドと呼ばれると仮定する。呼び出し可能なメソッドを検索する処理を開始する。最初にすることは、キャッシュの中を見ることである。判断ステップ610で、呼び出し可能なメソッドがキャッシュにないときには、ステップ615から635が呼び出し可能なメソッドを特定するために実行され、キャッシュに格納される。ステップ635は、doSomethingのために検索されるメソッド呼び出しを、以下の疑似コードを使用してキャッシュするcacheputメソッドが定義されているクラスdoSomething呼び出し可能なメソッド1呼び出し可能なメソッド2ここで、メソッドが定義されているクラスdoSomethingは、明確にdoSomethingメソッドを明確に特定するためのキーであり、呼び出し可能なメソッドは、doSomethingのための特定された呼び出し可能なメソッドである。doSomethingメソッドのためにプロシージャが次回に起動される際、キャッシュは以前に検索した情報を含む。そのため、キャッシュ内に呼び出されたメソッドに関する情報を持っているので、もうステップ615から635を実行する必要はない。上述したキーによって情報を取り出す。このように、もし、判断ステップ610において、ステップ600の少なくとも一つの特定されたメソッドの呼び出し可能なメソッドが一つまたはそれ以上の参照されるメソッド参照メソッドとしてキャッシュ内にあるならば、この一つまたはそれ以上の参照メソッドは、図11および12にて詳しく説明されるように、ステップ640で報告および/または計測され得る。もし、判断ステップ610において、このステップ600の少なくとも一つの特定された呼び出し可能なメソッドがキャッシュ内にないのであれば、ステップ615から635が実行される。ステップ615は、少なくとも一つのメソッドのクラスを、リフレクションを介して決定する。一つの可能性ある実装において、これはJavaアプリケーションプログラミングインタフェースAPI、javalanginstrumentステップ617の使用を含む。少なくとも一つのメソッドは、それが一つまたはそれ以上の呼び出し可能なメソッドを起動したり呼び出したりすることから、呼び出しメソッドであると考えられる。ステップ615は、メモリ内、例えばJVM内のすべてのロードされたクラスの中からJavaクラスをフェッチすることなどによって少なくとも一つのメソッドのクラスを決定することを含むことができる。ステップ620は、例えば、バイトコードが取得された元のリソース場所から、クラスのバイトコード表現をロードすることを含む。実装例では、可能な場合には、JavaクラスのClassLoaderが使用されるステップ622。自動的に発生したクラスが非常に大きくてメモリをいっぱいにしないように、ステップ620にて安全のための予防策によりメモリにロードされるコードの量が制限されることに留意されたい。ステップ625は、呼び出しバイトコードの一つまたはそれ以上のインスタンスを特定するためにステップ620で得られる各クラスのバイトコード表現を構文解析することを含む。特定の実装においては、クラスのバイトコード表現の特定のオペコードオペレーションコードを特定することが含まれるステップ627。例えば、Java言語の4つのオペコードが、別のメソッドを呼び出すバイトコードを特定する。具体的には、仮想呼び出しのためのオペコードは10進値182または16進値0xb6またはb6、特定呼び出しのオペコードは10進値183または16進値0xb7またはb7、静的呼び出しのオペコードは10進値184または16進値0xb8またはb8、および、インタフェース呼び出しのオペコードは10進値185または16進値0xb9またはb9、である。これらのオペコードのいずれかの存在が呼び出し可能なメソッドを特定する。ステップ625を、一つまたはそれ以上の特定のオペコードを検出するために制限することも可能であるが、すべての可能なオペコードよりも少ない。例えば、インタフェースメソッドは着目するものでないと定めることができ、その場合には、オペコードが、仮想呼び出し、特殊呼び出し、及び、静的呼び出しの場合のみ検出され、インタフェース呼び出しの場合は検出されない。ステップ630は、呼び出しバイトコードの一つまたはそれ以上のインスタンスに基づく一つまたはそれ以上の参照メソッドを特定する。実装例では、ステップ615にて、この一つまたはそれ以上の参照メソッドは、決定されるクラスの定数プールから抽出される。特に、ステップ632は、オペコードに基づき定数プールテーブル内のエントリに対してインデックスを特定し、ステップ634は、インデックスに基づき参照された一つまたはそれ以上のメソッドを特定する。ステップ635は、一つまたはそれ以上の参照メソッドをキャッシュ内に、文字列、例えばdoSomethingのために呼び出されたメソッド、として格納する。ステップ640は、図11-14にて詳しく説明されているように、一つまたはそれ以上の参照メソッドを報告および/または計測することを含む。図6の処理は、同時に、または異なる時間に、多くの異なるメソッドに対して個別に実行され得ることに留意されたい。図7は、700でまとめて示しているが、図6のメソッドに関連して使用されるソフトウェアおよびハードウェアを示す。ハードウェアは、動的計測キャッシュ702およびメモリリソース715を含む。図6のステップ605、610および640に関連して述べたように、動的計測キャッシュは、解析対象のメソッドに対して特定された呼び出し可能なメソッドを格納することができる。その呼び出し可能なメソッドは、同じメソッドの解析が続けて行われる場合、図6のステップ615から630を実行することなく、キャッシュから直ちに特定されることができ、これにより、コンピュータリソース消費量を削減することができる。リソース715は、アプリケーションの実行が開始され計測されるときにメモリにロードされるアプリケーションの異なるクラスのバイトコードを格納するために使用される記憶場所となり得る。一つの可能な実装においては、動的計測キャッシュ702およびリソース715は、アプリケーションサーバ内の図2のメモリ240において提供される。図6のステップ615および617に対応して、JavalanginstrumentAPI710は、少なくとも一つの解析されるメソッドの特定のクラス725を決定するため、ロードされたすべてのクラス705へのアクセスに使用される。一つのアプローチでは、ロードされたすべてのクラスは配列で提供される。図6のステップ620および622に対応して、クラスローダ720は、クラス725に基づいて、クラス725のためのバイトコード730をロードするため、リソース715へのアクセスに使用される。図6のステップ625および627に対応して、クラスバイトコード730は、オペコード735、740、745および750の一つまたはそれ以上のインスタンスを特定するために構文解析される。図6のステップ630、632および634に対応して、各オペコードは、定数プール755からメソッド呼び出しの文字列をフェッチするために使用されるインデックスバイトをそれぞれ持つことができる。図8は、ソフトウェアを計測するための処理フローの例を示す。図5Aに対応して、コンポーネント810の静的リストは、計測されたバイトコードを提供するためのトランスフォーマ/プローブビルダ800の使用のためにバイトコードをロードするクラスローダ802に提供され得る。例えば、defineClassメソッドが、バイト配列をClassクラスのインスタンスに変換する。さらに、図6の処理によって発見されたメソッドのような発見されたコンポーネント806は、計測されることが可能である。一つのアプローチでは、図4Cまたは9に示されているように、ユーザインタフェース808は、発見されたコンポーネントを計測すべきものとしてユーザに指定させることができる。ユーザも静的リスト810を変更することができる。ユーザインタフェースは、管理されたアプリケーション内に存在する既存のインスツルメンテーション計測から流入するパフォーマンスデータを監視するパフォーマンスモニタ812に応答することができ、例えば、あるコンポーネントがトランザクションにおいて実行に時間がかかるというような問題を起こしている事実を特定することができる。パフォーマンスデータは、範囲外にあるかどうかを決定するための下限および上限の閾値と比較され得る。発見されたコンポーネントは、計測すべきクラスの動的更新可能なリストを含む場合がある。このリストは、診断が行われる時間の限れた期間内に特定のメソッドが計測されるように随時変更することができる。ユーザインタフェース808によって時間期間を指定してもよいし、既定の時間期間を用いてもよい。したがって、コンポーネントは、例えば、インスツルメンテーション計測を有しないある時点からインスツルメンテーション計測を有する別の時点まで遷移するように、再定義することが可能である。計測の種類またはレベルが異なるものを提供することが可能であり、例えば、高いレベルの計測は、コンポーネントのパフォーマンスの多くの側面が追跡され、低いレベルの計測は、コンポーネントのパフォーマンスの僅かな側面が追跡される。コンポーネントを再定義することは、このように異なる計測の種類への遷移を含むことができる。計測は、多くの種類のパフォーマンス基準メトリクス/データを生成することができる。そのメトリクス/データには、コンポーネントの平均実行または応答時間、毎秒またはインターバルごとの呼び出し率、呼び出し回数、インターバルごとの、開始したが終了していない呼び出しの回数を示す同時並行性の基準、インターバルごとの、呼び出しを開始したメソッド呼び出しの回数が特定の閾値を超えた呼び出し回数を示すストール状態の基準が含まれる。また、データは、ガーベジコレクションのヒープサイズ、ファイルやソケットのアクティビティを示すバンド幅メトリック、スレッドの数、システムログ、例外処理、メモリリークおよびコンポーネントの相互作用を特定し得る。データは、どのコンポーネントが計測されたコンポーネントによって呼び出されたか、またはどれが計測されたコンポーネントを呼び出すか、を特定することもできる。例えば、コントローラのアーキテクチャにおいては、コンポーネントを管理するコントローラコンポーネント内の制御フローは、次に実行されて、どのくらいの頻度で実行され、どのように実行されるかを知っている。コントローラコンポーネントは、計測を介して、未計測のどのコンポーネントが頻繁に呼び出され、その結果、おそらく重要で計測を付加するために再定義される必要があることを報告することができる。上述のように、計測の種類を変更するためにコンポーネントを再定義することが可能である。例えば、一つまたはそれ以上のパラメータが範囲外に存在するなど、既存の計測が問題を検出しているときには、より多くの計測が付加される可能性がある。また、計測が通常の状態に戻った場合には、その付加的な計測が削除されることがある。削除は、ユーザのコマンドに基づき、またはユーザの介入なしに自動的に行うことができる。発見されたコンポーネント806、ユーザインタフェース808、コンポーネントの静的リスト810およびパフォーマンスモニタ812は、同じ場所または異なる場所に提供され得ることに留意されたい。例えば、ユーザインタフェース808は、ユーザインタフェースホスト122図1に提供されることが可能であり、発見されたコンポーネント806およびコンポーネントの静的リスト810は、アプリケーションサーバ106または110に提供されることが可能であり、そして、パフォーマンスモニタ812は、エージェント108および112からのパフォーマンスデータをアプリケーションサーバ106、110でそれぞれ受信するマネージャ120に関連付けられることが可能である。パフォーマンスモニタ812は、呼び出されたどのコンポーネントが問題のトランザクションに関与しているかの見解を提供し、これらのコンポーネントに問題があるのか、問題を起こすのかを判断し、ユーザインタフェース808上でこの情報を特定することができる。ユーザインタフェース808は、例えば、発見されたコンポーネントを含むどのコンポーネントを計測すべきであるのか、または計測しないのかをユーザに手動で取捨選択させることができる。異なった種類が利用可能であるときは、計測の種類は、ユーザインタフェースを介して指定することもできる。コンポーネントの静的リスト810は、アプリケーションの実行開始時に計測すべきクラスまたは他のコンポーネントを含めることができる。これは、重要なデータを生成すると予想されるコンポーネントのベースラインリストになり得る。一つのアプローチでは、発見されたコンポーネント806のリストは、次回、システムが起動したときに同じコンポーネントが計測されるように、残しておくこともできる。これは、ユーザが一定のデータ、レポートやコンポーネントからのパフォーマンスデータを得られることができるようにし、ユーザに環境をセットアップさせるのに良い方法を提供する。コンポーネントは、コンポーネントがアプリケーションの実行時に既に組み込まれているかどうかに応じて異なる方法で再定義されることができる。コンポーネントがアプリケーションにまだ組み込まれていない場合には、一つの可能な実装として、JMVなどのクラスローダ802によってロードされることによって、正常に組み込まれることが可能である。例えば、NETフレームワークを使用するような他の実装においては、クラスローダは使用されない。コンポーネントがロードされる場合には、命令があれば、例えば、ユーザインタフェース808、発見されたコンポーネント806、コンポーネントの静的リスト810およびパフォーマンスモニタ812、に応答して、トランスフォーマ/プローブビルダ800がコンポーネントを計測する。アプリケーションにすでに組み込まれているが、計測されていないコンポーネントは、計測によりアプリケーションに再組み込みされることができる。例えば、コンポーネントは、アプリケーションから削除することができ、仮想マシンを再起動することなく実行中にリロードすることが可能である。これを達成するためには、JavaのredefineClassコマンドがコンポーネントとともにクラスローダ802に提供される。Java開発キットJDKバージョン1.5またはそれ以降のバージョンがこのコマンドを使用する再定義機能を備えている。このコマンドは、提供されたクラスファイルを使用して提供されたクラスのセットを再定義する。それは、同時に複数のクラスの連動変更を許容するためにセットで動作する。また、再定義されたメソッドがアクティブなスタックフレームを有している場合には、これらのアクティブなフレームが元のメソッドのバイトコードの実行を続行し、再定義されたメソッドが新しい呼び出しで使用される。コンポーネントを例えばクラスのように再定義することは、クラスだけであるが、仮想マシンを再起動することに類似している。クラスが再定義されると、もしクラスが既存のメソッドスタックに存在するならば、そこにとどまる。しかし、すべての新しいメソッドが呼び出される場合には、新しいクラスが使用される。つまり、一旦、再定義されると、新しいバージョンがピックアップされる。トランスフォーマ/プローブビルダ800は、再定義されたコンポーネントを受信する際、もしそうするように命令されていたのであれば、コンポーネントを計測する。トランスフォーマ/プローブビルダ800は、コンポーネントに特定の種類の計測を付加することも可能である。発見されたコンポーネントが計測されアプリケーションに再組み込みされた後、計測が診断のために必要ではないならば、コンポーネントは、再度、アプリケーションに再組み込みされるが計測は行われなくなる。この計測の削除は、特定された診断期間または他のいくつかの他のイベントの後、ユーザコマンド、或いは、タイムアウトに基づいて行われる。例えば、パフォーマンスモニタ812は、発見されたコンポーネントのパフォーマンスデータが一定期間またはコンポーネントの呼び出し数が許容されていることを判断する。つまり、パフォーマンスモニタ812は、計測されたメソッドの少なくとも一つのメソッドのパフォーマンスデータがもはやパフォーマンスレベルの閾値に合致しない、ということはないということを判断する。応答においては、パフォーマンスモニタ812は、例えば、インスツルメンテーション計測を削除するためにredefineClassのようなコマンドを発行することができる。計測の付加および削除は実行時に動的に行われるので、バイトコードを実行している仮想マシンがダウンさせられることはなく、計測されたコンポーネントからのデータは直ちにアクセスされ得る計測を付加する場合。図9は、パフォーマンスデータに呼応したコンポーネント間の階層的関係を示すユーザインタフェース表示を示すもので、これにより、ユーザは、計測すべきコンポーネントを手動により特定することが可能となる。ユーザインタフェース900は、解析されるメソッドの呼び出し可能なコンポーネントとして発見された一以上のコンポーネントの名前を特定する表示領域902を含む。他のコンポーネントの名称もまた提供され得る。この例では、C5Aが唯一発見されたコンポーネントである。コンポーネントの名称/符号の横にあるチェックボックスは、このコンポーネントのための計測を選択するのにユーザがチェックを付けるものである。または、計測は、コンポーネントに自動的に付加され得る。表示領域902は、また、例えば、表示領域906内の計測に基づいたコンポーネントに対するトレースなどのデータを表示するために表示領域904内の一以上のコンポーネントを選択できることをユーザに通知する。同様に、ユーザは計測がコンポーネントから削除されるように示すためにチェックボックスのチェックを外すことも可能である。異なる種類の計測を特定するために、チェックボックスの追加または他のユーザインタフェース技術の使用もまた可能である。また、ユーザがユーザインタフェース900を最初に見る場合、現在の計測状態に応じてチェックボックスに事前にチェックを付けたり、チェックを外したりすることも可能である。場合によっては、チェックボックスは、例えば、計測が誤って重要なコンポーネントから削除されないように、例えば、コンポーネントの計測状態は変更することができないことを示すためにグレー表示されることがある。ユーザは、例えば、コンポーネントがエラーに関与しているか否か、コンポーネント自身がエラーを起こしていないか、以前のトラブルシューティングの経験やその他の要因の観測に基づいて、ある発見されたコンポーネントに計測を付加すべきかどうかを指示することができる。表示領域904は、どのコンポーネントが別のコンポーネントの下にあるのか、または別のコンポーネントによって呼び出されるのかを示すツリーのような階層構造を使って、アプリケーション内の各コンポーネントを自動的に付加する。表示領域906は、領域904内のコンポーネントうち選択された一つについて計測に基づいて計測されたコンポーネントのトランザクショントレースなどのパフォーマンスデータを表示している。例えば、コンポーネント名がアンダーラインで示されているように、コンポーネントC1、C5およびC5Aが現在ユーザによって選択されており、そして、対応するパフォーマンスデータ、例えば、トランザクショントレースが領域906における曲線910、912および914によって提示される。領域906は、エージェントからセントラルマネージャに提供されるパフォーマンスデータを付加する。いくつかのアプローチでは、領域904に表示されている情報は、発見されたコンポーネントのみが表示されるようにフィルタリングすることができる。また、ユーザは、ノードの下位レベルのコンポーネントを見るために、ツリーのノードを展開することができる。図10は、図6のステップ600の詳細を示す。解析するためのアプリケーション内の少なくとも一つのメソッドの特定は、様々な要因に基づいて行われ得る。一つの可能なアプローチでは、少なくとも一つのメソッドはパフォーマンスデータに基づいて特定される。具体的には、ステップ1000は、アプリケーション内のメソッドを計測することを含む。例えば、これは、図5Aおよび5Bに関連して記載したように静的計測を含むことができる。ステップ1005は、計測されたメソッドからパフォーマンスデータを取得することを含む。パフォーマンスデータは、図4A-Cおよび9に示されているように、継続的に得ることができ、リアルタイムの更新でユーザインタフェースに表示される。棒グラフバーチャート、グラフ、テーブル等々のような様々な表示もまた提示することができる。ステップ1010は、計測されたメソッドの少なくとも一つのメソッドのパフォーマンスデータが閾値のパフォーマンスレベルを下回っていることを判断することを含む。例えば、図4Aでは、パフォーマンスデータは、t16-t11であるC5442の応答時間を含み得る。今回、例えば、5タイムユニットでは、長すぎて閾値のパフォーマンスレベルを超えるので、応答時間は4タイムユニット以下にする必要があると仮定する。コンポーネントまたはメソッドC5は、このように、解析するための少なくとも1つのメソッドとして特定され得る。実際には、多くの異なるメソッドのパフォーマンスデータは、メソッドが期待された範囲内にあるか否かを確認するために閾値レベルに対して継続的に評価され、期待された範囲にないメソッドには解析のためにフラグが設定され得る。ステップ1015は、図6のステップ605から640の処理のように、少なくとも一つのメソッドによって呼び出し可能な一以上のメソッドを特定および/または計測するための処理を起動する。図11は、一つまたはそれ以上の参照メソッドを報告および/または計測することに関する図6のステップ640の詳細を示す。ステップ1100は、一つまたはそれ以上の参照メソッドを報告することを含む。即ち、それは、解析中の少なくとも一つのメソッドによって呼び出し可能なメソッドである。例えば、図4Cに表されているように、報告はユーザインタフェース表示の形式とすることができる。図4Cでは、一つまたはそれ以上の参照メソッドは、新しく発見されたコンポーネントC5Aを含む。ステップ1105は、一つまたはそれ以上の参照メソッドを計測することを含む。これは、例えば図8の技術を含み得る。例えば、計測がアプリーションの実行中に発生するように、計測を動的にすることが可能であり、また、例えばアプリケーションはユーザから離れている。ステップ1110は、一つまたはそれ以上の計測されたメソッドを含むアプリケーションを実行することを含む。実際には、アプリケーションは、計測が付加されている一つまたはそれ以上の参照メソッドを含んで実行を継続する可能性がある。ステップ1115は、一つまたはそれ以上の計測されたメソッドのためのパフォーマンスデータを取得することを含む。このように、計測が付加される結果、一つまたはそれ以上の発見されたメソッドに関するパフォーマンスデータがそれから取得され得る。これは、特にメソッドに関係する問題を診断するのに役に立つ。ステップ1120は、パフォーマンスデータを評価することを含む。このことは、例えば、パフォーマンスデータと値の許容範囲とを比較することにより、そして、パフォーマンスデータが範囲外である場合、最小レベルを下回る場合、若しくは、最大レベルを上回る場合にフラグを設定することにより、自動的に行われる。例えば、図13に示されたように、ステップ1125は、一つまたはそれ以上の計測されたメソッドによって呼び出し可能な一つまたはそれ以上のメソッドを特定および/または計測するための処理を起動することを含む。即ち、解析されている元のメソッドより1レベル低いメソッド、子メソッドに掘り下げるドリルダウンという、反復技法インタラクティブテクニックが実行され得る。続いて、もしこの子メソッドのパフォーマンスデータによって保証される場合、または他の理由で、掘り下げドリルダウンが解析されている元のメソッドよりも2レベル低いレベル、つまり孫メソッド、若しくは前の子メソッドの子に対して実行され得る。この処理は、メソッドの階層内の下位レベルのメソッドを解析するために連続的に繰り返され得る。別のアプローチでは、最初の掘り下げドリルダウンは解析されている元のメソッドよりも2レベル以上低いレベル、例えば、子メソッドおよび孫メソッドの両方に行われてもよい。計測は、子メソッドおよび孫メソッドの両方に同時に付加され得る。この計測からのパフォーマンスデータは、さらなるレベルへの掘り下げドリルダウンが保証されるかどうか、さらなるレベルの計測が保証されるかどうかを示し得る。図12は、一つまたはそれ以上の参照されたメソッドを報告および/または計測することに関する図6のステップ640の詳細を示す。ステップ1200は、一つまたはそれ以上の参照メソッド、即ち解析中の少なくとも一つのメソッドによって呼び出し可能な新たに発見されたメソッドが計測されるべきではないということを示しているルールが設定されているかどうかを決定することを含む。場合によっては、図5Aおよび5Bのルール505および555が特定のメソッドは計測されるべきではないことを示すこともある。これは、例えば、メソッドがネイティブでありそのためにバイトコードを有しない場合、メソッドが属するクラスがJavaAPIによって変換可能とされないようにマークされる場合、またはメソッド/クラスがエージェントのプルーブビルダーディレクティブPBDのインスツルメンテーション計測によってスキップされたとマークされた場合、に発生するが、それは破棄できない。ルールが一つまたはそれ以上の参照されたメソッドが計測されるべきではないということを示したことを示すユーザインタフェースを介して報告が作成され得る。ステップ1205は、一つまたはそれ以上の参照メソッドがすでに計測されているか否かを判断することを含む。例えば、ある場合においては、メソッドはアクティブにされていない計測を有し得るが、そのような場合、その計測をアクティブにさせることが可能である。また、メソッドがすでに計測されたことをユーザに示したい場合がある。それゆえ、もしそれに関する任意の情報をトランザクションコンポーネント内で見ないのであれば、それは呼び出されていないからである。ステップ1210は、一つまたはそれ以上の参照メソッドがインタフェースクラス内にあるか否かを判断することを含む。ユーザインタフェースは、この事実を報告することがあり、これにより、ユーザは、一つまたはそれ以上の参照メソッドが計測されるべきか否かを示すコマンドを入力することができる。この場合において、インスツルメンテーション計測は、すべての実装クラスを計測することに関与する。これは、いくつかの場合には望ましくないであろう計測が相当量になる可能性がある。ステップ1200から1210の情報は、可能なメソッド呼び出しごとにリフレクションを使用してエージェントによって提供されることがある。この情報は、呼び出し可能なメソッドに計測を付加するか否かの判断に際してユーザをサポートする。情報は、例えば、Java5InstrumentAPIによって提供されることによってロードされたクラスの配列から検索したクラスのリフレクションを介して取得され得る。この情報は、情報を再決定する場合における計算上のリソースの消費を避けるために、後続のアクセスのためにキャッシュされ得る。図13は、図11のステップ1125の詳細を示す。図13の処理は、図6のそれと類似しているが、それは一つまたはそれ以上の子メソッドに関しての説明である。ステップ1300は、一つまたはそれ以上の参照メソッドが少なくとも一つのメソッドの一つまたはそれ以上の子メソッド、例えば、図6のステップ600の解析するための少なくとも一つのメソッドであることを示す。ステップ1305は、図6のステップ615と同様であり、一つまたはそれ以上の子メソッドのクラスを決定する。ステップ1310は、図6のステップ620と同様であり、例えば、バイトコードが取得された元のリソース場所から、一つまたはそれ以上の子メソッドのクラスのバイトコード表現をロードすることを含む。ステップ1315は、図6のステップ625と同様であり、呼び出しバイトコードの一つまたはそれ以上のインスタンスを特定するためにステップ1305で得られる各クラスのバイトコード表現を構文解析することを含む。ステップ1320は、図6のステップ630と同様であり、一以上の子メソッドの呼び出しバイトコードステップ1315の一以上のインスタンスに基づいて、一以上の子メソッドの一以上の孫の参照メソッドを特定する。ステップ1325は、図6のステップ635と同様であり、一以上の孫の参照メソッドを文字列としてキャッシュに格納する。ステップ1330は、図6のステップ640と同様であり、一以上の孫の参照メソッドを報告および/または計測することを含む。図14は、図6のステップ640の詳細を示す。図1に関連して述べたように、複数のアプリケーションサーバはセントラルマネージャと通信しているエージェントをそれぞれ有することがある。したがって、エージェントは、アプリケーションのような同じコードで別々のインスタンス持つアプリケーションサーバで実行されているJVMのクラスタ内に展開されていることがある。エージェントA1108のような一つのエージェントは、アプリケーションにおける少なくとも一つのメソッドを解析し、一以上の参照メソッドを決定する。その一以上の参照の特定は、例えばマネージャ120を介して、一以上のエージェントが共有し得る。例えば、エージェントA1108は、呼び出し可能なメソッドなどのメソッド呼び出しの新しい規定が、指定されたクラスやメソッドに対して検索されたということを、マネージャ120に通知してもよい。マネージャ120は、エージェントA2112のようなクラスタ内の他のエージェントに重要である可能性のある情報をプッシュ転送することを決定することができる。これにより、他のエージェントにおけるメソッドの呼び出し検出ステップの繰り返しを避けることができ、発見された呼び出し可能なメソッドの異なるインスタンスからパフォーマンスデータをエージェントが収集できるようにすることができる。アプリケーションの別のインスタンスの同じメソッドのパフォーマンスデータを見ることによって、アプリケーションの動作をより詳細に把握することが可能となる。例示の処理では、ステップ1400は、一以上の参照メソッドを、アプリケーションの最初のインスタンスに関連づけられている最初のエージェント108から、マネージャに報告する。ステップ1405では、マネージャは、アプリケーションの一以上の他のインスタンスに関連付けられている一以上の他のエージェント112に、一以上の参照メソッドの特定をプッシュ転送する。ステップ1410では、一以上の他のエージェントが、アプリケーションの一以上の他のインスタンスにおける一以上の参照メソッドの一以上の他のインスタンスを計測する。以上、本発明の具体例を詳細に説明したが、これらは例示に過ぎず、本発明の範囲を限定するものではない。上記した技術には、以上に例示した具体例を様々に変形、変更したものが含まれる。上記した実施形態は、本発明の原理をベストに説明するために選定されたものであり、その実用に際しては、本発明が最適にその有用性を発揮するように、その特定用途に適するように当業者が様々に変形し得る。発明の範囲は、ここに添付した特許請求の範囲によって定められることを意図している。