"ソフトウェアコンポーネントがトランザクションを処理するときの複数のソフトウェアコンポーネント間の依存関係を記述するデータを収集すること602;ソフトウェアコンポーネントがトランザクションを処理するときの複数のソフトウェアコンポーネント間の依存関係を表す有向グラフを形成するように前記データを集約すること604;前記有向グラフに基づいて、トランザクションが処理されるときの依存関係を表す依存マップをディスプレィの画面上に表示すること606;を備える、コンピュータに実装される方法。収集されたデータは、複数のソフトウェアコンポーネントを記述する頂点データ、および、複数の辺に対する辺データを含み、各辺は、複数のソフトウェアコンポーネントの対に関係付けられている、請求項1のコンピュータに実装される方法。データを収集することは、複数のソフトウェアコンポーネントのいずれかに対するソフトウェアコンポーネントを記述する情報を収集することを含む、請求項2のコンピュータに実装される方法。データを収集することは、各辺の所属先を記述する情報を収集することを含む、請求項2または3のコンピュータに実装される方法。各辺の所属先は、ソフトウェアアプリケーションの一つまたは業務トランザクションのタイプである、請求項4のコンピュータに実装される方法。有向グラフを形成するように前記データを集約することは、依存データにおける同じ辺の異なるインスタンスに対する単一の論理的辺を生成すること;依存データにおける最初の辺の最初のインスタンスに対する最初の論理的辺を生成すること;および依存データにおける最初の辺の付加的なインスタンスに対する最初の論理的辺に情報を付加すること、を含む請求項2から5のいずれか1項のコンピュータに実装される方法。有向グラフを形成するように前記データを集約することは、依存データにおける同じソフトウェアコンポーネントの異なるインスタンスに対する単一の論理的頂点を生成すること;依存データにおける最初のソフトウェアコンポーネントの最初のインスタンスに対する最初の論理的頂点を生成すること;および依存データにおける最初のソフトウェアコンポーネントの付加的インスタンスに対する最初の論理的頂点に情報を付加すること、を含む請求項2から6のいずれか1項のコンピュータに実装される方法。有向グラフに基づいてディスプレィの画面上に依存マップを表示することは、時間が経過していることを示すように最初のソフトウェアアプリケーションを表示することを含む、請求項7のコンピュータに実装される方法。ソフトウェアコンポーネントによって処理されるトランザクションをトレースすること、をさらに備える請求項1から8のいずれか1項のコンピュータに実装される方法。依存マップは、複数のソフトウェアコンポーネントを含むアプリケーション間の依存関係を表す、請求項1から9のいずれか1項のコンピュータに実装される方法。1以上のコンピューティングデバイス110A,110B上で実行されるソフトウェアコンポーネントモジュールA1,A2,A3,B1によって処理されるトランザクションのトレースを開始する少なくとも一つのプロセッサ530を有しており、その少なくとも一つのプロセッサは、トランザクションが処理されるときのソフトウェアコンポーネント間の依存関係を記述するデータを収集し、その少なくとも一つのプロセッサは、トランザクションが処理されるときのソフトウェアコンポーネント間の依存関係を表す有向グラフを形成するように依存関係を記述する前記データを集約し、その少なくとも一つのプロセッサは、トランザクションが処理されるときのソフトウェアコンポーネント、またはソフトウェアコンポーネントが存在するアプリケーションのどちらかの依存関係を記述する前記有向グラフに基づいて依存マップを表示する、システム。少なくとも一つのプロセッサに接続されたディスプレィ550をさらに有し、その少なくとも一つのプロセッサは、複数のソフトウェアコンポーネント間の依存関係を表す依存マップをディスプレィ上に表示する、請求項11のシステム。収集されたデータは、複数のソフトウェアコンポーネントを記述する頂点データ、および、複数の辺に対する辺データを含み、各辺は、複数のソフトウェアコンポーネントの対に関係付けられている、請求項11または12のシステム。収集されたデータは、複数のソフトウェアコンポーネントのいずれかに対するソフトウェアコンポーネントを記述する情報を含む、請求項11から13のいずれか一項のシステム。ソフトウェアコンポーネントがトランザクションを処理するときの、複数のソフトウェアコンポーネント間の依存関係を記述するデータを収集する手段530;ソフトウェアコンポーネントがトランザクションを処理するときの、複数のソフトウェアコンポーネント間の依存関係を表す有向グラフを形成するように前記データを集約する手段530;および前記有向グラブに基づいて、トランザクションが処理されるときの依存関係を表す依存マップをディスプレィの画面上に表示する手段550、530;を備えるシステム。本明細書では、データに基づく依存マップを表示するだけでなく、トランザクションが処理される場合にソフトウェアコンポーネント間の依存関係を記述するデータを生成する技術を開示する。データは、ソフトウェアコンポーネントによって処理されるトランザクションを監視またはトレースするエージェントによって収集される。収集されたデータは、ソフトウェアコンポーネント間の依存関係を記述する有向グラフを形成するために集約される。依存マップは、その有向グラフに基づいて表示される。トランザクションが処理される場合、依存マップはソフトウェアコンポーネント間の依存関係を示す。依存マップは、またソフトウェアコンポーネントを含むアプリケーション間の依存関係を示すこともある。依存マップによって、問題がどこに発生しているかをユーザは簡単かつ迅速に確認できるようになる。例えば、ユーザは、フロントエンドのアプリケーションサーバにではなく、バックエンドのデータベースに問題があることを迅速に判定することができる。図1は、異なったコンピュータシステムがマネージャにデータを提供するネットワーク100を示す。例示のコンピュータシステムには、アプリケーションサーバ110a,110b、または、所望の機能を実現するためのコードを実行するのに適したプロセッサを有する他のタイプのコンピュータシステムを含む。アプリケーションサーバ110は、異なったアプリケーションを実行でき、または同じアプリケーションの別々のインスタンスを実行することができる。アプリケーションサーバ110は、互いに離れて設置されてもよいし、または同じ場所に設置されてもよい。この例では、アプリケーションサーバ110は、マネージャコンピュータ120と通信する。マネージャ120は、アプリケーションサーバ110と同じ場所にあってもよいし、離れた場所にあってもよい。例えば、Webベースの電子商取引アプリケーションなど企業アプリケーションenterpriseapplicationを実行している会社は、負荷分散のために1つの場所で複数のアプリケーションサーバを使用する。例えば、ユーザのWebブラウザ102のようなユーザからのリクエストは、インターネットのようなネットワーク104を介して受信され、いずれかのアプリケーションサーバ110に送られる。Webブラウザ102は、通常、図示していないインターネットサービスプロバイダーを介してネットワーククラウド104にアクセスする。アプリケーションサーバ110a,110bは、管理されたアプリケーションA151Aおよび管理されたアプリケーションB151Bを含み、それらは、エージェント112A,112Bおよび例示のプローブ153A,153Bを含む。プローブの数は、任意である。符号中に文字を持つ構成要素例えば、アプリケーションサーバ110a,110bは、説明用に区別するためである。ここでは、aまたはbのない符号の使用は、特定のサーバまたは他の構成要素に言及しないことを示す。アプリケーション151は、Java登録商標アプリケーションまたはアプリケーションの異なるタイプである。このように、アプリケーションサーバ110で実行されるエージェントソフトウェアは、エージェント112によって表され、ある可能なアプローチとして、アプリケーションサーバ110上で実行されている、管理されたアプリケーション151、ミドルウェアまたはその他のソフトウェアから、情報を収集する。例えば、アプリケーション151からの情報は、プローブ153を使用して得られる。実際には、多くのそのようなプローブは、アプリケーション151の様々なコンポーネントに関する情報を得るために使用することができる。いくつかの実施形態では、プローブは、計測を用いることによってアプリケーション151に付加され、その一例にはバイトコード計測がある。ただし、収集されたデータは、他の方法でも得ることができる。エージェント112は、監視対象となるコンピュータシステムに元々に存在しており、データの取得ポイントを提供する。エージェントは、マネージャ120と通信してデータをまとめ、最適化する。トランザクションの流れを記述する目的のため、トランザクションを処理するソフトウェアコンポーネントは、管理されたアプリケーション151に示される。ソフトウェアコンポーネントは、管理されたアプリケーション151内の任意のコードの部分例えば、モジュールを、または管理されたアプリケーション外の任意のコードの部分を含む。例えば、管理されたアプリケーション151内のソフトウェアコンポーネントは、サーブレット、PlainOldJavaObjectsPOJO、EnterpriseJavaBeans登録商標EJB登録商標、ソケットなどを含むが、これらに限定されない。管理されたアプリケーション151外のソフトウェアコンポーネントは、管理されたアプリケーション151と相互に作用するものを含むが、直接的な相互作用までは必要とされない。管理されたアプリケーション151外のソフトウェアコンポーネントは、データベース、Webサービス、Webブラウザなどを含むが、これらに限定されない。3つのトランザクションが図1に示される。トランザクションBTA1は、一例として、Webブラウザ102からのHTTPリクエストに応答して開始される。トランザクションBTA1の場合、その流れは、モジュールA1からモジュールA2、データベースX113へとなる。実際には、トランザクションBTA1に関与する多くのソフトウェアコンポーネントが存在することに留意されたい。しかし、すべてのソフトウェアコンポーネントがユーザに注目されるわけではない。例えば、モジュールA1とモジュールA2との間のトランザクションに伴って、1以上のソフトウェアコンポーネントが存在する可能性がある。また、モジュールA2とデータベースX133との間のトランザクションに伴って、1以上のコンポーネントが存在する可能性がある。例えば、モジュールA2とデータベースX113との間にソケットが存在し得る。しかしながら、そのソケットはユーザに注目されるわけではない。トランザクションBTA2の場合、その流れは、モジュールA3からWebサービス109、モジュールB1へとなる。モジュールB1からデータベースY114への流れは、例えば、それがモジュールA3からモジュールB1への呼び出しを原因としている場合には、トランザクションBTA2の一部とも考えられる。トランザクションBTA2は、アプリケーションBに対するトランザクションBTB1を生成する。具体的には、トランザクションBTB1の流れは、モジュールB1からデータベースY114へとなる。説明のため、トランザクションBTA1は、ユーザがWebブラウザ102で本または他のアイテムを購入する購入トランザクションとなり得る。説明のため、トランザクションBTA2は、本を購入するためのクレジットカードの使用を承認するクレジット確認トランザクションとなり得る。様々なユーザがWebサイトを訪れると、時間の経過とともに、トランザクションBTAの多くの異なるインスタンスが出現することに留意されたい。したがって、トランザクションBTA1は、多くのインスタンスが存在するトランザクションのタイプと称することが可能となる。複数の実施形態において、エージェント112は、トランザクションが処理されてマネージャ120へデータが供給される場合、ソフトウェアコンポーネント間の依存関係を記述するデータを収集する。マネージャ120は、ソフトウェアコンポーネントがトランザクションを処理するときにソフトウェアコンポーネント間の依存関係を示す有向グラフダイグラフを形成するためにそのデータを集約する。例えば、ダイグラフは、コンポーネントを表す頂点とコンポーネント間の依存関係を表す辺とを有する。依存マップは、ダイグラフに基づいて、ユーザインタフェース122のようなディスプレィの画面上に表示されることがある。トランザクションが処理される場合、依存マップが依存関係を示す。依存マップは、様々な詳細レベルを持つことがあり得る。例えば、それはソフトウェアコンポーネント間の依存関係を表す。しかし、依存マップは、より一般的になると、アプリケーション151間の依存関係を示すおそらくソフトウェアコンポーネントさえも示さない。以下は、図示目的のためのいくつかの依存マップの例である。これらのマップは、図1のシステム100によって処理されるトランザクションの例に対応している。図2は、ディスプレィの画面例えばユーザインタフェース122上に表示可能な依存マップ200aの一例を示す。依存マップ200aの例は、トランザクション処理におけるシステム100のソフトウェアコンポーネント間の依存関係を示す。この例では、依存マップ200aはアプリケーションAによって処理されるトランザクションに関係する。この依存マップ200aは、管理されたアプリケーションA151Aの詳細な依存マップのユーザリクエストに応答して表示可能である。トランザクションBTA1およびBTA2は、管理されたアプリケーションAの依存マップの一部と考えられる。両トランザクションは、アプリケーションAの依存マップを形成するために互いに結合されている。例えば、モジュールA1、モジュールA2およびデータベースX113の間の依存関係は、これらのコンポーネントを繋ぐ矢印で示される。これは、トランザクションBTA1に対応することに留意されたい。モジュールA3、Webサービス109、モジュールB1およびデータベースY114の間の依存関係は、これらの構成要素を繋ぐ矢印で示される。これは、トランザクションBTA2に対応することに留意されたい。別の可能性としては、ユーザがアプリケーションAの詳細のみを要求することにより、管理されたアプリケーションB151bの細部がわずかに示される。例えば、モジュールB1および/またはデータベースY114は、示されない。代わりに、Webサービス109から管理されたアプリケーションB151bへの矢印のみがある。依存マップ200は、頂点と辺を含む。頂点は、ソフトウェアコンポーネントに対応する。例えば、図2では、頂点は、外部頂点、モジュールA1、モジュールA2、モジュールA3、データベースX、Webサービス、モジュールB1およびデータベースYである。場合によっては、管理されたアプリケーションAおよび管理されたアプリケーションBが頂点になることに留意されたい。また、外部頂点という用語は、アプリケーションサーバ外にある頂点のタイプを示すのに使われていることにも留意されたい。この場合、外部頂点は、管理されたアプリケーションA151AにHTTPリクエストを送信するソフトウェアコンポーネントを表す。ユーザは、正確にどのソフトウェアコンポーネントがHTTPリクエストを送信したかには注目しないことに留意されたい。したがって、一般的な用語外部頂点を使用することで十分な説明を提供することができる。図2では、辺251a~251fに符号が付けられている。辺は、一対のソフトウェアコンポーネントの間の依存関係を表す。一般的に、辺は2つのソフトウェアコンポーネントの順序付けられた対として記述される。図2において、辺は、矢印で表現される。矢印の尾部と頭部は、順序付けられた対のソフトウェアコンポーネントの順序を定義するために使用される。例えば、辺251aは、モジュールA1、モジュールA2として記述される。辺251bは、モジュールA2、データベースXとして記述される。一実施形態では、依存マップ200は、図2で示すものよりも上位レベルのサマリーが含まれることもある。アプリケーションおよび/またはソフトウェアコンポーネントの数が多い場合には、アプリケーションのより詳細な表示としては複雑になることがある。図3は、ディスプレィの画面上に示されるサマリーの依存マップ200bの一例を示す。この例は、図2の例よりも上位レベルのサマリーであり、アプリケーションAの概要である。この例では、管理されたアプリケーションA151a、管理されたアプリケーションB151b、データベースX113およびデータベースY114の間の依存関係がトランザクションBTA1およびBTA2に対して示されている。管理されたアプリケーション151内のソフトウェアコンポーネントは示されていないことに留意されたい。しかし、依存マップ200bは、図2の依存マップ200aに使用されたエージェント112によって収集されたものと同じデータから生成されていることがある。依存マップ200は、また前例のような管理されたアプリケーションの代わりに、特定のトランザクションに向けられることもある。図4は、トランザクションBTA1のサマリーを示す一例を示している。このような依存マップ200cは、トランザクションBTA1の依存マップに対するユーザのリクエストに対応して示されることがある。業務トランザクションのサマリービューは、トランザクションの流れを表示する。この例では、トランザクションBTA1の一部である辺だけが強調されている太い実線の矢印。他の辺はトランザクションBTA1の一部ではないことを示すために破線になっている。例えば、辺アプリケーションA、WebサービスおよびWebサービス、アプリケーションBは、BTA1の一部ではないが、強調されることなく依然として表示はされている。辺BTA1、アプリケーションAおよびアプリケーションA、データベースXは、BTA1の一部であるので強調されている。アプリケーションBは、BTA1の一部ではないことから、辺アプリケーションB、データベースXは表示されていない。BTA2などのその他のトランザクションのサマリービューもまた表示され得る。共通の目的を達成するための互いに作用するトランザクションから構成されている業務サービスの依存マップ200を表示する別の可能性もある。一例として、BTA1およびBTA2は、同じ業務サービスの一部と考えることができる。業務サービスのサマリーは、BTA1およびBTA2に含まれるすべての頂点と辺の結合であり得る。図1の説明に再び戻ると、一実施形態では、プローブビルダー図1には図示されないは、プローブ153および付加的なコードを付加し、管理されたアプリケーション151のためにバイトコードを計測例えば変更する。プローブ153は、アプリケーションの業務ロジックを変更することなく、管理されたアプリケーション151についての情報の特定部分を測定する。あるタイプのプローブは、コンポーネントが実行に費やす時間を測定する。時間には、プローブを有するコンポーネントによって呼び出されたコンポーネントによる実行に費やす時間を含めることができるが、これは必須ではない。プローブ153は、コンポーネントの入口における始点およびコンポーネントの各出口における終点を有する。一実施形態では、始点ではタイマを起動し、終点ではタイマを止める。プローブ153は、タイミング情報に加えて他の情報も収集する。プローブビルダーは、アプリケーション151または別のマシンコンピュータと同じマシンコンピュータ上にインストールされるエージェント112もまた付加する。一旦、プローブ153がアプリケーション151にインストールされると、または監視機能が別に提供されると、そのアプリケーションは管理されたアプリケーションと称される。バイトコードを計測することについて、さらなる情報として、LewisKCirneによるSystemForModifyingObjectOrientedCodeと題する米国特許番号6,260,187や、2001年2月28日に出願されたAddingFunctionalityToExistingCodeAtExitsと題する米国特許出願番号09/795,901があり、それぞれその全体が参照により本明細書に組み込まれる。管理されたアプリケーション151が実行されると、プローブ153がエージェント112にデータを送信する。例えば、プローブからの情報は、トランザクションまたは他の実行フローの開始および停止回数、またはトランザクション/実行フロー内の個々のコンポーネントの開始および停止回数、のようなパフォーマンスデータを示す。一実施形態では、プローブ153は、またはデータを書いたり、データを変更したり、そうでなければアプリケーションサーバの状態を変更する原因となったりする他のコードやオブジェクトに実装される。このデータは、アプリケーション実行データと称される。エージェント122は、またトランザクションが処理される場合にコンポーネント間の依存関係を記述した依存データを収集する。エージェント112は、その後、アプリケーション実行データおよび依存データを収集し、要約してマネージャ120に送信する。それに呼応して、マネージャ120は要求された計算を実行し、アプリケーション実行データをユーザインタフェース112で使用可能にして、必要に応じて、後で解析するためにデータベース118へアプリケーション実行データを送信する。また、マネージャ120は、ダイグラフを形成し、そのダイグラフに基づいて1以上の依存マップを表示するため、依存データを集約する。プローブを用いてアプリケーションを監視することに関するさらなる情報として、2004年4月22日に公開された、LewisKCirneによるUserInterfaceForViewingPerformanceInformationAboutTransactionsと題する米国特許出願公開番号2004/0075690があり、その内容は参照により本明細書に組み込まれる。マネージャ120は、エージェントから受信したデータに基づいて情報を表示するために、例えばモニタのようなユーザインタフェース122と通信するワークステーションのような独立したコンピュータシステム上に提供される。マネージャ120は、またエージェントから受信したデータを格納するためにデータベース118へアクセスする。提示された例では、アプリケーションサーバは、ネットワーク104にアクセスすることなくマネージャ120と通信する。例えば、通信は、ローカルエリアネットワークを介して行われる。他の設計では、マネージャ120は、ネットワーク104を介して複数のアプリケーションサーバのエージェントからデータを受信することができる。例えば、大規模な組織は、セントラルネットワークオペレーションセンタを運用しており、そこでは、1以上のマネージャが、地理的に異なる場所に分散している複数のエージェントからデータを取得する。説明すると、Webベースの電子商取引企業では、顧客の注文を受ける地理的に異なる場所にあるサーバからエージェントのデータを取得することがある。支払い処理をするサーバ、倉庫で在庫を調べたり、受注を受けたりするサーバなどである。マネージャ120およびユーザインタフェースディスプレィ122は、企業の本社の場所で提供される。必ずしも、Webベース、または、小売り、若しくはその他の販売に関する必要はない他のアプリケーションにおいて同様にシステムを管理するためにエージェントとマネージャを利用することができる。例えば、銀行では、小切手の処理やクレジットの口座用にアプリケーションを使用することがある。また、上述した複数のコンピュータのシステムアレンジに加えて、エージェントによって単一のコンピュータシステムが同様に監視されることがある。図5Aは、図1のネットワークで使用されるコンピュータシステムの一実施形態を示す。コンピュータシステム500は、図1に関連して説明したように、Webブラウザ102、ホスト例えばアプリケーションサーバ110、マネージャ120および/またはユーザインタフェース122で使用されるシステムを簡略化して表したものである。コンピュータシステム500は、ハードディスクまたはポータブルメディアのような記憶装置510、他のコンピュータと通信するためのネットワークインタフェース520、ソフトウェアの命令を実行するためのプロセッサ530、例えば、記憶装置510からロードされた後にソフトウェアの命令を格納するためのRAMのような作業メモリ540およびユーザインタフェースディスプレィ550を含むものである。記憶装置510は、ここで説明した機能を提供するための方法を実行するのにプロセッサ530をプログラムするために具現化されているプロセッサ読み取り可能なコードを有する、プロセッサにより読み取り可能な記憶装置と考えることができる。ユーザインタフェースディスプレィ550は、1以上のエージェントから受信したデータに基づいて、人間のオペレータに情報を提供することが可能である。ユーザインタフェースディスプレィ550は、グラフィカルまたは表形式のような既知の任意の表示方式を使用することができる。画面上の表示に加え、プリンタからのハードコピーなどの出力も提供することができる。また、ここで説明した機能は、ハードウェア、ソフトウェアまたはハードウェアとソフトウェアの両方の組み合わせを使用して実装されてもよい。ソフトウェアについては、1以上のプロセッサをプログラムするために具現化されているプロセッサの読み取り可能に格納されたコードを有する、1以上のプロセッサにより読み取り可能な記憶装置を使用することができる。プロセッサにより読み取り可能な記憶装置は、揮発性および不揮発性メディア、リムーバブルおよび非リムーバブルメディアなどのコンピュータ読み取り可能な記憶装置を含むことが可能である。例えば、コンピュータにより読み取り可能な記憶装置には、コンピュータにより読み取り可能な命令、データ構造やプログラムモジュールまたは他のデータといった情報を記憶するために、任意の方法や技術でインプリメントされた揮発性、不揮発性、リムーバブル、非リムーバブルの媒体が含まれ得る。コンピュータにより読み取り可能な記憶装置の例としては、RAM、ROM、EEPROM、フラッシュメモリ、または他のメモリ技術、CD-ROM、ディジタルバーサタイルディスクDVD、または他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、他の磁気記憶装置、または所望の情報を格納したり、コンピュータによってアクセスしたりすることに用いられる他の媒体などがある。他の実施形態においては、一部またはすべてのソフトウェアは、カスタムIC、ゲートアレイ、FPGA、PLDや特殊用途向けプロセッサなど、専用のハードウェアに置き換えることができる。一実施形態では、1以上の実施形態を実装するソフトウェア記憶装置に格納されているは、1以上のプロセッサをプログラムするために用いられる。1以上のプロセッサは、1以上のコンピュータにより読み取り可能な記憶装置、周辺機器および/または通信インタフェースと通信することができる。いくつかの実施形態では、エージェント112は、アプリケーション151を監視してアプリケーション実行データをマネージャ120に転送し、そこでデータが解析されユーザに報告される。図5Bは、アプリケーション151を監視する処理の一実施形態のフローチャートを示している。当該処理は、図1のシステム100の例において実行される。アプリケーション151は、ステップ502でエージェント152に監視される。監視は、エージェント112が、アプリケーションサーバ110のどのトランザクションが処理されるのかを判定すること、及び、アプリケーションがクライアントの要求を処理するときにエージェント112が呼び出されている間の時間を決定することを含む。監視は、また、エージェント112が、コンポーネントがトランザクションを処理するときの依存データを特定することを含む。依存データのいくつかの例は、以下に説明される。ステップ502は、データを収集するために実行するアプリケーション151内のプローブを含む。アプリケーションの監視に基づくアプリケーション実行データは、ステップ504で生成される。生成されたアプリケーション実行データは、リクエストの処理に関わるアプリケーションのコンポーネント、リクエストの処理中に各コンポーネントが消費する時間幅、およびその他の情報を示す。アプリケーション実行データは、プローブの実行により結果として生じるデータに基づいてエージェント112により生成され、その後、エージェント112が、生成されたアプリケーション実行データをマネージャ120に転送する。一般的に、アプリケーション実行データには、平均的なコンポーネント例えば、メソッドの実行時間、毎秒または間隔ごとのコンポーネントの呼び出し率、コンポーネントの呼び出し回数、開始したが終了していない間隔ごとのコンポーネントの呼び出し回数を示す同時実行のメトリック、および呼び出しを開始した間隔ごとのコンポーネントの呼び出し回数が特定の閾値を超えたコンポーネントの呼び出し回数を示すストール状態のメトリックなどの情報が含まれる。また、アプリケーション実行データは、ガーベジコレクションのヒープサイズ、ファイルやソケットのアクティビティを示すバンド幅メトリック、スレッドの数、システムログ、例外処理、メモリリークおよびコンポーネントの相互作用を特定する。アプリケーション実行データは、管理されたアプリケーション151によって処理されている特定のトランザクションにリンクされることに留意されたい。アプリケーション実行データは、データを集約したり、データを格納したり、インタフェースまたは他のユーザインタフェース112を介してオペレータにデータを提供するなど、ステップ506でマネージャ120により処理されて報告される。図6は、ダイグラフに基づいて依存マップ200を表示するための処理600の一実施形態を示すフローチャートである。処理600は、システム100のようなシステムで使用される。図2~4は、処理600を使用して表示される依存マップ200のいくつかの例を示す。ステップ602で、依存データが収集される。依存データは、エージェント112によって収集される。一実施形態では、依存データは、ソフトウェアコンポーネントを記述する頂点データとソフトウェアコンポーネント間の依存関係を記述する辺データを含む。依存データは、管理されたアプリケーション151例えば、管理されたアプリケーションA151Aの多数の異なるインスタンスのデータを含むことに留意されたい。例えば、システム100は、管理されたアプリケーションA151Aの異なるインスタンスをそれぞれ実行する多くのサーバを有することがある。場合によっては、単一のサーバが、管理されたアプリケーションA151Aの異なるインスタンスを実行することがある。同様のファクターが、管理されたアプリケーションB151Bにも適用される。また、トランザクションの特定のタイプについても多数の異なるインスタンスが存在することに留意されたい。前述のように、トランザクションBTA1について多数の異なるインスタンスが存在する場合があり、別々のユーザが購入を行うことに対応している。このように、依存データは、トランザクションの各タイプの多数の異なるインスタンスに対するデータを含み得る。ステップ602の一実施形態のさらなる詳細を以下に述べる。ステップ604で、依存データは、トランザクションを処理するソフトウェアコンポーネント間の依存関係を表す有向グラフを形成するために集約される。いくつかの実施形態では、対になるソフトウェアコンポーネント間の辺と同様に、有向グラフは、種々のソフトウェアコンポーネント例えば、サーブレット、EJB、デバイスドライバ、DBMS、ソケットなどに対応する頂点を含む。依存データを集約することは、依存データにおける重複する頂点を探すことと、ソフトウェアコンポーネントの重複データを表す単一の論理的頂点を生成すること、を伴う。同様に、依存データを集約することは、依存データにおける重複する辺を探すことと、ソフトウェアコンポーネント間の依存関係に対する重複データを表す単一の論理的辺を生成すること、を伴う。ステップ604の一実施形態のさらなる詳細を以下に述べる。ステップ606では、依存マップ200が有向グラフに基づいて表示される。いくつか例を図2~4に示す。依存マップ200は、有向グラフの複雑さを減少させることに留意されたい。例えば、有向グラフのすべての頂点が依存マップ200で表示される必要はない。同様に、有向グラフのすべての辺も依存マップに表示される必要はない。典型的な一例として、管理されたアプリケーション151のサマリーは、管理されたアプリケーション151の内部のコンポーネントを示すことなく表示可能である。図7は、依存データを収集する処理700の一実施例を示すフローチャートである。処理700は、処理600のステップ602の一実施形態である。ステップ702で、トランザクショントレースを開始する。一実施形態では、特定のソフトウェアコンポーネントがトランザクションの呼び出しスタック内の最初の構成要素として特定されるときに、トランザクショントレースを開始する。これらのソフトウェアコンポーネントは、いくつかの点で注目すべきものとして特定されるものである。いくつかの実施形態では、トランザクショントレースはトランザクションの境界を捉える。境界の下限値は、呼び出しスタック内で注目される最初の構成要素によって定義される。注目される構成要素は、一例として、注目されると考えられるサーブレットなどのコンポーネントのタイプを指定することによって事前に定義され得る。一実施形態では、上側の境界は、JVMJavaVirtualMachineの外部のトランザクション呼び出しによって制御されることがある。スタック内の下側の境界は、フロントエンドと呼ばれる一方で、上側の境界は、バックエンドと呼ばれる。一例として図1を参照すると、モジュールA1はフロントエンドとなり、モジュールA2はバックエンドとなる。ステップ704では、トランザクションを処理するソフトウェアコンポーネント間の依存関係を表す依存データを1以上のエージェント112が収集する。例えば、依存データはフロントエンドとバックエンドとの間の辺を含む。図1のトランザクションBTA1を参照すると、モジュールA1とモジュールA2との間の矢印は、そのような辺である。開始辺も、また外部エンティティとフロントエンドの頂点との間に生成される。図1を参照すると、ネットワーク104またはWebブラウザ102は、外部頂点であると考えられる。外部頂点としてネットワーク104を参照する理由の1つは、アプリケーションサーバ110a上の仮想マシン例えばJVMの外部に存在するからである。このように、開始辺は、ネットワーク104とモジュールA1の間に存在する。また、モジュールA2とデータベースX113との間にも辺が存在する。1以上のエージェントが単一のトランザクションに対する依存データを収集するということに留意されたい。例えば、エージェント112aおよび112bの両方がトランザクションBTA2に対するデータを収集する。ステップ706では、エージェント112は、依存データがマネージャ120に提供されるべきか否かを判定する。依存データは、任意の時間に任意の頻度で提供される。依存データは、マネージャ120からのリクエストに応答して、あるいは、リクエストなしで提供される。依存データがマネージャ120に提供されるものでないのであれば、処理700はステップ702に戻って別のトランザクションのトレースを開始する。別のトランザクションをトレースすることは、トランザクションBTA1の別のインスタンスをトレースすること、または別のタイプのトランザクション例えば、BTA2をトレースすることである。ある時点で、依存データは、エージェント112からマネージャ120へ送信されるステップ708。前述のとおり、依存データは、辺と頂点を記述する。ステップ710において、マネージャ120は依存データを格納する。一実施形態では、マネージャ120は、到着タイムスタンプを依存データに付加する。一実施形態では、エージェント112は、マネージャ120に送信する前に収集タイムスタンプ例えば、依存データが収集された時間をデータに付加する。マネージャ120は、多数のエージェント112から依存データを受け取ることに留意されたい。様々なエージェント112からのこのデータは結合される。前述したように、エージェント112は、依存データを収集してマネージャ120に送信する。表1は、頂点について収集され得る依存データの例を示している。前述のとおり、頂点はソフトウェアコンポーネントに対応する。この例では、各頂点は、1セットの頂点プロパティを有する。タイププロパティについては、開始ノードはトランザクションの開始時のコンポーネントである。開始ノードは、アプリケーションサーバ110の内部、またはサーバ110の外部に存在し得る。外部頂点の抽象レベルは、アプリケーションサーバ110の外部にある少なくともいくつかのコンポーネントに付与される。一実施形態では、管理されたアプリケーション151を外部から呼び出すコンポーネントが外部頂点である。ただし、データベースなどのバックエンドの外部コンポーネントは、外部頂点とみなされる必要はない。表2は、辺に対して収集され得る依存データのタイプの例を示す。前述のように、トランザクションが処理される場合、辺データは、ソフトウェアコンポーネントまたは頂点間の依存関係に付随する。この例では、各辺は、1セットの辺プロパティを有する。以下に辺プロパティの例について詳しく述べる。図1を参照すると、モジュールA1とモジュールA2との間の辺は、次のように記述される。頭部頂点は、モジュールA2である。尾部頂点は、モジュールA1である。辺の所属先は、管理されたアプリケーション151Aである。頭部頂点の所属先は、管理されたアプリケーションA151Aである。尾部頂点の所属先は、管理されたアプリケーションA151Aである。別の例としては、モジュールA3とWebサーバ109との間の辺は、次のように記述される。頭部頂点は、Webサーバ109である。尾部頂点は、モジュールA3である。辺の所属先、頭部頂点の所属先および尾部頂点の所属先は、すべて管理されたアプリケーションA151Aである。さらに別の例として、Webサービス109とモジュールB1との間の辺は、次のように記述される。頭部頂点は、モジュールB1である。尾部頂点は、Webサーバ109である。辺の所属先、頭部頂点の所属先および尾部頂点の所属先は、すべて管理されたアプリケーションB151Bである。いくつかの実施形態では、データのもう1つのセットセカンドセット;asecondsetofdataは、この辺を形成する。セカンドセットは、管理されたアプリケーションA151Aを辺の所属先および尾部頂点の所属先として、頭部頂点の所属先である管理されたアプリケーションA151Aとともにリストアップする。この辺に対するデータのセカンドセットの1つの理由は、依存マップ200を異なるアプリケーション151の観点から表示させることにある。この例では、辺の情報は、管理されたアプリケーションA151Aが辺の所属先であるときに、アプリケーションA151Aの観点から依存マップ200を表示するのに使われる。同様の理由付けが、管理されたアプリケーションB151Bに対しても依存マップ200を表示するために適用される。エージェント112は、外部頂点のように、いくつかのコンポーネントへの特別な名称の割り当てが可能であることに留意されたい。例えば、最後の例では、Webサービス109のソフトウェアコンポーネントが、外部頂点と称される。モジュールA1にリクエストを送信するネットワーク104またはWebブラウザ102もまた外部頂点と呼ばれる。この命名法の1つの理由は、アプリケーション151を呼び出す実際のソフトウェアコンポーネントがユーザに注目されないことにある。したがって、外部頂点などのより一般的な用語で十分な詳細を提供する。図8は、ダイグラフのデータ構造800の一実施形態のブロック図である。ダイグラフのデータ構造800は、エージェント112により収集された依存データに基づいてマネージャ120によって形成される。ダイグラフ800は、頂点のセットノードとも呼ばれるおよび辺のセットを含む。各辺は、別個の頂点の一対を表現する。有向グラフの辺は、順序付けられた対である。ダイグラフのデータ構造800の一番下から始めると、そこには、物理的頂点を集めたものおよび物理的辺を集めたものが存在する。これらは、エージェント112によって収集された実際の依存データである。図示されているように、物理的頂点と物理的辺との間辺に対して順序付けられたコンポーネントの対に対応するには、2:1の関係がある。次の上位レベルには、論理的頂点の集まりと論理的辺の集まりがある。一般的には、特定の物理的頂点について、すべてのインスタンスに対応する1つの論理的頂点が存在し得る。一般的には、特定の物理的辺について、すべてのインスタンスに対応する1つの論理的辺が存在し得る。辺に対して順序付けられたコンポーネントの対に対応して、論理的頂点と論理的辺との間には2:1の関係がある。以下に述べるように、依存データは、物理的頂点生の依存データからの論理的頂点を形成するために集約される。同様に、依存データは、物理的辺から論理的辺を形成するために集約される。論理的頂点と物理的頂点論理的辺と物理的辺も同様との間には1:Nの関係があることに留意されたい。表1で述べたように、頂点には、種々のプロパティ、例えば、タイプ、抽象レベルや階層レベルなどがある。論理的頂点の上位にあるダイグラフ800の次の上位レベルは、これらのプロパティのためのコンテナである。例えば、サーブレット、EJBおよび/またはデータベースに対する個々のタイプのコンテナがある。別の例として、クラス、クラスメソッドに対する個々の階層レベルのコンテナがある。別の例として、頂点は、抽象レベルに基づいて分類される。一実施形態では、外部頂点のコンテナがあり、それは、アプリケーションサーバ110の外部に存在する少なくとも一部のコンポーネントに対するものである。一実施形態では、管理されたアプリケーション151を外部から呼び出すコンポーネントは外部頂点である。ただし、データベースのようなバックエンドの外部コンポーネントは、外部頂点として考慮する必要はない。これらのプロパティは例であり、他のプロパティも使用され得る。また、プロパティが異なる順序例えば、異なるレベルで配置される可能性があることにも留意されたい。最上位レベルにおけるダイグラフのデータ構造800は、依存マップの頂点および依存マップの辺をセットで含んでいる。依存マップは、依存マップの頂点と依存マップの辺とに基づいて描かれる。例えば、図2~4に見られる種々の構成要素は、依存マップの頂点と依存マップの辺とに基づくものである。依存マップの頂点は、類似した物理的頂点の集まりを表す。物理的頂点は、頂点の所属先とプロパティ例えば、カテゴリ、階層レベル、抽象レベル、タイプ、名称などに基づいて互いにグループ化される。依存マップの辺は、依存マップの頂点の順序付けられた対である。それぞれの依存マップの辺は、論理的辺の集まりを維持することによって元の物理的辺の関係を維持する。図9は、ダイグラフを作成するときに辺を処理するための処理900の一実施形態を示すフローチャートである。処理900は、マネージャ120によって実行されるが、別のコンピュータノードが処理900を実行してもよい。一般的に、処理900は、ダイグラフを形成するために依存データを集約することを含む。処理900では、物理的および論理的という用語が使用される。処理900で、物理的という用語は、収集されるデータを指す。例えば、物理的頂点および物理的辺という用語は、エージェント112によって収集されるデータを指すために使用される。依存データには、所定の物理的頂点についての多くのインスタンスが存在することに留意されたい。例えば、依存データには、モジュールA1についての多くのインスタンスが存在する。同様に、依存データには、所定の物理的辺の多くのインスタンスが存在する。処理900で、論理的という用語は、物理的頂点や辺を表すダイグラフの中で作成されたノードを示す。所定の物理的頂点のすべてのインスタンスに対して、単一の論理的頂点が存在することに留意されたい。例えば、モジュールA1について単一の論理的頂点が存在する。同様に、所定の物理的辺のすべてのインスタンスに対して、単一の論理的辺が存在する。処理900は、ユーザのリクエストに応答して実行される。ユーザは、依存データが特定のアプリケーションまたはトランザクションの観点から示されることを要求する。図204にこの例をいくつか示す。処理900は、ユーザが依存マップ200を表示するためにリクエスト中で特定したアプリケーションまたはトランザクションが有する辺を処理する。ステップ902では、処理するための依存データに物理的辺が他に存在するか否かの判定が行われる。他に存在する場合、次の物理的辺はステップ904で依存データからアクセスされる。本明細書で述べたように、辺は、頭部頂点と尾部頂点とにより記述される。ステップ906では、マネージャ120は、頭部頂点が既に検出されているか否かを判定する。換言すると、マネージャ120は、ダイグラフが頭部頂点についての論理的頂点を既に有するか否かを判定する。そうでない場合には、ステップ908において、新しい論理的頂点が当該頭部頂点のためにダイグラフ中で作成される。一実施形態では、マネージャ120は、依存データの頭部頂点に対して1以上のプロパティを調べる。例えば、表1を参照すると、タイプ、名称、所属先、階層レベル、および抽象レベルというような1以上のプロパティが、既にダイグラフに存在する論理的頂点と比較される。これらのプロパティは、例示であることに留意されたい。頭部頂点が既に検出されている場合には、ダイグラフに新しい論理的頂点を作成する必要はない。ただし、頭部頂点のこのインスタンスに関する情報は、ステップ910においてダイグラフに付加される。例えば、頭部頂点のこのインスタンスは、エージェント112が収集したデータの時間、またはマネージャ120が受信したこのインスタンスを含むデータの時間など、それに関係付けられた時間情報を有することがある。この時間情報は、ダイグラフに付加され得る。時間情報を含む1つの理由は、いくつかの実施形態では、依存マップは依存データの存在時間に基づいて表示されることである。例えば、ユーザは、特定のタイムスライスに発生したトランザクションに注目する場合がある。一実施形態では、論理的頂点は、検出された頭部頂点の各インスタンスを含むバケットを有する。様々なインスタンスは、時間情報に基づいて順序づけられる。頭部頂点の処理後、尾部頂点が処理される。尾部頂点の処理は、頭部頂点と類似している。ステップ912では、マネージャ120は、尾部頂点が既に検出されているか否かを判定する。換言すれば、マネージャ120は、ダイグラフが尾部頂点についての論理的頂点を既に有するか否かを判定する。そうでない場合、ステップ914において、新しい論理的頂点が当該尾部頂点のためにダイグラフ中で作成される。一実施形態では、マネージャ120は、依存データの尾部頂点に対して1以上のプロパティを調べる。尾部頂点が既に検出されている場合には、ダイグラフに新しい論理的頂点を作成する必要はない。ただし、尾部頂点のこのインスタンスに関する情報は、ステップ916においてダイグラフに付加される。一実施形態では、論理的頂点は検出された尾部頂点の各インスタンスを含むバケットを有する。異なるインスタンスは、時間情報に基づいて順序づけられる。尾部頂点の処理後、辺が処理される。ステップ918では、マネージャ120は、辺が既に検出されているか否かを判定する。換言すると、マネージャ120は、ダイグラフが辺についての論理的辺を既に有するか否かを判定する。本明細書に記載したように、辺は、尾部頂点と頭部頂点の順序付けられた対で記述される。一実施形態では、マネージャ120は、頭部と尾部のプロパティを有する辺が検出されたか否かを判定するため、辺のプロパティを調べる。ただし、別の技術を辺の等価性を調べるために使用することもできる。辺が検出されていない場合、ステップ920において、新しい論理的辺が当該辺のためにダイグラフ中で作成される。この論理的辺は、論理的頭部と論理的尾部との間に作成される。辺が既に検出されている場合には、ダイグラフに新しい論理的辺を作成する必要はない。ただし、辺のこのインスタンスに関する情報は、ステップ922においてダイグラフに付加される。例えば、辺に関係付けられた時間情報が付加されることがある。一実施形態では、論理的辺は、検出された辺の各インスタンスを含むバケットを有する。異なるインスタンスは、時間情報に基づいて順序づけられる。一実施形態では、格納される辺は、それを有しているエージェントに基づいてソートされる。図10Aおよび10Bは、ダイグラフを形成するときに頂点を処理する処理1000の一実施形態のフローチャートを示す。いくつかの実施形態では、論理的頂点は、タイプ、抽象レベル、階層などのプロパティを有することを想起されたい。処理1000は、ダイグラフデータ構造800にこれらのプロパティを付加する詳細を記述する。一般的に、処理1000は、単一の頂点の処理を記述する。したがって、処理1000は、各頂点尾部および頭部の両方のために繰り返される。処理1000は、マネージャ120によって実行されるが、別のノードも処理1000を実行し得る。ステップ1002では、マネージャ120は、依存データから物理的頂点にアクセスする。ステップ1004では、物理的頂点は、論理的なダイグラフ800に付加される。処理1000で、頂点は、フロントエンド、バックエンドおよびバックエンドファミリのカテゴリに分類される。処理は、物理的頂点のあるカテゴリに基づいて続けられる。フロントエンドは、一般的に、トランザクションの開始または前面またはそれに近いコンポーネントを参照する。例えば、モジュールA1は、トランザクションBTA1のためのフロントエンドである図1を参照のこと。バックエンドは、一般的に、トランザクションの背面またはそれに近いコンポーネントを参照する。一実施形態では、バックエンドは、パフォーマンスメトリクスの可用性に応じて、2つのカテゴリに分けられる。例えば、モジュールA2がデータベースX113を呼び出すとき、呼び出しのためのパフォーマンスメトリクスがあることがある。したがって、データベースX113は、バックエンドのカテゴリと呼ばれることがある。一方、モジュールA3がモジュールB1を呼び出すWebサービス109を呼び出すとき、Webサービス109への呼び出しのためのパフォーマンスメトリクスがあるが、モジュールB1を呼び出すためのものではない。したがって、Webサービス109は、バックエンドファミリのカテゴリと呼ばれることがある。ステップ1006は、物理的頂点がフロントエンドのカテゴリに属しているか否かを判定するテストである。コンポーネントがどのカテゴリに属するかを判定するために使用される1つのファクターは、リストを調べることである。例えば、リストは、あるタイプのソフトウェアコンポーネントがフロントエンドと考えられるということを特定する。例えば、サーブレットはフロントエンドであると考えられる。データベースは、バックエンドであると考えられる。他のプロパティも、またカテゴリを判定するために使用され得る。一実施形態では、ユーザは、種々のコンポーネントのカテゴリを定義することができる。物理的頂点がフロントエンドのカテゴリにあると仮定すると、マネージャ120は、物理的頂点の所属先のための依存マップの頂点が存在するか否かを判定する。もし存在しない場合には、依存マップの頂点は、ステップ1010で作成される。その後、物理的頂点は、ステップ1012において依存マップの頂点に付加される。依存マップの頂点が物理的頂点の所属先のために既に存在している場合には、ステップ1010はスキップされる。ステップ1014では、マネージャ120は、物理的頂点の親が存在するか否かを判定する。頂点の1つのプロパティは、階層レベルになっていることを想起されたい例えば、クラス、クラスメソッド。階層レベルは、有向グラフに既に存在する親があるか否かを判定するために検査される。親が存在する場合には、マネージャ120は、ステップ1016において、親の物理的頂点のための論理的頂点が存在するか否かを判定する。親の物理的頂点のための論理的頂点が存在しない場合にはステップ1016はNO、ステップ1017において、親の頂点が依存マップの頂点に付加される。ステップ1016がYESの場合には、ステップ1018にて、以下で説明する処理が続行される。物理的頂点のための親が存在しない場合ステップ1014はNO、ステップ1018において、マネージャは、物理的頂点の階層レベルのためのコンテナが存在するか否かを判定する。存在しない場合には、マネージャ120は、階層のコンテナを作成しステップ1020、階層のコンテナに物理的頂点を付加するステップ1022。一方、コンテナが物理的頂点の階層レベルのために既に存在する場合には、新しいコンテナは作成される必要はなくステップ1020はスキップされる、ステップ1022において既に存在している階層のコンテナに物理的頂点が付加される。次に、抽象レベルの処理が実行される。マネージャ120は、ステップ1024において、物理的頂点の抽象レベルのためのコンテナが存在するか否かを判定する。存在しない場合には、マネージャ120は、抽象レベルのコンテナを作成しステップ1026、抽象レベルに物理的頂点を付加するステップ1028。一方、コンテナが物理的頂点の抽象レベルのために既に存在する場合には、新しいコンテナは作成される必要はなくステップ1026はスキップされる、ステップ1028において既に存在している抽象レベルのコンテナに物理的頂点が付加される。次に、タイプの処理が実行される。マネージャ120は、ステップ1030において、物理的頂点のタイプのためのコンテナが存在するか否かを判定する。存在しない場合には、マネージャ120は、タイプのコンテナを作成しステップ1032、タイプのコンテナに物理的頂点を付加するステップ1034。一方、コンテナが物理的頂点のタイプのために既に存在する場合には、新しいコンテナは作成される必要はなくステップ1032はスキップされる、ステップ1034において既に存在しているタイプのコンテナに物理的頂点が付加される。次に、論理的頂点の処理が実行される。マネージャ120は、ステップ1036において、物理的頂点の名称が付いた論理的頂点が存在するか否かを判定する。存在しない場合には、マネージャ120は、論理的頂点を作成しステップ1038、論理的頂点に物理的頂点を付加するステップ1040。一方、論理的頂点が物理的頂点のために既に存在する場合には、新しい論理的頂点は作成される必要はなくステップ1038はスキップされる、ステップ1040において既に存在している論理的頂点に物理的頂点が付加される。これで、物理的頂点がフロントエンドのカテゴリに存在する場合の処理を終了する。物理的頂点がバックエンドファミリのカテゴリにある場合にはステップ1050はYES、処理は以下の通りである。マネージャ120は、頂点の所属先とバックエンドのファミリ名のための依存マップの頂点が既に存在するか否かを確認するステップ1052。存在しない場合には、マネージャ120は、ステップ1054でそのような依存マップの頂点を作成する。次に、処理1000は、ステップ1012で依存マップの頂点に物理的頂点を付加する。依存マップの頂点が既に存在する場合には、処理1000は、ステップ1012に進んで依存マップの頂点に物理的頂点を付加する。そして、処理1000は、フロントエンドのカテゴリのために、上述したように続く。物理的頂点がバックエンドファミリのカテゴリに存在しない場合にはステップ1050はNO、マネージャ120は、物理的頂点がバックエンドのカテゴリに存在するか否かを判定するステップ1060。存在する場合には、マネージャ120は、頂点のタイプと名称のための依存マップの頂点が既に存在するか否かを判定するステップ1062。存在しない場合には、マネージャ120は、ステップ1064でそのような依存マップの頂点を作成する。次に、処理1000は、ステップ1012で依存マップの頂点に物理的頂点を付加する。依存マップの頂点が既に存在する場合には、処理1000は、ステップ1012に進んで依存マップの頂点に物理的頂点を付加する。そして、処理1000は、フロントエンドのカテゴリのために上述したように続く。物理的な頂点がバックエンドのカテゴリに存在しない場合にはステップ1060はNO、処理は終了する。一実施形態では、依存マップ200は、依存データの存在時間に基づいて表示される。例えば、いくつかのコンポーネントおよび/または辺のデータがユーザの指定時間の範囲外にある場合には、依存マップの中のコンポーネントおよび/または辺の一部が灰色で表示され得る。図11は、依存データの存在時間に基づいて依存マップを表示する処理1100の一実施形態のフローチャートである。処理1100の一実施形態では、有向グラフは入力であり、時間が経過したとマークされる特定の頂点および/または辺を持つ有向グラフは出力である。ステップ1102では、時間範囲が受信される。一実施形態では、ユーザは、インタフェース122などのユーザインタフェースに時間範囲を入力する。ユーザは、また、1以上の管理されたアプリケーション151および/または依存データが1以上のトランザクションを特定する。一般的に、処理1100は、入力の有向グラフから辺および頂点を処理する。ステップ1104において、さらに辺が処理されるべきであるか否かの判定が行われる。もしそうであれば、次の辺は、ステップ1106において有向グラフからアクセスされる。例えば、有向グラフに格納された時間情報がアクセスされる。時間情報は、エージェント112が物理的辺のためにデータを収集した時間、および/または、マネージャ120が依存データを格納した時間、を含むことを想起されたい。ただし、時間情報は、これらの例に限定されるものではないことに留意されたい。ステップ1108においては、辺の存在時間がステップ1102で受信された期間外であるか否かの判定が行われる。例えば、ユーザが最後の24時間以内のデータを見たいだけの場合に、24時間以前に収集された辺のデータであれば、その辺はステップ1110において灰色にマークされる。灰色にマークすることは、依存マップが表示されるときに、辺が灰色で表示されるように辺がマークされるということである。灰色でマークするとは、存在時間が古いときの辺のマークの一例で、他の技術を使用することもできることに留意されたい。そうでなければ、ステップ1112において、辺は灰色でないようにマークされる。処理1110は、すべての辺が処理されるまで処理を続ける。次に、頂点の処理がステップ1114で開始される。ステップ1114で、有向グラフにさらに多くの頂点が存在するか否かの判定が行われる。もしそうであれば、その後、次の頂点は、有向グラフからアクセスされる。例えば、頂点に関する情報は、頂点を灰色にするか否かの判定を行い得る有向グラフからアクセスされる。一実施形態では、当該判定は、頂点に接続されている辺が灰色にされているか否かに基づく。ステップ1118では、頂点に接続されているすべての辺が灰色にマークされているか否かについて判定が行われる。もしそうであれば、ステップ1120において、頂点は灰色にマークされる。そうでなければ、ステップ1122において、頂点は灰色でないようにマークされる。頂点を灰色にマークするか否かを判定するために、異なるテストが行われ得ることに留意されたい。すべての頂点が処理された後、処理100は終了する。処理1110の処理結果は、灰色/灰色ではない、いずれかが注釈された辺および頂点を有する有向グラフとなる。したがって、依存関係が適切に表示される。上述のように、灰色表示することは、ある意味で依存データの時間経過を示すためのやり方でマークする一例である。本明細書で開示される一実施形態は、ディスプレィの画面上に依存マップを表示するために、装置に実装される方法コンピュータに実装される方法を含む。当該方法は、ソフトウェアコンポーネントがトランザクションを処理するときの複数のソフトウェアコンポーネント間の依存関係を記述するデータを収集すること;ソフトウェアコンポーネントがトランザクションを処理するときの複数のソフトウェアコンポーネント間の依存関係を表す有向グラフを形成するように上記のデータを集約すること;有向グラフに基づいて、ディスプレィの画面上に依存マップを表示すること、を有する。この依存マップは、トランザクションが処理されるときの依存関係を示す。本明細書で開示される一実施形態は、1以上のプロセッサを有するシステムを含み、コンピュータで読み取り可能な記憶装置が1以上のプロセッサに結合されている。コンピュータで読み取り可能な記憶装置は、それに格納されたコンピュータで読み取り可能な命令を有し、1以上のプロセッサ上で実行されると、1以上のプロセッサにシステム内のソフトウェアコンポーネントによって処理されるトランザクションのトレースを開始させ;トランザクションが処理されるときのソフトウェアコンポーネント間の依存関係を記述するデータを収集し;トランザクションが処理されるときのソフトウェアコンポーネント間の依存関係を表す有向グラフを形成するように依存関係を記述するデータを集約し;トランザクションが処理されるときのソフトウェアコンポーネント、またはソフトウェアコンポーネントが存在するアプリケーションのどちらかの依存関係を記述する有向グラフに基づいて依存マップを表示する。本明細書に開示される一実施形態は、ソフトウェアコンポーネントがトランザクションを処理するときの複数のソフトウェアコンポーネント間の依存関係を記述するデータを収集すること;ソフトウェアコンポーネントがトランザクションを処理するときの複数のソフトウェアコンポーネント間の依存関係を表す有向グラフを形成するように上記のデータを集約すること;および、有向グラフに基づいてディスプレィの画面上に依存マップを表示することを有する。ここで、その依存マップは、トランザクションが処理されるときのソフトウェアコンポーネントのセットまたは複数のソフトウェアコンポーネントが存在するアプリケーションのどちらかの依存関係を示す。方法:を実行するための少なくとも1つのプロセッサをプログラムするためのコンピュータで読み取り可能な命令を格納する、コンピュータで読み取り可能な記憶装置を含む。以上、本発明の具体例を詳細に説明したが、これらは例示に過ぎず、本発明の範囲を限定するものではない。上記した技術には、以上に例示した具体例を様々に変形、変更したものが含まれる。上記した実施形態は、本発明の原理をベストに説明するために選定されたものであり、その実用に際しては、本発明が最適にその有用性を発揮するように、その特定用途に適するように当業者が様々に変形し得る。発明の範囲は、ここに添付した特許請求の範囲によって定められることを意図している。"