(57)【特許請求の範囲】
【請求項１】
ソフトウェアおよびハードウェアを有するシステム（１２）上の複数のイベントに関するイベントデータを取得するように構成されたシナリオオブザーバ（２６）であって、前記複数のイベントがユーザ入力を含む、シナリオオブザーバ（２６）と、
前記イベントデータを複数のシナリオ（１８）と関連付けるように構成されたシナリオアソシエータ（２７）と、
前記システム（１２）の使用パターンを識別するために前記複数のシナリオ（１８）を分析するように構成されたシナリオアナライザ（３０）と、
を備え、
前記複数のシナリオ（１８）のそれぞれが、一意に識別される複数のイベントのサブセットを含み、
前記一意に識別される複数のイベントのサブセットの前記サブセットは、開始イベント、終了イベント、および１つ以上の中間イベントを含み、
前記シナリオアナライザ（３０）が、前記使用パターンを識別して前記システムに対する変更の優先順位を付けるために前記複数のシナリオ（１８）を分析するように構成される、
システム。
【請求項２】
前記シナリオオブザーバ（２６）が、ユーザアクティビティオブザーバ（３６）と、ソフトウェアコンポーネントオブザーバ（３４）と、ハードウェアコンポーネントオブザーバ（３２）とを備える、請求項１に記載のシステム。
【請求項３】
前記シナリオオブザーバ（２６）が、前記システムの複数のユーザ入力デバイス、ソフトウェアプロセス、ハードウェアアクティビティ、またはそれらの組合せをモニタリングして、前記イベントデータをモニタリング中に取得するように構成される、請求項１または２に記載のシステム。
【請求項４】
前記シナリオアソシエータ（２７）が、前記複数のシナリオ（１８）のシナリオごとの前記開始イベント、前記終了イベント、または前記中間イベントのうちの少なくとも１つを識別するように構成される、請求項１から３のいずかに記載のシステム。
【請求項５】
前記シナリオアソシエータ（２７）が、新規シナリオマトリクスを作成すること、既存のシナリオマトリクスを更新すること、または前記複数のシナリオ（１８）を相関させることのうちの少なくとも１つを実行するように構成される、請求項１から４のいずれかに記載のシステム。
【請求項６】
シナリオアナライザ（３０）がメトリックを用いて前記使用パターンを識別するために前記複数のシナリオ（１８）を分析するように構成され、前記メトリックが前記複数のシナリオ（１８）における各シナリオ（１８）の使用の頻度または数を示すシナリオ使用メトリックを備える、請求項１から５のいずれかに記載のシステム。
【請求項７】
前記シナリオアナライザ（３０）がメトリックを用いて前記使用パターンを識別するために前記複数のシナリオ（１８）を分析するように構成され、前記メトリックが、各シナリオ（１８）と前記複数のシナリオ（１８）における他のシナリオとの間の一致の程度を示すシナリオ一致メトリック（８０、８２）を備える、請求項１から６のいずれかに記載のシステム。
【請求項８】
前記シナリオアナライザ（３０）がメトリックを用いて前記使用パターンを識別するために前記複数のシナリオ（１８）を分析するように構成され、前記メトリックがハードウェア使用メトリックおよびソフトウェア使用メトリックを備え、前記ハードウェア使用メトリックが前記システムの１つまたは複数のハードウェアコンポーネントの使用の程度を示し、前記ソフトウェア使用メトリックが前記システムの１つまたは複数のソフトウェアコンポーネントの使用の程度を示す、請求項１から７のいずれかに記載のシステム。
【請求項９】
前記使用パターンが低い使用から高い使用までの複数の異なる使用レベルを備える、請求項１から８のいずれかに記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書で開示する主題は、パターン分析およびシミュレーションに関し、より具体的には、ハードウェアシステムおよびソフトウェアシステムの使用パターンを分析し、シミュレートするためのシステムおよび方法に関する。
【背景技術】
【０００２】
ハードウェアシステムは、ターボ機械、センサ、アクチュエータ、およびオートメーションコントローラなどのコンポーネントを含む。ソフトウェアシステムは、ループ、制御構造、ネットワーキング構造、およびユーザインターフェース構造などの様々なソフトウェアの振る舞いを実行することができる実行可能なプロセスを含む。ユーザは、例えば、ハードウェアコンポーネントおよびソフトウェアコンポーネントの開発およびテスト中に、様々なユーザ入力を入力することによって、ハードウェアコンポーネントおよびソフトウェアコンポーネントと対話する。ユーザ入力には障害または予期しない結果を引き起こす可能性があるものもある。残念ながら、可能な入力および入力組合せの数は非常に多いので、可能な入力および入力組合せをすべてテストすることは実行不可能である。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】米国特許出願公開第２００９／０１２５５８１号明細書
【発明の概要】
【０００４】
本願発明と同等の範囲を有するいくつかの実施形態を以下で要約する。これらの実施形態は、本願発明の範囲を限定することを意図するものではなく、これらの実施形態は、本発明の可能な形態の概要を提供することのみを意図するものである。実際には、本発明は、以下で説明する諸実施形態と同様でも異なっていてもよい様々な形態を包含することができる。
【０００５】
第１の実施形態では、システムは、シナリオオブザーバ、シナリオアソシエータ、およびシナリオアナライザを含む。シナリオオブザーバは、ソフトウェアおよびハードウェアを有するシステム上の複数のイベントに関するイベントデータを取得するように構成され、複数のイベントはユーザ入力を備える。シナリオアソシエータは、イベントデータを複数のシナリオと関連付けるように構成される。シナリオアナライザは、システムの使用パターンを識別するために複数のシナリオを分析するように構成される。
【０００６】
第２の実施形態では、非一時的機械可読媒体が提供される。機械可読媒体は、イベントデータを複数のシナリオと関連付けるための命令を備え、イベントデータはソフトウェアベースのシステム上の複数のイベントに関し、複数のイベントはユーザ入力を備える。機械可読媒体はまた、ソフトウェアベースのシステムの使用パターンを識別するために複数のシナリオを分析するための命令を備える。
【０００７】
第３の実施形態では、方法が提供される。本方法は、イベントデータを複数のシナリオと関連付けるステップを含み、イベントデータはソフトウェアベースのシステム上の複数のイベントに関し、複数のイベントはユーザ入力を含む。本方法はまた、ソフトウェアベースのシステムの使用パターンを識別するために複数のシナリオを分析するステップを含む。
【０００８】
本発明のこれらのおよび他の特徴、態様、および利点は、全図面にわたって同様の文字は同様の部分を表す添付の図面を参照しながら以下の詳細な説明を読めば、よりよく理解されるようになるであろう。
【図面の簡単な説明】
【０００９】
【図１】システムの開発を可能にするのに適した論理の一実施形態の流れ図である。
【図２】シナリオオブザーバ、シナリオアナライザ、およびシナリオ関連付けコンポーネントの諸実施形態の概略図である。
【図３】データをシナリオに分類するのに適した論理の一実施形態の流れ図である。
【図４】シナリオマトリクスの一実施形態を示す図である。
【図５】シナリオデータベースの一実施形態のエンティティ関係図である。
【発明を実施するための形態】
【００１０】
本発明の１つまたは複数の特定の実施形態を以下で説明する。これらの実施形態の簡明な説明を提供するために、本明細書では、実際の実施形態のすべての特徴を説明するわけではない。任意のそのような実際の実施形態の開発においては、任意のエンジニアリングまたは設計プロジェクトにおいてと同様に、実施形態ごとに異なるシステム関連および業務関連の制約に従うことなどの開発者の特定の目的を達成するために、多数の実施形態固有の決定をしなければならないことを理解されたい。さらに、そのような開発努力は、複雑で時間がかかる可能性があるが、それにもかかわらず、本開示の利益を受ける当業者にとっては、設計、組立、および製造の定型業務であることを理解されたい。
【００１１】
本発明の様々な実施形態の要素を導入する場合、冠詞「ａ」、「ａｎ」、「ｔｈｅ」および「前記」は、１つまたは複数の要素があることを意味するものとする。用語「備える（ｃｏｍｐｒｉｓｉｎｇ）」、「含む（ｉｎｃｌｕｄｉｎｇ）」、および「有する（ｈａｖｉｎｇ）」は、包括的であり、リストアップされた要素以外に追加の要素があり得ることを意味するものとする。
【００１２】
ソフトウェア製品およびハードウェア製品は、顧客にリリースされる前に品質保証またはテストを受けることができる。テストは、いくつかの形を取ってよく、例えば、自動ソフトウェアシステムが、ソフトウェアが故障しないまたは「クラッシュ」しないことを検証するためにソフトウェアにデータをランダムに入力するように構成されてよい。しかし、（例えば、ほとんど無限に等しい）いくつかの入力スペースのサイズのために、１００％のテストカバレッジを提供することは不可能である。さらに、人間がいくつかのシステムのオペレータとして含まれている可能性があり、その場合は、テストプロセスに人的要因要素を含む必要がある。開示する諸実施形態は、使用パターンの分析およびシミュレーションのための技法およびシステムを対象とする。使用パターンの分析およびシミュレーションを、ハードウェアシステムおよびソフトウェアシステムのより正確な品質保証またはテストを可能にするために使用することができる。いくつかの実施形態では、使用パターンを、ヘビーな使用を有する、中間の使用を有する、または軽い使用を有するに分類することができる。エンジニアリング時間、予算、および技術者の数などの開発資源を、使用パターン分類に基づいて、より最適に割り当てることができる。さらに、既存の製品に関する使用パターンを捕捉し、分析することができる。すなわち、すでに実際に使用されている製品を分析することができ、その分析を製品のより新しいバージョンを改善する際に使用することができる。
【００１３】
一実施形態では、いくつかのタスクを実行しながら人間オペレータなどのユーザをモニタリングすることができる。他の実施形態では、いくつかのタスクまたはイベントを実行しながらソフトウェアシステムまたはハードウェアシステムなどのシステムをモニタリングすることもできる。次いで、モニタリングを分析し、シナリオに分類することができる。例えば、シナリオはいくつかの開始イベントおよび終了イベントを有するイベントのサブセットを含んでよい。これらの開始イベントおよび終了イベントは、以下でさらに詳細に説明するように、ハードウェアイベントおよび／またはソフトウェアイベントでよい。シナリオはまた、特定のモジュールまたはコンポーネントフォーカスを有するイベント、例えばタービンエンジンを始動することにフォーカスしたイベントのサブセットを含んでよい。さらに、シナリオは、ハードウェアタスクまたはソフトウェアタスクにフォーカスしてよく、例えば、シナリオは、ある一定のグラフィック情報システム（ＧＩＳ）マップデータを第１のＧＩＳシステムから第２のビジネスオペレーションシステムにコピー／ペーストすることにフォーカスしてよい。実際には、シナリオは、ハードウェアシステムおよびソフトウェアシステムを含めて、複数のシステムにわたるハードウェアイベントおよびソフトウェアイベントを含んでよい。
【００１４】
製品開発および／または「デバッギング」のために有用ないくつかのメトリックおよびレポートを得るためにシナリオを分析することができる。例えば、シナリオ分析は、ソフトウェアコンポーネントおよび／またはハードウェアコンポーネントの現実世界の使用頻度、使用時間、使用方法、および／またはシステムパフォーマンスを示す使用パターンを含んでよい。したがって、追加の開発努力および精査を受けるために、ヘビーな使用に含まれるシステムの分野に優先順位を付けることができる。したがって、システム開発者および技術者は、開発中のシステムを改善するためにシナリオ分析を使用することができる。さらに、次いで、システムに対する任意の変更をリファインするためにシナリオシミュレーションを使用することができる。実際には、繰り返し開発は、新規システムおよび／または改訂システムにおけるシナリオをシミュレートするために、捕捉したシナリオデータを使用することを含んでよい。次いで、システムをさらにリファインするために、本明細書で開示する諸実施形態を使用することにより新規システムおよび／または改訂システムを分析することができる、など。
【００１５】
次に、上記を考慮して図１を参照すると、システム１２の開発を可能にするのに適した論理１０の一実施形態が例示されている。論理１０は、ユーザ入力およびセンサ入力などの入力をシナリオ分析またはレポートなどの出力に変換するためにコンピューティングデバイス（例えばワークステーション）によって使用される非一時的機械可読コードまたはコンピュータ命令を含んでよい。システム１２は、ソフトウェアシステム、ハードウェアシステム、またはそれらの組合せでよい。例えば、システム１２は、オートメーションコントローラ論理、組込みシステム論理、アプリケーションソフトウェア論理、オペレーティングシステム論理、またはそれらの任意の組合せなどの論理を実行するのに適したコンピュータプログラムまたはコンピュータ命令でよい。システム１２はまた、産業システム（例えば、ターボ機械、産業プラントハードウェア、パワープラントハードウェア、化学プラントハードウェア）、コンピュータハードウェア（例えば、ワークステーション、ラップトップ）、オートメーションコントローラ（例えば、プログラマブル論理コントローラ）、またはそれらの組合せなどのハードウェアシステムでよい。
【００１６】
論理１０は、第１に、システム１２のアクティビティをモニタリングすることができる（ブロック１４）。例えば、ユーザアクティビティ（例えば、マウス移動、クリック、キーボードを押すこと）および／またはソフトウェアアクティビティ（例えば、関数呼出し、プログラムカウンタの状態、レジスタの状態、ヒープの割り当て、スタックの割り当て、中央処理装置（ＣＰＵ）の使用、メモリの使用、ネットワークの使用、ページファイルの利用）など、ソフトウェアシステムにおけるアクティビティをモニタリングするためにソフトウェア「フック」を使用することができる。ソフトウェア「フック」は、システムの中断、イベントハンドラ、ネットワークハンドラ、仮想表などを含んでよい。実際には、ユーザアクティビティおよびソフトウェアアクティビティを中断するために有用な技法を使用することができる。ハードウェアシステムにおけるアクティビティをモニタリングするためにセンサ信号を使用することができる。例えば、システムアクティビティをモニタリングするために、温度センサ、負荷センサ、圧力センサ、フローセンサ、および速度センサを使用することができる（ブロック１４）。次いで、図３に関して以下でさらに詳細に説明するように、モニタリングしたアクティビティをシナリオ１８に分類することができる（ブロック１６）。シナリオ１８は、ユーザアクティビティ、センサ信号、および／またはソフトウェアモジュールに関するソフトウェアアクティビティを含んでよい。例えば、シナリオ１８は、ＧＩＳプログラムのマップモジュールなどのモジュールを使用しながら行われるすべての（またはいくつかの）モニタリングしたアクティビティに基づいてよい。他の実施例では、シナリオ１８は、印刷モジュール、リーク分析モジュール、ネットワークモジュールなどと関連付けられたすべての（またはいくつかの）アクティビティをモニタリングすることに基づいてよい。さらに、シナリオ１８はまた、モニタリングしたハードウェアコンポーネントからのアクティビティを含んでよい。例えば、シナリオ１８は、燃料ノズル、コンプレッサ、燃焼器、タービンエンジン、ディフューザなどのタービンコンポーネントに向けられたすべてのアクティビティを含んでよい。さらに、シナリオ１８は、ＧＩＳマップを作成すること、ファイルを印刷すること、他のユーザと協働すること、タービンを始動すること、タービンをランプアップすること、タービンをランプダウンすること、および／またはタービンをシャットダウンすることなどのタスクにフォーカスすることができる。
【００１７】
次いで、シナリオ１８を分析することができる（ブロック２０）。一実施形態では、シナリオの分析は、シナリオのための使用時間、所与の時間期間（例えば、分、時間、日、週）の間の使用頻度、すべてのシナリオのための使用と比較したある時間期間中の使用割合、使用方法（例えばタッチスクリーン、マウス、マウスおよびキーボード、キーボードだけ、ジョイスティック、トラックボール、音声認識による使用）、および／またはソフトウェアコンポーネントおよび／またはハードウェアコンポーネントのシステムパフォーマンスに関するメトリックなどのシナリオメトリックを計算することを含んでよい。ソフトウェアシステムのための分析は、ＣＰＵの利用、メモリの利用（例えば、ヒープ、スタック、仮想メモリ、ページング）、関数呼出しのリスト、プログラムカウンタの状態、レジスタの状態、ネットワークの使用（例えば、送信されたバイト、受信されたバイト、パケットカウント、ホップカウント）などのシナリオソフトウェア使用メトリックの微分を含んでよい。ハードウェアシステムに関するパフォーマンス分析は、分析するべきハードウェアのタイプに基づく。例えば、タービンシステムに関するシナリオ１８の分析は、電流負荷、シャフト速度、燃料フロー、コールドスタートの数、振動、温度、圧力などのシナリオハードウェア使用メトリックを含んでよい。
【００１８】
次いで、分析したシナリオ１８を、開発中のシステムを改訂および改善するために使用することができる（ブロック２２）。一実施形態では、いくつかのタスクを実行する（例えば、マップをコピー／ペーストする、マップレジェンドをタイプする、および地理的位置を入力する）頻度などの使用パターンを得ることができる。一実施形態では、使用パターンをヘビーな使用パターン、中程度の使用パターン、および軽い使用パターンに分類することができる。他の実施形態では、使用パターンに１から１０までのスケールなどのスケールを適用することができる。この実施形態では、１０の値は非常にヘビーな使用を意味することができ、１の値は低い使用を意味することができる。次いで、システム開発者は、観察したコンポーネントに対して固定または拡張の優先順位を付けることができる。次いで、例えば、複数の動作を簡単にし、すべての様々な制御を１つの単一画面に入れるダイアログボックスを提供することによって、マップおよび関連情報を絶えずコピー／ペーストする必要をなくして、システムを再設計することができる。したがって、実行するのに数分かかった可能性があるタスクが、今は１分もかからない可能性がある。同様に、ソフトウェアプロセスまたはモジュールを分析することができ、この分析を、システム１２を改善するために使用することができる。例えば、ソフトウェアプロセスまたはモジュールが数回ネットワーク帯域幅のかなりの部分を使用するのが見られることがある。したがって、時間中ネットワーク使用をより一様に分配するように、ソフトウェアプロセスを修正することができる。同様に、ハードウェアプロセスを分析し改善することができる。例えば、タービンシステムのコールドスタート中に、熱勾配のためにコンプレッサが遅れるのが見られることがある。したがって、熱勾配を最小限にする、またはなくすために、コンプレッサを再設計することができる。
【００１９】
シナリオ分析（ブロック２２）はまた、使用中に生じた可能性があるエラーまたは「バグ」の分析を含んでよい。実際には、今各シナリオ中に生じるエラーのタイプおよび数を捕捉し、使用アクティビティ、プロセスアクティビティ、および／またはハードウェアアクティビティに相関させることができる。例えば、いくつかのエラーは、ユーザアクション（例えば、ボタンをクリックすること）のある一定の組合せが特定のプロセスアクティビティ（例えば、ファイルの印刷）中に生じたときにしか生じ得ない。ボタンが押された場合に実行されるソフトウェアは、プリンタドライバによって使用される何らかのメモリを故意にではなくオーバライドしている可能性がある。シナリオ捕捉および相関分析を含む本明細書における技法を使用して、そのようなエラーをより容易に見つけ、診断することができる。同様に、ハードウェアエラーをユーザアクティビティおよび／またはプロセスアクティビティにログし、相関させることができる。例えば、タービンの間違った始動を、オペレータによって実行される動作に、および自動化されたプロセスアクティビティにログし、相関させることができる。分析は、間違った始動は、オペレータが点火するのが早すぎて自動オーバロード保護システムがアクティブになった場合に生じる傾向にあることを示すことができる。次いで、いかなるエラーにも対処するために、システム１２を修正または改訂することができる。
【００２０】
いくつかの実施形態では、改訂されたシステム１２において、シミュレーションを実行するためにシナリオ１８を使用することができる（ブロック２４）。より具体的には、次いで、システムアクティビティのモニタリング（ブロック１４）中に捕捉され、各シナリオ１８と関連付けられたデータを、改訂されたシステム１２上でシナリオをシミュレートするために使用することができる。実際には、通常シナリオ１８中に生じるアクティビティのハイフィデリティシミュレーション（ブロック２４）を可能にするために十分なデータを捕捉することができる（ブロック１４）。このアクティビティを、改訂されたシステム１２において繰り返すことができ（ブロック２４）、その結果を、システム１２をさらにリファインし再設計するために使用することができる。例えば、シミュレーションは、ヘビーな使用、中程度の使用、または軽い使用を有する新規のシナリオを識別することになる可能性がある。したがって、次いで、開発資源の優先順位を付け、かつ／または開発資源をシミュレーションに基づいて割り当てることができる。このようにして、システム１２を繰り返して開発することによって、シナリオ１８は、システム１２の結果としての品質およびパフォーマンスをかなり改善することができる。
【００２１】
図２は、シナリオオブザーバ２６、シナリオ関連付けコンポーネント２７（すなわち、シナリオアソシエータ）、シナリオ捕捉データベース２８、およびシナリオアナライザ３０の一実施形態を例示する概略図である。図示した実施形態では、シナリオオブザーバ２６を、システム１２のアクティビティをモニタリングし捕捉するために使用する。シナリオオブザーバは、ハードウェアコンポーネントオブザーバ３２、ソフトウェアコンポーネントオブザーバ３４、およびユーザアクティビティオブザーバ３６をさらに含んでよい。ハードウェアコンポーネントオブザーバ３２は、システム１２に関するハードウェアベースのデータを受信し、モニタリングするように構成される。例えば、１つのハードウェアコンポーネントオブザーバ３２は、システム１２のタービンエンジンをモニタリングするように構成されてよく、一方、第２のハードウェアコンポーネントオブザーバ３２は、システム１２のコンプレッサをモニタリングするように構成されてよい。燃料ノズル、インレット、コンプレッサ、シュラウド、タービンエンジン、ディフューザなどの任意のハードウェアコンポーネントをモニタリングすることができる。同様に、ソフトウェアコンポーネントオブザーバ３４は、システム１２の特定のソフトウェアモジュールをモニタリングするように構成されてよい。ＧＩＳマップモジュール、印刷モジュール、リーク分析モジュール、ネットワークモジュール、または任意の他のソフトウェアモジュールをモニタリングすることができる。ソフトウェアモジュールは、システム１２に含まれる任意のアプリケーションモジュールまたは任意のオペレーティングシステムモジュールを含んでよいことに留意されたい。より具体的には、アプリケーションモジュールは、ユーザスペースにおいてタスクを実行するために開発された機能のセット（または単一の機能）を含んでよく、一方、オペレーティングシステムモジュールは、カーネルまたはオペレーティングシステムスペースにおいてタスクを実行するために開発された機能のセット（または単一の機能）を含んでよい。実際には、ソフトウェアコンポーネントオブザーバ３４は、任意のソフトウェア機能またはソフトウェアタスクを観察することができる。
【００２２】
一実施形態では、ユーザアクティビティオブザーバ３６は、システムの特定のユーザに関するアクティビティを観察するように定められてよい。この実施形態では、モニタリングされるユーザを追跡するためにユーザログインまたはユーザＩＤを使用することができる。他の実施形態では、ユーザアクティビティオブザーバ３６は、ユーザのグループのアクティビティを観察するように定められてよい。そのようなグループは、シナリオオブザーバ２６において定義されてもよく、またはオペレーティングシステムによって定義されてもよい。例えば、オペレーティングシステムは、ユーザをグループ化し、各グループにいくつかのユーザ特権を割り当てることに向けられた機能を含んでよい。したがって、ユーザアクティビティオブザーバ３６は、オペレーティングシステム機能によって割り当てられたグループをモニタリングすることができる。したがって、ユーザアクティビティオブザーバ３６は、マウス入力、タッチスクリーン入力、ジョイスティック入力、トラックボール入力、キーボード入力、音声入力、プッシュボタン入力、および／またはスイッチ入力などのユーザ入力をモニタリングすることができる。実際には、マウス、キーボード、タッチスクリーン、指紋リーダ、マイクロホン、および他の周辺デバイス（例えば、スキャナ、プリンタ、ディスプレイ、ビデオカメラ）などの様々な入力デバイスをモニタリングすることができる。
【００２３】
次いで、シナリオアソシエータ２７は、図３に関して以下でさらに詳細に説明するように、シナリオを作成し、関連付けられたアクティビティをシナリオにリンクするためにすべてのモニタリングしたアクティビティを使用することができる。次いで、シナリオならびにすべてのモニタリングしたアクティビティを、シナリオ捕捉データベース２８に格納する。シナリオ捕捉データベース２８は、リレーショナルデータベース、オブジェクト指向データベース、ネットワークデータベース、テキストファイル、または他の任意の適切なリポジトリなどの任意の適切なデータベースでよい。データベース２８の１つのリレーショナルデータベース実施形態を以下で図５に関してさらに詳細に説明する。次いで、上記で図１のブロック２０に記載したように、シナリオアナライザ３０はシナリオを分析するためにデータベース２８を使用することができる。アクティビティを特定のシナリオと関連付けることによって、シナリオは現実世界の使用を反映するので、システム１２の開発が改善される。したがって、様々なメトリックを計算するためにシナリオを分析し、その分析を、システム１２を改善するために使用することができる。
【００２４】
図３は、データをシナリオに分類するために、オブザーバ３２、３４、および３６から受信したデータを関連付けるのに適した論理４０の一実施形態を例示する。すなわち、モニタリングされるすべてのアクティビティまたはイベントを、引き続きシナリオに属するように割り当てることができる。論理４０は、第１に、イベントが開始ベントかどうかを判定するために（判断４４）、イベントを分析する（ブロック４２）。開始イベントは、シナリオにおける第１の開始イベントに対応するオブザーバ３２、３４、および３６によってモニタリングされたアクティビティのある一定のサブセットである。例えば、テキストファイルの印刷を含むシナリオは、その開始イベントとしてテキストエディタの起動を有してよい。他の実施例では、タービンエンジンの始動を含むシナリオは、開始イベントとしてシャフトを回転させるために電気モータを使うことを含む。すべての開始イベントおよびそれらの対応するシナリオを図２のシナリオデータベース２８にリストアップすることができる。したがって、各イベントを、そのイベントが開始イベントかどうかを判定するために（判断４４）、開始イベントのリストと比較することができる。
【００２５】
イベントが開始イベントである場合は、論理４０はシナリオ捕捉を開始することができる（ブロック４６）。すなわち、論理４０は、すべての捕捉したアクティビティまたはイベントを特定のシナリオと関連付けることができる。したがって、論理４０は、次に続くイベントを捕捉し（ブロック４８）、捕捉したイベントをシナリオデータベース内のイベントリストと比較する（判断５０）。イベントがシナリオデータベースにあると判定した場合は（判断５０）、このイベントを使用してシナリオマトリクスを作成または更新する（ブロック５２）。シナリオマトリクスは、以下で図４に関してさらに詳細に説明するように、現在のシナリオと関連付けられたイベントのグループ化である。シナリオマトリクスは、シナリオの使用および他のメトリックを追跡および更新するために、タスクのグループを所与のシナリオと関連付けることを可能にする。いくつかの場合には、例えば、捕捉したイベント（ブロック４８）が開始イベントである場合には、シナリオマトリクスレコードはデータベースに存在しない。したがって、新規のシナリオマトリクスレコードを作成し（ブロック５２）、次に続くイベントを捕捉したときに更新する。他の場合には、捕捉したイベント（ブロック４８）をすでに作成してあるシナリオマトリクスと関連付ける。これらの場合には、新規に捕捉したイベントを反映するために既存のシナリオマトリクスを更新する（ブロック５２）。
【００２６】
イベントがデータベースにリストアップされていない場合は（判断５０）、論理４０は、イベントがデータベースにリストアップされている親を有するかどうかを判定する（判断５４）。すべてのイベントは、子イベント、孫イベント、ひ孫イベントなどを有することができる。実際には、親イベントが次に続く子イベントをリンクするイベントの階層を使用することができる。例えば、「ファイル」イベントは、「ファイルを保存する」という子イベントを有することができる。次に、イベント「ファイルを保存する」は、子イベント「ファイルを取り替える」を有することができる。各子イベントを１つまたは複数の親イベントにリンクすることもできる。例えば、イベント「ファイルを取り替える」は、イベント「ファイルを…として保存する」、「ファイルを保存する」、および「新規ファイルを作成する」の子イベントであり得る。同様に、イベント「ファイルを印刷する」は、子イベント「ファイルを選択して印刷する」を有することができ、次に、子イベント「ファイルを選択して印刷する」は、子イベント「プリンタを選択して印刷する」を有することができる。親イベントがあった場合は（判断５４）、さらにイベントを追跡し（ブロック５６）、シナリオマトリクスを更新する（ブロック５８）。シナリオマトリクスを更新すること（ブロック５８）は、新規に捕捉した子イベントをデータベースに追加すること、および捕捉した子イベントを親イベントのシナリオにリンクすることを含む。
【００２７】
子イベントが親を有しない場合は（判断５４）、前述のように、シナリオマトリクスを作成または更新するために（判断５２）イベントを再度使用し、次いで、論理４０はイベントを追跡し続けることができる（ブロック５６）。イベントを追跡し（ブロック５６）、シナリオマトリクスを更新する（ブロック５８）とき、イベントが終了イベントかどうかを判定するために（判断６０）イベントを検査する。終了イベントは、タスクのシナリオグループ化を完了するイベントである。言い換えれば、終了イベントはシナリオにおける最後のタスクである。例えば、テキストファイルを印刷するシナリオは、終了イベントとして「ファイル印刷完了」というダイアログボックスのポップアップを含む。同様に、タービンエンジンを始動するシナリオは、シャフトがある一定の最低速度を達成することに関する終了イベントを含んでよい。
【００２８】
イベントが終了イベントであるという判定を行った（判断６０）後は、シナリオにイベントがないかチェックするために別の判定を行う（判断６２）。イベントがシナリオデータベースにない場合は、子イベントがないかチェックするために判定を行う（判断６４）。前述のように、終了イベントを含めてすべてのイベントは、子イベントを有することができ、次に、子イベントは孫イベントを有することができ、以下同様である。したがって、終了イベントが任意の子イベントを有することができるかどうかチェックするために判定を行う（判断６４）。終了イベントが子イベントを有する場合は、子イベントを追跡し（ブロック５６）、それに対応してシナリオマトリクスを更新する（ブロック５８）。
【００２９】
終了イベントがシナリオデータベースにある（判断６２）、または終了イベントが子を有しない（判断６４）と判定した場合は、シナリオがすでに利用可能であるかどうかチェックするために判定を行う（判断６６）。すなわち、シナリオが現在モニタリングされていることを検証するために判定を行う（判断６６）。シナリオが利用可能である場合は（判断６６）、シナリオマトリクスを終了イベント情報で更新し（ブロック６８）、シナリオを閉じる（ブロック７０）。同様に、シナリオがまだ利用可能でない場合は（判断６６）、シナリオを閉じる（ブロック７０）。シナリオを閉じること（ブロック７０）は、さらにモニタリングされたアクティビティの閉じられるシナリオとのリンクまたは関連付けを終わらせることができる。次いで、シナリオ使用メトリックを得るために、モニタリングされたシナリオデータをさらに分析することができる。論理４０は、ユーザイベント、ソフトウェアイベント、およびハードウェアイベントなどのイベントの階層を１つまたは複数のシナリオに関連付ける適切なやり方を提供する。次いで、システム１２を開発および／またはデバッグする際に有用な様々なシナリオメトリックおよび他の情報を計算するためにシナリオを分析することができる。
【００３０】
図４は、２つのシナリオ「Ａ」および「Ｂ」を格納しているシナリオマトリクス７２の一実施形態を例示する。一実施形態では、シナリオアナライザ３０（図２に示す）は図３の論理および図５のデータベースを使用してシナリオマトリクス７２を得ることができる。さらに、１つまたは複数のシナリオを比較する、またはそうでなければ分析するのに適したレポートを生成するために、シナリオマトリクス７２を使用することができる。実際には、システム１２の機能を改善するために、ならびにシステム１２を「デバッグ」するために、シナリオマトリクス７２を使用することができる。この例示的実施形態では、シナリオマトリクス７２は、列「モジュール名」７４、「シナリオ」７６、「ユーザステップ」７８、「使用された回数」８０、「一致割合」８２、および「平均ＣＰＵ／メモリ使用率」８４を含む。「モジュール名」列７４は「シナリオ」列７６に格納されているいくつかのシナリオと関連付けられたモジュールまたはコンポーネントの名称を格納する。この図示した実施形態では、システム１２のモジュール「リーク分析」は、シナリオ「Ａ」および「Ｂ」と関連付けられる。「ユーザステップ」列７８は、例えばユーザアクティビティオブザーバ３６（図２に示す）によって捕捉されたユーザイベントまたはステップを格納する。シナリオ「Ａ」は、７つの捕捉されたイベントを有するように示され、一方、シナリオ「Ｂ」は、１０の捕捉されたイベントを有するように示されている。シナリオと関連付けられたイベントごとのイベント識別子も示されている。シナリオ「Ａ」は、イベント「０」、「４４５」、「４５６」、「５０２」、「４３２」、「５５５」、および「５１６」を有する。同様に、シナリオ「Ｂ」は、イベント「０」、「５４」、「２１６」、「３４３」、「４４５」、「４５６」、「５０２」、「４３２」、「５５５」、および「５１６」を有する。前述のように、各イベント識別子は、イベントを一意に識別する。例えば、識別子「０」は、イベント「メインのマップ選択を実行する」を一意に識別し、一方、識別子「４４５」は、イベント「リーク分析タブを選択する」を一意に識別する。
【００３１】
シナリオマトリクス７２はまた、シナリオおよびイベントを分析する際に有用な列を含む。例えば、「使用された回数」列８０は、シナリオが1日などのある一定の時間期間中に使用された回数を格納することができる。図示した実施例では、シナリオ「Ａ」は、１日の間に５回使用されるように示され、一方、シナリオ「Ｂ」は、１日の間に６回使用された。「使用された回数」という使用シナリオメトリックは、開発者が使用パターンを評価し、システム１２を再設計または開発してモニタリングされるシナリオのためのサポートをより効果的に提供することができるようにする。例示した実施例では、シナリオ「Ｂ」は、シナリオ「Ａ」より多く使用され、より多くのユーザイベントを含む。したがって、シナリオ「Ｂ」に含まれるユーザアクションの数を低減するためにシステム１２の「リーク分析」モジュールをさらにリファインすることができる。
【００３２】
シナリオの分析に有用な他の列は、「一致割合」列８２、および「平均ＣＰＵ／メモリ使用率」列８４を含む。「一致割合」列８２は、複数のシナリオにまたがるイベントを比較する際に有用である。より具体的には、「一致割合」列８２は、複数のシナリオにまたがって共有されるイベントの割合の比較を可能にするシナリオ一致使用メトリックである。例えば、第１のシナリオが識別子「０」を有する単一のイベントを有し、第２のシナリオが識別子０を有するイベントを含む２つのイベントを有する場合は、第１のシナリオは第２のシナリオにおけるイベントの半分を有するので、第１のシナリオは第２のシナリオと５０パーセントの一致を有することになる。例示した実施例では、シナリオ「Ａ」は、シナリオ「Ｂ」と７０パーセントの一致を有する。さらに、シナリオ「Ｂ」は、シナリオ「Ａ」と６０パーセントの一致を有し、シナリオ「Ｘ１」と９０パーセントの一致を有し、シナリオ「Ｘ２」と７０パーセントの一致を有する。シナリオが相互にどのくらい密接に関係しているかを分析するために「一致割合」列を使用することができる。したがって、システム１２を改善するために開発決定を行うことができる。例えば、シナリオが密接に関係しすぎている場合は、これは、システムが同じタスクを実行するために多すぎる機構または手段を提供していることを示している可能性がある。したがって、これらの機構のうちのいくつかを除去するためにシステム１２を再設計することができる。同様に、シナリオ間の低い共通性は、タスクを実行するには少なすぎる共有機構を提供する過度に複雑なシステム１２を示している可能性がある。より一般的な機能やグラフィカルインターフェースなどを追加することによってシステムの複雑性を低減することができる。
【００３３】
シナリオ中に使用されたＣＰＵ資源の割合およびメモリの割合を追跡するために「平均ＣＰＵ／メモリ使用率」列８４を使用することができる。例示した実施例では、シナリオ「Ａ」は、ＣＰＵの６０％およびメモリの８０％を使用した。比較として、シナリオ「Ｂ」は、ＣＰＵの２０％およびメモリの４０％しか使用しなかった。シナリオ「Ｂ」は、シナリオ「Ａ」より多くのイベントを含むので、シナリオ「Ａ」に関するより高い「平均ＣＰＵ／メモリ使用率」メトリックは、機能のうちの１つがメモリリークおよび／または多分デッドロックしたプロセス（例えば、適切に終了しないプロセス）を有することを示している可能性がある。したがって、リークもしくはデッドロックの位置を特定し修理するのに適したデバッグスコープまたは他の技法を使用することができる。他の実施形態ではシナリオマトリクス７２に他の列を追加することができることを理解されたい。例えば、他の列は、使用される関数呼出しのタイプおよび数、プログラムカウンタ状態、レジスタ状態、ヒープ割当てメトリック、スタック割当てメトリック、ＣＰＵ使用メトリック、見つけられた「バグ」の数（すなわち、「バグ」カウント）、および／またはネットワーク使用メトリックなど、他のシナリオメトリックを格納することができる。
【００３４】
シナリオアナライザ３０（図２に示す）はまた、高い使用シナリオ、中間の使用シナリオ、または低い使用シナリオなどのシナリオ使用メトリックによってシナリオマトリクス内のシナリオを分類することができる。すなわち、使用レベルをシナリオに割り当てるためにシナリオ使用メトリックを使用することができる。一実施形態では、「使用された回数」８０、および「平均ＣＰＵ／メモリ使用率」８４などのいくつかのメトリックをいくつかの範囲と比較し、シナリオを分類するために使用することができる。例えば、「使用された回数」８０メトリックが１日約１００回を超えた場合は、このシナリオを高い使用に分類することができる。同様に、「使用された回数」８０メトリックが1日約５０回から１００回までの間である場合は、このシナリオを中間の使用に分類することができる。最後に、「使用された回数」８０メトリックが１日５０回より少ない場合は、このシナリオを低い使用に分類することができる。使用を分類するための実際の値（例えば、高い使用、中間の使用、または低い使用）は、ユーザのタイプ（例えば、システム管理者、正規の使用者）およびソフトウェアシステムまたはハードウェアシステムのタイプに応じて変わることを理解されたい。ｅメールシステムなどのいくつかのシステムは常時実行したままになっている可能性があり、したがって、そのようなシステムを分類するために使用される値は、非常に様々である（かつ、より高い）可能性がある。タービンシャットダウンシステムなどの他のシステムを使用することができることはたまにしかない。したがって、タービンシャットダウンシステムを分類するために使用される値はまた、様々である（かつ、より低い）。「平均ＣＰＵ／メモリ使用率」８４などの他のメトリックはまた、シナリオをヘビーな使用シナリオ、中間の使用シナリオ、または低い使用シナリオに分類する範囲を提供するためにユーザおよびシステムのタイプを考慮することができる。このようにして、シナリオマトリクス７２内のすべてのシナリオを分類するためにシナリオアナライザ３０を使用することができる。次いで、そのような分類を、開発資源をより効率よく割り当てるために使用することができる。
【００３５】
図５は、シナリオデータベース２８の一実施形態のエンティティ関係（ＥＲ）図を示す。前述のように、シナリオデータベース２８は、例示したようなリレーショナルデータベース実施形態を含んでよい。シナリオ「パターン」表８６は、シナリオに関する使用パターン情報を格納するための列８８、９０、９２、９４、９６、９８、１００、１０２、１０４、および１０６のセットを含んでよい。図示した実施形態では、「パターン」表８６は、「名称」列８８、「モジュール」列９０、「アプリケーション」列９２、「製品」列９４、「シナリオを開始する」列９６、「シナリオを停止する」列９８、「シーケンスレコードＩＤ」列１００、「１日当たりの回数」列１０２、「一致割合」列１０４、および「平均メモリ使用率」列１０６を含む。これらの列は、可変長文字列（すなわち、ＶＡＲＣＨＡＲ）データタイプまたは数値データタイプなどの適切なデータタイプを有してよい。ＶＡＲＣＨＡＲデータタイプは、可変長のテキストデータに対応できる。すなわち、ＶＡＲＣＨＡＲデータタイプは、可変長を有するテキストの格納を可能にする。数値データタイプは、数値データを有する列の格納を可能にする。
【００３６】
パターンの名称を格納するために「名称」列８８を使用することができ、一方、名称を付けられたパターンと関連付けられたコンポーネントまたはモジュールの名称を格納するために「モジュール」列９０を使用することができる。すなわち、ソフトウェアコンポーネントまたはハードウェアコンポーネントを「モジュール」列９０に格納することができる。例えば、「ＧＩＳ  Ｍａｐを作成する」８８という名称を付けられた使用パターンを「Ｃｒｅａｔｅ＿２Ｄ＿ＭＡＰ＿Ｊａｖａ」モジュール９０と関連付けることができる。「アプリケーション」列９２および「製品」列９４を、それぞれアプリケーションの名称および製品の名称と関連付ける。例えば、監視制御データ収集（ＳＣＡＤＡ）、ヒューマンマシンインターフェース（ＨＭＩ）、および／またはプログラマブルロジックコントローラ（ＰＬＣ）ソフトウェアまたはハードウェアなどのソフトウェアアプリケーションまたはハードウェアアプリケーションの名称を格納するために「アプリケーション」列９２を使用することができる。製品列９４は、ニューヨーク州スケネクタディ市のＧｅｎｅｒａｌ  Ｅｌｅｃｔｒｉｃ  Ｃｏ．から入手できるＥＮＭＡＣ（登録商標）またはＭＳ７０００ＦＡなどの顧客に販売された製品の名称を格納することができる。実際には、ソフトウェア製品および／またはハードウェア製品を格納することができる。開始イベントを、名称を付けられたパターンまたはシナリオと関連付ける、またはリンクするために、「シナリオを開始する」列９６を使用することができる。したがって、「シナリオを開始する」列９６を、捕捉されてシナリオのための開始イベントとして使用されたイベントを格納するために使用することができる。同様に、捕捉されてシナリオの終了イベントとして使用されたイベントを格納するために、「シナリオを停止する」列９８を使用することができる。
【００３７】
捕捉されたデータを順々にグループ化するために、「シーケンスレコードＩＤ」列１００を使用する。すなわち、以下でさらに詳細に説明するように、名称を付けられたパターンのモニタリング中に捕捉された一連のイベントを追跡するために「シーケンス」表１０８に関連して「シーケンスレコードＩＤ」列１００を使用することができる。名称を付けられたパターンを通常使用する１日当たりの回数を格納するために、「1日当たりの回数」列１０２を使用することができる。シナリオまたはパターンを相互に関連付けるシナリオメトリックを格納するために「一致割合」列１０４を使用する。より具体的には、図４に関して上記で説明したように、２つの（またはそれ以上の）シナリオが相互に共有するイベントの割合を追跡するために、「一致割合」列１０４を使用することができる。メモリ（例えば、ランダムアクセスメモリ（ＲＡＭ））がシナリオ中に平均してどれだけ使用されたかを計算するシナリオメトリックを格納するために、「平均メモリ使用率」列１０６を使用する。他の実施形態では追加の列を使用することができることを理解されたい。例えば、列は、使用される関数呼出しのタイプおよび数、プログラムカウンタ状態、レジスタ状態、ヒープ割当てメトリック、スタック割当てメトリック、ＣＰＵ使用メトリック、見つけられた「バグ」の数（すなわち、「バグ」カウント）、および／またはネットワーク使用メトリックなどの他のシナリオメトリックを格納することができる。
【００３８】
「シーケンス」表１０８は、２つの列、「シーケンスレコードＩＤ」列１１０および「イベントＩＤ」列１１２を含む。一連の関連付けられたイベントを追跡するために、「シーケンスレコードＩＤ」列１１０を増分して補足することができる。イベントがモニタリングされ捕捉されると、イベントは昇順のシーケンス番号を割り当てられ、「シーケンス」表１０８に格納される。したがって、システム１２のための一意のイベントのすべてを格納するために「イベント」表１１４を使用する。表１１４は、一意のイベントごとの識別子を格納するために「イベントＩＤ」列１１６を含む。列１１２および１１６を使用することによって、「シーケンス」表１０８は、「イベント」表１１４へのリンケージを可能にする。同様に、列１００および１１０を使用することによって、「シーケンス」表１０８は「パターン」表８６へのリンケージを可能にする。実際には、これらのリンケージは、パターン、シーケンス、およびイベント間の１対１、１対多、多対１、または多対多の関係でよい。
【００３９】
シナリオアナライザ（図２に示す）は、シナリオマトリクス７２（図４に示す）などのシナリオマトリクスを得るために、および得たシナリオを分析するために、表８６、１０８、および１１４を使用することができる。例えば、シナリオアナライザ３０は、高い使用パターンを有するモジュールを計算し、どのシナリオが高い使用パターンを含むかを詳述するレポートを提供することができる。実際には、シナリオアナライザはまた、低い使用パターンおよび中間の使用パターンを発見することができる。高い使用を示すモジュールおよびシナリオにフォーカスすることによって開発資源をよりよく利用することができる。同様に、平均より高い「バグ」カウントを示すモジュールおよびシナリオに、より高い開発優先順位を与えることができる。実際には、シナリオアナライザ３０は、シナリオデータベース２８を使用して、データベース２８に格納されているデータから得たメトリックに基づいてモジュールおよび／またはシナリオをターゲットにすることによって、開発資源の割当てをかなり改善することができる。
【００４０】
本発明の技術的効果は、システムのためにユーザアクティビティ、ソフトウェアアクティビティ、およびハードウェアアクティビティをモニタリングする能力を含み、モニタリングしたアクティビティをシナリオに分類する。モニタリングしたアクティビティを特定のシナリオに属するとして分類するのを支援するために複数の開始イベントおよび終了イベントを使用することができる。モニタリングはまた、システムをデバッグおよびリファインする際に有用なシナリオごとのメトリックを得ることを含んでよい。次いで、再設計および再開発から利益を受けるシステムのコンポーネントを判定するために、シナリオおよび得られたメトリックを分析することができる。さらに、本明細書で開示する技法を、顧客サイトにおいてデプロイされる既存のシステムにおいて、または市場にまだリリースされていない新規のシステムにおいて、使用することができる。
【００４１】
本明細書は、ベストモードを含めて、本発明を開示するために、および当業者が、任意のデバイスまたはシステムを作成することおよび使用することならびに任意の組み込まれた方法を実施することを含めて、本発明を実施することができるようにするために、実施例を使用する。本発明の特許可能な範囲は、特許請求の範囲によって定義され、当業者が思いつく他の実施例を含んでよい。そのような他の実施例は、特許請求の範囲の請求項の文字言語と異ならない構造要素を有する場合、または特許請求の範囲の請求項の文字言語と事実上異ならない同等の構造要素を含む場合は、特許請求の範囲の請求項の範囲内にあるものとする。
【符号の説明】
【００４２】
２６  シナリオオブザーバ
２７  シナリオ関連付けコンポーネント
２８  シナリオ捕捉データベース
３０  シナリオアナライザ
３２  ハードウェアコンポーネントオブザーバ
３４  ソフトウェアコンポーネントオブザーバ
３６  ユーザアクティビティオブザーバ
７２  シナリオマトリクス
【図１】
0006348249.tif 000002
【図２】
0006348249.tif 000003
【図３】
0006348249.tif 000004
【図４】
0006348249.tif 000005
【図５】
0006348249.tif 000006