(57)【要約】本発明によって提供されるのは、並列動作するコンポーネントベースの分散形ソフトウェアをテストないしは観察できる汎用の手段である。ここで観察すべきシステムの変更は最小限度であり、正しいシステムコンポーネントに検査インスツルメントが備え付けられ、各送信側と受信側との間で通信メッセージのセマンティックな割り当てが行われ、また同期化されたクロック時間なしに分散形システムの個々のコンポーネントにおいて論理的なイベント列が評価モデルの形態で得られ、この評価モデルを任意の性質の評価ツールのベースにすることができる。
2004530209.tif 000002
【特許請求の範囲】
【請求項１】
並列動作するコンポーネントベースの分散形ソフトウェアシステムにおけるシステム情報および動作を自動的に検出して記録する方法において、
コンフィギュレーションデータ（ＣＤ１，…，ＣＤ３）およびタイプ情報（ＴＩ）を考慮して、観察すべきシステム（ＳＵＢ）の少なくとも１つのコンポーネント（ＳＣ１，ＳＣ２，ＭＩＤ）に少なくとも１つの検査インスツルメント（Ｉ１，Ｉ２，Ｉ３）を挿入し、
前記の検査インスツルメントを有するコンポーネントにて、前記の観察すべきシステムのメッセージ（Ｎ１，Ｎ２，Ｎ３）をランタイムに生成し、
該メッセージを収集し、かつ前記コンフィギュレーションデータに依存してフィルタリングし、
前記の収集したメッセージを、汎用の評価モデルに対するデータ（ＯＵＴ）に変換して、個々のシステムコンポーネント間の論理的な関係および通信関係を作成して、
前記の観察すべきシステム内のシステムイベントを時間的に正しい順序にし、固定的なタイプ情報を前記システム情報に付加することを特徴とする、
システム情報および動作を自動的に検出して記録する方法。
【請求項２】
前記のシステムの開始時に検査インスツルメントをCreateインスツルメント（Ｉ３）の形態で１ミドルウェア（ＭＩＤ）だけに形成し、ここで該ミドルウェアは、アプリケーションとその下にあるネットワーク層との間のソフトウェアであり、
また少なくとも１つのシステムコンポーネントに、Callインスツルメント（Ｉ１，Ｉ２）の形態の少なくとも１つの検査インスツルメントを付加する、
請求項１に記載の方法。
【請求項３】
前記検査インスツルメントによって、メッセージ（Ｎ１，Ｎ２）を検査コンポーネント（ＩＣ）に供給し、
該検査コンポーネントは、複数のプロセスによって応答されるインスツルメントコードを含み、また検査コンポーネントによって前記の観察すべきシステム（ＳＵＢ）のメッセージ（ＩＮ）を供給する、
請求項１または２に記載の方法。
【請求項４】
並列動作するコンポーネントベースの分散形ソフトウェアシステムにおけるシステム情報および動作を自動的に検出して記録する装置において、
コンフィギュレーションモジュール（ＣＯＮＦ）が設けられており、これによってタイプ情報（ＴＩ）に依存してシステムコンポーネントが選択されて、該システムコンポーネントに検査インスツルメント（Ｉ１，Ｉ２）が挿入され、
オブザーバモジュール（ＯＢＳ）が設けられており、これによって前記コンフィギュレーションモジュールにて、前記検査インスツルメントの選択されたメッセージ（ＩＮ）が収集され、
変換モジュール（ＴＲＡＮＳ）が設けられており、これにより、前記メッセージの通信の関係および論理的な関係が形成されることによって、システムイベントが時間的正しい順序で並べられることによって、および固定的なタイプ情報が付加されることによって、検査インスツルメントのメッセージから、少なくとも１つの評価モジュールに対するデータ（ＯＵＴ）が形成されることを特徴とする、
システム情報および動作を自動的に検出して記録する装置。
【請求項５】
インスツルメントモジュール（ＩＮＳＴ）が設けられており、これによって少なくとも１つの検査インスツルメントがCreateインスツルメント（Ｉ３）の形態で１ミドルウェアだけに形成され、ここで該ミドルウェアは、アプリケーションとその下にあるネットワーク層との間のソフトウェアであり、
少なくとも１つのシステムコンポーネントにCallインスツルメント（Ｉ１，Ｉ２）の形態の少なくとも１つの検査インスツルメントが挿入される、
請求項４に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、トレース方法、すなわち、観察すべきシステムのイベントメッセージを介して動作を追跡する方法に関し、ここでこの観察すべきシステムは、複数のプロセス、タスクまたはスレッドを有することができ、また種々異なる装置で動作することが可能である。
【０００２】
このような並列動作するコンポーネントベースの分散形システムソフトウェア、例えば、マイクロソフトのＣＯＭシステム、ＣＯＲＢＡシステムまたはエンタープライズＪＡＶＡビーンズシステム（Enterprise Java Beans System）などは、例えば、"COM and CORBA Side by Side Architectures, Strategies and Implementation", Addison Wesley, 1999"なる書名のJason Pritchardの書籍の第１７〜２５頁に簡潔に紹介されている。
【０００３】
開発のすべてのフェーズにおいて、すなわちインプリメント、統合およびテスト中に、またソフトウェアシステムの使用中に、つまり運用開始時および動作の監視時に、分析のため、エラー個所の特定のため、またはソフトウェアの正当性を証明するために、システムのランタイムにおける情報を見て評価できるようにしたいという要求がある。これらの情報には、例えば、内部変数などのシステム状態と、通信動作（Kommunikationsablauf）および時間順序を含むイベントについての情報とが含まれる。
【０００４】
従来は以下のトレース方法が公知である。すなわち、
ａ）デバッガを使用する。このデバッガのコントロールの下で各システムプロセスが動作し、またこのデバッガによって、ブレークポイント（Breakpoint）が対話的に設定され、このブレークポイントに到達した際に、デバッグ情報、すなわちローカルおよびグローバルな変数の内容を見ることができる。しかしながらこの解決手段によって可能になるのは、当の並列動作する分散形システムにおいては局所的に中を覗き見ることだけであり、これによって、全体システムについて、またはダイナミックな動作について知ることは困難である。さらにそのシステムの挙動は、個々のコンポーネント／プロセスを対話的に停止することによってもろくも障害を受けるか、ダウンしてしまうことさえもある。
【０００５】
ｂ）プログラムコードにおける付加的なデバッグ情報を使用する。すなわちオブジェクトの名前、変数など、ならびにソースコードの行をマシンコードに対応付ける情報をさらなる評価に使用する。ここでこのデバッグ情報、システムダウンの後のエラー分析、すなわち、事後分析（post mortem Analysen）に利用されることがほとんどである。このアプローチによっても、実質的にシステムに対する局所的な展望しか得られない。事後分析では、（すなわちシステムの終了状態の知識だけでは）実際のエラー原因を推し量ることができないことが多い。さらに殊にわずかな資源しか有しない組込型の小さなシステムでは、これをできる限り小さく維持するために、デバッグ情報なしにソフトウェアが提供されるのがほとんどである。
【０００６】
ｃ）あらかじめインスツルメントが備え付けられたコード（instrumentierter Code）、すなわち、作成されるシステムのつねに一部をなし、かつ必要に応じて起動されて、関連するシステム情報を生成する付加的なプログラムコードを使用する。このアプローチも、小さなシステムにおいて資源がぎりぎりであるという理由から適用できないか、または上記のようなインスツルメントの備え付け（Instrumentierung）はシステムのごく一部分に制限される。このようなインスツルメントの備え付けは、固定的であり、後で変更することはできない。すなわち、インプリメントの際にすでに設けられていたコード個所のシステム情報だけしか表示できないのである。
【０００７】
問題の分散アプリケーションは、殊にその大きさおよび複雑さが特徴であり、したがって通常の手段でテストすることは困難である。
【０００８】
このような方法ないしはシステムは、例えば、ＷＯ２０００／５５７３３Ａ１，ＤＥ４３２３７８７Ａ１，ＵＳ５７９０８５８，ＥＰ０４７０３２２Ａ１，ＵＳ５３０７４９８およびＵＳ５３７１７４６から公知である。
【０００９】
本発明の基礎にある課題は、上に述べた欠点を回避する方法ないしは装置を提供することである。
【００１０】
この課題は、本発明により、方法については請求項１の特徴部分に記載された構成により、また装置について請求項４の特徴部分に記載された構成によって解決される。
【００１１】
その他の請求項には、上記の方法ないしは装置の有利な発展形態が記載されている。
【００１２】
本発明により、並列動作するコンポーネントベースの分散形ソフトウェアシステムを汎用的にテストないしは観察することができ、ここでは、観察すべきシステムが最小限にしか変更されず、正しいシステムコンポーネントに検査インスツルメントが自動的に備え付けられ、各送信側と受信側との間で通信メッセージがセマンティックに割り当てられ、同期化されたクロック時間なしにこの分散形システムの個々のコンポーネントにおいて論理的なイベント列が評価モデルの形態で得られ、この評価モデルを任意の性質の評価ツールのベースにすることができる。
【００１３】
本発明を以下、図面に示した実施例に基づいて詳しく説明する。ここで
図１は、方法ないしは本発明の装置を説明する概略図を示しており、
図２は、自動的なインスツルメントの備え付けを説明する図を示しており、
図３は、いわゆるCallインスツルメント備え付けの動作を説明する図を示しており、
図４は、本発明の方法に使用されるモデルの抽象的な設計を説明する図を示しており、
図５は、このモデルのアプリケーション構造を説明する図を示しており、
図６は、このモデルの物理的な構造を説明する図を示している。
【００１４】
図１には、自動化されたコンポーネントトレーシングに対するフレームプログラム（Rahmenprogram）ＦＡＣＴが示されており、このプログラムは、その入力情報ＩＮをメッセージの形態で観察中のシステムＳＵＢから受け取り、このプログラムそれ自体は出力情報ＯＵＴを、オンラインかまたはオフラインで、視覚化ツールまたは分析ツールＴＯＯＬＳに供給する。コンフィギュレーションモジュールＣＯＮＦからの情報に依存して、インスツルメント備え付けモジュールＩＮＳＴを用いて、検査インスツルメントＩ１…Ｉ３の植え込み（Einpflanzung）ないしは注入（Injektion）が行われ、ここではシステムコンポーネントＳＣ１…ＳＣ３のうちで、コンフィギュレーションに依存して選択されたシステムコンポーネントＳＣ１およびＳＣ２に、または以下に詳しく説明するいわゆるミドルウェアＭＩＤに植え込みないしは注入が行われる。選択的にはＳＵＢを観察して、このシステムに検査コンポーネントＩＣを植え込みないしは注入することも可能である。システムコンポーネントＳＣ１およびＳＣ２の検査インスツルメントＩ１およびＩ２はつぎにそれらのメッセージを、直接、または検査コンポーネントＩＣを利用して供給する。この検査コンポーネントＩＣそれ自体は、メッセージＩＮをフレームプログラムＦＡＣＴに対して供給する。フレームプログラムＦＡＣＴは、オブザーバ部ＯＢＳを有しており、このＯＢＳによって、メッセージＩＮが集められ、またこのメッセージが、コンフィギュレーションモジュールにも利用可能であるタイプ情報ＴＩに依存して、フィルタリングされて変換モジュールＴＲＡＮＳに転送される。つぎにこれは、コンフィギュレーションモジュールに依存して、汎用評価モデルに対するデータＯＵＴとして、視覚化または分析のためのツールＴＯＯＬＳに転送される。システムをこのように３つに分割することは、論理的な分類とみることができ、関与する複数のプロセスまたは装置に物理的に構造化することについてはなにも示していない。
【００１５】
フレームプログラムＦＡＣＴのグローバルな動作は、実質的に以下の２つの過程に分類される。すなわち、
ａ）インスツルメント備え付け：自動的なインスツルメント備え付けに対するコンポーネントまたはモジュールＩＮＳＴは、モジュールＣＯＮＦのコンフィギュレーションデータとタイプ情報ＴＩとを考慮して、観察中のシステムＳＵＢのシステムコンポーネントＳＣ１およびＳＣ２に、インスツルメントＩ１，Ｉ２またはＩ３を植え込む。このような過程は、コンポーネントが形成されると直ちに行われ、すなわちシステムの開始時にも、またシステムＳＵＢのランタイムにおける後のダイナミックな拡張時にも行われるのである。
ｂ）システム情報の記録および転送：ここでは検査コンポーネントＩＣにおいてメッセージが形成され、オブザーバＯＢＳに転送される。このオブザーバにより、これらのメッセージが集められ、またコンフィギュレーションモジュールないしはタイプ情報に依存してフィルタリングされる。その後、このオブザーバにより、これらのメッセージが変換モジュールに転送される。タイプ情報ＴＩが使用され、モジュールＴＲＡＮＳにおいて変換と、視覚化ないしは分析のための転送とが行われる。
【００１６】
システムデータを取得するため、およびダイナミックなシステム動作を記録（Dokumentation）するアプリケーションコンポーネントの自動的なインスツルメント備え付けは、システム監視およびシステム拡張の慣用の手法を組み合わせおよび応用することによって実現されるが、他の方法に対してつぎような一連の利点を有する。すなわち、
１．インスツルメント備え付けが、システムのランタイムに行われる。すなわち、システム設計およびシステム構造がこれによって影響を受けることがない。
２．インスツルメント備え付けのためにプログラムコードを新たにコンパイルする必要がなく、この方法は、すでにリリース版として出荷されたソフトウェアまたは他社のバイナリコンポーネントに適用可能である。
３．関連するすべてのプログラム部分にインスツルメントを備え付けることができる。ここで重要であるのは、ランタイムに形成されるアプリケーションコンポーネントが自動的に後付けでインスツルメントが備え付けられる。これによって静的な部分、すなわち開始時点において既知の部分に対してだけでなく、全体システムについての見通しが可能になる。ランタイムにおいてインスツルメント備え付けの範囲を設定し、また検出すべき情報を定めることも可能である。
４．インスツルメント備え付けのコードは極めてコンパクトであり、したがって資源が限られた組込式システムに対しても適用可能である。
５．インスツルメント備え付けコードの実行は、極めて高性能に行われる。
６．アプリケーションの挙動に対する影響はほとんどない。
【００１７】
自動的なインスツルメント備え付けのためのモジュールＩＮＳＴは、２つの時点に使用される。第１の時点は、調べるべきシステムＳＵＢの開始時であり、ここではいわゆる「ミドルウェア」に"Create"インスツルメントＩ３を備え付けることにより、観察すべきシステムＳＵＢに新たなコンポーネントが設けられる際にフレームプログラムＦＡＣＴに報告がなされるようにする。ここでミドルウェアＭＩＤとは、アプリケーションと、その下にあるネットワーク層との間を仲介するソフトウェアのことであると理解されたい。このミドルウェアは、所定のプログラムインタフェース（ＡＰＩ）を介してその機能をエクスポートし、また例えば、種々異なるプラットホームの装置で動作するアプリケーション部分間の対話を実現する。第２の時点は、後の時点に、すなわちシステムＳＵＢのランタイム中にシステムコンポーネントが設けられる時点である。ここでは"Create"インスツルメント部分Ｉ３によって、"Call"インスツルメントコンポーネントＩ１が、新たに設けられたコンポーネントＳＣ１に植え込まれ、これが、このコンポーネントのすべての呼出を監視する。これらの関係は、図２および３に説明されている。
【００１８】
インスツルメントコンポーネントＩ１，Ｉ２およびＩ３は、システムＳＣ１，ＳＣ２およびＭＩＤ、つまりミドルウェアまたはシステムコンポーネントの相応する部分に直接、結合され、１ユニットを構成する。この際にコンポーネントのインタフェースは変更されないため、全体システムには影響がまったく発生しない。検査コンポーネントは、ジェネリックなオブジェクトとして実現される。すなわちこれは、インスツルメントが備え付けられた種々異なるコード個所からデータを受け取る。ここで有利であるのは、インスツルメントコードは装置毎に１つだけあるが、種々異なるプロセスから応答され得ることである。これによってメモリスペースが節約される。コンフィギュレーションモジュールＣＯＮＦによって、情報取得の際にシステム観察のためにメッセージを記録すべきであるシステムコンポーネントの選択が可能になる。このコンフィギュレーションモジュールはタイプ情報ＴＩを使用し、このタイプ情報によってすべてのシステムコンポーネントＳＣ１…ＳＣ３を一義的に識別することができ、またこのタイプ情報は、例えば、システム要素に対する可読の名前を含む。インスツルメントコンポーネントによって、システムコンポーネントのタイプと、データ生成のために設けられたタイプとが比較され、これらのコンポーネントのインスツルメント備え付けについて決定がなされる。これによって保証されるのは、ユーザが生成することにしたデータだけが生成されることである。さらに発生し得るメモリバッファのオーバーフロー（Ueberlaufen）が予防される。
【００１９】
オブザーバモジュールＯＢＳはフレームプログラム内で、種々異なる検査インスツルメントからの生データを収集し、変換モジュールに転送されるデータの選択ないしはフィルタリングを行う。どのデータを選択するないしはフィルタリングするかは、コンフィギュレーションによって設定される。このコンフィギュレーションは、前もってまたはシステムのランタイムに行うことができる。オブザーバモジュールＯＢＳもまた、（インスツルメントのコンフィギュレーションとは無関係に）トレースすべきコンポーネントないしはオブジェクト、トレース内容およびトレースの深さについて、すなわち、収集するシステム情報の詳細の度合いについて設定することができる。
【００２０】
変換モジュールＴＲＡＮＳの役割は、観察すべきシステムＳＵＢへの種々異なる部分で収集した生データを処理して補足することである。データＯＵＴは１モデルに対するものであり、また所定のインタフェースを介して視覚化ツール／分析ツールに転送される。このモデルは柔軟に選択され、これによって考えられ得る多くのツールを扱うことができる。この変換モジュールでは、個々のシステム要素間の論理的な関係および通信の関係が形成され、イベントが時間的正しい順序にされ、システムコンポーネントの固定的なタイプ情報が追加されて、データが構造化され、例えば、名前によって人間が読めるようにする。
【００２１】
以下の入力情報ＩＮは、観察中のシステムＳＵＢから得る必要がある。すなわち、
１．プログラムユニットならびにランタイム環境内でのコンポーネントの識別、すなわち目下のプロセスと目下のスレッド内での識別。この情報は、通常、オペレーティングシステム機能を介して問い合わせることができ、ここで装置毎に一義的な識別子ＩＤが得られる。このようなＩＤは、オブジェクトに対する一義的な識別であり、非負の整数値から構成されることが多い。
２．観察すべきシステム要素についてのタイプ情報、すなわち、コンポーネント、オブジェクト、インタフェースおよびグローバルな関数についてのタイプ情報。このタイプ情報によって、システム要素の抽象的な構造が表される。これはアプリケーションを設計する時点に決定され、ほとんどの場合、明確に規定された形式を有する。フレームプログラムＦＡＣＴそれ自体は、これらの情報を必ずしも必要としないが、このフレームプログラムをベースにするツールＴＯＯＬＳはこれらを使用して、設計構造を記録し、人間に読める表現に翻訳することができる。
【００２２】
詳述すると、タイプ情報の以下の部分が関連する。すなわち、
システム要素の名前。または一義的な識別子番号ＩＤだけのことも多い。
【００２３】
オブジェクトおよびインタフェースに対して：メソッドのリストおよびそのシグニチャ、すなわち、メソッドの復帰値およびパラメタ情報。
【００２４】
コンポーネントに対して：界面のリスト、すなわち、このコンポーネントのインタフェースのリスト。
【００２５】
インタフェースに対して：上記のインタフェースを含むメソッドのリストとそのシグニチャ。
【００２６】
オブジェクト指向プログラミングで行われているようにシステム要素が継承または集約を介して別の要素のインスツルメントを利用する場合、継承関係／集約関係の構造。
【００２７】
付加的には、観察すべきシステムの以下のサービスも利用する。すなわち、
アプリケーションに所属するモジュールのリストアップないしは関与するコンポーネントの識別。
【００２８】
他のプロセスへのコード部分またはライブラリの注入。これによってインスツルメント備え付けを行う。
【００２９】
システム関数のインタセプト（Interception）、例えば、オブジェクトないしはコンポーネントを生成する関数のインタセプト。これによってランタイム中に生成されるコンポーネントも監視できるようにする、および
レジストレーションメッセージおよびメソッド呼出のインタセプト。
【００３０】
これらのサービスの一部はオペレーティングシステムによって提供され、ないしは公知の方法を利用してモジュールＦＡＣＴに実現される。
【００３１】
変換の際には以下の情報を１モデルに対して生データＩＮから導き出す。すなわち、
・  種々の様相から分類されたシステム要素についての情報：抽象的な設計と、アプリケーション構造と、物理的なランタイム構造とに関連した情報。
【００３２】
・  システム構造についての情報、すなわちシステム要素の相互関係、例えば、プロセスがどの装置に所属するかであり、ここでこの割り当ては固定的ではなく、実行時間について変化し得る。
【００３３】
・  システム要素のライフサイクルを記述するデータ、
・  イベントおよび局所的および分散された通信動作について情報、
・  同期化されたクロックの必要のない、通信を行うシステム要素間の関係ならびに論理的なイベントの列を表すデータ、
・  一義的でありかつ人間が読むことのできるシステム要素の識別子、すなわち内部的なＩＤだけでなくクリアテキストの名前が可能なデータ。
【００３４】
このためにモジュールＦＡＣＴにより、システムで一義的なＩＤが、個々のシステム要素に対して、また個々の通信動作に対して生成され、これらは各システムメッセージに付加される。
【００３５】
多くのシステム要素に対してオペレーティングシステムによってすでにＩＤが付与されている。しかしながらこれらは単に局所的であり、すなわち、例えば、１プログラムユニットに対してまたは１装置に対して一義的である。変換コンポーネントは、システム要素毎に、種々異なる局所的なＩＤを組み合わせてシステムで一義的なＩＤを作成するか、またはこの変換コンポーネントそれ自体が一義的なＩＤを付与する。これによってシステムにおける識別が可能である。
【００３６】
開始時点またはランタイムに新たなシステム要素を作成する際には、タイプ情報を使用し、またランタイム環境に関する情報から、種々異なるシステム要素間の関係をさらに付加的に作成する。つぎにこれらのデータから、分散システムのランタイム構造を推定することができる。
【００３７】
インスツルメントによって生成される、個々の通信動作を表す情報には論理的な依存性があるが、これは得られた生データには直接含まれていない依存性である。この方法では、これらの情報が、相応する依存性の分だけ拡張される。
【００３８】
このためには、個々の通信毎に一義的なＩＤを生成する。この通信動作の一部である各イベントにはこれらのＩＤが含まれる。これによって以下が可能である。すなわち、
・  １つまたは複数の送信側の通信メッセージを受信側のそれにセマンティックに対応付ける、
・  同期化されるクロックなしに分散システムの個々にノードにおいて論理的なイベント列を決定する。
【００３９】
信号ＯＵＴを有する出力インタフェースは、検査コンポーネントによって形成されるシステムメッセージに対するデータモデルに基づく。
【００４０】
このモデル自体は、複数の論理的な部分に分類することができ、ここでこれらの部分により、ＳＵＢの種々異なる様相が表されるか、またはシステムに種々異なる層が定められる。すなわち、
・  抽象的な設計、
・  ランタイムにおけるアプリケーション構造
・  物理的構造。
【００４１】
分散アプリケーションの抽象的な設計は、開発の極めて早いフェーズにおいて決定されかつ固定的である。これはインスツルメントによってトレースされず、タイプ情報から導出される。これらのデータは、このモデルの一部とみなされる。それは、これをベースにするツールは、人間が読むことのできる名前を介する識別のため、構造化、ならびにシステム要素のフィルタリングのためにこれらのデータを使用できるからである。
【００４２】
このモデルは図４に示した構造を有し、ここでは分散アプリケーション、コンポーネント、インタフェース、クラス、メソッドおよびグローバルな関数が、集約の関係、継承の関係、インプリメントの関係（Implementierungsbeziehung）を介して関連づけられている。コンポーネントおよびクラスは、場合によっては集約ないしは入れ子にするか、または互いに継承関係を有することができる。
【００４３】
アプリケーション構造は図５に示されており、また（抽象的な設計とは異なり）分散アプリケーションの具体的なインスタンスを表し、ここでこれらは固有のプログラム動作中に形成ないしは削除されたものである。
【００４４】
物理的な構造は図６に示されており、これはこの分散システムのランタイム環境を表し、つぎのように分類される。すなわち、
分散システム、装置／デバイス、プロセスおよびタスク／スレッド。
【００４５】
このモデルはシステムイベントの以下のタイプを定義し、ここでこれらは検査コンポーネントによって生成される。すなわち、
・  通信イベント：  send/receive
・  レジストレーションイベント：  create/destroy
・  ローカルイベント：  pass
・  周期的なイベント：  periodic update。
【００４６】
すべてのイベントはタイムスタンプを含んでおり、すなわちローカルな装置時間と、タイプと、関与するシステム要素への参照と含んでいる。通信イベントではこれらつねに２つであり、レジストレーションイベント、ローカルイベントおよび周期的なイベントでは１つずつである。
【００４７】
通信イベントはつぎの過程を表すために使用される。すなわち、
・"send"：は、出力されるメソッド呼出（send call）、出力されるデータ転送（send message）または出力される復帰値（send return）とすることができる。
・"receive"：は、到来するメソッド呼出（receive call）、到来するデータ転送（receive message）または到来する復帰値（receive return）とすることができる。
【００４８】
レジストレーションイベントとは、例えば：
・"new"：別のシステム要素によるあらたなコンポーネントまたはオブジェクトの生成／設定を記録する。生成の際には、通例、関連するコンポーネント相互の通信（データ交換）も、通信イベント"send"と同様に行われる。
・"delete"：別のシステム要素によるコンポーネントまたはオブジェクトの削除を記録する。
・"create"：イベントnewの特殊な形態である。これは新たなコンポーネントまたはオブジェクトの生成／設定を記録するが、その際に、生成を行う要素との関係が形成されることがない。
・"destroy"：それ自体によるコンポーネントまたはオブジェクトの削除を記録する。
【００４９】
ローカルイベント（pass）は、所定のコード個所に到達した際に生成されるイベントである。これらのイベントによって、所定のコード個所の処理または記録することができ、またはこれらのイベントは、内部データ、例えば、ローカル変数の内容を含むことができる。
【００５０】
周期的なイベント（periodic update）は、周期的な間隔でシステム変数、またはユーザによって定義された別の量を監視できるようにするために使用可能である。
【００５１】
本発明の方法および本発明の装置は基本的に、例えば、ＣＯＭ，ＣＯＲＢＡ，ＥＪＢなどの、観察すべきシステムＳＵＢに対して上記の要求を満たすすべてのＭＷベースの分散システムに使用可能である。
【００５２】
Windows CEＴＭおよびCOMＴＭを含む種々異なるWindowsＴＭシステムに対する実現が存在する。インスツルメント備え付けのためのこの方法は、例えば、WindowsＴＭ／COMＴＭで使用されるつぎのようなメソッドに基づく。すなわち、
１．メソッド呼出の委譲、
２．別のプロセスまたはすでに動作しているプロセスのダイナミックロードライブラリ（ＤＬＬ dynamisch zuladbare Libralies）、および
３．Win32 API関数のリダイレクション。
【図面の簡単な説明】
【００５３】
【図１】方法ないしは本発明の装置を説明する概略図である
【図２】自動的なインスツルメントの備え付けを説明する図である
【図３】いわゆるCallインスツルメントの動作を説明する図である
【図４】本発明の方法に使用されるモデルの抽象的な設計を説明する図である
【図５】図４のモデルのアプリケーション構造を説明する図である
【図６】図４のモデルの物理的な構造を説明する図である
【図１】
2004530209.tif 000003
【図２】
2004530209.tif 000004
【図３】
2004530209.tif 000005
【図４】
2004530209.tif 000006
【図５】
2004530209.tif 000007
【図６】
2004530209.tif 000008
【国際公開パンフレット】
2004530209.tif 000009
2004530209.tif 000010
2004530209.tif 000011
2004530209.tif 000012
2004530209.tif 000013
2004530209.tif 000014
2004530209.tif 000015
2004530209.tif 000016
2004530209.tif 000017
2004530209.tif 000018
2004530209.tif 000019
2004530209.tif 000020
2004530209.tif 000021
2004530209.tif 000022
2004530209.tif 000023
2004530209.tif 000024
2004530209.tif 000025
2004530209.tif 000026
2004530209.tif 000027
2004530209.tif 000028
2004530209.tif 000029
2004530209.tif 000030
2004530209.tif 000031
2004530209.tif 000032
2004530209.tif 000033
【国際公開パンフレット（コレクトバージョン）】
2004530209.tif 000034
2004530209.tif 000035
【国際調査報告】
2004530209.tif 000036
2004530209.tif 000037
2004530209.tif 000038
2004530209.tif 000039
2004530209.tif 000040
2004530209.tif 000041