(57)【要約】【課題】アプリケーションの開発工程で作成された、抽象度の高い設計情報上で記述されたアプリケーションの監視要求に応じたアプリケーションプログラムの監視を実現するためには、プログラムの実装を理解し、監視要求を実装レベルの記述に変換する作業を行う必要がある。このため、要求された監視を迅速に実行することができない。【解決手段】アプリケーションの開発工程における各段階の設計情報の構成要素間の対応関係を用いて、抽象度の高い設計情報上のポイント又はデータと、プログラムコード上のポイント又はデータとを対応付けることによって、抽象度の高い設計情報上で記述された監視要求を、プログラム実装レベルの記述へと変換する。【選択図】図１
2007316905.tif 000002
【特許請求の範囲】
【請求項１】
アプリケーションプログラムを実行する計算機システムにおいて、
前記計算機システムは、
前記アプリケーションプログラムの開発工程の一つの段階における設計情報の構成要素と、前記一つの段階より進んだ段階における設計情報の構成要素との対応関係を示す情報を保持し、
前記対応関係を示す情報に基づいて、前記アプリケーションプログラムの開発工程の一つの段階における設計情報の構成要素と、前記アプリケーションプログラムのコードとを対応付けることを特徴とする計算機システム。
【請求項２】
前記アプリケーションプログラムのコードと対応付けられる設計情報の構成要素は、業務プロセス上の点を示す情報であり、
前記計算機システムは、前記対応関係を示す情報に基づいて、業務プロセス上の点と、前記アプリケーションプログラムのコード上の点とを対応付けることを特徴とする請求項１に記載の計算機システム。
【請求項３】
前記計算機システムは、前記業務プロセス上の点を示す情報を入力されると、
前記対応関係を示す情報に基づいて、前記入力された情報によって識別される業務プロセス上の点と、前記アプリケーションプログラムのコード上の点とを対応付け、
前記対応付けられたアプリケーションプログラムのコード上の点に、前記アプリケーションプログラムを監視するプログラムモジュールを挿入することを特徴とする請求項２に記載の計算機システム。
【請求項４】
前記アプリケーションプログラムに挿入されるプログラムモジュールは、前記アプリケーションプログラムのログ情報を取得することによって、前記アプリケーションプログラムを監視することを特徴とする請求項３に記載の計算機システム。
【請求項５】
前記ログ情報は、前記アプリケーションプログラムによって処理されるデータ、又は、前記アプリケーションプログラムの処理時間を示す情報を含むことを特徴とする請求項４に記載の計算機システム。
【請求項６】
前記計算機システムは、前記業務プロセス上の点を示す情報を入力するためのユーザインタフェースを備えることを特徴とする請求項３に記載の計算機システム。
【請求項７】
前記アプリケーションプログラムのコードと対応付けられる設計情報の構成要素は、業務プロセス上で処理されるデータを示す情報であり、
前記計算機システムは、前記対応関係を示す情報に基づいて、業務プロセス上で処理されるデータと、前記アプリケーションプログラムのコード上のデータとを対応付けることを特徴とする請求項１に記載の計算機システム。
【請求項８】
前記計算機システムは、前記業務プロセス上で処理されるデータを示す情報を入力されると、
前記対応関係を示す情報に基づいて、前記入力された情報によって識別される業務プロセス上のデータと、前記アプリケーションプログラムのコード上のデータとを対応付け、
前記対応付けられたデータを取得するプログラムモジュールを生成することを特徴とする請求項７に記載の計算機システム。
【請求項９】
前記プログラムモジュールが取得するデータは、前記アプリケーションプログラムのログ情報であることを特徴とする請求項８に記載の計算機システム。
【請求項１０】
前記計算機システムは、前記業務プロセス上で処理されるデータを示す情報を入力するためのユーザインタフェースを備えることを特徴とする請求項８に記載の計算機システム。
【請求項１１】
前記計算機システムによって対応付けられる設計情報の構成要素は、業務プロセス図におけるアクティビティ及び接続フロー、ＵＭＬシーケンス図におけるメッセージ、クラス図におけるクラス、メソッド及びフィールド、並びに、プログラムコードにおけるクラス、メソッド及びフィールドの少なくとも一つであることを特徴とする請求項１に記載の計算機システム。
【請求項１２】
前記計算機システムは、
前記各設計情報の構成要素に、前記計算機システム内で一意の識別子を付与し、
前記識別子を用いて前記設計情報の構成要素の対応関係を示す情報を管理することを特徴とする請求項１１に記載の計算機システム。
【請求項１３】
アプリケーションプログラムを実行する計算機システムの制御方法であって、
前記方法は、
前記アプリケーションプログラムの開発工程の一つの段階における設計情報の構成要素と、前記一つの段階より進んだ段階における設計情報の構成要素との対応関係を示す情報を保持し、
前記対応関係を示す情報に基づいて、前記アプリケーションプログラムの開発工程の一つの段階における設計情報の構成要素と、前記アプリケーションプログラムのコードとを対応付けることを特徴とする方法。
【請求項１４】
前記アプリケーションプログラムのコードと対応付けられる設計情報の構成要素は、業務プロセス上の点を示す情報であり、
前記方法は、前記業務プロセス上の点を示す情報を入力されると、
前記対応関係を示す情報に基づいて、前記入力された情報によって識別される業務プロセス上の点と、前記アプリケーションプログラムのコード上の点とを対応付け、
前記対応付けられたアプリケーションプログラムのコード上の点に、前記アプリケーションプログラムを監視するプログラムモジュールを挿入することを特徴とする請求項１３に記載の方法。
【請求項１５】
前記アプリケーションプログラムのコードと対応付けられる設計情報は、業務プロセス上のデータを示す情報であり、
前記方法は、前記業務プロセス上で処理されるデータを示す情報を入力されると、
前記対応関係を示す情報に基づいて、前記入力された情報によって識別される業務プロセス上で処理されるデータと、前記アプリケーションプログラムのコード上のデータとを対応付け、
前記対応付けられたデータを取得するプログラムモジュールを生成することを特徴とする請求項１３に記載の方法。
【請求項１６】
アプリケーションプログラムを実行する計算機システムを制御するプログラムであって、
前記計算機システムは、
前記プログラムが格納される記憶装置と、前記記憶装置に格納されたプログラムを実行するプロセッサと、を備え、
前記アプリケーションプログラムの開発工程の一つの段階における設計情報の構成要素と、前記一つの段階より進んだ段階における設計情報の構成要素との対応関係を示す情報を保持し、
前記プログラムは、前記対応関係を示す情報に基づいて、前記アプリケーションプログラムの開発工程の一つの段階における設計情報の構成要素と、前記アプリケーションプログラムのコードとを対応付ける第１の手順を前記プロセッサに実行させることを特徴とするプログラム。
【請求項１７】
前記アプリケーションプログラムのコードと対応付けられる設計情報の構成要素は、業務プロセス上の点を示す情報であり、
前記第１の手順は、前記業務プロセス上の点を示す情報を入力されると、前記対応関係を示す情報に基づいて、前記入力された情報によって識別される業務プロセス上の点と、前記アプリケーションプログラムのコード上の点とを対応付け、
前記プログラムは、さらに、前記対応付けられたアプリケーションプログラムのコード上の点に、前記アプリケーションプログラムを監視するプログラムモジュールを挿入する第２の手順を前記プロセッサに実行させることを特徴とする請求項１６に記載のプログラム。
【請求項１８】
前記アプリケーションプログラムのコードと対応付けられる設計情報の構成要素は、業務プロセス上のデータを示す情報であり、
前記第１の手順は、前記業務プロセス上で処理されるデータを示す情報を入力されると、前記対応関係を示す情報に基づいて、前記入力された情報によって識別される業務プロセス上で処理されるデータと、前記アプリケーションプログラムのコード上のデータとを対応付け、
前記プログラムは、さらに、前記対応付けられたデータを取得するプログラムモジュールを生成する第２の手順を前記プロセッサに実行させることを特徴とする請求項１６に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本願明細書で開示される技術は、アプリケーションプログラムの実行中の挙動を監視する方法に関し、特に、アプリケーションプログラム監視の設定及び制御を実行する方法に関する。
【背景技術】
【０００２】
情報システムの運用管理者又は業務管理者は、業務アプリケーションが出力するログを用いてシステム及び業務の状態を監視する。ログには、ハードウェア、ＯＳ、アプリケーションサーバ等の業務アプリケーションを実行する情報システムの各階層において出力されるシステムログと、業務アプリケーションが出力するアプリケーションログがある。情報システムの各階層は、それぞれシステムログを出力する機能と、運用管理者又は業務管理者の要求に応じて、出力するログをシステムの運用中にカスタマイズする機能とを備える。
【０００３】
情報システムによって処理されている業務の状態を監視するためには、システムログではなく、アプリケーションログが必要となる。業務の状態監視に必要となるアプリケーションログは、企業をとりまく法改正などの環境変化によって、アプリケーションの運用開始後に変化する可能性がある。このため、アプリケーションが出力するログを運用開始後に追加又は変更する必要がある。
【０００４】
アプリケーションログを出力する機能の実現方法は、アプリケーションプログラムの実装の形態によって異なる。
【０００５】
昨今、業務アプリケーションの開発においては、モデル中心の開発手法が用いられるようになってきている。この開発手法によれば、経営者又は設計コンサルタントが、業務プロセスをBusiness Process Modeling Notation（ＢＰＭＮ）（非特許文献１参照）等のモデル記述言語を用いてモデル化する。作成されたモデルが実装レベルのモデルへと段階的に変換、詳細化されることによって、プログラムの実装レベルの仕様が作成される。そして、作成された仕様に基づいてアプリケーションプログラムが実装される（非特許文献２参照）。
【０００６】
図２は、アプリケーションの開発工程、及び、その過程で作成されるモデル図の説明図である。
【０００７】
アプリケーションの開発においては、ビジネスプロセスモデリング表記法（ＢＰＭＮ）等を用いて作成された業務プロセス図３０１、Unified Modeling Language（ＵＭＬ）等のモデル記述言語を用いて作成されたＵＭＬクラス図３０２、及び、ＵＭＬシーケンス図３０３等が用いられる。
【０００８】
以下、業務プロセス図、ＵＭＬクラス図及びＵＭＬシーケンス図等、アプリケーションの開発において用いられるモデル図を総称して設計情報と呼ぶ。
【０００９】
このようなアプリケーション開発工程では、まず、業務プロセスを分析しモデル化することによって、抽象的な業務プロセス図３０１が作成される。作成された業務プロセス図３０１が、段階的に詳細化される。詳細化された業務プロセス図は、さらに、ＵＭＬクラス図３０２又はＵＭＬシーケンス図３０３のモデルへと詳細化される。詳細化を繰り返すことによって、抽象的なアプリケーション設計モデルは、アプリケーションプログラムの実装に近いレベルのモデルに変換される。最終的に、実装レベルのモデルに基づいて、アプリケーションのプログラムコード３０４が実装される。
【００１０】
昨今の業務アプリケーションは、オブジェクト指向言語を用いて複数の小規模なソフトウェア部品であるコンポーネントを組み合わせることによって構築されることが一般的となっている。そのようなアプリケーションを構築するための基盤技術として、J2EE（非特許文献３参照）及び.NETがある。これらの基盤技術を用いて実装されたアプリケーションは、J2EEアプリケーションサーバ又は.NETアプリケーションサーバと呼ばれるアプリケーション運用基盤上で実行される。
【００１１】
一方、異なるアプローチとして、業務プロセスを構成する各機能をサービスとして実装し、メッセージングシステムを用いてサービスの疎結合としてアプリケーションを実装するService Oriented Architecture（ＳＯＡ）のアプローチが提唱されている（非特許文献４参照）。
【００１２】
ＳＯＡによって実装されたアプリケーションでは、メッセージングシステムでサービス間のメッセージを捕捉することによって、アプリケーションで処理される業務の状態を監視することができる（非特許文献５参照）。メッセージングシステムによる監視は、サービスと独立して設定できるため、アプリケーションへの作りこみ無しにアプリケーションレベルの監視を実現し、運用中に監視内容のカスタマイズをすることができる。あるいは、サービス間でやりとりされる全てのメッセージを記録し、その後必要なメッセージを参照することによって、監視する内容を追加又は変更することができる。
【００１３】
ＳＯＡのアプローチを取らない一般的なアプリケーションの場合、ＳＯＡアプリケーションのようにアプリケーションの挙動を外部から捕捉して業務の状態を監視することができない。従って、アプリケーションによって出力されるログを追加又は変更する場合、個々のログについて、ログを出力する機能をアプリケーションに個別に作りこむ必要があるため、アプリケーションプログラムの変更が必要であった。そのため、出力する個々のログに応じてログ出力コードを実装する手間がかかるという問題と、アプリケーションプログラムの変更のためにアプリケーションの運用を停止する必要があるという問題があった。
【００１４】
アプリケーションにログ出力コードの追加又は変更を行うためにプログラムを変更する必要があるという問題を解決する方法として、バイトコードインスツルメンテーション技術（特許文献１参照）を用いる方法がある。バイトコードインスツルメンテーション技術は、アプリケーションプログラムのプログラムコードを動的に書き換えることによって、プログラム実行中の機能追加及び変更を実現する。この技術を用いて、ログ出力機能の動的な追加、変更を実現することができる。
【００１５】
特許文献２では、バイトコードインスツルメンテーション技術を用いて、事前に用意したログを出力するプログラムモジュールを選択して、そのプログラムモジュールを、実行中のアプリケーションプログラムに挿入するシステムが示されている。その結果、任意のアプリケーション監視を、アプリケーションの運用を止めずに追加することができる。
【００１６】
特許文献３では、アプリケーションプログラムの指定された箇所に、監視を実行するプログラムモジュールをアプリケーションプログラムの実行中に挿入し、実行パフォーマンスを監視するシステムが示されている。このシステムでは、プログラムのどこで監視を実行するかを、プログラムコードレベルで入力する。すると、入力した位置に、予め用意された監視を実行するプログラムモジュールが自動的に挿入され、監視が実行される。
【００１７】
また、ログ出力コードを実装する手間がかかるという問題を解決するために、ログ出力コードを自動的に生成する方法がある。非特許文献６では、アプリケーションを監視するプログラムモジュールを自動的に生成するシステムが示されている。このシステムでは、監視を行う箇所とそこで監視するデータをプログラムコードレベルで入力することによって、アプリケーションを監視するプログラムモジュールが自動的に生成される。
【００１８】
また、アプリケーションの運用中に、出力するログを追加又は変更することを実現する別の方法として、特許文献４では、アプリケーションに事前に作りこんでおいた監視機能をアプリケーションの運用中に選択し、監視の実行を制御するユーザインタフェースを備えるシステムが示されている。この方法では、アプリケーション運用前に作りこんだ監視機能の範囲内で、運用中に監視の実行を制御することができる。しかし選択可能な監視機能をアプリケーションの運用中に追加又は変更することはできない。
【００１９】
また、アプリケーションの監視を実行する際に、監視の実行によって生じる性能劣化を考慮する必要がある。アプリケーションを監視し、監視データを出力する処理は、一定の負荷を生じる。従って、監視負荷がアプリケーションプログラムの実行に出来るだけ影響を与えないように監視を実行する必要がある。
【００２０】
監視項目の中には、常に監視する必要はないが、特定の状況下において監視する必要がある監視項目も存在する。このような監視項目が多数存在する場合に、それらの監視を常に実行することによって監視負荷が高くなり、その負荷がアプリケーションの実行に大きな影響を与える可能性がある。この問題に対処するため、全ての監視を常に実行するのではなく、監視を実行する条件を設定し、必要に応じて監視の実行を制御する方法がある。特許文献５では、ある監視項目の値に応じて別の監視項目を取得するか否かを制御するシステムが開示されている。この制御によって、必要以上の監視負荷をかけずに、状況に応じて必要な監視を実行することができる。このシステムでは、監視データの閾値と、閾値を超えた場合に実行される監視項目とを設定することによって、監視を実行する条件が設定される。
【００２１】
また、特許文献６では、アプリケーションがログの出力に用いるログ出力装置において、ログの出力に要する所要時間を測定し、ログ出力の所要時間がアプリケーション全体の実行の所要時間に対して一定の割合以下となるようにログの出力レベルを調整するシステムが示されている。
【特許文献１】米国特許第６２６０１８７号明細書
【特許文献２】米国特許出願公開第２００５／０２７３６６７号明細書
【特許文献３】特表２００５−５２３５１８号公報
【特許文献４】特開２００３−２３３５１５号公報
【特許文献５】特開２００４−２０６４９５号公報
【特許文献６】特開２００１−１７５５０８号公報
【非特許文献１】ステファン・Ａ・ホワイト（Stephen A. White）著、日揮情報ソフトウェア株式会社翻訳、「ＢＰＭＮの概要」、［online］、２００４年５月、日揮情報ソフトウェア株式会社、［２００５年１２月１３日検索］、インターネット＜URL：http://www.jsys-products.com/iwaken/bpmn/pub/Introduction_to_BPMN.pdf＞
【非特許文献２】ビル・シャノン（Bill Shannon）、「ジャバ２  プラットフォーム  エンタープライズ  エディション  スペシフィケーション  v1.4（Java 2 Platform Enterprise Edition Specification, v1.4）」、［online］、２００３年１１月２４日、サンマイクロシステムズ社（Sun Microsystems, Inc.）、［２００５年６月２３日検索］、インターネット＜URL：http://java.sun.com/j2ee/j2ee-1_4-fr-spec.pdf＞
【非特許文献３】デビッド・Ｓ・フランケル（David S. Frankel）著、日本アイ・ビー・エム株式会社TEC-J MDA分科会翻訳、「ＭＤＡモデル駆動アーキテクチャ」、株式会社エスアイビー・アクセス、２００３年１１月１日
【非特許文献４】日本ＢＥＡシステムズ株式会社、「ＳＯＡ  サービス指向アーキテクチャ」、株式会社翔泳社、２００５年３月２２日
【非特許文献５】デビッド・チャペル（David Chappell）、「BizTalk Server 2004 の理解」、［online］、２００３年１０月、マイクロソフト株式会社、［２００５年６月２３日検索］、インターネット＜URL：http://download.microsoft.com/download/1/1/1/1118730e-ec93-45aa-8c06-97af628db61d/UnderstandingBizTalkServer2004_J.doc>
【非特許文献６】アドベントネット社（AdventNet, Inc.）、「マネージエンジン  ジェイエムエックス  スタジオ５  プロダクト  ドキュメンテーション（ManageEngine JMX Studio 5 Product Documentation）」、［online］、２００４年、アドベントネット社（AdventNet, Inc.）、［２００５年８月２日検索］、インターネット＜URL：http://manageengine.adventnet.com/products/jmx_studio/AdventNetManageEngineJMXStudio.pdf＞
【発明の開示】
【発明が解決しようとする課題】
【００２２】
これらアプリケーションプログラムを監視する従来の技術には、以下の様な問題があった。
【００２３】
第１に、従来の技術は、アプリケーションプログラムへ監視機能を追加又は変更するために、監視を実行するプログラムモジュールを自動的に生成し、生成したプログラムモジュールをアプリケーション実行中に適用する。しかし、このような従来の技術を利用するためには、監視を実行する場所（点）及び監視対象のデータをプログラムコードのレベルで入力する必要があった。
【００２４】
一般に、追加又は変更されるログを必要とするのは運用管理者又は業務管理者であることが多い。一般に、運用管理者及び業務管理者は、アプリケーションの実装プログラムコードを理解していない。そのため、運用管理者及び業務管理者は、従来の技術を利用するために必要な、監視する内容のプログラムコードレベルでの入力を行うことが出来ない。従って、プログラムコードを理解しているアプリケーションの設計者又はプログラマが、運用管理者又は業務管理者の要求を受けて必要な情報を作成し、入力する必要がある。この手間が、迅速な監視機能の追加又は変更の妨げとなるという問題がある。
【００２５】
この問題に対処するために、入力する情報を事前に準備しておき、その情報の中から、運用管理者が必要に応じて選択したものを適用することもできる。しかし、必要となる可能性があるあらゆる監視内容を事前に把握し、必要な入力情報を用意しておくことは困難である。従って、上記の方法では、事前に想定していなかった監視内容を追加する必要が生じた場合に対処できず、本質的な解決策にはならない。
【００２６】
第２に、従来の技術を用いることによって、アプリケーションの状態に応じて監視を実行する項目を制御することができる。ここで、監視の実行を制御する条件を指定する際に、条件の判定に用いる監視項目が指定される。さらに、状態に応じて制御する対象である監視項目が指定される。このとき、指定可能な監視項目がプログラムコードレベルで名前付けされている場合、プログラムコードを理解していない限り、適切に監視の制御を設定できない。また、条件の判定に用いたいデータを監視する機能が存在しない場合、新規に監視機能を追加する必要がある。
【００２７】
また、従来技術では、アプリケーションからの監視データの出力をフィルタリングすることによって監視の実行が制御される。そのため、監視のためのプログラムコードは、監視データの出力の有無に関わらず、アプリケーションプログラム中に組み込まれ、アプリケーションの実行に従って監視コードの処理を実行する。そのため、監視データの出力を制御しても、完全に監視負荷を削減することができなかった。
【００２８】
第３に、一般に、プログラムの実装を理解せずに監視負荷を見積もることは困難である。上記の第１の問題が解決されれば、アプリケーションプログラムの実装を意識することなくアプリケーションの監視機能を追加又は変更することができる。しかし、この場合、意図せずに監視負荷の高い監視機能をアプリケーションプログラムに追加してしまうことによって、アプリケーションプログラムの実行に重大な性能低下が引き起こされる可能性がある。
【００２９】
従来技術では、監視負荷はアプリケーション外部のログ出力装置において測定されるため、アプリケーションプログラム内部で処理される監視データの取得、生成及び外部への出力要求の処理の負荷を測定することが出来なかった。また、従来技術では、アプリケーションの監視機能全体の負荷が測定され、その結果に基づいて監視の実行が制御される。このため、個別の監視機能の負荷を測定し、その結果に基づいて監視の実行を制御することが出来なかった。
【００３０】
上記の点から、本発明が解決しようとする第１の課題は、業務管理者又は運用管理者が理解しうる業務プロセスレベルで、監視を実行する箇所及び監視するデータが指定されたときに、人手を介さずに、指定された監視を実行するプログラムモジュールを生成し、そのプログラムモジュールをアプリケーションプログラムへ挿入するために必要なプログラムコードレベルの指定をする方法を提供することである。
【００３１】
本発明が解決しようとする第２の課題は、アプリケーションの監視を条件に基づいて制御することによって、状況に応じて適切な監視を実行することを、プログラムの知識を必要とせずに可能とすることである。
【００３２】
本発明が解決しようとする第３の課題は、アプリケーションプログラムに新規の監視機能を追加した結果、追加された監視機能の負荷によってアプリケーションプログラムの実行に重大な性能低下が生じることを防止することである。
【課題を解決するための手段】
【００３３】
本願で開示する代表的な発明は、アプリケーションプログラムを実行する計算機システムにおいて、前記計算機システムは、前記アプリケーションプログラムの開発工程の一つの段階における設計情報の構成要素と、前記一つの段階より進んだ段階における設計情報の構成要素との対応関係を示す情報を保持し、前記対応関係を示す情報に基づいて、前記アプリケーションプログラムの開発工程の一つの段階における設計情報の構成要素と、前記アプリケーションプログラムのコードとを対応付けることを特徴とする。
【発明の効果】
【００３４】
本発明の一実施形態によれば、プログラムの実装を理解していない業務管理者又は運用管理者等であっても、業務の視点で理解できる上流のアプリケーション設計情報上で、アプリケーションプログラムの監視を指定することができる。指定された監視を実現するためのプログラムモジュールは、設計者又はプログラマの作業を必要とせずに、直ちにアプリケーションプログラムに追加され、又は変更される。また、プログラミング作業を必要とせずに、複数の監視機能を協調動作させ、アプリケーションプログラムの実行状態に応じた適切な監視を容易に実現することができる。さらに、不用意な監視設定が、アプリケーションプログラムの実行に重大な性能低下を引き起こすことを防止し、アプリケーション監視の設定を安全に行うことができる。
【発明を実施するための最良の形態】
【００３５】
以下、本発明の実施の形態について、図面を参照し説明する。
【００３６】
図１は、本発明の第１の実施の形態のアプリケーションプログラム監視システムの構成を示すブロック図である。
【００３７】
公知のアプリケーションサーバ１６０は、アプリケーションプログラム１７０を公知のプログラム記憶装置（図示省略）から読み込み、実行する。本実施の形態では、アプリケーションサーバ１６０がJava 2 Enterprise Edition（Ｊ２ＥＥ）（Javaは登録商標）アプリケーションサーバであり、アプリケーションプログラム１７０がＪ２ＥＥを用いて実装されたアプリケーションプログラムである場合を例として説明する。また、本実施の形態において、アプリケーションサーバ１６０は、実行するアプリケーションプログラム１７０を、バイトコードインスツルメンテーション技術を用いて実行中に書き換える機能、及び、書き換え機能を制御するインタフェース（図示省略）を備える。
【００３８】
ユーザインタフェース１１０は、本システムで実行されるアプリケーションプログラムの監視を設定及び管理するユーザインタフェースである。
【００３９】
対応検索部１１５は、設計対応関係記憶部１３０に記憶された情報を用いて、設計情報記憶部１２０に記憶された、アプリケーションの開発工程で作成された設計情報の構成要素間の対応関係を検索する。
【００４０】
ここで、設計情報とは、アプリケーションプログラム１７０の開発の際に用いられるモデル図等の総称である。設計情報の構成要素とは、設計情報上の点（箇所）又はデータ等である。例えば、設計情報の構成要素は、業務プロセス図におけるアクティビティ又は接続フローであってもよいし、ＵＭＬシーケンス図におけるメッセージであってもよいし、クラス図におけるクラス、メソッド又はフィールドであってもよいし、プログラムコードにおけるクラス、メソッド又はフィールドであってもよい。
【００４１】
管理部１４１は、設定に従って、アプリケーションサーバ１６０においてアプリケーションプログラム１７０の監視を実行するプログラムモジュールを生成し、さらに、生成したプログラムモジュールをアプリケーションプログラム１７０に挿入する。この監視を実行するプログラムモジュールをプローブと呼ぶ。
【００４２】
条件制御部１４３は、所定の条件に基づいてプローブの監視動作を制御する。
【００４３】
負荷制御部１４５は、プローブの監視動作の負荷によるアプリケーションプログラム１７０への影響を測定し、制御する。
【００４４】
公知の監視イベント出力部１８０は、アプリケーションプログラム１７０に対して、監視イベントを出力するApplication Programming Interface（ＡＰＩ）を提供する。監視イベント出力部１８０の例としては、JavaのロギングＡＰＩであるJava Logging API又はLog4J等がある。監視イベント出力部１８０は、公知の監視イベント記録部１９０に、監視イベントをユーザが指定した形式で出力する。監視イベント記録部１９０は、例えば、ファイルシステム又はデータベース等であってもよい。
【００４５】
図２４は、本発明の第１の実施の形態のアプリケーションプログラム監視システムの物理的な構成を示すブロック図である。
【００４６】
具体的には、図２４は、図１に示したシステムを実現するコンピュータシステムの一例を示している。このコンピュータシステムは、ＣＰＵ２７０３、主記憶２７０５、外部記憶装置２７０７、入力装置２７０９、出力装置２７１１及びネットワークインタフェース２７１３を備える。これらはバス２７０１によって接続されている。
【００４７】
ＣＰＵ２７０３は、主記憶２７０５に格納されたプログラムを実行するプロセッサである。以下の説明において、主記憶２７０５に格納されたプログラムが実行する処理は、実際にはＣＰＵ２７０３によって実行される。
【００４８】
主記憶２７０５は、例えば、半導体装置である。主記憶２７０５には、外部記憶装置２７０７から読み込まれたソフトウェアプログラム及びそのプログラムによって参照される情報等が格納される。
【００４９】
入力装置２７０９は、例えば、キーボード又はマウスである。
【００５０】
出力装置２７１１は、例えば、ディスプレイ装置である。
【００５１】
外部記憶装置２７０７は、例えば、ハードディスク装置である。図1に示す設計情報記憶部１２０、設計対応関係記憶部１３０及び監視イベント記録部１９０は、外部記憶装置２７０７内の記憶領域として実現される。これらの記憶部は、例えば、データベースとして実装されてもよい。さらに、図１に示すアプリケーションプログラム監視システムを構成するソフトウェアプログラムが外部記憶装置２７０７に格納される。
【００５２】
アプリケーションプログラム監視システムを構成するソフトウェアプログラムとは、具体的には、ユーザインタフェース１１０、対応検索部１１５、管理部１４１、条件制御部１４３、負荷制御部１４５及び監視イベント出力部１８０である。それらのソフトウェアプログラムが主記憶２７０５に読み込まれ、ＣＰＵ２７０３がそれらを実行することによって、図１に示すシステムが実現される。ユーザインタフェース１１０は、入力装置２７０９及び出力装置２７１１を用いて、ユーザからの入力の受け付け及びユーザへの情報の出力を実行する。
【００５３】
図１に示すシステムが、一つのコンピュータシステムによって実現される場合、外部記憶装置２７０７は、さらにアプリケーションサーバ１６０及びアプリケーションプログラム１７０を格納する。その場合、アプリケーションサーバ１６０及びアプリケーションプログラム１７０は、主記憶２７０５に読み込まれ、ＣＰＵ２７０３によって実行される。
【００５４】
図１に示すアプリケーションプログラム監視システムは、一つのコンピュータシステムではなく、ネットワークインタフェース２７１３を介して接続された複数のコンピュータシステムによって実現することもできる。その場合、図１に示す各部が複数のコンピュータシステム上に分かれて配置され、ネットワークインタフェース２７１３を介して接続される。
【００５５】
次に、図１に示す管理部１４１が、与えられたアプリケーションプログラムの監視設定に基づいてアプリケーションプログラムの監視を実行する処理の流れを、図３及び図４を参照して説明する。
【００５６】
図３は、本発明の第１の実施の形態の管理部１４１の構成を示す説明図である。
【００５７】
管理部１４１は、プローブ定義記憶部１６０１、プローブ生成部１６０４及びプローブ挿入部１６０８を含む。プローブ定義記憶部１６０１は、主記憶２７０５又は外部記憶装置２７０７に確保された記憶領域である。プローブ生成部１６０４及びプローブ挿入部１６０８は、管理部１４１に含まれるプログラムモジュールである。ユーザインタフェース１１０、アプリケーションサーバ１６０、アプリケーションプログラム１７０、監視イベント出力部１８０及び監視イベント記録部１９０は、図１に示したものと同一である。
【００５８】
アプリケーションプログラム１７０は、アプリケーションサーバ１６０に読み込まれ、実行される。
【００５９】
プローブ１６１０は、アプリケーションプログラム１７０に挿入され、アプリケーションプログラム１７０の監視を実行するプログラムモジュールである。
【００６０】
プローブ定義記憶部１６０１は、プログラムコードレベルで記述されたアプリケーションプログラム１７０の監視設定であるプローブ定義を記憶する。プローブ定義によって、アプリケーションプログラムにおける監視を実行する「場所（点）」と、監視する「項目」が、プログラムコードの構成要素を用いて明示的に指定される。
【００６１】
図４は、本発明の第１の実施の形態のプローブ定義記憶部１６０１の構成例を示す説明図である。
【００６２】
プローブ定義記憶部１６０１が記憶するプローブ定義は、プローブＩＤ１００１、プローブ番号１００２、プローブ名称１００３、プローブ挿入ポイント１０１２及び監視データ１０２１からなる。
【００６３】
プローブＩＤ１００１は、プローブ１６１０を一意に識別するためのＩＤであり、プローブ１６１０及びプローブ１６１０が出力する監視データを識別するために用いられる。
【００６４】
プローブ番号１００２は、同一のプローブＩＤ１００１を持つプローブ定義が複数存在する場合に、それらを識別する通し番号である。本実施の形態では、一つのプローブＩＤを持つプローブ定義は一つしか存在しないので、プローブ番号１００２は常に「１」となる。そのため、本実施の形態ではプローブ番号１００２は必須項目ではない。
【００６５】
プローブ名称１００３は、プローブ１６１０に付与された名称である。
【００６６】
プローブ挿入ポイント１０１２は、プローブ１６１０が挿入される場所（点）を指定する。具体的には、プローブ挿入ポイント１０１２は、アプリケーションプログラムの構成要素によって指定される。
【００６７】
監視データ１０２１は、プローブ１６１０が取得し、出力するデータを指定する。プローブ１６１０が取得し、出力するデータとは、通常、いわゆるアプリケーションログとして取得されるものである。プローブ１６１０は、アプリケーションログとして、例えば、アプリケーションプログラム１７０によって処理される入出力パラメータ等のデータ、又は、アプリケーションプログラム１７０の処理時間等を取得し、出力する（図３のＳ３０５参照）。
【００６８】
図４の例において、１行目のプローブ定義は、プローブＩＤ１００１が「Ｐ００１」であるプローブ１６１０が、メソッド「FuncA.method1（String d1,String d2）」に挿入され、メソッドの第１引数「d1」を監視データとして取得することを示している。また、３行目の監視データ１０２１の項目に指定された「__responseTime」は、メソッドの処理時間を示す。すなわち、３行目のプローブ定義は、プローブＩＤ１００１が「Ｐ００３」であるプローブ１６１０が、メソッド「FuncC.method3（Data2 d）」に挿入され、そのメソッドの処理時間を監視データとして取得することを示している。
【００６９】
本実施の形態において、プローブ１６１０は、公知技術であるアスペクト指向プログラミングにおけるアドバイスとして実現される。プローブ挿入部１６０８は、アドバイスとして定義されたプローブ１６１０のプログラムコードを、アスペクト指向プログラミングフレームワークによってアプリケーションプログラム１７０に組み込むことによって、プローブ１６１０をアプリケーションプログラム１７０に挿入する。プローブ１６１０を挿入する点は、プローブ定義で指定されるプローブ挿入ポイント１０１２に基づいて作成されたポイントカットをアスペクト指向プログラミングフレームワークへの入力とすることによって指定される。
【００７０】
アプリケーションプログラム１７０へのプローブ１６１０の挿入は、動的なアドバイスの組み込みをサポートするアスペクト指向プログラミングフレームワーク（Dynamic AOPフレームワーク）を用いることによって、アプリケーションプログラム１７０の実行中に、動的に実行することができる。Dynamic AOPフレームワークの例として、JBoss AOPがある。
【００７１】
なお、アプリケーションプログラム１７０の実行中に、動的にプログラムコードを更新する任意の技術を用いることによって、プローブ１６１０の形態及びプローブ１６１０のアプリケーションプログラム１７０への挿入を実現することができる。
【００７２】
また、プローブ１６１０は、アプリケーションプログラム１７０が実行されていないときに挿入されてもよい。しかし、プローブ挿入部１６０８がアプリケーションプログラム１７０の実行中にプローブ１６１０を挿入する機能を持たない場合、プローブ１６１０を挿入又は除去するときに、アプリケーションプログラム１７０の全体又は一部を停止し、その後再起動する必要がある。
【００７３】
次に、プローブ定義に基づいてアプリケーションプログラム１７０の監視を実行する処理の流れを、図３を参照して説明する。まず、管理部１４１内のプローブ生成部は、外部からの要求（Ｓ３０１）に応じて、プローブ定義記憶部１６０１からプローブ定義を取得する（Ｓ３０２）。この要求は、例えば、業務管理者又は運用管理者がユーザインタフェース１１０を使用して入力した要求である。そして、プローブ生成部１６０４は、指定されたデータを取得し、そのデータを監視データとして出力するプローブ１６１０のプログラムコードを、プローブ定義に監視データ１０２１の内容に基づいて、アスペクト指向プログラミングのアドバイスとして生成する。
【００７４】
プローブ１６１０のコード生成には、公知のプログラムコード自動生成技術が用いられる。具体的には、プローブ挿入ポイント１０１２及び監視データ１０２１を入力として与えられたプローブ生成部１６０４は、入力に従って、プローブ１６１０のプログラムコードを自動生成する。このとき生成されるプログラムコードは、入力されたプローブ挿入ポイント１０１２に対応するアプリケーションプログラム１７０のコード上の点で、入力された監視データ１０２１に対応するデータを取得し、そのデータを監視イベント出力部１８０のＡＰＩを用いて出力する（Ｓ３０５、Ｓ３０６）プログラムコードである。
【００７５】
図５は、本発明の第１の実施の形態においてアドバイスとして生成されるプローブ１６１０のコード例を示す説明図である。
【００７６】
図５は、図４に例示したプローブＩＤ１００１が「Ｐ００２」であるプローブ定義に基づいて生成されるプローブ１６１０の例を示している。プローブ１６１０は、Interceptorクラスを継承する一つのクラスとして、プローブ生成部１６０４によって生成される。一つのプローブに対して一つのプローブアドバイスが生成される。Staticフィールドlogger（５行目）は、監視データを出力する監視イベント出力部１８０へのインタフェースであり、プローブ１６１０の挿入時に実行される初期化コード（図示省略）によって設定される。
【００７７】
プローブアドバイスのメソッドinvokeが、アプリケーションプログラム監視を実行するコードである。invokeメソッドのコードが、Dynamic AOPフレームワークによってアプリケーションプログラム１７０の指定された点に挿入される。
【００７８】
invokeメソッドでは、まず、JBoss AOPが提供するＡＰＩを用いて、プローブが挿入されたメソッドの第一引数のオブジェクトを取得する（８行目）。更に、そのオブジェクトから特定のフィールドの値を取得し（９行目）、プローブ定義で指定された監視データを取得する。そして、出力する監視イベントオブジェクトeventを生成する（１０行目）。監視イベントオブジェクトには、プローブＩＤが設定される。このプローブＩＤは監視データを識別するために用いられる。次いで、loggerインタフェースを用いて、生成されたeventオブジェクトを監視イベント出力部１８０へ出力する（１１行目）。その後、このプローブ１６１０が挿入されたメソッド本体の処理を実行する（１２行目）。
【００７９】
プローブ挿入部１６０８は、プローブ生成部１６０４によって生成されたプローブ１６１０を、Dynamic AOPフレームワークによってアプリケーションプログラム１７０に動的に挿入する（図３のＳ３０４参照）。プローブ１６１０の挿入位置を指定するポイントカットは、プローブ定義のプローブ挿入ポイント１０１２に基づいて生成される。例えば、図４に示すプローブ定義において、プローブＩＤが「Ｐ００２」であるプローブ１６１０の挿入位置を指定するポイントカットは、“execution（* FuncB->method2（Data1））”となる。
【００８０】
プローブ挿入部１６０８は、プローブ１６１０を挿入するために、JBoss AOPが提供するアスペクトマネージャに、生成したプローブアスペクトのクラスオブジェクト、ポイントカット及びプローブＩＤを与える（図６参照）。
【００８１】
図６は、本発明の第１の実施の形態のプローブ１６１０をアプリケーションプログラム１７０に追加するためのプログラムコードの例を示す説明図である。
【００８２】
図６は、例として、図５に示すプローブ１６１０をアプリケーションプログラム１７０に挿入するために、プローブ挿入部１６０８によって生成されるプログラムコードを示す。以下、図６のプログラムコードによって実行される処理の手順を説明する。
【００８３】
まず、プローブ１６１０を挿入する位置を指定するポイントカットのAdviseBindingオブジェクトbindingを生成する（１行目）。
【００８４】
次に、生成したAdviseBindingオブジェクトの名称としてプローブＩＤを設定し（２行目）、プローブアドバイスのクラスを設定する（３行目）。
【００８５】
次に、このAdviseBindingオブジェクトをアスペクトマネージャに登録する（４行目）。
【００８６】
アスペクトマネージャは、登録されたAdviseBindingオブジェクトに設定されたポイントカット及びアドバイスクラスに従って、アプリケーションプログラム１７０のバイトコードを書き換えることによって、プローブアドバイスのプログラムコードを挿入する。
【００８７】
また、プローブ挿入部１６０８は、外部からの要求に応じて、既にアプリケーションプログラム１７０に挿入されているプローブ１６１０を、Dynamic AOPフレームワークの機能を用いてアプリケーションプログラム１７０から除去することもできる。プローブ１６１０の除去は、アスペクトマネージャのremoveBindingメソッドを、除去するプローブ１６１０のＩＤを引数として呼び出すことによって実行される。アスペクトマネージャは、アプリケーションプログラム１７０のバイトコードを書き換えることによって、引数として渡されたプローブＩＤを名称とするAdviseBindingオブジェクトに設定されたアドバイスのプログラムコードを取り除く。
【００８８】
次に、対応検索部１１５が設計対応関係を用いて、「監視を実行する点」の設計情報上における指定に対して、対応するプログラムコード上の点、即ち、プローブ定義におけるプローブ挿入点を検索する処理の流れを説明する。
【００８９】
最初に、設計対応関係について、図７の例を参照して説明する。
【００９０】
図７は、本発明の第１の実施の形態の設計対応関係の例を示す説明図である。
【００９１】
設計対応関係は、設計対応関係記憶部１３０に記憶される。設計対応関係は、対応元要素６０１及び対応先要素６０３からなる。対応元要素６０１には、アプリケーションプログラム開発工程の任意の段階で作成された設計情報の構成要素が記憶される。対応先要素６０３には、対応元要素６０１として記憶された各構成要素と設計対応関係にある構成要素が記憶される。設計対応関係にある構成要素とは、より開発工程の進んだ段階で作成された設計情報の構成要素である。例えば、図７の設計対応関係６１１として、対応元要素６０１「A01.機能１」及び対応先要素６０３「B02.機能１.処理１（データ１ X）」が記憶されている。これは、ある段階の開発工程における構成要素「A01.機能１」が、一段階進んだ開発工程においては、構成要素「B02.機能１.処理１（データ１ X）」となることを意味する。
【００９２】
なお、一つの構成要素に対して、一つ又は複数の構成要素が設計対応関係にある場合がある。本実施の形態では、一つの構成要素に対して一つの構成要素のみが対応する場合について説明する。一つの構成要素に対して複数の構成要素が対応する場合については、第２の実施の形態において後述する。
【００９３】
複数の設計情報にわたって任意の構成要素を特定し、構成要素間の設計対応関係を表現するために、設計情報の各構成要素には、それらを一意に識別するＩＤが付与される。このＩＤが、設計対応情報として記憶される。本実施の形態では、このＩＤをオブジェクトＩＤと呼ぶ。
【００９４】
本実施の形態では、オブジェクトＩＤは、それが識別する構成要素を含む設計情報のＩＤと、各構成要素のＩＤとによって構成される。例えば、図７の例において、設計対応関係６１１の対応元要素のオブジェクトＩＤ”A01.機能1"”は、ＩＤがA01である業務プロセス図に存在する、機能1を表すアクティビティ要素を示す。設計情報のＩＤは、アプリケーションプログラム１７０の開発工程の段階を示すアルファベット（例えば、A）と、各段階における設計情報の通し番号（例えば、01）で表す。
【００９５】
オブジェクトＩＤは、設計情報の構成要素を一意に識別できればよい。また、オブジェクトＩＤから、それが指す構成要素を含む設計情報を特定することができればよい。従って、オブジェクトＩＤは、その一部に設計情報のＩＤを含んでいることが望ましい。
【００９６】
図７は、A、B及びCの三つの段階の設計情報を用いて開発されたアプリケーションプログラム１７０について、段階Aの業務プロセス図の２つのアクティビティ要素（機能１及び機能２）に関する設計対応関係を示している。具体的には、図７の例の設計対応情報は、処理（メソッド）の設計対応関係（６１１、６１２、６１４、６１７、６３１、６３２）、処理の入力データの設計対応関係（６１５、６１６）、及び、処理の入力データに用いるデータ構造の設計対応関係（６２０〜６２２）を記憶している。
【００９７】
処理の入力データの設計対応関係を示すために、各入力データのオブジェクトＩＤが用いられる。入力データのオブジェクトＩＤは、処理の名称と、入力データの表現とを連結することによって構成される。例えば、設計対応関係６１５では、設計情報B02におけるメソッド“機能1.処理１”の入力データ“X.a”と、設計情報C 02におけるメソッド“FuncA.method1”の入力データd1とが対応していることを示している。
【００９８】
また、設計対応関係６３１及び６３２は、設計情報C02の構成要素が、実装されたアプリケーションプログラム１７０の特定のメソッドに対応していることを示している。
【００９９】
本発明において、設計対応情報の生成、及び、その設計対応情報の設計対応情報記憶部１３０への蓄積は、任意の方法によって実行することができる。ただし、アプリケーションプログラム１７０の開発工程で作成される各設計情報に対して、適切な設計対応情報が記憶されている必要がある。
【０１００】
設計対応情報の生成及び設計対応情報記憶部への蓄積は、アプリケーションプログラム１７０の開発工程において、開発工程の段階が進んだ設計情報が作成されるたびに実行されることが望ましい。そのために、アプリケーションプログラム１７０の開発工程で使用されるアプリケーション設計ツールが、設計対応情報の生成及び記憶を実行する機能を備えることが望ましい。
【０１０１】
次に、設計情報上で指定された「監視する点（すなわち、監視の対象の点）」から、指定された監視を行うプローブを挿入する点を、記憶された設計対応関係を用いてプログラムコードレベルで検索する処理の流れを、図８を参照して説明する。
【０１０２】
図８は、本発明の第１の実施の形態の対応検索部１１５がプローブ１６１０を挿入する点を検索する処理のフローチャートである。
【０１０３】
図８の説明では、図７に示した設計対応関係の例を用いる。
【０１０４】
ユーザ（例えば、業務管理者又は運用管理者）が設計情報の構成要素を指定することによって、監視する点が指定される。指定された構成要素のオブジェクトＩＤが、対応検索部１１５に入力される。
【０１０５】
まず、ステップ１２０１において、対応検索部１１５は、入力されたオブジェクトＩＤによって変数oidを初期化する。
【０１０６】
次に、ステップ１２０２において、対応検索部１１５は、oidをキーとして設計対応関係記憶部１３０にアクセスし、oidを対応元要素６０１とする設計対応関係を検索する。そして、対応検索部１１５は、この検索の結果取得された設計対応関係の対応先要素６０３に記憶されているオブジェクトＩＤを変数nextOidに格納する。
【０１０７】
次に、ステップ１２０３において、対応検索部１１５は、nextOidがアプリケーションプログラム１７０の実装プログラムコードの構成要素と対応していることを表す特別なオブジェクトＩＤであるか否かを判定する。実装プログラムコードの構成要素とは、例えば、特定のメソッド等である。
【０１０８】
ステップ１２０３において、nextOidがアプリケーションプログラム１７０の実装プログラムコードの構成要素を識別する特別なＩＤであると判定された場合、検索された構成要素は、特定のメソッド等と対応している。その場合、処理はステップ１２０５に移行し、対応検索部１１５は、nextOidが示すプログラムコード要素を検索結果として出力し、処理を終了する。
【０１０９】
一方、ステップ１２０３において、nextOidがアプリケーションプログラム１７０の実装プログラムコードの構成要素を識別する特別なＩＤでないと判定された場合、指定された構成要素に対応する実装プログラムコードの構成要素がまだ検索されていない。この場合、対応検索部１１５は、ステップ１２０４において、検索されたnextOidの値でoidを更新し、ステップ１２０２に戻る。
【０１１０】
ステップ１２０２乃至ステップ１２０４の処理を繰り返すことによって、抽象度の高い、開発工程の初期の設計情報の構成要素から、開発工程の各段階の設計情報の構成要素を段階を追って検索し、最終的にプログラムコードの構成要素が検索される。
【０１１１】
例えば、図７に示した設計対応関係の例において、業務プロセス図「A01」のアクティビティ「機能１」が監視するポイントとして指定された場合について説明する。この場合、そのオブジェクトＩＤである“A01.機能1”がoidの初期値となる（ステップ１２０１）。その後、対応検索部１１５は、ステップ１２０２から１２０４を繰り返し実行することによって、設計対応関係を順に検索する。
【０１１２】
検索の結果、“A01.機能1”と対応する“B02.機能1.処理1（データ1 X）”が取得され（対応関係６１１）、“B02.機能1.処理1（データ1 X）”と対応する“C02.FuncA.method1（String d1,String d2）”が取得され（対応関係６１４）、“C02.FuncA.method1（String d1,String d2）”と対応する“CODE.FuncA.method1（String d1,String d2）”が取得される（対応関係６３１）。
【０１１３】
“CODE.FuncA.method1（String d1,String d2）”がプログラムコードの構成要素であるため（ステップ１２０３）、メソッド“FuncA.method1（String d1,String d2）”が機能１に対応するプログラムコードの要素であることが検索される（ステップ１２０５）。このメソッドにプローブ１６１０を挿入することによって、「機能１」における監視が実行される。指定された点において監視する対象が、挿入するプローブを個別に生成する必要がないものである場合、検索されたプログラムコード上のポイントに事前に用意されたプローブアドバイスを挿入することによって、指定された監視を実行する。挿入するプローブを個別に生成する必要がない監視対象とは、例えば、処理時間である。
【０１１４】
以上の処理によって、設計情報上で指定された「監視する点」に対応するプログラムコード上のポイントが、記憶した設計対応関係を用いて検索される。そして、検索されたポイントの監視が実行される。その結果、実装されたプログラムコードを意識する必要なく、アプリケーションプログラム開発工程で作成した設計情報上でアプリケーションプログラム１７０の監視を指定することが実現される。
【０１１５】
上記図８は、「監視する点」が設計情報上で指定された場合の対応検索部１１５の処理である。一方、設計情報上の任意のデータが、「監視するデータ（すなわち、監視対象のデータ）」として指定される場合もある。設計情報上の任意のデータとは、業務プロセス上で処理されるデータであり、例えば、いずれかの処理の入出力パラメータである。続いて、「監視するデータ」が設計情報上で指定された場合に、対応検索部１１５が実行する処理の流れを説明する。この場合、対応検索部１１５は、設計対応関係を参照して、指定された「監視するデータ」に対応するプログラムコードの構成要素、即ち、プローブ定義における監視データ１０２１を検索する。
【０１１６】
「監視するデータ」の検索は、前述した「監視する点」の検索と同様の処理によって実行される。
【０１１７】
設計対応関係には、設計情報間の「処理」の対応関係だけでなく、「データ構造」及び「入出力パラメータ」の対応関係も含まれる。例えば、図７において、設計対応関係６１５及び６１６は、設計対応関係にある処理の入力パラメータ同士の対応関係を示している。設計対応関係６１５は、処理１の入力パラメータ「X」のフィールド「a」が、処理１に対応するメソッド「method1」の第１引数に対応することを示している。
【０１１８】
設計対応関係６２０乃至６２２は、データ構造「データ１」と、データ構造「Data1」の各フィールドとの対応関係を示す。
【０１１９】
例えば、アプリケーションプログラム開発工程のある段階のクラス図「B02」において、クラス「機能１」のメソッド「処理１」の入力パラメータ「X」について、そのフィールド「b」を監視することを指定する場合、運用管理者又は業務管理者は、対応検索部への入力としてオブジェクトＩＤ“B02.機能１.処理１#X.b”を与える。以降、図８に示したフローに従って設計対応関係をたどることによって、実装されたプログラムにおいては、クラス「FuncA」のメソッド「method1」における第２引数「d2」が、指定された監視するデータに対応していることが検索される。この例の場合、監視するデータと共に、監視する点も同時に指定される。このため、検索によって、プローブを挿入するポイントと、プローブが取得するデータの両方が決定され、指定された監視が実行される。
【０１２０】
設計対応関係記憶部には、監視を実行する点及びデータとして指定可能な全ての構成要素についての設計対応関係が記憶されてもよい。しかし、複数の設計対応関係又は設計情報に関する情報を組み合わせることによって、別の設計対応関係を類推することができる場合、その類推可能な設計対応関係の記憶を省略することによって、設計対応関係の記憶に要するコストを削減することができる。
【０１２１】
図７の設計対応関係６１７の例は、対応元の処理における入力パラメータ「X」が対応先の処理の入力パラメータ「d1」に対応していることを示している。しかし、入力パラメータ「X」の個々のフィールドについての設計対応関係は記憶されていない。しかし、入力パラメータ「X」のデータ構造である“B11.データ1”と、入力パラメータ「d1」のデータ構造である“C11.Data1”の設計対応関係６２０乃至６２２を用いることで、記憶されていない設計対応関係を類推することができる。その処理の流れを図９を用いて説明する。
【０１２２】
図９は、本発明の第１の実施の形態の対応検索部１１５が設計対応関係を類推する処理のフローチャートである。
【０１２３】
この処理は、図８に示した設計対応関係を用いてプログラムコード要素を特定するフローにおける、ステップ１２０２の処理に相当する。
【０１２４】
まず、ステップ１３０１において、対応検索部１１５は、入力されたオブジェクトＩＤを変数oidに格納する。上記の例では、オブジェクトＩＤとして、“B02.機能2.処理2#X.a”、すなわち、「処理2」のパラメータ「X」のフィールド「a」が入力される。
【０１２５】
次に、ステップ１３０３において、対応検索部１１５は、oidをキーとして、設計対応関係記憶部１３０にアクセスし、oidを対応元要素６０１とする設計対応関係を検索する。
【０１２６】
次に、ステップ１３０５において、対応検索部１１５は、oidに関する設計対応関係が存在するか否かを判定する。具体的には、対応元要素６０１がoidである設計対応関係が設計対応関係記憶部１３０に記憶されているか否かを判定する。
【０１２７】
ステップ１３０５において、oidに関する設計対応関係が存在すると判定された場合、対応検索部１１５の処理はステップ１３０７に進む。
【０１２８】
ステップ１３０７において、対応検索部１１５は、検索した設計対応関係の対応先要素６０３を検索結果として出力し、処理を終了する。
【０１２９】
ステップ１３０５において、oidに関する設計対応関係が存在しないと判定された場合、対応検索部１１５の処理はステップ１３０９に進む。例えば、oidが“B02.機能2.処理2#X.a”である場合、そのoidを対応元要素６０１として持つ設計対応関係が存在しない。この場合、処理はステップ１３０９に進む。
【０１３０】
ステップ１３０９において、対応検索部１１５は、oidが指す構成要素の上位の構成要素を特定する。例えば、oidが“B02.機能2.処理2#X.a”である場合、フィールド「a」を削除した“B02.機能2.処理2#X”が上位の構成要素である。この場合、対応検索部１１５は、“B02.機能2.処理2#X.a”に代わって“B02.機能2.処理2#X”を新たなoidとして、設計対応関係を検索する。
【０１３１】
次に、ステップ１３１１において、対応検索部１１５は、oid（すなわち、ステップ１３０９で特定された上位の構成要素）に関する設計対応関係が記憶されているか否かを判定する。この判定は、ステップ１３０５と同様にして実行される。
【０１３２】
ステップ１３１１において、oidに関する設計対応関係が記憶されていないと判定された場合、対応検索部１１５は、ステップ１３０９に戻り、更に上位の構成要素を特定し、検索する。
【０１３３】
ステップ１３１１において、oidに関する設計対応関係が記憶されていると判定された場合、対応検索部１１５は、ステップ１３１３に進む。
【０１３４】
ステップ１３１３において、対応検索部１１５は、上位の構成要素と設計対応関係にある構成要素を取得する。例えば、上位の構成要素が“B02.機能2.処理2#X”である場合、この構成要素は１つのパラメータXを持つ「B02.機能2.処理2」という処理である。これは設計対応関係６１７の対応元要素であるB02.機能2.処理2（データ1 X）に相当し、これに関する設計対応関係６１７が記憶されている。この場合、上位の構成要素に対応する構成要素として“C02.FuncB.method2#d1”が取得される。
【０１３５】
ステップ１３１５において、対応検索部１１５は、ステップ１３１３で検索された上位の構成要素の設計対応関係に基づいて、下位の構成要素の設計対応関係を類推する。例えば、ステップ１３１３において“C02.FuncB.method2#d1”が取得された場合、対応検索部１１５は、パラメータ「X」のデータ構造「B11.データ１」について、そのフィールド「a」の設計対応関係を検索する。その結果、パラメータ「D1」のデータ構造「C11.Data1」における「fieldA」が対応することが検索される（設計対応関係６２１参照）。このため、対応検索部１１５は、“B02.機能2.処理2 #X.a”と設計対応関係にある構成要素として“C02.FuncB.method2#d1.fieldA”を類推し、設計対応関係の検索結果として出力する。
【０１３６】
上記のフローにおける上位の構成要素の特定及びそれに基づく設計対応関係の類推は、構成要素の存在する設計情報及び構成要素の種類に応じて事前に定義されたルールに従って実行される。このルールに従って、設計対応関係記憶部１３０に記憶される設計対応情報を一部省略し、記憶のコストを削減することができる。
【０１３７】
次に、図１に示したユーザインタフェース１１０について説明する。
【０１３８】
図１０は、本発明の第１の実施の形態における、設計情報上でアプリケーションプログラム１７０の監視設定を実行するユーザインタフェース１１０の例の説明図である。
【０１３９】
図１０に示すユーザインタフェース１１０は、アプリケーションプログラム開発の一設計段階で作成された設計情報の上で、ユーザ（例えば、運用管理者又は業務管理者）が、アプリケーションプログラム１７０において監視を実行する点（監視ポイント）及び監視する対象のデータ（監視データ）を入力することを可能とする。
【０１４０】
設計情報表示ウィンドウ５５０は、ユーザが監視する内容を入力する設計情報を表示するウィンドウである。ユーザは、このウィンドウに表示される設計情報５５２の構成要素５５１を、例えば構成要素をクリックする等の操作によって選択することによって、監視ポイントを指定する。
【０１４１】
監視ポイントが指定されると、ユーザインタフェース１１０は、指定された監視ポイントにおいて監視可能な項目のリスト５６２を監視データ選択ウィンドウ５６０に表示する。ユーザは、項目リスト５６２に表示される各データ項目に対応するラジオボタン５６１をチェックすることによって、指定した監視ポイントにおいて監視するデータを選択することができる。
【０１４２】
監視データを選択した後、ユーザが決定ボタン５６３を操作することによって、指定された監視ポイント及び監視データが決定され、対応検索部１１５による検索が実行される。
【０１４３】
監視データとして、監視ポイントに固有でないデータ、例えば、処理時間等が指定されている場合、対応検索部１１５による検索は、指定された監視ポイントのオブジェクトＩＤをキーとして実行される（図８参照）。そして、検索されたプログラムコードの構成要素は、生成されるプローブ定義のプローブ挿入ポイント１０１２に記憶される。またプローブ定義の監視データ１０２１には、処理時間等、選択された監視データを表す予め定義されたシンボルが記憶される。
【０１４４】
指定された監視データが、監視ポイントに固有の入出力パラメータ等である場合、そのデータを表すオブジェクトＩＤをキーとして、対応検索部１１５による検索が実行される（図８参照）。その結果、検索されるプログラムコードの構成要素は、指定された監視ポイントに対応するプログラムコード上のポイントと、そのポイントにおいて扱われるデータの両方の情報を持つ。このため、検索された構成要素に従って、生成されるプローブ定義のプローブ挿入ポイント１０１２に、監視ポイントに対応するプログラムコード上のポイントが記憶され、監視データ１０２１に、そのポイントにおいて扱われるデータが記憶される。
【０１４５】
プローブ定義を記憶する際に、ユーザインタフェース１１０は、入力された監視の設定に付与する名称をユーザに入力させるインタフェースを表示する。そして、ユーザインタフェース１１０は、入力された名称をプローブ定義のプローブ名称１００３に記憶する。さらに、ユーザインタフェース１１０は、プローブ定義を一意に識別するＩＤを生成し、そのＩＤをプローブ定義のＩＤ１００１として記憶する。
【０１４６】
図１１は、本発明の第１の実施の形態の監視設定テーブルの例を示す説明図である。
【０１４７】
監視設定テーブルは、ユーザが入力した監視の設定及びそれに基づいて生成されたプローブ１６１０を管理するためのテーブルである。監視設定テーブルは、ユーザインタフェース１１０の一部であってもよいし、ユーザインタフェース１１０がアクセスすることができるいずれかの記憶部（例えば、設計情報記憶部１２０）の一部であってもよい。いずれの場合であっても、監視設定テーブルは、主記憶２７０５又は外部記憶装置２７０７に格納される。
【０１４８】
ＩＤ９０１には、個々の監視設定を一意に識別するＩＤが格納される。
【０１４９】
監視設定名称９０３には、監視設定に付与された名称が格納される。
【０１５０】
監視ポイント９１２には、入力された監視する箇所のオブジェクトＩＤが格納される。
【０１５１】
監視データ９２１には、入力された監視するデータのオブジェクトＩＤ、又は、予め定義された監視データ項目のシンボルが格納される。予め定義された監視データ項目のシンボルとは、例えば、“__responseTime”等である。
【０１５２】
監視設定テーブルのＩＤ９０１及び監視設定名称９０３には、生成されるプローブ定義のＩＤ１００１及びプローブ名称１００３と同じものが格納される。監視設定とプローブ定義において、同一のＩＤを用いることで、監視設定とプローブ定義が対応付けられる。
【０１５３】
ユーザインタフェース１１０は、監視設定テーブルに格納された監視ポイント９１２及び監視データ９２１の情報を参照して、設定済みのプローブ１６１０の情報を設計情報上に表示し、さらに、ユーザに選択させることができる。
【０１５４】
例えば、ユーザが、図１０に示す画面を操作して、監視ポイント“A01.機能1”に対応する箇所において、監視データ“データ1.a”に対応するデータを監視することを指定した場合、監視設定テーブルの監視ポイント９１２に“A01.機能1”が記憶され、監視データ９２１に“データ1.a”が記憶される。さらに、ＩＤ９０１及び監視設定名称９０３に、上記の監視ポイント等を識別する情報が記憶される。図１１の例では、監視ポイント“A01.機能1”及び監視データ“データ1.a”を識別するＩＤ９０１及び監視設定名称９０３として、それぞれ、“Ｐ００１”及び“処理１入力データ”が記憶される（図１１の１行目参照）。
【０１５５】
この場合、対応検索部１１５は、“A01.機能1”及び“データ1.a”を入力として、図８及び図９に示す処理を実行する。その結果、例えば、プローブ挿入ポイント及び監視データとして、それぞれ“FuncA.method1（String d1,String d2）”及び“d1”が取得される。この場合、プローブ定義記憶部１６０１のＩＤ１００１及びプローブ名称１００３として、監視設定テーブルと同様、“Ｐ００１”及び“処理１入力データ”が記憶される。そして、プローブ挿入ポイント１０１２及び監視データ１０２１として、それぞれ、検索の結果取得された“FuncA.method1（String d1,String d2）”及び“d1”が記憶される（図４の１行目参照）。
【０１５６】
監視ポイント及び監視データを指定するために設計情報表示ウィンドウ５５０に表示される設計情報として、ユーザの入力に応じてアプリケーション開発工程の任意の段階で作成された任意の設計情報を用いることができる。このとき、表示されている設計情報の構成要素と設計対応関係にある構成要素を含む設計情報を、設計対応情報を用いて検索し、検索された設計情報を、表示する設計情報の候補として表示し、表示された候補のいずれかをユーザに選択させることもできる。
【０１５７】
また、ユーザインタフェース１１０は、監視定義の設定において、設定する監視定義に付与する監視定義ＩＤおよび監視定義で設定される個々の監視項目に付与する監視項目ＩＤの値を入力させるユーザインタフェースを設けてもよい。あるいは、ユーザインタフェース１１０は、監視定義ＩＤ及び監視項目ＩＤを自動的に生成し、それらを設定してもよい。
【０１５８】
監視設定のためのユーザインタフェース１１０の構成及び入力の手順は、本実施の形態で示した例に限定されず、監視ポイント、及び、監視ポイントにおいて監視する項目、さらに必要に応じて、監視定義ＩＤ及び監視項目ＩＤを入力できるインタフェースであればよい。
【０１５９】
上記のように、図１に示すシステムを用いれば、ユーザがアプリケーションプログラムの開発工程の一段階の設計情報において、実行したいアプリケーションプログラムの監視を設定すると、入力された設定と実装されたプログラムとの対応付けが、人手を介することなく自動的に実行される。このため、設定されたアプリケーションプログラムの監視を直ちに実行することができる。
【０１６０】
次に、アプリケーションプログラム１７０に挿入されるプローブ１６１０の監視動作を、指定された条件に従って制御するシステムの構成及び動作について説明する。
【０１６１】
図１２は、本発明の第１の実施の形態のプローブ１６１０の監視動作を条件に従って制御するシステムの構成を示すブロック図である。
【０１６２】
条件制御部１４３は、プローブ制御定義記憶部１６０２、設定部１６０９、条件判定部１６０６及びプローブ制御部１６０７を備える。管理部１４１は、図３に示したものと同一である。
【０１６３】
プローブ制御定義記憶部１６０２は、主記憶２７０５又は外部記憶装置２７０７に確保された記憶領域である。条件判定部１６０６、プローブ制御部１６０７及び設定部１６０９は、条件制御部１４３に含まれるプログラムモジュールである。
【０１６４】
プローブ１６１０は、図３に示す管理部１４１によってアプリケーションプログラム１７０に挿入されるプログラムモジュールである。一つ又は複数のプローブ１６１０がアプリケーションプログラム１７０に挿入されてもよい。
【０１６５】
監視イベント出力部１８０ａは、図１に示す公知の監視イベント出力部１８０にコレクタ１６２０を追加したものである。
【０１６６】
コレクタ１６２０は、プローブ１６１０が出力したデータを取得し、必要に応じてそのデータを条件判定部１６０６に転送するプログラムモジュールである。
【０１６７】
データ取得部１６３０は、アプリケーションサーバ１６０等に配置され、状態監視データ及び外部情報を取得するプログラムモジュールである。図１２は、アプリケーションサーバ１６０上にデータ取得部１６３０が配置されている例を示している。
【０１６８】
データ取得部１６３０は、プローブ１６１０が監視するデータ以外の情報を取得する。具体的には、データ取得部１６３０は、例えば、アプリケーションプログラム１７０、アプリケーションサーバ１６０、アプリケーションサーバ１６０を実行するＯＳ及びハードウェア、又は、アプリケーションプログラムを監視するシステムそのものの状態監視データを取得する。例えば、データ取得部１６３０は、状態監視データとして、ＣＰＵ２７０３の負荷を取得してもよい。
【０１６９】
データ取得部１６３０は、上記の状態監視データの他に、時刻等の外部情報を取得してもよい。
【０１７０】
プローブ制御定義記憶部１６０２は、プローブ制御定義を記憶する。プローブ制御定義とは、アプリケーションプログラム１７０に挿入されたプローブ１６１０の監視動作を制御する条件、及び、プローブ１６１０の監視動作を制御する操作を指定する情報である。プローブ１６１０の監視動作とは、例えば、監視データの取得又は出力である。
【０１７１】
このプローブ制御定義に基づいて、設定部１６０９は各部を設定し、プローブ１６１０の監視動作を制御する。
【０１７２】
まず、プローブ制御定義に基づいてプローブ１６１０の監視動作を制御する処理の流れを説明する。
【０１７３】
図１３は、本発明の第１の実施の形態のプローブ制御定義記憶部１６０２の構成例を示す説明図である。
【０１７４】
プローブ制御定義記憶部１６０２に記憶されるプローブ制御定義は、ＩＤ１８０１、制御条件１８０３及び制御操作１８０５を含む。ＩＤ１８０１は、各プローブ制御定義を識別する。制御条件１８０３は、プローブ１６１０の監視動作を制御する条件を指定する。制御操作１８０５は、プローブ１６１０の監視動作を制御する操作を指定する。
【０１７５】
プローブ１６１０の監視動作の制御は、IF-THEN形式で記述される。具体的には、IF部分が制御条件１８０３に、THEN部分が制御操作１８０５に相当する。言い換えると、制御条件１８０３に記憶された条件が成立するときに、制御操作１８０５に記憶された操作が実行される。
【０１７６】
制御条件１８０３は、条件判定に用いるデータを含む条件式によって記述される。条件判定に用いるデータとして、アプリケーションプログラム１７０に挿入されたプローブ１６１０が取得する監視データを指定することができる。あるいは、予めシステムに用意されたデータ取得部１６３０によって取得される情報が指定されてもよい。
【０１７７】
それら条件判定に用いるデータを判定情報と呼ぶ。各判定情報は、一意のＩＤによって識別される。制御条件を表す条件式は、判定情報のＩＤを用いて記述される。プローブ１６１０によって取得される監視データが判定情報として使用される場合、図４に示したプローブ定義におけるプローブＩＤ１００１が判定情報のＩＤとなる。データ取得部１６３０によって取得されるデータは、予め付与された特別なＩＤによって指定される。
【０１７８】
制御操作１８０５には、制御条件１８０３が成立する場合に実行される制御の方法、及び、その方法によって監視動作が制御されるプローブ１６１０が記憶される。さらに、必要であれば、制御のパラメータも記憶される。
【０１７９】
プローブ１６１０の監視動作の制御方法とは、例えば、プローブ１６１０による監視動作の開始又は停止である。あるいは、時間又はアプリケーションプログラム１７０の実行回数によって設定された所定の間隔ごとに、監視データの取得及び出力を実行させることによって、プローブ１６１０の監視動作を制御してもよい。
【０１８０】
プローブ１６１０の監視動作の開始又は停止は、プローブ挿入部１６０８が、アプリケーションプログラム１７０へプローブ１６１０を挿入する（insert）、あるいは、アプリケーションプログラム１７０からプローブを除去する（remove）ことによって実行することができる。あるいは、プローブ１６１０に監視動作の実行を制御する動作制御コード（図示省略）を組み込み、動作制御コードを制御する変数を割り当ててもよい。この変数を動作制御変数と呼ぶ。動作制御コードが動作制御変数を参照して監視動作の実行の可否を判定することによってプローブの監視動作を制御（停止（di sable）又は開始（enable））することもできる。動作制御変数は、プローブ１６１０及びプローブ制御部１６０７の両方からアクセス可能なメモリ領域に格納される。
【０１８１】
図１３の１行目は、プローブＩＤがＰ００３であるプローブ１６１０の監視データの一定期間の平均値が１０を上回った場合に、プローブＩＤがＰ００４であるプローブをアプリケーションプログラム１７０から除去することを示している。２行目は、プローブＰ００２の監視データの値が５を下回ると、プローブＰ００５の動作を停止することを示している。３行目は、プローブＰ００１の値がＡで始まる文字列である場合に、プローブＰ００６の動作を開始することを示している。
【０１８２】
上記のシステムによってプローブ１６１０の監視動作を制御する処理の流れを説明する。
【０１８３】
まず、アプリケーションプログラム１７０の実行に従って、アプリケーションプログラム１７０に挿入されたプローブ１６１０が監視データを出力する（Ｓ１２０１）。出力される監視データは、監視イベント出力部１８０ａを経由して出力される。このとき監視イベント出力部１８０ａ内のコレクタ１６２０は、監視データが判定情報として用いられるデータであるか否かを判定する。監視データが判定情報として用いるデータであると判定された場合、監視イベント出力部１８０ａは、その監視データを条件判定部１６０６に転送する（Ｓ１２０２）。
【０１８４】
一方、判定情報がプローブ１６１０の監視データ以外のデータである場合、データ取得部１６３０は定期的にデータを取得し、取得したデータを条件判定部１６０６に送信する（Ｓ１２０３）。あるいは、条件判定部１６０６が定期的にデータ取得部１６３０を呼び出すことによって、判定情報として用いるデータを取得してもよい。
【０１８５】
条件判定部１６０６は、コレクタ１６２０又はデータ取得部１６３０から取得した判定情報を用いて、制御条件１８０３に記憶された条件式を評価し、評価した結果をプローブ制御部１６０７へ送信する（Ｓ１２０４）。プローブ制御部１６０７は、条件判定部１６０６から受信した条件判定の結果に応じて、制御操作１８０５に記憶された操作を実行することによって、プローブ１６１０の監視動作を制御する（Ｓ１２０５）。
【０１８６】
次に、設定部１６０９がプローブ制御定義に基づいて、プローブ１６１０の監視動作の制御を実行するように、条件判定部１６０６及びプローブ制御部１６０７を設定する処理の流れを図１４及び図１５を参照して説明する。
【０１８７】
図１４は、本発明の第１の実施の形態の設定部１６０９が条件判定部１６０６を設定する処理のフローチャートである。
【０１８８】
設定部１６０９は、プローブ定義に基づいて、図１４のフローを実行することによって条件判定部１６０６を設定する。
【０１８９】
まず、ステップ２００１において、設定部１６０９は、プローブ制御定義記憶部１６０２からプローブ制御定義を取得する。
【０１９０】
次に、ステップ２００３において、設定部１６０９は、プローブ定義の制御条件１８０３を解析し、判定情報の指定を抽出する。
【０１９１】
次に、設定部１６０９は、ステップ２００３で抽出された全ての判定情報について、ステップ２００５乃至２００８の処理を実行する。
【０１９２】
ステップ２００５において、設定部１６０９は、判定情報として指定されたデータのＩＤに基づいて、データがプローブ１６１０によって取得されるデータであるか否かを判定する。ステップ２００５において、指定されたデータがプローブ１６１０によって取得されるデータであると判定された場合、処理はステップ２００６に移行する。一方、ステップ２００５において、指定されたデータがプローブ１６１０によって取得されるデータでないと判定された場合、処理はステップ２００７に移行する。
【０１９３】
ステップ２００６において、設定部１６０９は、監視イベント出力部１８０ａのコレクタ１６２０に、指定されたデータのＩＤを登録する。
【０１９４】
ステップ２００７において、設定部１６０９は、判定情報として指定されたデータのＩＤに基づいて、データを取得するデータ取得部１６３０を特定し、特定されたデータ取得部１６３０がデータを取得するように設定する。
【０１９５】
ステップ２００６又は２００７が実行された後、設定部１６０９は、ステップ２００８において、ステップ２００３で抽出された全ての判定情報の処理が完了したか否かを判定する。
【０１９６】
ステップ２００８において、全ての判定情報の処理が完了したと判定された場合、設定部１６０９は処理を終了する。一方、ステップ２００８において、全ての判定情報の処理が完了していないと判定された場合、未処理の判定情報が存在する。この場合、未処理の判定情報を処理するために、設定部１６０９はステップ２００５に戻る。
【０１９７】
コレクタ１６２０は、プローブ１６１０が監視データを取得し、監視イベント出力部１８０ａを介して出力する際に、監視データに付加されるＩＤがステップ２００６で登録されたＩＤであるか否かを判定する。ＩＤが登録されていると判定された場合、コレクタ１６２０は、監視データを条件判定部１６０６に送信する。
【０１９８】
条件判定部１６０６は、判定情報の値を用いて、制御条件１８０３として記述された条件判定式を解釈し、実行する。具体的には、条件判定部１６０６が備える公知のインタプリタが条件判定式を解釈し、実行してもよい。あるいは、事前に公知のコンパイラによって条件判定式を実行するプログラムモジュールが生成及び管理され、このプログラムモジュールが条件判定式を解釈し、実行してもよい。
【０１９９】
なお、条件判定式に代わって、条件判定部１６０６が解釈及び実行することができるプログラム言語で記述された条件判定プログラムコードが、制御条件１８０３として記憶されてもよい。その場合、条件判定部１６０６は、条件判定に必要な判定情報を入力として、条件判定プログラムコードを呼び出す。条件判定プログラムコードは、条件判定結果を返すことによって、条件判定を実行する。
【０２００】
図１５は、本発明の第１の実施の形態の設定部１６０９がプローブ制御部１６０７を設定する処理のフローチャートである。
【０２０１】
設定部１６０９は、プローブ定義に基づいて、図１５に示すフローを実行することによってプローブ制御部１６０７を設定する。
【０２０２】
ステップ２１０１において、設定部１６０９は、プローブ制御定義記憶部１６０２からプローブ制御定義を取得する。
【０２０３】
次に、ステップ２１０２において、設定部１６０９は、プローブ定義の制御操作を解析することによって、制御するプローブ１６１０のＩＤと、プローブ１６１０の監視動作を制御する操作とを特定する。
【０２０４】
次に、ステップ２１０４において、設定部１６０９は、プローブ１６１０の監視動作制御が、プローブ１６１０をアプリケーションプログラム１７０に挿入すること、又は、プローブ１６１０をアプリケーションプログラムから除去することによって実行されるように指定されているか否かを判定する。ステップ２１０４において、プローブ１６１０の挿入又は除去によって制御が実行されると判定された場合、処理を終了する。プローブ１６１０の挿入又は除去によって制御が実行されないと判定された場合、処理はステップ２１０５に移行する。
【０２０５】
ステップ２１０５において、設定部１６０９は、ステップ２１０２で特定されたプローブ１６１０にそのプローブ１６１０の監視動作を制御する動作制御コードを組み込んだ新たなプローブ１６１０を、管理部１４１に生成させる。管理部１４１は、特定されたプローブ１６１０のプログラムコードをプローブ定義に基づいて再生成する。その際、管理部１４１は、再生成されるプローブ１６１０に動作制御コードを組み込む。
【０２０６】
ステップ２１０６において、管理部１４１は、ステップ２１０５で生成された動作制御コードを組み込んだプローブ１６１０を、アプリケーションプログラム１７０に挿入する。ステップ２１０２で特定されたプローブ１６１０が既に挿入されている場合、古いプローブ１６１０のプログラムコードはステップ２１０５で生成したプローブのプログラムコードで置き換えられる。
【０２０７】
上記の処理によって、プローブ１６１０の監視動作を制御するために必要な機能が設定される。
【０２０８】
図１６は、本発明の第１の実施の形態のプローブ制御部１６０７がプローブ１６１０の動作を制御する処理のフローチャートである。
【０２０９】
ステップ１９０１において、プローブ制御部１６０７は、プローブ１６１０の監視動作の制御をプローブ１６１０の挿入又は除去によって実行するか否かを判定する。この判定のために、例えば、プローブ制御部１６０７にプローブ制御定義のＩＤ１８０１をキーとするテーブル（図示省略）が設けられてもよい。そのテーブルには、プローブ１６１０の監視動作を制御する方法が記憶される。プローブ制御部１６０７は、このテーブルを参照することによって、ステップ１９０１の判定を実行することができる。
【０２１０】
ステップ１９０１において、プローブ１６１０の監視動作制御をプローブ１６１０の挿入又は除去によって実行すると判定された場合、処理はステップ１９０２に移行する。一方、プローブ１６１０の監視動作制御をプローブ１６１０の挿入又は除去によって実行しないと判定された場合、処理はステップ１９０３に移行する。
【０２１１】
ステップ１９０２において、プローブ制御部１６０７は、制御対象のプローブ１６１０のＩＤを指定し、プローブ１６１０の挿入又は除去を管理部１４１に指示する。この指示に応じて、管理部１４１は、指定されたプローブ１６１０の挿入又は除去を実行する。その結果、プローブ１６１０によるアプリケーションプログラムの監視動作が開始又は停止される。そして、プローブ動作の制御処理が終了する。
【０２１２】
ステップ１９０３において、プローブ制御部１６０７は、制御対象のプローブ１６１０に割り当てられた動作制御変数の値を制御の内容に応じて設定する。
【０２１３】
ステップ１９０４において、制御対象のプローブ１６１０のプログラムコードが実行される際に、監視動作を実行するコードに先立って、動作制御コードが実行される。この動作制御コードは、図１５に示したフローのステップ２１０５において、制御対象のプローブ１６１０に組み込まれたものである。動作制御コードは、動作制御変数を参照し、その値に応じて監視動作を実行するか否かを判定し、監視動作を行うコードの実行を制御する。そして、プローブ監視動作の制御処理が終了する。
【０２１４】
なお、本実施の形態において、プローブ１６１０からの判定情報の収集は、監視イベント出力部１８０ａのコレクタ１６２０を介して実行される。しかし、コレクタ１６２０を介さずに、個々のプローブ１６１０が取得したデータを条件判定部１６０６に直接出力してもよい。この場合、図１４のフローに示した判定情報の設定処理のステップ２００６において、設定部１６０９がコレクタ１６２０を設定する代わりに、管理部１４１がプローブ１６１０を設定してもよい。その場合、管理部１４１は、プローブコード生成機能を用いて、プローブ１６１０が取得した監視項目を、条件判定部１６０６が備えるインタフェースを通してプローブから直接条件判定部１６０６に送信するプログラムコードをプローブに組み込む処理を実行する。
【０２１５】
上記の本実施の形態において、条件判定部１６０６及びプローブ制御部１６０７はいずれも条件制御部１４３の一部として構成されている。しかし、条件判定部１６０６又はプローブ制御部１６０７が実行する処理の全て又は一部は、管理部１４１がプローブ１６１０のプログラムコード生成時に組み込む、条件制御のためのプログラムコードによって実行されてもよい。
【０２１６】
その場合、判定情報を出力するプローブ１６１０や、監視動作の制御対象となるプローブに、判定情報の取得及び受け渡し、判定情報を用いた条件判定及びその判定結果の受け渡し、及び、判定結果に基づくプローブ監視動作の制御などの処理を実行するプログラムコードが、設定部１６０９の指示に応じて生成される。そして、生成されたプログラムコードが、判定情報を出力するプローブ１６１０又は監視動作の制御対象のプローブ１６１０に組み込まれる。
【０２１７】
図１７は、本発明の第１の実施の形態のプローブ制御定義記憶部１６０２から取得されるプローブ制御定義を入力するために使用される監視制御設定ユーザインタフェース１１０の例を示す説明図である。
【０２１８】
監視動作制御の設定ウィンドウ１８５０は、ユーザ（例えば、運用管理者又は業務管理者）にプローブ制御定義を入力させるために、出力装置２７１１に表示される。
【０２１９】
監視動作制御の設定ウィンドウ１８５０は、設定名称入力欄１８５２、制御条件入力欄１８５４、制御操作入力欄１８５６、決定ボタン１８５８及び取消ボタン１８５９を備える。
【０２２０】
設定名称入力欄１８５２は、入力されるプローブ制御定義に付与され、ユーザが管理、識別するために使用する名称を入力させるための欄である。
【０２２１】
制御条件入力欄１８５４には、プローブ１６１０の監視動作を制御する条件式が入力される。条件式の中で判定情報として用いられるデータは、プローブ１６１０のＩＤ及び予め定義されたデータ取得部１６３０のＩＤによって指定される。
【０２２２】
制御操作入力欄１８５７には、制御条件入力欄に入力された条件が成立する場合に実行される、プローブ１６１０の監視動作を制御する操作が入力される。制御操作において、監視動作の制御対象のプローブ１６１０のＩＤが指定される。
【０２２３】
ボタン１８５５は、ユーザによる制御条件の入力を支援するインタフェースを表示するボタンである。このボタン１８５５を操作した結果表示されるユーザインタフェース（図示省略）によって、制御条件の記述に用いることができる演算子又は関数の一覧が表示されてもよい。さらに、判定情報に用いることができるプローブ１６１０及びデータ取得部１６３０の一覧が表示されてもよい。ユーザは、表示された内容から任意のものを選択することができる。選択された内容は、制御条件入力欄に反映される。
【０２２４】
ボタン１８５７は、ユーザによる制御操作の入力を支援するインタフェースを表示するボタンである。このボタン１８５７を操作した結果表示されるユーザインタフェース（図示省略）によって、制御操作の記述に用いることができる制御操作の一覧が表示されてもよい。さらに、監視動作の制御対象とすることができるプローブ１６１０の一覧が表示されてもよい。ユーザは、表示された内容から任意のものを選択することができる。選択された内容は、制御操作入力欄に反映される。
【０２２５】
ユーザによって設定名称、制御条件及び制御操作が入力され、決定ボタン１８５８が操作されると、ユーザインタフェース１１０は、入力された各項目の内容に従ってプローブ制御定義を生成し、プローブ制御定義記憶部１６０２に格納する。
【０２２６】
図１２に示したシステムによるプローブ１６１０の監視動作の条件制御は、図１０に示すユーザインタフェースが用いられるシステムと組み合わせて実行することができる。図１０に示すユーザインタフェースが用いられるシステムでは、設計情報上で監視設定が実行され、その監視設定によって指定された設計情報上の「監視する点」及び「監視するデータ」に基づいてプローブ定義が生成される。具体的には、既に説明したように、図１の対応検索部１１５が設計対応関係記憶部１３０を参照して、図８及び図９に示す処理を実行し、設計情報上の指定から、プログラムコードにおいてプローブ１６１０を挿入する点と監視するデータを特定する。
【０２２７】
この場合、プローブ制御定義の入力の際に、図１７に示したユーザインタフェースにおいて判定情報とされるプローブ１６１０を指定するために、図１１に示した監視設定テーブルに記憶された監視設定の情報をユーザに入力させることができる。監視動作の制御対象のプローブ１６１０の指定においても同様である。監視設定と、それに対応するプローブ定義には、同一のＩＤが付与される。このため、指定された監視設定のＩＤに基づいて、対応するプローブ１６１０が特定される。
【０２２８】
例えば、プローブ１６１０を指定するために、監視対象のプローブ１６１０を、プローブ定義を用いて、「メソッド“FuncA.method1（String d1,String d2）”の第１引数“d1”を監視するプローブ」と表示しても、プログラムの実装を理解していないユーザは、そのプローブ１６１０が取得するデータの意味を理解することができない。しかし、監視設定の情報を用いて、「設計情報の機能“１”における入力データ“a”を監視するプローブ」と表示されていれば、ユーザはその意味を容易に理解することができる。
【０２２９】
プローブ１６１０の監視動作の制御を設定する際に、ユーザが、プローブ定義の情報ではなく、監視設定の情報を用いてプローブ１６１０を指定することによって、アプリケーションプログラム１７０の実装を意識することなく設定を実行することができる。
【０２３０】
また、制御条件を入力する際に、監視設定を指定するのではなく、図１０に示したようなユーザインタフェースを用いて、設計情報上で監視する点及び監視するデータをユーザに入力させることができる。この場合、上記の設計情報上で監視設定が入力されると、図１の対応検索部１１５が設計対応関係記憶部１３０を参照して、入力された監視設定に対応するプローブ１６１０のプローブ定義を新規に生成する。生成されたプローブ１６１０は、判定情報を取得するためのプローブ１６１０又は監視動作の制御対象のプローブ１６１０として用いられる。
【０２３１】
このとき、新規に生成するプローブ定義と同一のプローブ定義が、プローブ定義記憶部に既に存在しているか否かがチェックされる。同一のプローブ１６１０が既に存在している場合、そのプローブ１６１０が指定され、既存のプローブ定義が使用される。一方、同一のプローブ１６１０が存在していない場合、新規に生成されたプローブ定義に従って、判定情報を取得するためのプローブ１６１０又は監視動作の制御対象のプローブ１６１０が新規に生成され、アプリケーションプログラム１７０に挿入される。
【０２３２】
また、プローブ１６１０の条件制御の設定において、図１０に示したようなユーザインタフェースを用いて設計情報上において監視設定を行う際に、同時に制御条件及び制御操作をユーザに入力させてもよい。その結果、条件付きの監視設定を入力することができる。この場合、プローブ定義の生成と同時に、プローブ制御定義が生成され、プローブ制御定義記憶部１６０２に格納される。
【０２３３】
次に、プローブ負荷に応じてプローブ１６１０の監視動作を制御するシステムの構成および動作について説明する。プローブ負荷とは、プローブ１６１０がアプリケーションプログラム１７０に挿入され、アプリケーションプログラム１７０監視を実行することによって発生する負荷である。プローブ負荷がアプリケーションプログラム１７０の実行に性能低下等の影響を与えることを防止するため、プローブ負荷が測定され、測定値に応じてプローブの監視動作が制御される。
【０２３４】
図１８は、本発明の第１の実施の形態のプローブ１６１０の監視動作を、測定されたプローブ負荷に応じて制御するシステムの構成を示すブロック図である。
【０２３５】
負荷制御部１４０は、測定部２２０１、制御部２２０３、設定部２２０５及びプローブログ記憶部２２０９を備える。管理部１４１は、図３に示したものと同一である。
【０２３６】
プローブログ記憶部２２０９は、主記憶２７０５又は外部記憶装置２７０７に確保された記憶領域である。測定部２２０１、制御部２２０３及び設定部２２０５は、管理部１４１に含まれるプログラムモジュールである。プローブ１６１０は、図３に示した管理部１４１によってアプリケーションプログラム１７０に挿入されるプログラムモジュールである。
【０２３７】
まず、プローブ負荷を測定する処理を説明する。
【０２３８】
プローブ負荷の測定が指示されると、設定部２２０５はアプリケーションプログラム１７０に挿入されているプローブ１６１０に、プローブ１６１０の監視動作のログ（以降、プローブログと記載する）をプローブ負荷の測定期間の間出力させる（Ｓ１８０１）。
【０２３９】
プローブログは、プローブ１６１０によって実行される監視動作に関する情報であり、プローブ１６１０が動作するたびに出力され、プローブログ記憶部２２０９に蓄積される。プローブログは、少なくとも、プローブ１６１０が動作したこと（すなわち、プローブ１６１０が実行されたこと）を示す情報を含む。プローブログは、さらに、プローブ１６１０が実行した処理に関する種々の情報を含んでもよい。
【０２４０】
プローブログを出力する処理は、各プローブ１６１０にプローブログを出力させるコードを組み込んだプローブ１６１０を生成し、生成されたプローブ１６１０をアプリケーションプログラム１７０に再度挿入することによって実行してもよい。あるいは、プローブ１６１０にプローブログを出力する機能をあらかじめ組み込んでおき、これを有効化することで実行してもよい。
【０２４１】
あるいは、プローブ負荷の測定に必要な情報が、プローブ１６１０が出力した監視イベントによって取得できる場合、プローブログを出力する代わりに、各プローブ１６１０が出力する監視イベントを監視イベント出力部１８０が捕捉してもよい。この場合、監視イベント出力部１８０は、監視ベントに付加されているプローブＩＤに基づいて、動作したプローブ１６１０を特定し、プローブログに相当する情報を監視イベントから抽出し、プローブログ記憶部２２０９に出力する。
【０２４２】
測定部２２０５は、各プローブ１６１０が出力するプローブログをプローブログ記憶部２２０９から取得し、集計することによって、各プローブ１６１０の負荷を計算する。プローブ負荷の計算には、各プローブ１６１０の動作回数（すなわち、実行回数）等が用いられる。以下、プローブの動作回数が用いられる場合を例として説明する。測定部２２０５は、プローブログを集計して各プローブ１６１０の単位時間当たりの動作回数を計算し、この値をプローブ負荷とする。
【０２４３】
プローブ負荷の測定期間が終了すると、設定部２２０１は、各プローブ１６１０にプローブログの出力を停止させる。プローブログを出力するコードを組み込んだプローブ１６１０を生成することによってプローブログを出力している場合、設定部２２０５はプローブログの出力コードを除去したプローブ１６１０を再度生成する。設定部２２０５は管理部１４１を用いて、生成されたプローブ１６１０をアプリケーションプログラム１７０に再度挿入する。
【０２４４】
上記の処理によって、各プローブ１６１０の監視動作の負荷が測定される。
【０２４５】
なお、プローブ負荷の測定処理そのものの負荷を軽減するため、プローブログをプローブ１６１０の動作ごとに出力させるのではなく、各プローブ１６１０がプローブログを一時蓄積し、所定の間隔でまとめて出力してもよい。あるいは、プローブ１６１０に一時蓄積されたプローブログを各プローブ１６１０が集計し、統計処理された値のみを所定の間隔で出力してもよい。
【０２４６】
図１９は、本発明の第１の実施の形態の負荷制御部１４０が、測定されたプローブ負荷に応じて、プローブ１６１０の監視動作を制御する処理のフローチャートである。
【０２４７】
まず、ステップ２４０１において、負荷制御部１４０は、プローブ負荷の測定を開始する。上記のように、プローブログを出力するコードを組み込んだプローブ１６１０がアプリケーションプログラム１７０に挿入されてもよいし、プローブログを出力する機能が有効化されてもよい。
【０２４８】
次に、ステップ２４０２において、負荷制御部１４０は、プローブ１６１０の負荷を測定する。
【０２４９】
次に、ステップ２４０３において、負荷制御部１４０は、測定されたプローブ負荷を、あらかじめ設定されたプローブ負荷の基準値と比較する。
【０２５０】
ステップ２４０３において、プローブ負荷が基準を満たしていると判定された場合（すなわち、プローブ負荷が基準値の範囲内である場合）、処理はステップ２４０７に移行する。一方、ステップ２４０３において、プローブ負荷が基準を満たしていないと判定された場合、プローブ負荷がアプリケーションプログラム１７０の実行に与える影響を軽減するために、プローブ負荷を軽減する必要がある。このため、処理はステップ２４０５に移行する。
【０２５１】
次に、ステップ２４０５において、負荷制御部１４０は、プローブ負荷を軽減するように、プローブの監視動作を制御する。
【０２５２】
次に、ステップ２４０７において、負荷制御部１４０は、設定されたプローブ負荷の測定期間が終了したか否かを判定する。
【０２５３】
ステップ２４０７において、測定期間が終了していないと判定された場合、処理はステップ２４０２に戻り、プローブ負荷の測定及び監視動作の制御を継続する。
【０２５４】
一方、ステップ２４０７において、測定期間が終了したと判定された場合、負荷制御部１４０は、ステップ２４０９において、プローブ負荷の測定を終了し、処理を終了する。
【０２５５】
ステップ２４０３で比較されるプローブ負荷の基準値は、各プローブ１６１０の負荷の絶対値によって設定されてもよいし、他のプローブ１６１０の負荷との相対値によって設定されてもよい。
【０２５６】
負荷の絶対値を用いる場合、負荷制御部１４０は、ステップ２４０３において、各プローブ１６１０の負荷と、設定された基準値とを比較し、基準の範囲内にあるか否かを判定する。プローブ負荷の基準値は、負荷制御部１４０の記憶領域にあらかじめ記憶しておく。
【０２５７】
一方、負荷の相対値を用いる場合、負荷制御部１４０は、ステップ２４０３において、基準となるプローブ１６１０の負荷と、測定対象のプローブ１６１０の負荷との相対値を計算する。そして、負荷制御部１４０は、計算された相対値を、設定された基準値と比較する。相対値を用いてプローブ負荷を評価する場合、アプリケーションプログラム１７０全体の負荷に関わらず、他のプローブ１６１０と比較して特に負荷の高いプローブ１６１０を発見することができる。
【０２５８】
基準値と比較した結果、負荷が基準値を超えているプローブ１６１０があった場合、負荷制御部１４０は、そのプローブ１６１０の監視動作を制御する。監視動作を制御する方法には、例えば、（１）プローブ１６１０をアプリケーションプログラム１７０から除去する。（２）プローブ１６１０の監視データの出力を間引く。等がある。
【０２５９】
上記（１）の方法によれば、プローブ１６１０による監視が完全に停止するとともに、プローブ１６１０のプログラムコードがアプリケーションプログラム１７０から取り除かれるため、アプリケーションプログラムの実行への影響が完全に取り除かれる。
【０２６０】
一方、上記（２）の方法によれば、プローブ１６１０の監視データの出力を数回に1回とする等によって、プローブ１６１０の監視データの取得及び出力の処理が行われる回数が減少する。その結果、プローブ１６１０の負荷が減少する。
【０２６１】
負荷制御部１４０は、上記の監視動作の制御を実行した後、再びプローブ負荷を測定する。
【０２６２】
なお、プローブ１６１０の監視負荷の測定中に上記（２）の制御を実行する場合、プローブ１６１０が実際に監視データを出力したか否かに関わらず、プローブ１６１０が動作したときに必ずプローブログを出力することによって、より正確にプローブ負荷を測定することができる。このとき出力されるプローブログには、監視データが出力されたか否かを示す情報が含まれる。
【０２６３】
あるいは、全プローブ負荷の総和が基準値を超えた場合に、負荷制御部１４０は、各プローブ負荷の値を上記の処理によって調整し、全体の負荷が基準値を超えないように制御することもできる。この場合、負荷制御部１４０は、各プローブ１６１０の負荷のバランス、及び、各プローブ１６１０が出力する監視データの重要度を考慮して、各プローブ１６１０の負荷の目標値を計算し、プローブ１６１０の監視動作を制御する。
【０２６４】
プローブ負荷の測定及び制御は、新規にプローブ１６１０をアプリケーションプログラム１７０に追加する時及びユーザによって指示された時に実行される。
【０２６５】
新規にプローブ１６１０をアプリケーション１７０に追加する時、ユーザインタフェース１１０は、新規のプローブ１６１０をアプリケーションプログラム１７０に挿入するように管理部１４１に指示を出すと同時に、負荷制御部１４０にプローブ負荷の測定を指示する。
【０２６６】
負荷制御部１４０は、管理部１４１が実行する新規プローブ１６１０のアプリケーションプログラム１７０への挿入に合わせて、新規プローブ１６１０を含めたプローブ１６１０の負荷の測定及び制御を開始する。そして、負荷制御部１４０は、予め設定された期間、プローブ負荷の測定及び制御を実行し、測定したプローブ負荷及び監視動作の制御の状態をユーザインタフェース１１０に表示する。
【０２６７】
また、ユーザは、ユーザインタフェース１１０を使用して、任意にプローブ負荷の測定及び制御の実行を指示するとともに、プローブ負荷の基準値、及び、負荷が基準値を超えている場合に実行される制御の方法等を設定してもよい。
【０２６８】
図２１は、本発明の第１の実施の形態の監視動作負荷の測定に関するユーザインタフェース１１０の例を示す説明図である。
【０２６９】
具体的には、図２１のユーザインタフェース１１０は、ユーザに監視動作の負荷を測定する対象のプローブ１６１０を入力させ、さらに、入力されたプローブ１６１０の監視動作の負荷の測定結果を表示する。
【０２７０】
測定プローブ設定ウィンドウ２６００は、管理部１４１のプローブ定義記憶部１６０１に記憶されているプローブ１６１０を一覧表示する。さらに、測定プローブ設定ウィンドウ２６００は、各プローブ１６１０の監視動作の負荷が既に測定されている場合、測定されたプローブ負荷の値を２６０５の欄に表示する。
【０２７１】
各プローブ１６１０を表す行にはそれぞれチェックボックス２６０１が設けられる。ユーザは、チェックボックス２６０１を操作することによって、監視動作の負荷を測定する対象のプローブ１６１０を選択する。
【０２７２】
各プローブの負荷の基準値は、基準値入力欄２６０４に表示される。ユーザは、基準値入力欄２６０４に値を入力することができる。
【０２７３】
ユーザが測定ボタン２６０７を操作すると、上記のプローブ負荷の測定及び制御が実行され、測定されたプローブ負荷がプローブ負荷表示欄２６０５に、監視動作の制御の状態が制御状態表示欄２６０６に表示される。
【０２７４】
なお、各プローブ１６１０又は全てのプローブ１６１０について、プローブ負荷の許容基準値を入力させるインタフェースを設け、プローブ１６１０の測定と共に、図１９に示すフローによって、負荷の高いプローブの監視動作の制御を実行してもよい。
【０２７５】
あるいは、各プローブ１６１０にプローブ負荷を出力させるのではなく、システム又はアプリケーションプログラム１７０の性能指標を測定することによってプローブ負荷を測定してもよい。
【０２７６】
図２０は、本発明の第１の実施の形態の負荷制御部１４０が、アプリケーションプログラム１７０の性能指標を測定することによってプローブ負荷を測定する処理のフローチャートである。
【０２７７】
ステップ２３０１において、負荷制御部１４０は、アプリケーションプログラム１７０の実行性能を示す指標の測定を開始する。性能指標は、アプリケーションサーバ１６０等が備える、性能指標を測定する機能によって測定されてもよい。本実施の形態では、アプリケーションサーバ１６０において測定可能である、アプリケーションプログラム１７０の処理スループットを、プローブ負荷の測定に用いる性能指標として説明する。
【０２７８】
次に、ステップ２３０３において、負荷制御部１４０は、測定対象プローブ１６１０を挿入していない状態の処理スループットを測定する。具体的には、測定対象プローブ１６１０をアプリケーションプログラム１７０に挿入していない状態でアプリケーションプログラム１７０を実行し、所定の期間の平均処理スループットを求める。
【０２７９】
次に、ステップ２３０４において、プローブ挿入部１６０８が、測定対象プローブ１６１０をアプリケーションプログラム１７０に挿入し、プローブ１６１０による監視を実行する。
【０２８０】
次に、ステップ２３０５において、測定対象プローブ１６１０を挿入した状態でアプリケーションプログラム１７０を実行し、ステップ２３０３と同様、所定の期間の平均処理スループットを測定する。
【０２８１】
次に、ステップ２３０６において、負荷制御部１４０は、ステップ２３０３及びステップ２３０５において測定された処理スループットの値を用いて、プローブ負荷の値を計算する。
【０２８２】
次に、ステップ２３０８において、負荷制御部１４０は、ステップ２３０１で設定した性能指標の測定を停止し、プローブ負荷の測定処理を終了する。
【０２８３】
以上の処理によって、測定対象プローブ１６１０のプローブ負荷が測定される。
【０２８４】
なお、プローブの負荷の測定に用いられる性能指標は、処理スループットに限定されない。また、複数の性能指標を測定することによって、より精度の高いプローブ負荷の測定を実行することもできる。
【０２８５】
また、図２０のフローにおいて、ステップ２３０５における性能指標の測定と、ステップ２３０６におけるプローブ負荷の計算が、同時に実行されてもよい。さらに、計算されたプローブ負荷の値を用いて、図１９のステップ２４０３以降の処理が実行されてもよい。この場合、計算されたプローブ負荷の値が基準値の範囲内であるか否かが判定され、必要に応じてプローブ１６１０の監視動作が制御される。その結果、ステップ２３０５において、性能指標を測定する期間の終了を待つことなく、測定対象プローブ１６１０の負荷が高い場合に、測定対象プローブ１６１０の監視動作を制御し、アプリケーションプログラム１７０の実行に影響が生じることを防止できる。
【０２８６】
また、本実施の形態においては、プローブ負荷を測定する度に、ステップ２３０３において、測定対象プローブ１６１０を挿入していない状態での性能指標の測定を行っている。そして、ステップ２３０６において、測定された値を使用してプローブ１６１０の影響が計算されている。しかし、過去において測定された性能指標を記録しておき、記録した値を用いてステップ２３０６の計算が実行されてもよい。
【０２８７】
また、本実施の形態においては、測定対象プローブ１６１０を挿入している状態及び挿入していない状態の性能指標の測定を別個に行っている。しかし、可能であれば、両者を同時に測定してもよい。例えば、測定対象プローブ１６１０を挿入するメソッドの処理時間を性能指標とする場合、測定対象プローブ１６１０のプログラムコードに負荷測定プローブ１６１０の機能を組み込み、測定対象プローブ１６１０の監視動作の処理を含む処理時間と、測定対象プローブ１６１０の監視動作の処理を含まない処理時間を同時に測定させてもよい。その結果、両者を同時に測定し、測定対象プローブの負荷を求めることができる。
【０２８８】
上記本発明の第１の実施の形態は、設計情報上の一つの構成要素が、プログラムコードのただ一つの構成要素と設計対応関係にあることを前提としている。以下、第２の実施の形態として、設計情報上の一つの構成要素に、プログラムコードの複数の構成要素が対応する場合の例を示す。
【０２８９】
以下、本発明の第２の実施の形態が第１の実施の形態と相違する点についてのみ説明する。以下で説明しない第２の実施の形態の構成は、第１の実施の形態と同様である。
【０２９０】
図２２は、本発明の第２の実施の形態の設計対応関係の例を示す説明図である。
【０２９１】
具体的には、図２２は、一つの構成要素に、プログラムコードの一つ又は複数の構成要素が対応する場合の設計対応情報の例を示す。一つの構成要素に複数の構成要素が対応する場合、対応するそれぞれの構成要素のオブジェクトＩＤと、それらの構成要素の間の関係が、対応先要素６０３に記憶される。図２２の例は、設計対応関係６１２ａにおいて、「機能２」の処理が状況に応じて二つのメソッドのいずれかによって処理されることを示している。
【０２９２】
本実施の形態の対応検索部１１５は、第１の実施の形態と同様、図８及び図９に示すように、対応するプログラムコードの構成要素の検索処理を実行する。ただし、設計対応関係６１２ａに示すような設計対応関係が存在する場合、対応検索部１１５は、複数の構成要素を検索する。対応検索部１１５は、検索された個々の構成要素について、図８及び図９に示した処理を実行し、対応するプログラムコードの構成要素を検索し、指定された監視を実現するために必要な複数のプローブ定義のセットを生成する。
【０２９３】
例えば、図５の例において、“A01.機能2”が監視する箇所として指定された場合、メソッド“FuncB.method2a（Data1 d1）”及びメソッド“FuncB.method2b（Data1 d1）”の二つが、指定された箇所に対応するプログラムコード上の監視する箇所として検索される。その結果、それぞれの箇所に応じたプローブ定義が生成される。これらのプローブ定義には、同一のプローブＩＤ１００１と、それぞれを識別する通し番号（プローブ番号１００２）とが付与される。
【０２９４】
図２３は、本発明の第２の実施の形態のプローブ定義記憶部１６０１の構成例を示す説明図である。
【０２９５】
具体的には、図２３は、設計対応関係が図２２に示す通りである場合のプローブ定義の例を示す。図２３の２行目及び３行目が、図２２における“A01.機能2”に対応するメソッド“FuncB.method2a（Data1 d1）”及びメソッド“FuncB.method2b（Data1 d1）”に挿入されるプローブ１６１０を示す。これらのプローブ１６１０は、同一のプローブＩＤ１００１「P002」を持ち、異なるプローブ番号１００２「１」及び「２」によって識別される。
【０２９６】
管理部１４１は、プローブＩＤ１００１を用いて対象となるプローブ１６１０を指定し、指定されたプローブＩＤ１００１を持つ全てのプローブ定義に基づいてプローブ１６１０の生成、挿入及び除去を実行する。図２３に示した例では、管理部１４１が、プローブＩＤ１００１が「P002」であるプローブの挿入を指示すると、２つのプローブ１６１０が生成され、それぞれ、アプリケーションプログラム１７０に挿入される。
【０２９７】
特許請求の範囲に記載した以外の本発明の観点の代表的なものとして、次のものが挙げられる。
【０２９８】
（１）アプリケーションプログラムを実行するアプリケーションサーバを含む計算機システムにおいて、
前記計算機システムは、
前記アプリケーションプログラムを監視するプログラムモジュールを制御するために実行される操作と、前記操作を実行するか否かを判定するために使用される条件と、を保持し、
前記条件が成立する場合、前記操作を実行することを特徴とする計算機システム。
【０２９９】
（２）前記計算機システムは、
前記アプリケーションプログラムを監視する一つ以上の前記プログラムモジュールを実行し、
いずれかの前記プログラムモジュールが取得したデータに基づいて、前記条件が成立するか否かを判定することを特徴とする（１）に記載の計算機システム。
【０３００】
（３）前記アプリケーションプログラムを監視するプログラムモジュールを制御するために実行される操作は、前記プログラムモジュールの前記アプリケーションプログラムへの挿入、又は、前記プログラムモジュールの前記アプリケーションプログラムからの除去であることを特徴とする（１）に記載の計算機システム。
【０３０１】
（４）前記計算機システムは、前記操作を実行するか否かの判定と、前記判定の結果実行される前記操作と、の全部又は一部を実行するプログラムコードを生成することを特徴とする（１）に記載の計算機システム。
【０３０２】
（５）前記計算機システムは、前記アプリケーションプログラムを監視するプログラムモジュールを制御するために実行される操作と、前記操作を実行するか否かを判定するために使用される条件と、を入力するためのユーザインタフェースを備えることを特徴とする（１）に記載の計算機システム。
【０３０３】
（６）前記計算機システムは、
前記アプリケーションプログラムの開発工程の一つの段階における設計情報の構成要素と、前記一つの段階より進んだ段階における設計情報の構成要素との対応関係を示す情報を保持し、
業務プロセス上の点又はデータを示す情報を入力されると、前記入力された情報及び前記対応関係を示す情報に基づいて、前記操作を実行するプログラムモジュール、又は、前記操作を実行するか否かを判定するために用いられるデータを取得するプログラムモジュールを指定することを特徴とする（５）に記載の計算機システム。
【０３０４】
（７）前記計算機システムは、
前記指定されたプログラムモジュールが存在しない場合、前記指定されたプログラムモジュールを新規に生成することを特徴とする（６）に記載の計算機システム。
【０３０５】
（８）アプリケーションプログラムを実行するアプリケーションサーバを含む計算機システムにおいて、
前記計算機システムは、前記アプリケーションプログラムを監視するプログラムモジュールを前記アプリケーションプログラムに挿入して実行することによって発生する負荷を測定することを特徴とする計算機システム。
【０３０６】
（９）前記計算機システムは、前記アプリケーションプログラムを監視するプログラムモジュールの監視動作のログに基づいて、前記負荷を測定することを特徴とする（８）に記載の計算機システム。
【０３０７】
（１０）前記計算機システムは、前記アプリケーションプログラムを実行する際の性能指標に基づいて、前記負荷を測定することを特徴とする（８）に記載の計算機システム。
【０３０８】
（１１）前記計算機システムは、測定された前記負荷が所定の条件を満たさない場合に、前記アプリケーションプログラムを監視するプログラムモジュールの動作を制御することを特徴とする（８）に記載の計算機システム。
【０３０９】
（１２）前記計算機システムは、測定された前記負荷が所定の条件を満たさない場合に、前記アプリケーションプログラムを監視するプログラムモジュールを除去することによって、前記プログラムモジュールの動作を制御することを特徴とする（１１）に記載の計算機システム。
【０３１０】
（１３）前記計算機システムは、
前記アプリケーションプログラムを監視するプログラムモジュールを前記アプリケーションプログラムに挿入するときに、前記プログラムモジュールによる負荷を測定し、
前記測定された負荷が所定の条件を満たさない場合、前記プログラムモジュールの動作を制御することを特徴とする（８）に記載の計算機システム。
【０３１１】
（１４）前記計算機システムは、測定された前記負荷が所定の条件を満たさない場合に、前記アプリケーションプログラムを監視するプログラムモジュールを除去することによって、前記プログラムモジュールの動作を制御することを特徴とする（１３）に記載の計算機システム。
【０３１２】
（１５）前記計算機システムは、負荷を測定する対象の前記プログラムモジュールと、前記条件とを入力し、前記測定された負荷を表示するユーザインタフェースを備えることを特徴とする（８）に記載の計算機システム。
【産業上の利用可能性】
【０３１３】
本発明を用いることによって、アプリケーションプログラムの実装を意識することなく、アプリケーションの監視を容易に設定し、実行することができる。
【図面の簡単な説明】
【０３１４】
【図１】本発明の第１の実施の形態のアプリケーションプログラム監視システムの構成を示すブロック図である。
【図２】アプリケーションの開発工程、及び、その過程で作成されるモデル図の説明図である。
【図３】本発明の第１の実施の形態の管理部の構成を示す説明図である。
【図４】本発明の第１の実施の形態のプローブ定義記憶部の構成例を示す説明図である。
【図５】本発明の第１の実施の形態においてアドバイスとして生成されるプローブのコード例を示す説明図である。
【図６】本発明の第１の実施の形態のプローブをアプリケーションプログラムに追加するためのプログラムコードの例を示す説明図である。
【図７】本発明の第１の実施の形態の設計対応関係の例を示す説明図である。
【図８】本発明の第１の実施の形態の対応検索部がプローブを挿入する点を検索する処理のフローチャートである。
【図９】本発明の第１の実施の形態の対応検索部が設計対応関係を類推する処理のフローチャートである。
【図１０】本発明の第１の実施の形態における、設計情報上でアプリケーションプログラムの監視設定を実行するユーザインタフェースの例の説明図である。
【図１１】本発明の第１の実施の形態の監視設定テーブルの例を示す説明図である。
【図１２】本発明の第１の実施の形態のプローブの監視動作を条件に従って制御するシステムの構成を示すブロック図である。
【図１３】本発明の第１の実施の形態のプローブ制御定義記憶部の構成例を示す説明図である。
【図１４】本発明の第１の実施の形態の設定部が条件判定部を設定する処理のフローチャートである。
【図１５】本発明の第１の実施の形態の設定部がプローブ制御部を設定する処理のフローチャートである。
【図１６】本発明の第１の実施の形態のプローブ制御部がプローブの動作を制御する処理のフローチャートである。
【図１７】本発明の第１の実施の形態のプローブ制御定義記憶部から取得されるプローブ制御定義を入力するために使用される監視制御設定ユーザインタフェースの例を示す説明図である。
【図１８】本発明の第１の実施の形態のプローブの監視動作を、測定されたプローブ負荷に応じて制御するシステムの構成を示すブロック図である。
【図１９】本発明の第１の実施の形態の負荷制御部が、測定されたプローブ負荷に応じて、プローブの監視動作を制御する処理のフローチャートである。
【図２０】本発明の第１の実施の形態の負荷制御部が、アプリケーションプログラムの性能指標を測定することによってプローブ負荷を測定する処理のフローチャートである。
【図２１】本発明の第１の実施の形態の監視動作負荷の測定に関するユーザインタフェースの例を示す説明図である。
【図２２】本発明の第２の実施の形態の設計対応関係の例を示す説明図である。
【図２３】本発明の第２の実施の形態のプローブ定義記憶部の構成例を示す説明図である。
【図２４】本発明の第１の実施の形態のアプリケーションプログラム監視システムの物理的な構成を示すブロック図である。
【符号の説明】
【０３１５】
１１０  ユーザインタフェース
１１５  対応検索部
１２０  設計情報検索部
１３０  設計対応関係記憶部
１４１  管理部
１４３  条件制御部
１４５  負荷制御部
１６０  アプリケーションサーバ
１７０  アプリケーションプログラム
１８０、１８０a  監視イベント出力部
１９０  監視イベント記録部
５５０  設計情報表示ウィンドウ
５５１  設計情報構成要素
５５２  設計情報
５６０  監視データ選択ウィンドウ
５６１  監視データ選択ボタン
５６２  監視データリスト
５６３  決定ボタン
９０１  監視設定ＩＤ
９０３  監視設定名称
９１２  監視ポイント
９２１  監視データ
６０１  対応元要素
６０３  対応先要素
１００１  プローブＩＤ
１００２  プローブ番号
１００３  プローブ名称
１０１２  プローブ挿入ポイント
１０２１  監視データ
１６０１  プローブ定義記憶部
１６０４  プローブ生成部
１６０８  プローブ挿入部
１６１０  プローブ
１６０２  プローブ制御定義記憶部
１６０６  条件判定部
１６０７  プローブ制御部
１６０９  設定部
１６２０  コレクタ
１６３０  データ取得部
１８０１  監視制御設定ＩＤ
１８０３  制御条件
１８０５  制御操作
１８５０  監視動作制御設定ウィンドウ
１８５２  設定名称入力欄
１８５４  制御条件入力欄
１８５５  制御条件入力支援インタフェース表示ボタン
１８５６  制御操作入力欄
１８５７  制御操作入力支援インタフェース表示ボタン
１８５８  決定ボタン
１８５９  取消ボタン
２２０１  測定部
２２０３  制御部
２２０５  設定部
２２０９  プローブログ記憶部
２６００  監視負荷測定設定ウィンドウ
２６０１  測定プローブ選択チェックボックス
２６０３  プローブ名称
２６０４  負荷基準値入力欄
２６０５  監視負荷表示欄
２６０６  制御状態表示欄
２６０７  測定開始ボタン
２７０１  バス
２７０３  ＣＰＵ
２７０５  主記憶
２７０７  外部記憶装置
２７０９  入力装置
２７１１  出力装置
２７１３  ネットワークインタフェース
【図１】
2007316905.tif 000003
【図２】
2007316905.tif 000004
【図３】
2007316905.tif 000005
【図４】
2007316905.tif 000006
【図５】
2007316905.tif 000007
【図６】
2007316905.tif 000008
【図７】
2007316905.tif 000009
【図８】
2007316905.tif 000010
【図９】
2007316905.tif 000011
【図１０】
2007316905.tif 000012
【図１１】
2007316905.tif 000013
【図１２】
2007316905.tif 000014
【図１３】
2007316905.tif 000015
【図１４】
2007316905.tif 000016
【図１５】
2007316905.tif 000017
【図１６】
2007316905.tif 000018
【図１７】
2007316905.tif 000019
【図１８】
2007316905.tif 000020
【図１９】
2007316905.tif 000021
【図２０】
2007316905.tif 000022
【図２１】
2007316905.tif 000023
【図２２】
2007316905.tif 000024
【図２３】
2007316905.tif 000025
【図２４】
2007316905.tif 000026