JP2004533185A - 会話型階層状態の表示 - Google Patents

Abstract

本発明は、スノーフレーク・レイアウト内にレンダリング・フィッシュボーン・レイアウト（４５）を内蔵させるために、ネットワーク・リソースの状態を表示するための方法および装置を特徴とする。各フィッシュボーン・レイアウトは、リソース・プロファイル（３０）およびリソース・プロファイル（７７）間の従属関係を含む階層を特徴とする。リソース・プロファイルは、ネットワーク・リソースを表す。スノーフレーク・レイアウト（４６）内の階層は、共通の根を共有する。

Description

【技術分野】
【０００１】
本発明は、ネットワークの監視に関し、特に状態の表示に関する。
【背景技術】
【０００２】
（優先権の主張）
本出願は、引用によってその全文を本明細書の記載に援用する、２００１年６月８日出願の米国特許出願第６０／２９７，２１９号の優先権を３５ＵＳＣ§１１９（ｅ）により主張する。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ネットワーク監視ソフトウェアの目的は、ネットワーク・リソースに関する問題および潜在的問題を検出することである。それ故、ネットワーク監視ソフトウェアは、問題があるリソースから次のリソースにどのようにして伝搬する恐れがあるのかに関連する。ネットワーク監視ソフトウェアは、また、問題を起こしているいくつかの構成リソースを含む所与のリソースのために、所与の構成要素または一組の構成要素への問題の根元を分離することにも関連する。ネットワーク監視ソフトウェアのこの目標および関連する目標についての１つの用語は、「根本原因分析（ｒｏｏｔ ｃａｕｓｅ ａｎａｌｙｓｉｓ）」である。根本原因分析は、問題の発生源、すなわち、問題を伝搬した第１の状況を探す。それに沿って問題が伝搬した経路は、その問題が発生した第１のリソースと、その問題が伝搬した先の第２のリソースとの間の依存関係として表すことができる。第２のリソースが問題を引き起こさないかどうかは、第１のリソースに依存する。このように２つのリソースが関連している場合、従属関係は「二元性」のものになる。もっと複雑な従属関係は二元的なものではなく、３つまたはそれ以上のリソースが関連している場合がある。このような関係は、通常一組の二元従属関係で表すことができる。
【０００４】
有向木
図９Ａは、有向木３９、すなわち、コンピュータ業界では周知のデータ・モデルを示す。木３９は、ノード３９１および縁部３９６を含む。木３９は、その根３９２と呼ばれる正確に１つのノード３９１を含む。各縁部３９６は方向３９４を持ち、２つの異なるノード３９１を接続している。「経路」は各メンバー縁部３９６が、その近隣の縁部３９６とノード３９１を共有するような一連の縁部３９６である。
【０００５】
方向３９４は、２つのノード３９１の一方に、「起点」という名称をつけ、他方のノードに所与の縁部３９６に対して「宛先」という名称をつける。有向経路は、経路の第１の縁部３９６の起点ノード３９１「から」、経路の最後の縁部３９６の宛先ノード３９１「へ」つながっている。この場合、有向経路内の隣接する縁部３９６は、他方の宛先ノード３９１と一方の隣接する起点ノード３９１を共有する。有向木３９は、根３９２に関連する位置により各縁部３９６に対して決定した方向３９４を持つ。より詳細に説明すると、すべての縁部３９６が根３９２「の方を指している」か、またはすべての縁部３９６が根３９２「から反対方向を指している」有向木３９。根３９２「の方を指している」という用語のもっと正式な定義は、木３９の各縁部３９６は、根３９２に向かって有向経路をスタートするという定義である。同様に、根３９２「から反対方向を指している」という用語は、木３９の各縁部３９６は、根３９２からの有向経路のところで終わっていると定義することができる。
【０００６】
木３９の周知の特性としては、各ノード３９１が、木３９のある経路を通して、他の各ノード３９６に接続していることを意味する「接続状態」；および第１のノード３９１と第２のノード３９６の間の木３９の最短経路は、これらのノード３９６間のこのような経路だけであることを意味する「経路の一意性」等がある。この経路は最短距離の経路である。経路の「長さ」は、それが含む縁部の数である。
【０００７】
各ノード３９１の「深さ」は、ノード３９１を根３９２に接続する（一意の）経路の長さである。根３９２と呼ばれるノード３９１の深さはゼロである。すべての他のノード３９１は、ゼロでない整数の深さを持つ。
【０００８】
１つの縁部３９６のノード３９１を記述するには、「起点」および「宛先」の他にもう１つの方法がある。深さが浅い方のノード３９１は他のノード３９１の「親」と呼ばれ、一方、深さが深い方のノード３９１は親の「子」と呼ばれる。Ａがノード３９１である場合には、ＢはＡの子ノード３９１であり、ＣはＢの子ノード３９１である。その場合、ＣはＡの「孫」と呼ばれる。子ノードを持たないノード３９１は「葉」と呼ばれる。ノード３９１の子ノード３９１の数は、そのノード３９１の「等級」と呼ばれる。
【０００９】
同じ深さを持つノード３９１は、同じ「レベル」上に位置するといわれる。レベルはまた「層」とも呼ばれる。層は、多くの場合、そのノード３９１の深さを示す数により指定される。例えば、「層１」は、根３９２と縁部３９６を共有するすべてのノード３９１を含む。少なくとも２つの数学的真が、層に関して木３９内の縁部３９６に適用される（当業者にとって証明は周知のものである）。最初に、ゼロより大きい「ｎ」の場合には、各層の「ｎ」ノード３９１は、層「ｎ−１」内のノード３９１と正確に１つの縁部３９６を共有する。第二に、縁部３９６は、常に、異なる層、より詳細に説明すると、深さが正確に１だけ違う層からのノード３９１を結合する。第２の真の推論は、縁部３９６は、同じ層内でノード３９１と結合しないということである。これらの真は、直観的に下記のように要約することができる。木３９の縁部３９６は、常に隣接する層間で「上下に」移動するが、決して（１つの層内で）「横に」移動したり、ある層を飛び越したりしないし、また、根ノード３９２を除くすべてのノード３９１は親を持つ。
【００１０】
第１のノード３９１は、そのすべての子ノード３９１、孫ノード３９１、孫ノード３９１の子ノード３９１（以下同様）と一緒に、またその接続縁部３９６と一緒に、部分木３９５を形成する。今説明した部分木３９５は、それ自身根３９２として第１のノード３９１を持つ木３９である。部分木３９５は木３９と同じ構造および特性を持っているので、木３９は「自己類似」であるといわれる。多くの再帰的アルゴリズムは、木３９でうまく動作する。何故なら、他の理由もあるが、木３９が自己類似であるからである。
【００１１】
木３９の２つのノード３９１間の「距離」は、これらのノードを接続している最短経路の長さである。（木３９は接続しているので、少なくとも１つのこのような経路が存在すること、また木３９は経路の一意性を持っているので、正確に１つのこのような経路が存在することを思い起こされたい。）１つの縁部３９６を共有する２つのノード３９１は、「直接」接続している。これを表すもう１つの方法は、その経路の長さが１であることである。１より長い経路により接続している２つのノード３９１は、「間接的に」、すなわち、中間ノード３９１を通して接続している。
【００１２】
ノード３９１から深さの浅いノード３９１への方向は上方と呼ばれ、深さの深い方への方向は下方と呼ばれる。木３９を「横断する」ということは、順次そのノード３９１へポイントすることを意味する。この場合、連続しているノードが縁部３９６により接続している場合には、連続しているノード３９１が選択されるだけである。
【００１３】
ノード３９１は、木３９に参加するために必要なものに加えて、データ構造とすることができる。縁部３９６は、同じ様な方法で、追加のデータ構造を含むことができるデータ構造としてコード化される。それ故、ノード３９１および縁部３９６用のデータ構造のいくつかの属性は、木３９自身に固有のものではないエンティティに関連する場合がある。例えば、データ構造は、多くの場合、木３９によりモデル化されているコンセプトの属性を含む。
【００１４】
同じ用語が、階層が木構造を持つ等級に適用される。
【課題を解決するための手段】
【００１５】
一般的にいって、ある態様においては、本発明は、複数のリソース・プロファイルおよびこれら複数のリソース・プロファイル間に複数の従属関係を含む階層をフィッシュボーン・レイアウト（特性要因図）にレンダリングするステップを含む、ネットワークで接続しているリソースの状態を表示するためのコンピュータをベースとする方法を特徴とする。リソース・プロファイルは、ネットワークで接続しているリソースを表す。
【００１６】
好ましい実施形態は、下記のものの中の１つまたはそれ以上を含む。本発明の方法は、フィッシュボーン・レイアウトの監視下のリソース・プロファイルを含む監視下のリソースの状態を入手するステップと、その状態を反映するためにフィッシュボーン・レイアウトを更新するステップとを含む。状態を入手するステップは、一定の時間間隔で状態を反復して入手するステップを含む。上記状態を入手するステップは、最も最新の時間間隔内で変化した監視下のリソースの特性についての情報を入手するステップを含む。監視下のリソース・プロファイルは、監視下のリソース・プロファイルとコンシューマ従属関係にある従属リソース・プロファイルに、入手した状態をどのように伝搬すべきかについての伝搬規則を含み、一方、フィッシュボーン・レイアウトを更新するステップは、従属リソース・プロファイルのレンダリングを更新するステップを含む。このレンダリングは、最初に、フィッシュボーン・レイアウトの第１の密度モードにより、表示パネルにフィッシュボーン・レイアウトを表示し、一方、本発明の方法は、さらに、第１の密度モードを第２の密度モードに置き換えるステップを含む。この置換は、表示パネルのサイズに対するフィッシュボーン・レイアウトの部材の比率の変化に応じて行われる。フィッシュボーン・レイアウトの第１の密度モードは、層２のリソース・プロファイルを背骨としてレンダリングする標準モードであり、第２の密度モードは、第１の密度モードに対して、もっと高い密度でフィッシュボーン・レイアウトの構成要素をレンダリングするためのモードである。フィッシュボーン・レイアウトの第１の密度モードは、第２の密度モードに対して、もっと高い密度でフィッシュボーン・レイアウトの構成要素をレンダリングするためのモードであり、第２の密度モードは、層２のリソース・プロファイルを背骨としてレンダリングする標準モードである。フィッシュボーン・レイアウトでの２つのリソース・プロファイルのレンダリングの間の位相的接続の一例は、２つのリソース・プロファイル間の直接的な従属関係に対応し、一方、フィッシュボーン・レイアウトの２つのリソース・プロファイルのレンダリング間に位相的接続が存在しないということは、リソース・プロファイル間に任意の直接的な従属関係が存在しないことに対応する。フィッシュボーン・レイアウトの第２の密度モードは、層２のリソース・プロファイルを平行四辺形としてレンダリングする稠密モードである。
【００１７】
本発明の方法は、マウスオーバが継続した場合に応じて、フィッシュボーン・レイアウトの構成要素を記述する会話の要約を提示するステップを含む。この方法は、構成要素上でマウスが右クリックされた場合に、フィッシュボーン・レイアウトの構成要素に対するコンテキスト・メニューを表示するステップを含む。この場合、コンテキスト・メニューは、構成要素上で呼び出すための手順を提供するドリル・ダウン・リストを含む。コンテキスト・メニューは、構成要素に対してカスタマイズされる。ドリル・ダウン・リスト内のある手順は、ユーザが選択を行うとネットワーク分析ツール内の報告を呼び出す。ドリル・ダウン・リスト内のある手順は、構成要素がフィッシュボーン・レイアウトの根になるように、ユーザが選択を行った場合、フィッシュボーン・レイアウトの再度のレンダリングを行う。ドリル・ダウン・リスト内のある手順は、ユーザが選択を行った場合、フィッシュボーン・レイアウトを有する新しい表示パネルを開く。フィッシュボーン・レイアウトは、１つの根を有し、構成要素を根として使用する。ドリル・ダウン・リスト内のある手順は、ユーザが選択を行った場合、１つの根を有し、構成要素を根として使用する新しいスノーフレーク表示を開く。
【００１８】
他の態様においては、本発明は、ネットワークで接続しているリソースの状態を表示するためのコンピュータをベースとする方法を特徴とする。この方法は、ルート・リソース・プロファイル（ｒｏｏｔ ｒｅｓｏｕｒｃｅ ｐｒｏｆｉｌｅ）およびこのルート・リソース・プロファイルと従属関係にある従属リソース・プロファイルを含む階層を提供するステップを含む。一連の従属関係を含む各従属リソース・プロファイルからルート・リソース・プロファイルへの最短経路は、上記各従属リソース・プロファイルに対してその階層内の１つの層に対応する長さの経路を有する。リソース・プロファイルは、ネットワークにより接続しているリソースを表す。上記方法は、また、ルート・リソース・プロファイルまたは従属リソース・プロファイル間の監視下のリソース・プロファイルの状態を入手するステップと；上記状態を重大度に関連づけるステップと；フィッシュボーン・レイアウトの階層をレンダリングするステップとを含む。監視下のリソース・プロファイルは、重大度を示す視覚的特徴にレンダリングされる。
【００１９】
好ましい実施形態は、下記のものの中の１つまたはそれ以上を含む。視覚的特徴は、重大度の程度を表す複数の色から選択した１つの色を含む。状態を重大度と関連づけるステップは、監視下のリソース・プロファイルに関連する状態測定基準の使用を含む。この方法は、状態の変化の通知を入手するステップと、重大度を更新するステップと；更新した重大度を表示するために監視下のリソース・プロファイルをレンダリングするステップを含むために、フィッシュボーン・レイアウトの階層を再度レンダリングするステップとを含む。重大度は、状態測定基準が表す行動から逸脱するために、アプリケーション全体のオーバライドを適用するステップを含む。この逸脱は、重大度の変化を抑制するステップを含む。フィッシュボーン・レイアウトは、スノーフレーク・レイアウトに含まれている。
【００２０】
さらに他の態様においては、本発明は、ネットワークで接続しているリソースの状態を表示するためのコンピュータをベースとする方法を特徴とする。この方法は、リソース・プロファイルおよびこれらリソース・プロファイル間の従属関係を含む論理階層を入手するステップを含む。リソース・プロファイルはネットワークで接続しているリソースを表す。この方法は、また、論理階層から視覚的階層を入手するステップを含む。この場合、視覚的階層の構成要素は、視覚的階層が木であるような論理階層の構成要素に対応する。この方法は、フィッシュボーン・レイアウトで視覚的階層をレンダリングするステップを含む。
【００２１】
好ましい実施形態は、下記のものの中の１つまたはそれ以上を含む。視覚的階層は有向木である。フィッシュボーン・レイアウトは、スノーフレーク・レイアウトに含まれている。
【００２２】
さらに他の態様においては、本発明は、ネットワークで接続しているリソースの状態を表示するための計算装置を特徴とする。この装置は、プロセッサ、主記憶装置、視覚的表示装置、記憶装置、およびネットワーク接続を含む、その中で実施されているコンピュータ可読プログラム・コード手段を有する、コンピュータが使用することができる媒体を含む。プログラム・コード手段は、コンピュータに、リソース・プロファイルおよびこれらリソース・プロファイル間の従属関係を含む階層を表示させるためのコンピュータ可読プログラム・コード手段を含む。リソース・プロファイルは、ネットワークで接続しているリソースを表す。この装置は、また、コンピュータに、リソース・プロファイル間の監視下のリソース・プロファイルの状態を入手させるためのコンピュータ可読プログラム・コード手段を含む。この装置は、コンピュータに、監視下のリソース・プロファイルの状態の視覚的表現のレンダリングを含む、フィッシュボーン・レイアウトの階層をレンダリングさせるためのコンピュータ可読プログラム・コード手段を含む。
【００２３】
さらに他の態様においては、本発明は、スノーフレーク・レイアウトでフィッシュボーン・レイアウトをレンダリングするステップを含む、ネットワークで接続しているリソースの状態を表示するためのコンピュータをベースとする方法を特徴とする。フィッシュボーン・レイアウトは、それぞれリソース・プロファイルおよびこれらリソース・プロファイル間の従属関係を含む階層を特徴とする。リソース・プロファイルは、ネットワークで接続しているリソースを表す。各階層は共通の根を共有する。スノーフレーク・レイアウト内の１つまたはそれ以上のフィッシュボーン・レイアウトに関する好ましい実施形態は、フィッシュボーン・レイアウトのところですでに説明した１つまたはそれ以上の特徴を含む。
【００２４】
さらに他の態様においては、本発明は、ネットワークで接続しているリソースの状態を表示するための計算装置を特徴とする。該装置は、プロセッサ、主記憶装置、視覚的表示装置、記憶装置、およびネットワーク接続を含む、その中で実施されているコンピュータ可読プログラム・コード手段を有する、コンピュータが使用することができる媒体を含む。プログラム・コード手段は、コンピュータに、スノーフレーク・レイアウト内にフィッシュボーン・レイアウトをレンダリングさせるためのコンピュータ可読プログラム・コード手段を含む。各フィッシュボーン・レイアウトは、リソース・プロファイルおよびこれらリソース・プロファイル間の従属関係を含む階層を特徴とする。リソース・プロファイルは、ネットワークで接続しているリソースを表す。各階層は共通の根を共有する。
【００２５】
本発明の利点としては下記のものを含む。
【発明の効果】
【００２６】
根本原因分析は、従属関係用の有用なアプリケーションである。システム計画は、従属関係の知識から見て、同様に有用であり、そのため、変化の影響を予測することができる。
【００２７】
監視下のリソースの数が増大すると、ユーザは、相互に関連するリソースの組織化していないウェブを理解するのが困難になる。本発明の１つの利点は、ウェブ上に論理階層が置かれた場合、ルート・リソースに対して、フィッシュボーンまたはスノーフレークのようなレイアウトにより、論理階層が視覚的階層としてレンダリングされることである。フィッシュボーンまたはスノーフレーク内で発生するような視覚的階層の組織化した表現は、視覚的レンダリングの前には、意味が概念的に容易に理解できなかった場合でも、ウェブ内の状態の変化（例えば、ある問題の影響）の意味が視覚的に容易に理解することができることである。例えば、ルート・リソースの展望からリソースのウェブを見た場合、ウェブ内のルート・リソースの役割を洞察することができる。それにより、例えば、リソースが拡張された関係で中間的役割を果たしている場合には、多くの場合、他のリソースの役割も理解できる。上記関係が従属関係である場合には、１つの階層は、直接的に（根のすぐ下の階層のレベルで）、また間接的に（一時的に、その階層の以降のレベルで）、ルート・リソースが依存するすべてのリソースを表すことができる。
【００２８】
本発明のもう１つの利点は、同じ一組のリソース上で、複数の論理階層を定義し、種々の展望を提供することができることである。さらに、論理階層は、種々のユーザ・プロファイルに合わせて調整することができるので、（例えば）ある種のユーザに高いレベルの展望を与え、一方リソースのもっと狭いサブセットに対して責任を持つユーザは、そのユーザの興味に排他的に焦点を当てる視点を使用することができる。
【００２９】
本発明の１つまたはそれ以上の実施形態の詳細については、添付の図面および下記の説明内に記載する。下記の説明、図面および下記の特許請求の範囲を読めば、本発明の他の特徴、目的および利点を理解することができるだろう。種々の図面内の類似の参照符号は、類似の要素を示す。
【発明を実施するための最良の形態】
【００３０】
上記態様の場合には、会話型表示は、ネットワーク監視ソフトウェアが監視しているリソースについての状態情報を示す。階層状態表示プロセスは、視覚的階層内に表示のためのリソースを配列する。視覚的階層は、相互に従属関係にあるリソースを含む論理階層から由来する。論理階層は、データ・モデルであり、一方、視覚的階層は論理階層の図形による表示である。視覚的階層は、「フィッシュボーン」および「スノーフレーク」レイアウトを含む。スノーフレーク・レイアウトは、２つのフィッシュボーン・レイアウトを含む。フィッシュボーン・レイアウトは、論理階層を１つの面内に様式化した木として表示する。フィッシュボーン・レイアウトは、ある瞬間に、石川ダイアグラムでいくつかの視覚的属性を共有する。しかし、より詳細に説明するように、フィッシュボーン・レイアウトは、他にも違いはあるが、フィッシュボーン・レイアウトが動的に更新され、ユーザと会話している間に、時間の経過中に変化することができるという点で、石川ダイアグラムとは異なる。また、フィッシュボーン・レイアウトは、その関連する論理階層が、所与の表示エリアに表示できないほどのフィッシュボーン・レイアウトに対する多くの部材を含んでいる場合には、表示モード間で移動することができる。
【００３１】
階層状態表示プロセスは、ネットワーク監視ソフトウェアが監視しているリソースの状態が変化すると、視覚的階層を変えることができる。階層状態表示プロセスは、表示ウィンドウ内の視覚的階層をレンダリングする。ユーザは、各リソースに適合するように調整されたオプションのメニューを含む、リソースに関するもっと多くの情報を入手するために、表示ウィンドウと会話を行うことができる。オプションは、ユーザがリソースの詳細なチェックをスタートすることができる分析ツールを含む。分析ツールは、表示をレンダリングするアプリケーションの外部に存在する。通常、視覚的階層は、要約レベルの情報を表示し、一方、会話型オプションにより、ユーザは詳細レベルの情報を入手することができる。
【００３２】
リソースは、ネットワーク管理ソフトウェアが監視するエンティティである。リソースは、ハードウェア、アプリケーション、サービス、ビジネス・プロセス、組織化構造（企業または大学の学部内のビジネス・ユニットなど）、ネットワーク内の経路、および他のネットワーク・リソースを含む。ハードウェア・リソースは、クライアント、サーバ、ルータ、スイッチ、およびＮＩＣ、並びに周辺デバイス（ディスク・ドライブなど）、およびネットワークで接続しているデバイス（プリンタおよびネットワークで接続している記憶装置など）を含む。個々のネットワーク・リソース、およびこのようなリソースの集合体の両方がリソースとなることができる。リソースの集合体を含むリソースの場合には、リソースは分散型のものであっても、異質なものまたは両方であってもよい。この集合体は他の集合体を含むことができる。
【００３３】
図１Ａは、ＨＴＴＰインタフェース６０１を通して、ウェブ・サーバ６０にアクセスするクライアント・アプリケーション２２を含む階層状態表示プロセス２０である。クライアント・アプリケーション２２は、表示リポジトリ７５内に記憶している論理階層３０に関する情報を検索する。クライアント・アプリケーション２２は、論理階層３０をユーザ２３への表示ウィンドウ５０内に図形でレンダリングするために階層表現４０を使用する。
【００３４】
クライアント・アプリケーション２２は、状態リポジトリ７０および表示リポジトリ７５からの情報を求めてウェブ・サーバ６０にポーリングする。状態リポジトリ７０は、リソースの状態に関する情報を収集し、それをリポジトリ７０に入れる監視システム８０により維持される。
【００３５】
表示ウィンドウ５０は会話型である。すなわち、ユーザ２３からの入力に応答する。表示ウィンドウ５０を使用することにより、ユーザ２３は論理階層３０内に記述されているリソースに分析ツール９０を適用することができる。
【００３６】
計算プラットフォーム
図１Ｂについて説明すると、階層状態表示プロセス２０は、コンピュータ命令を含み、計算プラットフォーム６３上のオペレーティング・システム６３１上で稼働する。図面を簡単にするために、図１Ｂは、階層状態表示プロセス２０の実際の構成要素プロセスを、ネットワーク接続６３８により相互に接続している複数の計算プラットフォーム６３上で分散することができる場合の、１つのオペレーティング・システム６３１および関連するハードウェアと会話を行う階層状態表示プロセス２０を示す。
【００３７】
オペレーティング・システム６３１は、主記憶装置６３４または不揮発性記憶装置６３７または両方内に常駐する一組のコンピュータ命令である。プロセッサ６３３は、オペレーティング・システム６３１および階層状態表示プロセス２０に対するコンピュータ命令を実行するために、主記憶装置６３４および不揮発性記憶装置６３７にアクセスすることができる。
【００３８】
ユーザ２３は、視覚的表示装置６３９を含む１つまたはそれ以上の入力装置６３２、および１つまたはそれ以上の出力装置６３６を通して、計算プラットフォームと会話を行う。使用できる入力装置６３２としては、キーボード、マイクロホン、タッチセンシティブスクリーン、およびマウスのようなポインティング・デバイス等がある。視覚的表示装置６３９以外の使用できる出力装置６３６としては、スピーカおよびプリンタ等がある。通常、視覚的表示装置６３９は、種々の色を表示することができる（すなわち、モノクロ表示装置ではない）。
【００３９】
不揮発性記憶装置６３７は、ディスク・ドライブのようなコンピュータが書き込むことができ、コンピュータ可読媒体を含む。バス６３５は、プロセッサ６３３、入力装置６３２、出力装置６３６、記憶装置６３７、主記憶装置６３４、およびオプションとしてのネットワーク接続６３８を相互に接続する。ネットワーク接続６３８は、例えば、ＴＣＰ／ＩＰを実行するように構成されたイーサネット（登録商標）・カードのようなネットワーク機能を供給するためのデバイスおよびソフトウェア・ドライバを含む。
【００４０】
クライアント・アプリケーション２２は、Ｊａｖａ（登録商標）プログラミング言語で書き込まれる。クライアント・アプリケーション２２のいくつかの構成要素は、もっと低いレベルのコード（機械コードなど）にコンパイルされたＣ＋＋のような他の言語で書き込まれて、構成要素相互動作規格を通してソフトウェア・コードの本体に内蔵される。マイクロソフト・ウィンドウズ（登録商標）計算プラットフォームにおいては、例えば、構成要素相互動作規格は、ＣＯＭ（共通オブジェクト・モデル）およびＯＬＥ（オブジェクト・リンキングおよび埋込み）を含む。
【００４１】
監視システムおよびリソース
図４Ａについて説明すると、監視システム８０は、監視下の環境２５でリソース２４を監視する。どのリソース２４を監視すべきかの決定を含む監視システム８０の構成は、本発明の範囲内に含まれないので、ここでは詳細に説明しない。監視システム８０は、ネットワーク監視ソフトウェアを含む。市販の監視システム８０の一例としては、米国マサチューセッツ州マールボロ所在のＣｏｎｃｏｒｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ社が市販しているＬｉｖｅＥｘｃｅｐｔｉｏｎｓがある。
【００４２】
概念的には、リソース２４は、広い範囲の事柄用のプレースホルダーである。通常、リソースは、監視下の環境２５でのネットワーク通信に関連する機能を実行するか、または他のリソース２４との従属関係７８内に含まれる。この機能自身は、ネットワーク通信に直接関連するものでなくてもよい。例えば、サーバ内のディスク・ドライブは、サーバのネットワークで接続している役割により、ネットワークで接続しているリソース２４と見なすことができる。リソース２４を定義するもう１つの方法は、階層状態表示プロセス２０でそれがどのように使用されるかによる方法である。リソース２４は、監視システム８０により監視される何者かである。例えば、リソース２４は、パーソナル・コンピュータ、サーバ、ルータ、スイッチ、リンク、Ｌ３経路、または応答経路のような、監視される１つの物理的ユニットを表すことができる。しかし、リソース２４は、アトミックでなくてもよい。リソースは、リソース２４の１つのグループ、１つのグループ内の複数のグループ等を表すことができる。リソース２４は、例えば、ビジネス・プロセス、または部門またはプロジェクトのような組織上のユニットのようなコンセプトであってもよい。リソース２４は、また、レベル３のネットワーク経路のような論理的構造であってもよい。重要なことは、リソース２４は、また、アプリケーションまたはサービスのようなソフトウェアであってもよいということである。リソース２４は、分散させることもできるし、１台のコンピュータに集中させることもできる。
【００４３】
リソース２４の特性は、名前、あるシステムまたは領域内の役割、およびそのコンテキストに適している特性を含む。リソース２４の各特性は、現在の状態を含む。リソースは、また、所与の時点で現在の状態からの１つの値を持つ少なくとも１つの状態を持つ。リソース２４の状態に対する値の範囲は、通常、トラブルが無い状態、警告およびエラーに対する値を含む。
【００４４】
例えば、「東キャンパス・ルータ」という名称のリソースが存在するかもしれない。このリソースはあるネットワークでルータになる役目を持つ。このルータは、例えば、ＣＰＵのようなシステム構成要素、２つのネットワーク・インタフェース、および（ネットワークがＩＰプロトコルを使用すると仮定した場合の）少なくとも１つのＩＰアドレスのようなルータになるのに適した特性を有している。ネットワーク・インタフェースは、「理想的」、「混雑状態」および「故障」を含む動作状態を持つことができる。
【００４５】
図４Ｂについて説明すると、リソース２４は、表示リポジトリ７５内に位置していて、リソース表現７９５により表される。リソース表現７９５は、リソース２４および計算環境内で乗算を行うためのリソース２４の抽象特性を参照するソフトウェア・オブジェクトである。それ故、リソース表現７９５とそのリソース２４との間の相互関係は、概念的に非常に強固である。
【００４６】
リソース参照７９６はリソース２４を記述する。リソース表現７９５の特性７９７は、対応するリソース２４上の特性を表す。特性７９７は、特性状態７９８を含む。図４Ｂに示すように、監視下の環境２５は、任意のリソース参照７９６により参照されないリソース２４ｃを含むことができることに留意されたい。しかし、各リソース参照７９６は、ある種のリソース２４を記述する。
【００４７】
リソース・プロファイル
所与のリソース２４は、監視下の環境２５内で種々の役割を行うことができる。例えば、所与のサーバは、複数のアプリケーションおよびサービスをサポートすることができる。場合によっては、ある役割を行っているリソース２４に関する問題は、その役割の中の他の役割を行っている同じリソース２４に関する問題でない場合がある。例えば、あるレベルの混雑を経験しているルータは、ネットワーク・サービスをサポートしているリアルタイム・トラヒックを供給するために、ルータに依存するアプリケーション類似のビデオ会議の場合のように、「リアルタイム」コンテキストで問題を引き起こす場合がある。同時に、「電子メール」コンテキストの場合には、電子メール・アプリケーションは、同じルータに依存する場合があるが、混雑のレベルがある問題を発生する前に遥かに高いしきい値を持つことができる。
【００４８】
通常、リソース・プロファイル７７は、コンテキスト内でリソース２４を表現する１つの方法を提供する。それ故、所与のリソース２４は、２つ以上のコンテキストで表現することができる。
【００４９】
図５Ａについて説明すると、リソース・プロファイル７７は、リソース表現７９５を状態の値７７５とペアにする。この ペアの形成は、参照７７０によりコード化される。状態の値７７５は、関連するリソース表現７９５の状態７９８からのものである。この派生は状態測定基準７７６により与えられる。状態の測定基準７７６は、状態の値７７５が表す状態およびその値の加重方法を決定するので、状態の測定基準７７６は、その状態７９８の選択により、またそれが割り当てる出力によりコンテキストを表すことができる。例えば、図５Ａの場合には、リソース・プロファイル７７ａおよび７７ｂは、１つのリソース表現７９５に対する２つの異なるコンテキスト（それぞれ、「コンテキストＡ」および「コンテキストＢ）を表す。また、異なるプロファイル７７は、状態の測定基準７７６の使用のために同じ状態７９８を使用することにも留意されたい。図の例の場合には、リソース・プロファイル７７ａは、状態７９８ｉおよび７９８ｉｉを使用することができ、一方リソース・プロファイル７７ｂは、状態７９８ｉおよび７９８ｉｉｉを使用する。すなわち、状態７９８ｉは両方に共通である。
【００５０】
リソース・プロファイル７７は、そうでない場合には、イベント・フィルタ７７１内のこれらの分類に対する基準をコード化することにより、その状態の値７７５に影響を与える例外の分類を無視することができる。
【００５１】
リソース・プロファイル７７は、分析ツール９０により露出される分析機能７９９のドリル・ダウン・リスト７７８を指定することができる。ドリル・ダウン・リスト７７８は、視覚的階層４０内のリソース・プロファイル７７のレンダリングにより、ある相互作用中ユーザ２３に提示される。（「フィッシュボーン会話」の節を参照されたい。）ドリル・ダウン・リスト７７８は、ユーザ２３が使用することができる分析方法を調整するための方法を各リソース・プロファイル７７に供給する。
【００５２】
リソース・プロファイル７７を供給する市販の製品としては、米国マサチューセッツ州マールボロ所在のＣｏｎｃｏｒｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ社が市販しているＮｅｔｗｏｒｋＨｅａｌｔｈがある。
【００５３】
従属関係
図５Ｂについて説明すると、従属関係７８は、それにより、１つのリソース２４（この例の場合には、リソース２４ｂである）内のイベントが、他のリソース２４ａの状態に影響を与えることができる１つの条件を表す。より詳細に説明すると、リソース２４ｂは、リソース・プロファイル７７ｂにより参照されるリソース表現７９５ｂにより表される。同様に、リソース２４ａは、リソース・プロファイル７７ａにより参照されるリソース表現７９５ａにより表される。用語の下記の使用に留意されたい。コンシューマの従属関係７８の「方向」は、問題が伝搬する方向と反対方向である。リソース・プロファイル７７ａは、リソース・プロファイル７７ｂ「に依存する」かまたは「のコンシューマである」。一方、リソース２４ｂ内の問題は、リソース２４ａの方向に伝搬する（または影響を与える）。従属関係７８上の他の端部の展望から、すなわち、リソース・プロファイル７７ｂがリソース・プロファイル７７ａ「へのプロバイダである」プロバイダの従属関係７８の場合には、従属関係７８の方向は問題が伝搬する方向と一致する。
【００５４】
リソース・プロファイル７７は、コンテキストの視点から見るとリソース２４を表していることを思い起こされたい。従属関係７８は、リソース・エンティティ７９５ではなく、リソース・プロファイル７７を参照することによりコンテキストを内蔵する。
【００５５】
所与の従属関係７８に関連するリソース・プロファイル７７の数は、従属関係７８の「等級」と呼ばれる。２つのだけのリソース・プロファイルに関連する関係は「二元」と呼ばれる。図５Ｂは、例示としての二元従属関係７８である。２より高い等級の従属関係７８は、下記のように一組の二元従属関係７８により表すことができる。等級ｎの関係を記述するコンテキストを選択し、そのコンテキスト内の関連する各リソース２４に対してリソース・プロファイル７７を作成し、２つのリソース２４の相互作用を記述するために、リソース・プロファイル７７の各ペア間の二元従属関係７８を追加する。
【００５６】
コンシューマの関係およびプロバイダの関係は、実際の世界のアプリケーション内では共通である。これらの関係は、「内に含む」または「に依存する」という句で直観的に記述する多くの関係をモデル化することができる。「に依存する」という句は、明らかに従属関係７８に適している。「内に含まれる」という句も、また、多くの場合、従属関係７８によく適している。何故なら、構成要素内の問題は、多くの場合、全体に伝搬する恐れがあるからである。例えば、サーバＳが３つのハード・ディスク・ドライブＣ、ＤおよびＥに依存している場合には、Ｓ、Ｃ、ＤおよびＥに対するリソース・プロファイル７７、およびＳからＣ、ＤおよびＥへそれぞれ３つの従属関係７８を生成することができる。同様に、会計部Ａが２つのサーバＳおよびＴに依存している場合には、それぞれＡからＳおよびＴへ２つの従属関係７８と一緒に、ＡおよびＴに対して追加のリソース・プロファイル７７を生成することができる。１つのリソース２４が、いくつかの他のリソース２４を内蔵または統合していて、一方、それらリソースに依存している状態は、ネットワーク監視ソフトウェアのユーザにとって非常に重要である。
【００５７】
二元でない従属関係７８の一例は、３つまたはそれ以上のリソース２４を含む分散処理またはサービスの構成要素である。
【００５８】
論理階層
論理階層３０は、リソース・プロファイル７７間の従属関係７８のウェブを記述する木をベースとするデータ・モデルを提供する。表示リポジトリ７５は、図８に示すように、表示記録７５２内に各論理階層３０を記憶する。表示リポジトリ７５は、そこから２つ以上のクライアント・アプリケーション２２が、同時に同じ論理階層３０にアクセスすることができる中央の位置を供給する。
【００５９】
論理階層の意味
広い意味で、論理階層３０は、（以下にさらに詳細に説明するように）１つまたはそれ以上の概念上のフレームワークの下で、リソース・プロファイル７７およびその関連する従属関係７８を収集するための柔軟な構造である。その柔軟性により種々様々な設計を行うことができるので、論理階層３０は悪い設計の影響を受けやすい。例えば、ユーザ２３は、機能分析に基づく組織スキームより、アルファベット順の組織スキームを軽視する場合がある。もっと微妙には、第１のユーザ２３は、ネットワーク・ハードウェアに基づく機能分析よりもビジネス処理に基づく機能分析を軽視する場合がある。また、第２のユーザ２３は、おそらく第２のユーザ２３が監視下の環境２５内で、第１のユーザ２３とは異なる役割または目的を持っているために、異なる意見を持つ場合がある。論理階層３０を内蔵するために、リソース・プロファイル７７および従属関係７８の選択を含む、論理階層３０の意味をユーザ２３の要件に形成するための技術は、本発明の範囲を超えるものである。代わりに、記述は、表示リポジトリ７５が、ユーザ２３にとって有用な論理階層３０を含むように、すでに構成されていると仮定する。
【００６０】
論理階層３０は、多くの場合、ユーザ２３を考慮するために、監視下の環境２５のある１つの態様をモデル化する。それ故、監視下の環境２５のすべての態様をモデル化するには、複数の論理階層３０が必要になる場合がある。また、複数の論理階層３０を異なるユーザ２３に適するように供給することもできる。
【００６１】
木の基礎
論理階層３０は、木をベースとする構造に図９Ｂに示す要素を表示するために、図９Ａの従来技術によるデータ・モデルを利用する。各リソース・プロファイル７７は、１つのノード３９１に対応し、一方、その対応する従属関係７８が対応するリソース・プロファイル７７を接続する場合だけ、縁部３９６が２つのノード３９１を接続するように、各従属関係７８は１つの縁部３９６に対応する。根ノード３９２は、論理階層３０が表す意味の「先端」または「中央」のところで、１つのリソース・プロファイル７７と関連する。論理階層３０のレベルは、木３９内の層に対応する。
【００６２】
例えば、その木をベースとするデータ・モデルを使用することにより、論理階層３０は、隣接する層のエンティティの間に親子関係を持つように、情報を層内に組織することができる。親子関係は、従属関係７８をベースとしている。例えば、それぞれがデータ・センターに依存するビジネス・ユニットに依存する法人のように、親リソース・プロファイル７７は、子リソース・プロファイル７７に依存することができる。別の方法としては、親リソース・プロファイル７７は、複数のネットワークで接続しているサービスを供給するサーバのように、複数の子リソース・プロファイル７７に供給することができ、一方、ネットワークで接続している各サービス（例えば、ＤＮＳ、ファイル共有、およびネットワーク機密保護）は、複数のソフトウェア・アプリケーションにその機能を供給する。
【００６３】
有向木３９が経路一意性特性を持つことを図９Ａから思い起こされたい。経路の一意性は、モデル化した世界、すなわち、監視下の環境２５内には存在していなくてもよい。例えば、リソース・プロファイル７７Ａ、ＢおよびＣは、ＡがＢに関連し、ＢがＣに関連し、およびＣがＡに関連するように相互に関連することができる。この場合、ＡからＢへの経路は、直接の経路でもＣを通しての経路であってもよい。これは、有向木３９の経路の一意性の要件に違反する。この問題を処理するために、Ａのコピーとして新しいリソース・プロファイル７７Ａ’を導入し、次に、Ｃとのその直接的関係でＡの代わりにＡ’を使用することができる。Ａ’は、Ａと同じリソースを持っているが、特にＣに対するコンテキストを含むリソース・プロファイルである。ＡにＣを正式に結合した関係が、こんどはＡ’にＣを結合する。それ故、Ａ’を導入した後で、Ａ、Ｂ、ＣおよびＡ’上のすべての経路は一意のものになる。一般的に、グラフ内の任意のマルチプルを除去するために、このアプローチを適用することができる。
【００６４】
一般的に、所与のリソース２４は、それぞれがそれ自身のコンテキストを持つ、複数のリソース・プロファイル７７を通して、論理階層３０内の複数の位置内に表すことができる。さらに、リソース２４の状態は、複数のリソース・プロファイル７７間で異なる場合がある。何故なら、それぞれの状態は、リソース・プロファイル７７が表すコンテキストに依存するからである。例えば、あるルータがサービス・プロバイダの２人の顧客のためのトラヒックをサポートしていて、顧客Ａが顧客Ｂよりも高いサービスの品質（ＱＯＳ）で契約していると仮定しよう。ルータは、一方がＡに対する、他方がＢに対する、２つのリソース・プロファイル７７によりモデル化されるリソース２４である。ルータ上の混雑がある種のレベルに達すると、Ｂのもっと低い規格には適合している状態でＡのＱＯＳに適合できなくなる場合がある。それ故、顧客Ａのコンテキスト内のルータに対応するリソース・プロファイル７７は、他のコンテキスト（すなわち、Ｂのコンテキスト）内の同じリソース２４が問題のないレベルであっても、警告レベルになる場合がある。
【００６５】
従属プロファイルの階層
図９Ｂは、ルート・プロファイル（ｒｏｏｔ ｐｒｏｆｉｌｅ）３２と呼ばれる、リソース・プロファイル７７を含む論理階層３０である。説明を簡単にするために、この説明および図９Ｂは、３つのレベルを持つ例示としての階層を使用する。実際には、もっと多くのレベルを含むことができる。この例示としての階層は統合階層である。このことは、親がその子を統合する集合的なものであることを意味する。この３つのレベルのアプローチを使用する場合、根は「グループ・リスト」と呼ばれ、レベル１は、「グループ」を含み、レベル２は「要素」を含む。図９Ｂの場合には、ルート・プロファイル３２は、グループ・リストを表し、グループ・プロファイル３３は１つのグループを表し、要素プロファイル３４はレベル２上の１つの要素を表す。
【００６６】
論理階層の例示としてのソース
いくつかの分析技術が、監視下の環境２５のような環境をモデル化するために、木をベースとするデータ・モデルを形成することに留意されたい。論理階層３０は、その木をベースとするデータ・モデルにより上記技術をサポートする。いくつかの例は、トップダウン分析およびボトムアップ分析を含む。例えば、トップダウン分析は、所与のリソース・プロファイル３５の方向に状態の変化が、どのように伝搬するのかを調査することができ、一方、ボトムアップ分析は、局部的状態から広い範囲にどのようにして状態の変化がエスカレートするのかを調査することができる。監視下の環境２５に適用する特殊な分析技術、およびそのような技術の詳細は、本発明の範囲を超える。しかし、広い意味での例として、論理階層３０は、下記のように、１つのリソース２４の展望から、監視下の環境２５のトップダウン分析により作成されたモデル階層をサポートすることができる。所与のリソース２４は、対応するリソース・プロファイル７７をルート・プロファイル３２として指定する。ルート・プロファイル３２が依存する、１つまたはそれ以上のリソース・プロファイル７７を識別するためには、監視下の環境２５のトップダウン分析を使用されたい。これらのリソース・プロファイル７７を、二元従属関係７８によりルート・プロファイル３２に接続しているグループ・プロファイル３３として指定されたい。論理階層３０の木の連続しているレベルに位置させるために再帰的に反復されたい。
【００６７】
アラーム
監視システム８０は、アラーム３５をリソース・プロファイル７７と関連づける。より詳細に説明すると、図４Ａに点線の矢印で示すように、監視エージェント８２は、リソース２４に対するイベント２６を検出する。イベント２６は、リソース２４の１つまたはそれ以上の特性の状態の変化であってもよい。監視エージェント８２は、監視サーバ８１にイベント２６を通知する。監視サーバ８１は、リソース２４を表す１つまたはそれ以上のリソース・プロファイル７７を発見するために、表示リポジトリ７５（図４に図示せず；図８を参照されたい）をチェックする。リソース・プロファイル７７（図５Ａに示すように）は、監視サーバ８１にイベント２６を無視するように指示することができるイベント・フィルタ７７１を含む。そうでない場合、監視サーバ８１は、状態の値７７５を評価するために、リソース・プロファイル７７の測定基準７７６を呼び出すことができる。監視システム８０は、評価された状態の値７７５のいくつかの設定が、監視システム８０にリソース・プロファイル７７に対するアラーム３５を生成させるように構成されている。すなわち、状態の値７７５のいくつかの指定の設定は、アラーム３５を生成するのに十分な重大度レベルを持つ。監視システム８０は、イベント２６を評価したリソース・プロファイル７７に対応する状態ファイル７１に、各アラーム３５を書き込む。１つのイベント２６が、２つ以上のリソース・プロファイル７７上でアラーム３５を生成することができることに留意されたい。また、１つのイベント２６が、所与のリソース・プロファイル７７上で２つ以上のアラーム３５を生成することができる。例えば、第２のアラーム３５とは異なる方法で伝搬するように、第１のアラーム３５を指定することができる。
【００６８】
アラーム３５は、重大度レベル３５１、（重大度レベルを故障対警告のようなもっと広い分類にグループ分けする）等級３５２、テキスト記述３５３、および能動／非能動フラッグ３５４を含む。
【００６９】
表示
次の節においては、論理階層３０の視覚的表示装置の構成要素および技術について説明する。
【００７０】
表示ウィンドウ
表示ウィンドウ５０は、通常は、ＣＲＴモニタまたは平面パネル・ディスプレイのような視覚的表示装置６３９である、出力装置６３６（図１Ｂに示す）上でユーザ２３に表示される。図３Ｂは、表示ウィンドウ５０が、表示ウィンドウ５０の頂縁部に沿って配置されているタイトル・バー５１１、タイトル・バー５１１のすぐ下に配置されているメニュー・バー５１２、表示ウィンドウ５０の底縁部に沿って配置されているステータス・バー５１３、および表示ウィンドウ５０の残りの部分を占める表示パネル５１５を含む、当業者にとって周知のある種のＧＵＩオブジェクトおよび技術を含む様子を示す。
【００７１】
タイトル・バー５１１は、クライアント・アプリケーション２２を、オペレーティング・システム６３１（図１Ｂに示す）上で稼働している（おそらくいくつかの）アプリケーション間の表示ウィンドウ５０のオーナーとして識別するテキストを含む。タイトル・バー５１１は、オペレーティング・システム６３１に対して特有の他の機能を供給する。通常、上記機能は、表示ウィンドウ５０の位置を再度変え、再度サイズを決め、表示ウィンドウを閉じることを要求し、またはサイズを元に戻す機能を含む。
【００７２】
メニュー・バー５１２は、メニューバー５１２の上のドロップダウン・メニュー５１８上のドロップダウン項目５１９を選択するために、ユーザ２３がキーおよびマウスを操作するとそれに反応する。メニュー５１８のドロップダウン項目５１９は、ユーザ２３がメニュー５１８と会話を行うまで表示されない。通常、メニュー５１８およびドロップダウン項目５１９の中のあるものは、オペレーティング・システム６３１のＧＵＩ規格により命令を受ける。例えば、「ファイル」メニュー５１８（図６Ｂに示す）は、通常、アプリケーション・ファイルを開閉するための、およびクライアント・アプリケーション２２を中止するためのドロップダウン項目５１９を含む。
【００７３】
第２の種類のメニューであるコンテキスト・メニュー５１４も、ユーザ２３が表示パネル５１５上にマウスのポインタ５１を位置させ、入力装置６３２を通して右クリックするか、または他の何らかの指定の行動をするまで画面に表示されない。（例えば、マイクロソフト・ウィンドウズ（登録商標）の場合には、コンテキスト・メニュー５１４を表示するためにキーボード上に専用のキーが存在する場合がある。）この説明においては、「右クリック」は通常この行動を意味する。「右クリック」すると、マウス・ポインタ５１の位置の近くにコンテキスト・メニュー５１４が表示される。ドロップダウン・メニュー５１８と同様に、コンテキスト・メニュー５１４は、ユーザが選択するためのドリル・ダウン項目５１６のリストを含む。しかし、コンテキスト・メニュー５１４は、通常、アプリケーションの現在の状態およびマウス・ポインタの位置、それ故、用語「コンテキスト」に対して調整される。より詳細に説明すると、マウス・ポインタ５１が、リソース２４のレンダリングの上に位置している場合には、ドリル・ダウン項目５１６は、そのリソース２４またはリソース・プロファイル７７およびその現在の状態に調整することができる。
【００７４】
例えば、マイクロソフト・ウィンドウズ（登録商標）のようないくつかのオペレーティング・システム６３１においては、メニュー・バー５１２またはステータス・バー５１３または両方は、拡張することもできるし、カスタマイズすることもできるし、完全に隠すこともできる。タイトル・バー５１１、メニュー・バー５１２、ステータス・バー５１３、中央の表示パネル５１５、およびコンテキスト・メニュー５１４を使用するユーザ・インタフェースは、当業者であれば周知のものである。（メニュー・バー５１２のドロップダウン項目５１９、コンテキスト・メニュー５１４内のドリル・ダウン項目５１６の内容を含む、それを供給するその特定の内容および技術は、本発明の重要な部分であるが）このようなユーザ・インタフェース要素は、それ自身、本発明の重要な部分ではないので、ＧＵＩ技術については、これ以上詳細に説明しない。
【００７５】
フィッシュボーン
階層状態表示の１つの形は、１つの面内に論理階層３０を、様式化した木として表示するフィッシュボーン・レイアウト４５（図２Ａ）である。階層状態表示のもう１つの形は、以下に説明するようにスノーフレーク４６である。フィッシュボーン・レイアウト４５という名前がついたのは、魚の背骨を連想させるからである。フィッシュボーン・レイアウト４５は、ある場合には、製造品質制御の分野でのレイアウトである石川ダイアグラムといくつかの視覚的属性を共有する。しかし、フィッシュボーン・レイアウト４５は、動的に更新することができ、石川ダイアグラムといろいろ異なる点があるが会話型である。
【００７６】
フィッシュボーン・レイアウト４５は、論理階層３０内のルート・プロファイル３２と関連する、ルート・アイコン／ラベル（ｒｏｏｔ ｉｃｏｎ／ｌａｂｅｌ）４２１を持つ木を示す。フィッシュボーン・レイアウト４５は、また、フィッシュボーン・レイアウト４５のほぼ全長を走るルート・ライン（ｒｏｏｔ ｌｉｎｅ）４２２を特徴とする。通常、ルート・ライン４２２は、フィッシュボーン・レイアウト４５をほぼ半分に分割する。
【００７７】
通常、各リソース・プロファイル７７のレンダリングは、ラベルまたはアイコンまたは両方により固定されている（または以下に説明するように、レンダリング・エンジンが空間のために制限されている場合には、どれによっても固定されていない）ラインを含む。「アイコン／ラベル」という用語は、この可能なアイコンまたはラベルまたは両方を意味する。
【００７８】
ルート・リソース・プロファイル７７と直接従属関係７８にあるリソース・プロファイル７７は、１つのグループである。各グループは、グループ・アイコン／ラベル４２４をルート・ライン４２２に接続している、それ自身のライン４２３と一緒にその自身のアイコン／ラベル４２４を含む。グループ・ライン４２３（および一般的に任意の非ルート・リソース・プロファイル７７のライン）は、「背骨」と呼ばれる。一般的に、レベル「ｎ−１」のリソース・プロファイル７７に直接関連する、レベル「ｎ」のリソース・プロファイル７７の場合には、レベル「ｎ」のリソースは、アイコン／ラベルおよびアイコン／ラベルをレベル「ｎ−１」用のラインに接続しているラインとして表示し、ファン状に拡がる木を形成する。背骨は、従属関係７８に関してルート・プロファイル３２からのまたはこのルート・プロファイル３２に向かう方向性を示すために、一方の端部に矢尻を持つことができる。背骨上の方向は、通常、従属関係７８の「プロバイダ」の方向を示すが、凡例４２７はそれに違反している。
【００７９】
ルート・ライン４２２に直接接続している背骨は、ルート・ラインに対して通常は７０〜８０度の範囲内（しかし、必ずしもこの範囲に入らない）角度４３４だけ傾いている。ルート・ライン４２２のどちらかの側面へのこれらの背骨は、図２Ａに示すように、ルート・ライン４２２に対してほぼ同じ角度４３４を共有する。それ故、ルート・ライン４２２の所与の側面上のすべての傾斜している背骨は、ほぼ相互に平行である。
【００８０】
反復する類似性により、視覚的階層４０の以降のレベルがレンダリングされる。傾斜している背骨に直接接続している背骨は、ルート・ライン４２２に平行であり、ルート・ライン４２２に平行な背骨に直接接続している背骨は傾斜している等々。それ故、すべての背骨は、３つの分類に入り、各分類のメンバーはほぼ相互に平行である。１つの分類は（ルート・プロファイル７７から分かれる偶数の階層レベルであるリソース・プロファイル７７を表す）ルート・ライン４２２に平行な背骨用の分類である。この分類は、「偶数」グループと呼ばれる。何故なら、これらの背骨は論理階層３０の偶数レベル内のリソース・プロファイル７７に対応するからである。（これらの目的のために、ゼロ（ルート・レベルの数）は、偶数と見なされる。）第２の分類は、偶数グループに入らないで、表示パネル５１５内でルート・ライン４２２の上にレンダリングされる背骨を含む。この背骨は「上部」グループと呼ばれる。上部グループ内の背骨は、主ライン４２２に直接接続しているか（すなわち、レベル１に位置するか）、またはこのような背骨から分岐する偶数の階層レベルである（すなわち、奇数レベルに位置する）。第３の分類は、最初の２つのグループに入らない背骨を含み、上部グループからルート・ライン４２２の他方の側面上にレンダリングされる。これらの背骨は「下部」グループと呼ばれる。上部グループの場合のように、下部グループ内の背骨は、ルート・ライン４２２に直接接続しているか、またはこのような背骨から分岐する偶数の階層レベルである。
【００８１】
ルート・ライン４２２が垂直な場合には、他の背骨がルート・ライン４２２と同一線上に位置していないので、それより上には背骨は存在しない。この場合、上部グループは、ルート・ライン４２２の右手に偶数の背骨でなくてもよい。すでに説明したように、下部グループは、上部グループからルート・ライン４２２の他方の側面上で収集されなかった背骨を収集する。
【００８２】
ユーザ試験は、フィッシュボーン整合スキームが、論理階層３０を視覚的階層４０としてレンダリングする視覚的に「クリーン」な方法であることを示している。ユーザ２３は、一般的に、特に表示装置上に丁度３つのレベルが存在する場合には、論理階層３０内でリソース・プロファイル７７の大体のレベルを容易に知覚することができる。
【００８３】
モード
フィッシュボーン・レイアウト４５は、複数のモードで表示することができる。この実施形態の場合には、モードは、デフォールト・モード４２（図２Ａに示す）および稠密モード４３（図２Ｂに示す）を含む。稠密モード４３は、表示する要素の数が、表示パネル５１５の現在のサイズで効果的に処理するには、デフォールト・モード４２に対してあまりに高い状況を処理する。モード間の切り替え点は変化する。何故なら、切替え点は、表示装置内の要素の数、ノードの等級（子の数）、現在の表示パネル５１５のサイズおよび解像度、およびおそらく階層の身分の変化速度に依存するからである（何故なら、ユーザ２３は、ある周期より頻繁に表示装置が再配置されるのを望ましくないと見なすからである）。例えば、切替え点は、さらに、フォントおよびアイコン・サイズの選択および低いコントラストまたは低い解像度のような表示装置自身の特性を収容するための他の選択に依存する、各モードで達成することができる密度に依存する。広く一般化すると、１０２４×７６８ピクセルのウィンドウは、通常７００〜１０００フィッシュボーン構成要素の切替え点を生み出すことができる。
【００８４】
デフォールト・モード４２も稠密モード４３も、ほとんどのオブジェクトおよび行動を共有する。視覚的取り決め（レイアウト、表示行動、色づけスキーム等）は、各モードで異なっていてもよい。より詳細に説明すると、稠密モード４３は、通常、デフォールト・モード４２とは異なる方法で、要素リソース・プロファイル７７を表示する。デフォールト・モード４２（図２Ａに示す）は、通常、要素アイコン／ラベル４２６、要素ライン４２５、および要素分離４２９用の領域を使用する。要素分離４２９により、表示パネル５１５の背景を１つの要素レンダリングとそれに隣接するものとの間で見ることができる。しかし、稠密モード４３（図２Ｂに示す）は、１つの辺がグループ・ライン４２３と接触していて、おそらく他の辺も隣接する稠密平行四辺形４３０に接触している、稠密平行四辺形４３０を含む要素リソース・プロファイル７７を表す。隣接する稠密平行四辺形４３０は、交互ルミネセンスのような種々の図形的技術により互に視覚的に識別することができるが、密度が増大し（平行四辺形４３０が必要な程度に小さくなる）、小さなエリア、特に、大部分の視覚的表示装置６３９の解像度が低い場合には、コントラスト（色、ルミネセンス、肌理等）間を人間の目で識別するのが困難になる。マウスオーバ技術（以下に説明する）を使用すれば、ユーザ２３は、パックされた平行四辺形４３０をしっかりと区別することができる。
【００８５】
フィッシュボーン・レイアウト４５の背骨は、少なくとも２つの層（すなわち、ルート・ライン４２２およびグループ・ライン４２３）の深さ、および通常は３つの層の深さに層状に重なっている。この技術には固有の上限はない。しかし、実際には、サイズおよび解像度が有限であるために、所与の視覚的表示装置６３９には限界がある。また、通常のユーザが視覚的に容易に入手できる情報の量が限定される場合がある。予備的ユーザ試験により、大部分のユーザは、１０２４×７６８ピクセルの視覚的表示装置６３９による、３つの層の階層が表示する情報に満足していることが分かっている。
【００８６】
フィッシュボーン・レイアウト４５は、また、凡例エントリ４３５を持つ凡例４２７を特徴とする。凡例エントリ４３５は、グラフィック４３６および凡例説明４３７を含む。凡例グラフィック４３６は、フィッシュボーン・レイアウト４５内で使用される図形的取り決めを例示するグラフィックである。凡例説明４３７は、図形についての取り決めの意図する意味を説明するテキストを含む。
【００８７】
フィッシュボーンの視覚的取り決め
この節では、フィッシュボーン・レイアウト４５の視覚的外観に影響を与える取り決めの中のいくつかについて説明する。レイアウトまたは相互作用に関する取り決めを含む他の取り決めについては他の場所で説明する。
【００８８】
表示パネル５１５は、レンダリングに優れた視覚的コントラストとプロミネンスを与える、その上にレンダリングが発光している黒い背景を持つ。通常、デフォールトの場合、レンダリングは、その最大のルミネセンスで表示されない。そのため、必要な場合、特に強調するためにルミネセンスを増大することができる。
【００８９】
背骨上の矢尻は、従属関係７８の方向を示す。
【００９０】
レイアウトの密度により可能な場合には、位相的接続（接触または重ね合わせるレンダリング）は、フィッシュボーン内で意味を持つ。デフォールトの場合、レンダリングは、その間に背景が現れるように、分離４２９により表示パネル５１５内で相互に十分な間隔を持っている。レンダリングが表す構成要素間に直接的な従属関係７８がある場合には、唯一の例外が（このデフォールト設定は強制的なものであるが）発生する。それ故、接続は従属関係７８を示す。この視覚的取り決めは、デフォールト・モード４２内のデフォールトである。
【００９１】
表示装置６３９は、カラーを表示することができる。フィッシュボーン・レイアウト４５は、その表示中にカラーを使用するが、個々に、また相互を比較する際に、赤緑盲のユーザ２３が視認できるように色づけされている。色づけは、またモノクロ表示装置６３９と一緒に使用できるようにもなっている。
【００９２】
フィッシュボーン・レイアウト技術
この節においては、表示パネル５１５内でのフィッシュボーンの構成要素の配置を制御する技術について説明する。
【００９３】
デフォールトの場合、ルート・アイコン／ラベル３２１は、表示パネル５１５の右の境界の中央付近に位置するが、表示パネル５１５の任意の位置に表示することもできる。表示パネル５１５内にレンダリングする他の項目がない場合には、表示パネルの境界近くに位置するルート・アイコン／ラベル４２１は、フィッシュボーンの残りの部分のために使用することができる空間を最大にする。
【００９４】
ルート・ライン４２２は、デフォールトの場合は水平であるが、任意の角度４３４にすることができる。例えば、スノーフレーク・レイアウト４６のところで説明するが、３つ以上のフィッシュボーン・レイアウト４５は、１つのルート・プロファイル３２を共有することができる。この場合、レンダリングする第１の２つのフィッシュボーン・レイアウト４５は、水平ルート・ライン４２２を持つことができるが、以降のフィッシュボーン・レイアウト４５は、水平でないルート・ライン４２２を持つことができる。背骨の勾配は、通常、ルート・ライン４２２に対して７０〜８０度の範囲の角度である。ルート・ライン４２２のどちらかの側面への背骨は、図２Ａおよび図２Ｂに示すように、ルート・ライン４２２に対して同じ角度４３４を共有する。
【００９５】
背骨が直線であり、類似の背骨に対してほぼ相互に平行であるという原則は、背骨の分岐に対して特殊な例外を持つ。背骨は、有限の表示領域の制限を超えるために「分岐」または「包み込み」することができる。例えば、親の背骨が、表示パネル５１５内の同じ直線方向に継続することができないほど多くの、所与の親に接続する子リソース・プロファイル７７が存在する場合がある。それ故、背骨（図２Ａの分岐グループ・ライン４２８のような）は、背骨を位相的に接続状態に維持する必要がある追加のサブセグメント（分岐コネクタ４４５）を除いて、相互にほぼ平行な複数のサブセグメント４４６に分岐することができる。複数の平行なサブセグメント４４６は、背骨が１つのセグメントが使用するより小さな空間を、所与の直線方向に沿って使用することができるような方向を向くことができる。それ故、分岐することにより、ビューア６４（図８に示す、以下に説明する）は、表示のための有限の境界へのファン状に拡がるフィッシュボーン・レイアウト４５に適応することができる。
【００９６】
背骨を包み込むためのアルゴリズムの目的は、使用する分岐の数を最も少なくすることである。ビューア６４は、包み込みの必要性をすでに検出済みであると仮定する。「長さ優先」アプローチの場合には、分岐コネクタ４４５用の余裕があるが、追加のサブセグメント４４６の充填をスタートする前に、最も遠い許容できる長さに第１のサブセグメント４４６を充填する（すなわち、それらをサブセグメント４４６に接続している分岐の部分木からリソース・プロファイル７７をレンダリングする）。
【００９７】
デフォールトの場合には、階層の層内の構成要素は、最も近いルート・アイコン／ラベル４２１からスタートして先に移動するという方法で、名前によりアルファベット順にレイアウトされる。（他の静的スキームも使用することができ、論理階層３０とペアになっている図８の表示記録７５２のレイアウト優先順位７５４で指定することができる。例えば、類似のレベル１の背骨をレイアウトするフィッシュボーン・レイアウト４５に対して表示パネル５１５の領域を指定することができる。ある領域はサーバ用のものであり、他の領域はルータ用のものであり、第３の領域はサービス用のものであり、第４の領域はアプリケーション用のものである。）各フィッシュボーン・レイアウト４５に対するレイアウトを標準化することにより、ユーザ２３は、そのフィッシュボーン・レイアウト４５に精通することができ、その構成要素に対する位置的メモリを形成することができる。このように精通することができれば、ユーザ２３への情報の通信をスピードアップすることができる。例えば、精通することができれば、ユーザ２３は、リソース・プロファイル７７内に記憶しているアイデンティティまたはコンテキストを知るために、構成要素をチェックする必要がなくなり、ユーザ２３は構成要素のレンダリングの変化をもっと迅速に解釈することができる。フィッシュボーン４５を動的に分類することができる（例えば、各リソース・プロファイル７７の現在の状態の値７７５の重大度レベルにより分類して）が、この実施形態の場合には、デフォールト・スキームは、非動的特性に基づいて分類するためのものである。
【００９８】
表示パネル５１５は有限であるので、モードが何であれ、各要素をレンダリングする空間が常にあるわけではない。この場合には、空間がなくなったら、図２Ａに示すように、楕円または他の先端を切除した記号４３３が表示される。
【００９９】
デフォールトの場合には、重大度レベルのための色づけスキームが、グローバル色づけスキームまたは特定の用途用に設計されたスキームを持つことができる、監視エンジン８０（または論理階層３０を設計している際には、適当であると選択されたもの）から検索される。色づけスキームが一致すると、多くの場合そうであるように、特に監視エンジン８０を使用しているユーザ２３に対して、監視エンジン８０と状態表示との統合がもっと継ぎ目のない状態になる。
【０１００】
通常、重大度用の色づけスキームは、所与の重大度をカラーに関連づけるマッピングを含む。所与の重大度は、重大度のスケール上にランキングを含む。重大度スケールは、重大度を比較することができる重大度の全順位を示す。スケールに適している任意の２つの重大度の場合には、その重大度ランキングは、第１のランキングが、第２のランキングより低いのか、同じなのか、高いのかを示す。「重大度ランキング」と明示するための速記法は、ある重大度がもう１つの重大度よりランキングが低いか、同じか、高いかを単に表示する方法である。重大度に対する色づけスキームのカラーは、通常、不明瞭になるのを極力防止する目的で、相互にハッキリ見分けられるように選択される。また、高い重大度を示すために選択したカラーは、多くの場合、低いレベルの重大度を示すカラーよりも（もっと強烈な飽和度を持つように、またはもっと明るいルミネセンスで表示されるように）もっと目立つようになっている。基本的なカラー・スキームの通常の例は、デフォールトまたは問題がない場合にはグリーン、警戒を要する重大度の場合には黄色、および、故障または緊急な重大度の場合には赤を使用し、重大度データがない場合またはオフラインの場合にはグレイを使用する方法である。
【０１０１】
（アイコン／ラベル内の）アイコンは、サイズ、カラー、ルミネセンス、形状、またはブリンキングまたはチラツキのような動きにより変化をつけることができる。ブリンキングは、通常、非ブリンキング・レンダリングに戻る前の短い時間の間にだけ使用される。例えば、ブリンキングは、状態の最近の変化を示し、ブリンキングの後でいったんブリンキングを停止するのは、変化が最近のものでないことを示す。
【０１０２】
フィッシュボーンとの会話
この節においては、ユーザの行動にフィッシュボーン・レイアウト４５が応答することができる方法について説明する。
【０１０３】
グループ・ライン４２３または要素ライン４２５上で左クリックすると、それが選択される。選択された場合には、背骨を強調することにより視覚的に表示される。グループ・アイコン／ラベルを選択すると、そのグループに対する全部分木が強調される。ルート・アイコン／ラベルを選択すると、全階層木が強調される。
【０１０４】
マウスオーバ・イベントは、ユーザ２３がマウス・ポインタ５１（図３Ｂに示す）をパスオーバした場合に、リソース・プロファイル７７のレンダリングに対して発生する。ある要素ライン４２５または要素アイコン／ラベル４２６のマウスオーバ中、表示プロセスは、ある意味では、アイコン／ラベル４２６をより容易にクリック・オンすることができるように、要素アイコン／ラベル４２６内のラベルのフォントおよびアイコンのサイズを拡大する。表示プロセスは、また、特にフィッシュボーン・レイアウト４５が稠密モード４３である場合に、要素ライン４２５を拡大することができる。何故なら、稠密モード４３は、場合により、空間をセーブするために要素アイコン／ラベル４２６を省略することがあるからである。潜在的クリックの目標を拡大すると、ユーザ２３がクリックした場合、マウスが選択するものが見易くなる。ユーザ２３がクリックするつもりがなくても、拡大すると、ユーザ２３は、目標を識別するカラーおよび他の特徴を見やすくなる。
【０１０５】
リソース・プロファイル７７の任意のレンダリングのマウスオーバを持続すると、マウスオーバ・ダイアログ５１７が開く。短い所定の時間間隔（通常は、例えば、１ミリ秒に対して１秒程度）よりも長い間マウスオーバが持続した場合には、マウスオーバが「保持」されるという。マウスオーバ・ダイアログ５１７は、リソース名、その状態およびそれに影響を与えるイベントについての統合情報を含む、リソース・プロファイル７７に関するテキスト情報を含む。例えば、マウスオーバ・ダイアログ５１７は、下記のものを引用することができる。
【０１０６】
ルータ１３
混雑状態
最後の３０分間の１１の警告
【０１０７】
図２Ａについて説明すると、凡例４２７内においては、凡例エントリ４３５内の凡例グラフィック４３６は、フィッシュボーン・レイアウト４５で使用する図形的取り決めの例を示す。凡例エントリ４３５の１つの使用方法は、重大度レベルを表す色づけまたは他の図形による取り決めの説明である。このような凡例エントリ４３５内で凡例グラフィック４３６を持続的に左クリックすると、その状態の値７７５が重大度レベルに対応するリソース・プロファイル７７の背骨を除いて、すべての背骨のレンダリングが暗くなる。このように暗くなることにより、対応するリソース・プロファイルのレンダリングを強調する。
【０１０８】
フィッシュボーン・レイアウト４５内のリソース・プロファイル７７のレンダリング上で右クリックすると、リソース・プロファイル７７のドリル・ダウン・リスト７７８が指定する、ドリル・ダウン項目５１６を含む図３Ｂのコンテキスト・メニュー５１４が表示される。ドリル・ダウン項目５１６は、リソース・プロファイル７７に特有の分析ツール・ソフトウェア９０（図１Ａに示す）内の報告を開く。ドリル・ダウン項目５１６は、また別の表示ウィンドウ５０でフィッシュボーン・レイアウト４５を開くため、または選択したリソース・プロファイル７７を根として使用するために、現在のフィッシュボーン・レイアウト４５の再度中央への表示のようなナビゲーション・オプションを含むこともできる。もう１つのナビゲーション・オプションは、選択したリソース・プロファイル７７の子供を見ることである。特に、視覚的階層４０の最も低い表示レベルのところの要素に対して、フィッシュボーン・レイアウト４５に現在表示されていない論理階層３０の追加レベルであってもよい。子供は、他の表示ウィンドウ５０でも見ることができるし、または（図３Ｂ内に示す所与のドリル・ダウン項目５１６に特有のコンテキスト・メニュー５１４のサブメニューを開く）階層メニュー５２０を通して見ることもできる。階層メニュー５２０は、もう１つの階層メニュー５２０を表示するドリル・ダウン項目５１６を含むことができる。
【０１０９】
フィッシュボーン・レイアウト４５は、以下にさらに詳細に説明するように、呼び出した再描画イベントを表示することができる。呼び出された再描画イベントは、レンダリング・エンジンに表示パネルを再描画させる。呼び出された再描画イベントは、表示ウィンドウ５０のサイズを変えた後、またはクライアント・アプリケーション２２が論理階層３０を、視覚的階層４０の変化を必要とする再定義をしなければならないことを検出した場合に、クライアント・アプリケーション２２の初期化中に発生する。再描画されたフィッシュボーン・レイアウト４５が、現在の表示パネル５１５内に入らない場合には、ユーザ２３に、先端切除に関する警告ダイアログが表示される。
【０１１０】
２つ以上の表示ウィンドウ５０が開いた場合には、一番前の表示ウィンドウ５０が、「現在の表示ウィンドウ」と呼ばれる。
【０１１１】
メニュー・バー
メニュー・バー５１２コマンドは、図６Ｂに示すように、下記のドロップダウン・メニュー５１８およびドロップ・ダウン項目５１９を含む。
【０１１２】
メニュー・バー５１２は、「ファイル」、「表示」、「実行」および「ヘルプ」というラベルがついているドロップダウン・メニュー５１８を含む。
【０１１３】
「ファイル」ドロップダウン・メニュー５１８は、「新規」、「開く」、「削除」、「サーバへ接続」、「新規ウィンドウ」、「最新リスト」および「エクシット」のためのドロップダウン項目５１９を含む。「新規」を使用することにより、ユーザ２３は、新しい表示ウィンドウ５０内に開くために、論理階層３０を選択することができ、一方「開く」を使用することにより、同じ選択を行うことができるが、この場合使用するのは現在の表示ウィンドウ５０である。「削除」を使用することにより、ユーザは、このような表示ウィンドウ５０を閉じることができる。「サーバに接続」は、ログイン・ダイアログ（図示せず）を開くので、ユーザ２３は、ウェブ・サーバ６０に信用証明書を提示することができる。「新しいウィンドウ」は、現在の表示ウィンドウ５０の冗長バージョンを開く。「最近のリスト」は、各ドロップダウン項目５１９が最近使用した論理階層３０に対応するいくつかのドロップダウン項目５１９の柔軟なリストである。メニュー・セパレータ５２１は、「最近のリスト」を括弧内に入れることができる。「エクシット」は、クライアント・アプリケーション２２を閉じるプロセスをスタートする。
【０１１４】
「表示」ドロップダウン・メニュー５１８は、現在の表示ウィンドウ５０を変えるためのドロップダウン項目５１９を含む表示に影響を与えるドロップダウン項目５１９を表示する。
【０１１５】
「実行」ドロップダウン・メニュー５１８は、分析ソフトウェア９０に関連するドロップダウン項目５１９を表示する。ドロップダウン項目５１９は、現在選択しているリソース・プロファイル７７のスノーフレーク・ダイアグラム４６を開く１つの項目を含む。ドロップダウン項目５１９は、また、性能報告、故障管理報告（現在選択しているリソース・プロファイル７７のすべてのアラームのリストなど）、リソース・プロファイル７７に関連するリソース２４の構成に関する報告、およびピング（ｐｉｎｇ）、テルネット（ｔｅｌｎｅｔ）またはリソース２４のための管理システムのような（しかし、これらに限定されない）外部分析ツール９０を含む。さらに、ユーザ２３は、分析ツール９０のリストを拡張することができる。ドロップダウン項目５１９は、分析ツール９０とのその会話中、リソース・プロファイル７７およびリソース２４に関する情報を送ることができる。このような情報の例としては、リソース・プロファイル７７の名前、そのネットワーク・アドレス等がある。
【０１１６】
「ヘルプ」ドロップダウン・メニュー５１８は、ウィンドウズ（登録商標）またはユニックス（ＵＮＩＸ（登録商標））のような、その上でクライアント・アプリケーション２２が稼働している、オペレーティング・システム６３１のためのインタフェース規格に適合する。例えば、マイクロソフト・ウィンドウズ（登録商標）の場合には、「ヘルプ」ドロップダウン・メニュー５１８は、「の中に（ｉｎｔｒｏ）」、「使用する（ｕｓｉｎｇ）」、および「に関する（ａｂｏｕｔ）」のための項目を含む。
【０１１７】
スノーフレーク
図３Ａについて説明すると、スノーフレーク４６は、視覚的階層４０のための他の表示形式である。スノーフレーク４６は、複数の同時論理階層３０の先端に、（ルート・プロファイル３２を表す）ルート・アイコン／ラベル４４２を表示する。フィッシュボーン・レイアウト４５として表示されているこの各論理階層３０は、ルート・アイコン／ラベル４４２を共有する。各フィッシュボーン・レイアウト４５は、関連する表示記録７５２内に表示されたそれ自身のレンダリング取り決めを有することができる。例えば、図３Ａに示すように、第１のフィッシュボーン・レイアウト４５ａは、デフォールト・モード４２でレンダリングされ、一方、第２のフィッシュボーン・レイアウト４５ｂは、稠密モード４３でレンダリングされる。
【０１１８】
スノーフレーク・レイアウト４６は、コンシューマおよびプロバイダの従属関係７８の両方を同時に表示することができる。より詳細に説明すると、スノーフレーク・レイアウト４６は、それが消費し、供給するリソース・プロファイル７７の両方で、ルート・プロファイル３２を表示することができる。図３Ａの例の場合には、スノーフレーク・レイアウト４６は、ルート・アイコン／ラベル４４２の左に位置する左のフィッシュボーン・レイアウト４５ａと、右に位置する右のフィッシュボーン・レイアウト４５ｂを含む。左のフィッシュボーン・レイアウト４５ａは、ルート・プロファイル３２が消費するリソース・プロファイル７７を表示する。右のフィッシュボーン・レイアウト４５ｂは、ルート・プロファイル３２を消費するリソース・プロファイル７７を表示する。この場合、フィッシュボーン・レイアウト４５ａには「原因」のラベルを、フィッシュボーン・レイアウト４５ｂには「結果」のラベルをつけることができる。ルート・プロファイル３２が、「原因」フィッシュボーン・レイアウト４５ａ内の任意のリソース・プロファイル７７と、「結果」フィッシュボーン・レイアウト４５ｂ内のリソース・プロファイル７７との間の間接従属関係７８用の重要な経路上に位置している状態で、この構成内のスノーフレーク４６は、図形の形で、リソース・プロファイル７７間の従属関係７８の２つの木を表示する。ユーザ２３は、スノーフレーク・レイアウト４６を見ることにより、また原因のフィッシュボーン・レイアウト４５ａをチェックすることにより、問題の原因と思われるものを迅速に識別することができる。ユーザ２３は、また、例えば、フィッシュボーン・レイアウト４５ｂをチェックすることにより、問題の潜在的な影響を識別することができる。それ故、ユーザ２３は最も重要な問題を最初に解決することができる。
【０１１９】
図３Ａには示していないが、スノーフレーク・レイアウト４６は、おそらく、水平でないルート・ライン４２２と一緒に、第３およびそれ以降のフィッシュボーン・レイアウト４５を含むことができる。
【０１２０】
クライアント・アプリケーション
この節においては、クライアント・アプリケーション２２のソフトウェア・コードについて説明する。一般的に、クライアント・アプリケーションは、ユーザへの視覚的階層４０を含むＧＵＩの提示；ユーザの行動に対する応答；状態情報および論理階層３０にアクセスするためのウェブ・サーバ６０との通信；および論理階層３０内のリソース・プロファイル７７用のドリル・ダウン・リスト７７８を動作可能にするための分析ツールとの通信という主要な特徴をカバーする。
【０１２１】
クライアント・アプリケーション２２（図７Ａに示す）は、Ｊａｖａ（登録商標）ソフトウェア・アプリケーションである。クライアント・アプリケーション２２の内部アーキテクチャは、Ｊａｖａ（登録商標）アプリケーション用に勧告されたオブジェクト指向設計技術を使用する。これらの技術の中の１つは、モデル−デリゲイト・アーキテクチャと呼ばれる。モデル−デリゲイト・アーキテクチャ（Ｍｏｄｅｌ−Ｄｅｌｅｇａｔｅ ａｒｃｈｉｔｅｃｔｕｒｅ）は、ユーザ相互作用用のコードを、レンダリングされるデータ構造をモデル化するためのモデル構成要素およびユーザ・インタフェースをレンダリングし、ユーザ行動を受信し、またモデル−デリゲイト・アーキテクチャの周囲のプログラムの流れおよび実行を制御するためのデリゲイト構成要素に機能的に分離することを勧告している。以下に説明するように、ビューア・モデル・クラス６９（図７Ｂに示す）は、モデル構成要素としての働きをし、一方ビューア・クラス６４は、デリゲイト構成要素としての働きをする。
【０１２２】
ＡＰＰクラス
図７Ｂに示すＡｐｐクラス６１は、クライアント・アプリケーション内のトップ・レベルのクラスである。Ａｐｐクラス６１は、クライアント・アプリケーション２２がスタートした場合に実行する最初のクラスである。最初に、スタート後に、Ａｐｐクラス６１は、データ・マネージャ６５、同期マネージャ６６および主ＵＩクラス６７を含む他のクラスのいくつかの例をスタートする。
【０１２３】
データ・マネージャ
データ・マネージャ６５は、オブジェクト内で多重化されるだろう情報を抽出するために、ウェブ・サーバ６０と通信するために使用されるオブジェクトを構文解析する。すなわち、オブジェクトは、クライアント・アプリケーション２２内の種々の宛先向けの複数の情報を含むことができる。データ・マネージャ６５の主な機能は、送られてきた場合に、同期ブラウザ・マネージャ６８（図７Ｂに示す）にアラーム３５を通知することである。
【０１２４】
同期マネージャ
図８について説明すると、同期マネージャ６６は、現在のすべての表示論理階層３０用のハッシュ・テーブル６６１内に局部的にデータをキャッシュする。キャッシュされたデータは、論理階層３０自身と表示記録７５２からの他の情報を含む。同期マネージャ６６は、キャッシュ内のデータが確実にそのままでいるようにするために、すなわち、状態リポジトリ７０および表示リポジトリ７５に常駐するデータの正式なバージョンと同期状態に維持するために、ウェブ・サーバ６０と通信する。
【０１２５】
ハッシュ・テーブル６６１は、表示リポジトリ７５内のリソース・プロファイル７７を識別するデータベースＩＤ６６２；名前６６３；それぞれが指定のリソース・プロファイル７７と直接従属関係７８にあるリソース・プロファイル７７を表す子と親のリスト６６４を含む各リソース・プロファイル７７に対する特性を記憶することができる。ローカル・キャッシュを維持することにより、同期マネージャ６６は、クライアント・アプリケーション２２内の集中場所からデータの参照を迅速に行う。例えば、同期マネージャ６６は、データベースＩＤ６６２に関連する名前６６３を入手するための迅速な方法を供給する。例えば、要素アイコン／ラベル４２６（例えば、図２Ａに示す）上のマウスオーバ中に、名前６６３が必要になる。マウスオーバは、要素のリソース・プロファイル７７の名前を含む、マウスオーバ・ダイアログ５１７（例えば、図３Ｂに示す）を表示するのに必要になる。リソース・プロファイル７７を表示したレンダリング・オブジェクト６９１（以下に説明する）は、レンダリング・データベースＩＤ６９２だけを有する。（名前６６３は、レンダリング・オブジェクト６９１内に直接記憶されない。何故なら、名前６６３は、変化することができるからである。ハッシュ・テーブル６６１だけが、名前６６３に対する局部的の正式な値を持つ）。また、名前６６３は、かなり迅速に必要になるので、ユーザ２３は、クライアント・アプリケーション２２が応答しないとは感じない。キャッシュは、名前６３３を発見する迅速な方法であり、キャッシュを使用すれば、ネットワークを通してのウェブ・サーバ６０への問い合わせは必要なくなる。
【０１２６】
同期マネージャ６６は、また、子および親のリスト６６４を通して、リソースの子または親の迅速な参照を提供する。
【０１２７】
同期マネージャ６６は、クライアント・アプリケーション２２内のバラバラの単独固体のクラスであり、このことは、クライアント・アプリケーション２２の１つにつき１つの同期マネージャ６６しか存在しないことを意味する。それ故、同期マネージャ２２は、クライアント・アプリケーション２２内でハッキリした存在である。
【０１２８】
論理階層３０が開いている場合には、同期マネージャ６６は、すべての構成データを収集する。同期マネージャ６６は、その内部においてリソース・プロファイル７７を名前によりアルファベット順に配列することにより、必要に応じてプロファイルがレンダリングされるデフォールトの順序配置を行う（フィッシュボーン・レイアウト技術の節参照）。
【０１２９】
論理階層３０の最初の構成が完了した後で、同期マネージャ６６は、維持ループに進み、論理階層３０に構成を変える目的で、ウェブ・サーバ６０を周期的にポーリングするために、構成ポーリング６６８（図８に示す）を使用する。構成の変化は増分により検索される。構成ポーリング６６８は、各サイクル中、全論理階層３０および関連する構成情報を検索する必要はない。その代わりに、同期マネージャ６６は、初期化中に完全な情報を検索し、その後で、最後のポーリングの後で変化した情報を検索するために構成ポーリング６６８を使用する。構成ポーリング６６８の周期は、通常５分であるが、ユーザ２３は周期を調整することができる。
【０１３０】
接続ポーリング６６９は、構成ポーリング６６８から独立しているポーリングである。接続ポーリング６６９は、接続が依然として行われていることを確認するために、ウェブ・サーバ６０とのネットワーク通信をチェックする。接続ポーリング６６９は、頻繁に発生するが、毎分デフォールトである。
【０１３１】
ウェブ・サーバ６０は、構成ポーリング６６８に応じてある変更を行い、同期マネージャは、上記変更を記述するウェブ・サーバ６０からオブジェクトを要求する。
【０１３２】
主ＵＩ
主ＵＩクラス６７は、スタート時に、クライアント・アプリケーション２２が表示する第１の会話型ウィンドウである表示ウィンドウ５０を表示する。ユーザ２３が、表示のために論理階層３０を開く「新規」または「開く」のようなドロップ・ダウン項目５１９（図６Ｂに示す）を選択すると、主ＵＩクラス６７の一例は表示を管理する。図７Ｂに示すように、主ＵＩクラス６７は同期ブラウザ・マネージャ６８、ビューア・モデル６９、およびビューア６４を含むオブジェクトをスタートする。
【０１３３】
同期ブラウザ・マネージャ
図７Ｂに示すように、同期ブラウザ・マネージャ６８は、データ・マネージャ６５からアラーム３５の通知を受信し、イベント・キャッシュ６８２内にアラームを維持する。同期ブラウザ・マネージャ６８の各例が、所与の論理階層３０に関連する主ＵＩクラス６７の一例と関連していることを思い出して欲しい。それ故、同期ブラウザ・マネージャ６８の各例は、他の論理階層３０に対するアラーム３５からのその関連する論理階層３０に対するアラーム３５を識別することができるフィルタ・サーバ６８１をスタートする。
【０１３４】
同期ブラウザ・マネージャ６８が、フィルタ・サーバ６８１を通して送られた、データ・マネージャ６５からアラーム通知を入手した場合には、同期ブラウザ・マネージャ６８は、イベント・キャッシュ６８２内のアラーム３５をＪａｖａ（登録商標）ベクトル・オブジェクト内に入れ、ベクトル・オブジェクトをビューア・モデル６９に送る。
【０１３５】
ビューア・モデル
ビューア・モデル６９は、モデル−デリゲイト・アーキテクチャ・スキーム内のモデル構成要素である。その制御容量において、ビューア・モデル６９は、表示ウィンドウ５０と会話しているユーザ２３が発生したイベントを処理するロジックを含む。より詳細に説明すると、上記イベントはビューア６４で検出されるが、処理のためにビューア・モデル６９に送られる。そのモデル容量において、ビューア・モデル６９は、ビューア６４により表示されるリソース・プロファイル７７を表すレンダリング・オブジェクト６９１（図８に示す）を含む。それ故、レンダリング・オブジェクト６９１の目的は、参照したリソース・プロファイル７７とは別個に、レンダリングについての情報を含むことである。例えば、リソース・プロファイル７７用のレンダリング・オブジェクト６９１は、その参照したリソース・プロファイル７７を指定するレンダリング・データベースＩＤ６９２；警告レベル６９３；位置情報６９４；およびレンダリングを指定するのに必要な他の属性のような情報を含む。
【０１３６】
レンダリング・オブジェクト６９１は、再描画準備ＯＫ方法６９６またはレンダリング・オブジェクト６９１が再描画される準備ができていることを、ビューア６４に通知する他の手段を含む。
【０１３７】
ビューア・モデル６９は、同期ブラウザ・マネージャ６８から、Ｊａｖａ（登録商標）ベクトル・オブジェクト内にパッケージされているアラーム３５のバッチを受信する。ビューア・モデル６９は、各アラーム３５をチェックするためにベクトル上で反復する。ビューア・モデル６９は、同期マネージャ６６内のハッシュ・テーブル６６１により、アラーム３５と関連するリソース・プロファイル７７の位置を発見する。ビューア・モデル６９は、リソース・プロファイル７７のアラーム・リスト７７３、（またＪａｖａ（登録商標）のベクトル・オブジェクト）にアラーム３５を追加する。すべてのアラーム３５を処理した後で、ビューア・モデル６９は、状態の値７７５を再計算するために、リソース・プロファイル７７の測定基準７７６を使用する。状態の値７７５が分かっている場合には、ビューア・モデル６９は、関連するレンダリング・オブジェクト６９１が、リソース・プロファイル７７と関連させなければならない重大度レベル６９３を設定することができる。このような各レンダリング・オブジェクト６９１は、レンダリング・オブジェクト６９１が再描画される準備ができていることをビューア６４に通知するために、その再描画準備ＯＫ方法６９６を使用する。ビューア・モデル６９は、また、アラーム３５を受信したプロファイル７７に対する親のような関連するリソース・プロファイル７７を発見するために、同期マネージャ６６のキャッシュをチェックする。ビューア・モデル６９は、これらの関連するリソース・プロファイル７７にアラーム３５を通知する。そうすることにより、関連するリソース・プロファイル７７は、それ自身の状態の値７７５を更新することができる。
【０１３８】
ビューア・モデル６９は、ドリル・ダウンおよびマウスオーバを含むレンダリングとのユーザの会話により発生したイベントを処理する。ビューア・モデル６９は、また、アプリケーション・オーバーライドを処理する。ドリル・ダウンおよびマウスオーバについてはすでに説明した。図８に示すアプリケーション全体にわたるアラーム・オーバーライド６９７により、クライアント・アプリケーション２２は、リソース・プロファイル７７の伝搬規則７７２（図５Ａに示す）にオーバーライドしているあるタイプのアラーム３５を抑制することができる。より詳細に説明すると、この実施形態の場合には、ルータのＣＰＵはレンダリングされない。何故なら、ルータ自身だけがレンダリングされるからである。この特徴は、簡単にするために、ユーザ２３に提示される情報の量を低減するために追加される。またそうすることにより、他のオブジェクトのレンダリングするための空間が増大する。ＣＰＵはレンダリングされないので、ビューア・モデル６９は、ルータＣＰＵアラーム３５をルータ自身上で統合する。ルータのリソース・プロファイル７７（図５Ａに示す）のドリル・ダウン・リスト７７８内のオプションにより、依然としてユーザは各ルータＣＰＵに関する詳細を入手することができる。
【０１３９】
もう１つのオーバーライド６９７が、モデムを含むＲＡＳ（遠隔アクセス・サービス）グループに対して発生する。この場合、レンダリングは抑制されない。モデムおよびＲＡＳグループの両方が表示される。しかし、ＲＡＳグループ内のモデムに対してアラーム３５が発生した場合には、ビューア・モデル６９は、関連するリソース・プロファイル７７上の設定が何であれ、自動的に、アラーム３５をモデムおよびＲＡＳグループの両方に関連づける。
【０１４０】
ビューア・モデル６９は、論理階層３０の構造に対する変化の通知を受信する。この受信により、ビューア・モデル６９は、リソース・プロファイル７７へのレンダリング・オブジェクト６９１の関連が依然として正確なものであることを確認させ、この変化により追加された任意の新しいリソース・プロファイル７７に対する、新しいレンダリング・オブジェクト６９１を生成させる。ビューア・モデル６９は、また、任意のリソース・プロファイル７７が、論理階層３０に追加されたか、そこから削除された場合には、ビューア６４に表示パネル５１５を再描画するように指示する。
【０１４１】
ビューア
ビューア６４は、モデル−デリゲイト・アーキテクチャ・スキームのデリゲイト構成要素である。ビューア６４は、ユーザ２３にＧＵＩを提示し、ＧＵＩ内でユーザの行動に応答する。
【０１４２】
ビューア６４は、論理階層３０を、フィッシュボーン・レイアウト４５またはスノーフレーク・レイアウト４６のような視覚的階層４０としてレンダリングし、論理階層３０内に定義されている順序に従って視覚的階層４０をレイアウトする。これに対して、ビューア６４は、図８に示すビューア・レイアウト・クラス６４１を使用する。ビューア６４は、分岐（背骨とも呼ばれる）を表示パネル５１５内に表示する。上記分岐は、ビューア分岐クラス６４２によりすでにレンダリングされている。ビューア分岐クラス６４２は、分岐のレンダリングを包み込み、先端を切除し、また再スケールすることができる。
【０１４３】
ビューア６４は、ユーザの会話イベントを受信し、それをビューア・モデル６９に送る。ユーザの会話イベントは、クリック、右クリック、マウスオーバ、メニュー・バー選択、およびウィンドウのサイズの変更を含む。
【０１４４】
クライアント側のポーラ
クライアント側のポーラ６２は、ウェブ・サーバ６０と通信する。より詳細に説明すると、図８に示すように、クライアント側のポーラ６２は、ネットワークを通してＪａｖａ（登録商標）オブジェクトを送るためにＨＴＴＰ直列化機能６２１を使用し、ＨＴＴＰプロトコル６０１によりネットワークを通して直列化したオブジェクトを送り、およびウェブ・サーバ６０は、オブジェクトを受信するために、ＨＴＴＰ直列化機能６０２を使用する。このプロセスは、ウェブ・サーバ６０からクライアント側のポーラ６２へ通信するために、同じような方法で逆方向にも動作する。
【０１４５】
クライアント側のＨＴＴＰ直列化機能６２１およびサーバ側のＨＴＴＰ直列化機能６０２は、例えば、ネットワーク・トラヒックまたは通信オーバーヘッドを低減するために、複数のメッセージを１つの直列化オブジェクトに多重化することができる。
【０１４６】
サーバ
ウェブ・サーバ６０は、クライアント・アプリケーション２２に、ＨＴＴＰをベースとするインタフェースを供給する。インタフェースを通して、ウェブ・サーバ６０により、クライアント・アプリケーション２２は、状態リポジトリ７０および表示リポジトリ７５にアクセスすることができる。状態リポジトリ７０内の状態ファイル７１は、アラーム３５に関する情報および論理階層３０への構成の変更に関する情報を含む。論理階層３０は、図８に示すように、表示リポジトリ７５内の表示記録７５２内に記憶される。
【０１４７】
ウェブ・サーバ６０は、ウェブ・サーバ内にＣＧＩプロセスを含む。ウェブ・サーバ６０は、表示するための論理階層３０のデフォールト・リスト６０３を有し、そのためクライアント・アプリケーション２２のユーザ２３が、「ファイル」ドロップダウン・メニュー５１８（図６Ｂに示す）から、「サーバへ接続」ドロップダウン項目５１９を選択し、ウェブ・サーバ６０に接続すると、デフォールト・リスト６０３をクライアント・アプリケーション２２に提示することができる。
【０１４８】
状態ファイル７１は、モニタ・エンジン８０により維持される。状態ファイル７１は、アラーム３５および名前の変更のような構成の変更を含む、リソース２４の状態に関する情報を含む。状態ファイル７１は、また、追加、削除、および（関係への変化、および異なるルート・プロファイル３２の指定を含む）再配置を含む、論理階層３０の構造への変化を追跡する。状態ファイル７１は、また、図４Ａに示すリソース２４とその監視エージェント８２との間で、状態情報が自由に流れているかどうかを示す。状態情報の中断は、監視サービスの管理上の中断（すなわち、故意の中断）および通信チャネル内の問題または故障（意図的でない中断）を含む。
【０１４９】
表示リポジトリ７５は、リソース・エンティティ７９５（図４Ｂに示す）およびそのリソース・プロファイル７７（図５Ａに示す）の両方を含む。表示リポジトリ７５は、また、リソース・プロファイル７７および従属関係７８を参照する論理階層３０を含む。表示リポジトリ７５は、それにより表示リポジトリ７５の内容をユーザ２３が生成し、維持することができる編集機能も提供する。表示リポジトリ７５は、この実施形態が必要とする以上の追加機能および目的を持つことができる。表示リポジトリを供給する製品の一例としては、米国マサチューセッツ州マールボロ所在のＣｏｎｃｏｒｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ社が市販しているＮｅｔｗｏｒｋＨｅａｌｔｈがある。
【０１５０】
監視エンジン８０は、状態ファイル７１に書込みを行い、維持し、ウェブ・サーバ６０は、クライアント・アプリケーション２２の代わりに探索を行うことができる。監視エンジン８０は、ネットワーク・リソース２４上でデータを収集する分散型エージェントである、監視エージェント８２（図４Ａに示す）から状態ファイル７１に関する情報を収集する。監視エージェント８２は、リソース２４に関するデータを収集し、そのデータをＡＳＣＩＩファイル（図示せず）内に入れ、そのファイルを監視サーバ８１に送る。監視エージェント８２は、意図的な理由（保守、または執務時間中だけしか監視が必要でないというような）、または故障または破壊を含む、種々の理由でデータの送信を中止することができる。監視エージェント８２が稼働中である場合には、監視エージェント８２は、リソース・プロファイル７７に基づいてアラーム３５を発生しなければならない条件が存在するかどうかを判断する。アラーム３５が発生した場合には、監視エンジン８０は、そのアラームをリソース・プロファイル７７に対応する状態ファイル７１に書き込む。
【０１５１】
分析ソフトウェア
分析ソフトウェア９０により、ユーザ２３は監視エンジン８０が収集した監視データをブラウズすることができる。分析ソフトウェア９０は、分類、合計などによるような個々のイベントの詳細を示し、それらを統合するスナップショットを供給する。分析ソフトウェア９０は、また、生の動的報告および履歴トレンドも供給する。
【０１５２】
分析ソフトウェア９０は、フィッシュボーン・レイアウト４５から、ドリル・ダウン項目５１６を通してアクセスすることができる。
【０１５３】
市販の分析ソフトウェア９０の例としては、ＬｉｖｅＥｘｃｅｐｔｉｏｎｓ、ＬｉｖｅＴｒｅｎｄ、およびＮｅｔｗｏｒｋＨｅａｌｔｈ等がある。これら３つの製品はすべて、米国マサチューセッツ州マールボロ所在のＣｏｎｃｏｒｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ社から入手することができる。
【０１５４】
他の実施形態
本発明の多数の実施形態について説明してきた。しかし、本発明の精神および範囲から逸脱することなしに、種々の修正を行うことができることを理解することができるだろう。例えば、監視エンジン８０は、状態ファイル７１を維持するために、監視エージェント８２からデータを収集する必要はなく、監視エンジン８０は、何らかの他の情報源を持つことができる。クライアント・アプリケーション２２は、データをダウンロードまたは「プルダウン」するために、ウェブ・サーバ８０をポーリングする必要はなく、「プッシュ」アーキテクチャ、すなわち、それに対するポーリングを行わなければならないクライアント・アプリケーション２２を使用しないで、データがクライアント・アプリケーション２２に送られるアーキテクチャにより、ウェブ・サーバ６０からデータを送ることもできる。フィッシュボーン・レイアウト４５またはスノーフレーク・レイアウト４６を含む表示パネル５１５は、表示装置の先端を切除しないでスクロールすることができる。このスクロールは、スクロール・バーにより行うことができる。図３Ａは、２つのフィッシュボーン・レイアウト４５を含むスノーフレーク・レイアウト４６を示しているが、スノーフレーク・レイアウト４６は、３つ以上のフィッシュボーン・レイアウト４５を含むことができる。
【０１５５】
最も少ない数の分岐で背骨を包むための方法が、少なくとも２つある。長さ優先アプローチについてはすでに説明した。他の実施形態は、各サブセグメント４４６が大体同じ長さになるように、図２Ａに示すように、サブセグメント４４６を分配する「バランシング」アプローチを使用する。
【０１５６】
都合のよいことに、下に位置する論理階層３０、フィッシュボーン・レイアウト４５内の背骨は、ルート・アイコン／ラベル４２１の方向に均等に送ることができるし、ルート・アイコン／ラベル４２１の反対方向に均等に送ることもできるし、またはルート・アイコン／ラベル４２１に関して、所与のフィッシュボーン・レイアウト４５内で種々の方向に配列することもできる。
【産業上の利用可能性】
【０１５７】
上記実施形態の場合には、クライアント・アプリケーション２２の一部は、Ｊａｖａ（登録商標）プログラミング言語で書かれている。何故なら、Ｊａｖａ（登録商標）は、アプリケーションを広い範囲のオペレーティング・システムおよび計算プラットフォームに移植することができるからである。しかし、Ｊａｖａ（登録商標）の代わりに他のプログラミング言語も使用することもできる。
【０１５８】
従って、他の実施形態も上記の特許請求の範囲に入る。
【図面の簡単な説明】
【０１５９】
【図１Ａ】会話型階層状態表示用のシステムのブロック図である。
【図１Ｂ】計算プラットフォームのブロック図である。
【図２Ａ】デフォールト・モードでのフィッシュボーンの表示を含む表示パネルである。
【図２Ｂ】稠密モードでのフィッシュボーンの表示を含む表示パネルである。
【図３Ａ】スノーフレーク表示を含む表示パネルである。
【図３Ｂ】従来技術によるＧＵＩ要素および技術である。
【図４Ａ】従来技術による監視システムである。
【図４Ｂ】表示リポジトリのブロック図である。
【図５Ａ】プロファイルを通しての多重コンテキスト内の表示用の１つのリソースである。
【図５Ｂ】論理階層表示リソースである。
【図６Ａ】あるイベントのデータの流れを示す。
【図６Ｂ】表示ウィンドウ用のＧＵＩ要素と技術である。
【図７Ａ】クライアント・アプリケーションおよびサーバ内のソフトウェア要素である。
【図７Ｂ】クライアント・アプリケーション内のソフトウェアのクラスである。
【図８】クライアント・アプリケーション内のクラスのブロック図である。
【図９Ａ】従来技術による有向木データ・モデルである。
【図９Ｂ】論理階層の構造である。
【符号の説明】
【０１６０】
４５ レンダリング・フィッシュボーン・レイアウト
３０ リソース・プロファイル
７７ リソース・プロファイル
４６ スノーフレーク・レイアウト

Claims (48)

1. ネットワークで接続しているリソースの状態を表示するためのコンピュータをベースとする方法であって、
   フィッシュボーン・レイアウト内に、複数のリソース・プロファイルおよび前記複数のリソース・プロファイル内のリソース・プロファイル間の複数の従属関係を含む階層をレンダリングするステップを含み、前記リソース・プロファイルがネットワークで接続しているリソースを表す方法。
2. さらに、
   前記フィッシュボーン・レイアウト内に、監視下のリソース・プロファイルを有する監視下のリソースの状態を入手するステップと、
   前記状態を反映するために前記フィッシュボーン・レイアウトを更新するステップとを含む、請求項１に記載の方法。
3. 前記状態を入手するステップが、一定の時間間隔で、前記状態を反復して入手するステップを含む、請求項２に記載の方法。
4. 前記状態を反復して入手するステップが、前記一定の時間間隔内の最も最近の時間間隔中に変化した前記監視下のリソースの特性に関する情報を入手するステップを含む、請求項３に記載の方法。
5. 前記監視下のリソース・プロファイルが、前記監視下のリソース・プロファイルとのコンシューマの従属関係の従属リソース・プロファイルに、前記入手した状態をどのように伝搬すべきかについての伝搬規則を含み、
   前記フィッシュボーン・レイアウトを更新するステップが、従属リソース・プロファイルのレンダリングを更新するステップを含む、請求項４に記載の方法。
6. 前記レンダリング・ステップが、最初に、前記フィッシュボーン・レイアウトの第１の密度モードで表示パネルに前記フィッシュボーン・レイアウトを表示し、さらに、
   前記第１の密度モードを第２の密度モードで置換するステップを含む、請求項１に記載の方法。
7. 前記置換ステップが、前記表示パネルのサイズに対する前記フィッシュボーン・レイアウトの部材の比率で変化に応じる、請求項６に記載の方法。
8. 前記フィッシュボーン・レイアウトの前記第１の密度モードが、層２のリソース・プロファイルを背骨としてレンダリングする標準モードであり、前記第２の密度モードが、第１の密度モードに対して、もっと高い密度で前記フィッシュボーン・レイアウトの構成要素をレンダリングするためのモードである、請求項６に記載の方法。
9. 前記フィッシュボーン・レイアウトの前記第１の密度モードが、前記第２の密度モードに対してもっと高い密度で、前記フィッシュボーン・レイアウトの構成要素をレンダリングするためのモードであり、前記第２の密度モードが、層２のリソース・プロファイルを背骨としてレンダリングする標準モードである、請求項６に記載の方法。
10. 第１のリソース・プロファイルのレンダリングと前記フィッシュボーン・レイアウトの第２のリソース・プロファイルのレンダリングとの間の位相的接続が、前記第１のリソース・プロファイルと前記第２のリソース・プロファイルとの間の直接の従属関係に対応し、
    第１のリソース・プロファイルのレンダリングと前記フィッシュボーン・レイアウトの第３のリソース・プロファイルのレンダリングとの間の位相的接続が存在しないことが、前記第１のリソース・プロファイルと前記第３のリソース・プロファイルとの間の任意の直接の従属関係が存在しないことに対応する、請求項６に記載の方法。
11. 前記フィッシュボーン・レイアウトの前記第２の密度モードが、層２のリソース・プロファイルを平行四辺形としてレンダリングする稠密モードである、請求項１０に記載の方法。
12. さらに、
    継続したマウスオーバに応答して、前記フィッシュボーン・レイアウトの構成要素を記述するダイアログの要約を提示するステップを含む、請求項１に記載の方法。
13. さらに、
    構成要素上での右クリックに応じて、前記フィッシュボーン・レイアウトの構成要素に対するコンテキスト・メニューを表示するステップを含み、前記コンテキスト・メニューが、前記構成要素を呼び出す手順を提供するドリル・ダウン・リストを含む、請求項１に記載の方法。
14. 前記コンテキスト・メニューが、前記構成要素に対してカスタマイズされる、請求項１３に記載の方法。
15. 前記ドリル・ダウン・リスト内のある手順が、ユーザによる選択に応じて、ネットワーク分析ツール内の報告を呼び出す、請求項１３に記載の方法。
16. 前記ドリル・ダウン・リスト内のある手順が、ユーザによる選択に応じて、前記フィッシュボーン・レイアウトを再度レンダリングさせ、前記フィッシュボーン・レイアウトが根を有し、前記構成要素が前記フィッシュボーン・レイアウトの根になる、請求項１３に記載の方法。
17. 前記ドリル・ダウン・リスト内のある手順が、ユーザによる選択に応じて、根を有し、前記構成要素を前記根として使用するフィッシュボーン・レイアウトを有する新しい表示パネルを開く、請求項１３に記載の方法。
18. 前記ドリル・ダウン・リスト内のある手順が、ユーザによる選択に応じて、根を有し、前記構成要素を前記根として使用する新しいスノーフレーク表示を開く、請求項１３に記載の方法。
19. ネットワークで接続しているリソースの状態を表示するためのコンピュータをベースとする方法であって、
    各従属リソース・プロファイルからルート・リソース・プロファイルへの一連の従属関係を含む最短経路が、前記各従属リソース・プロファイルに対する前記階層内の１つの層に対応する経路の長さを有するように、ルート・リソース・プロファイルおよび前記ルート・リソース・プロファイルと従属関係にある複数の従属リソース・プロファイルを含む階層を供給し、前記リソース・プロファイルが、ネットワークで接続しているリソースを表すステップと、
    前記ルート・リソース・プロファイルであるか、または前記複数の従属リソース・プロファイル内に位置する監視下のリソース・プロファイルの状態を入手するステップと、
    前記状態を重大度レベルと関連づけるステップと、
    フィッシュボーン・レイアウト内に、前記重大度レベルを示す視覚的特徴により、前記監視下のリソース・プロファイルのレンダリングを含む階層をレンダリングするステップとを含む方法。
20. 前記視覚的特徴が、重大度レベルを表す複数のカラーから選択した１つのカラーを含む、請求項１９に記載の方法。
21. 前記状態を重大度レベルと関連づけるステップが、前記監視下のリソース・プロファイルと関連する状態測定基準を使用するステップを含む、請求項２０に記載の方法。
22. さらに、
    前記状態の変化の通知を入手するステップと、
    前記重大度レベルを更新するステップと、
    前記更新した重大度レベルを表示するために、前記監視下のリソース・プロファイルのレンダリングを含むように、フィッシュボーン・レイアウト内に前記階層を再レンダリングするステップとを含む、請求項２１に記載の方法。
23. 前記重大度レベルを更新するステップが、前記状態の測定基準が示す行動から逸脱するために、アプリケーション全体のオーバーライドを適用するステップを含む、請求項２２に記載の方法。
24. 前記逸脱が重大度レベルの変化を抑制するステップを含む、請求項２３に記載の方法。
25. 前記フィッシュボーン・レイアウトがスノーフレーク・レイアウトに含まれる、請求項１９に記載の方法。
26. ネットワークで接続しているリソースの状態を表示するためのコンピュータをベースとする方法であって、
    複数のリソース・プロファイルと、前記複数のリソース・プロファイル内のリソース・プロファイル間の複数の従属関係とを含む論理階層を入手するステップであって、前記リソース・プロファイルがネットワークで接続しているリソースを表すステップと、
    前記論理階層から視覚的階層を入手するステップであって、前記視覚的階層が木になるように、前記視覚的階層の構成要素が前記論理階層の構成要素に対応するステップと、
    フィッシュボーン・レイアウト内に前記視覚的階層をレンダリングするステップとを含む方法。
27. 前記視覚的階層が有向木である、請求項２６に記載の方法。
28. 前記フィッシュボーン・レイアウトがスノーフレーク・レイアウトに含まれる、請求項２６に記載の方法。
29. ネットワークで接続しているリソースの状態を表示するための計算装置であって、
    プロセッサ、主記憶装置、視覚的表示装置、記憶装置およびネットワーク接続を含む、その中で実施されたコンピュータ可読プログラム・コード手段を有するコンピュータが使用することができる媒体を備え、前記プログラム・コード手段が、
    コンピュータに複数のリソース・プロファイルおよび前記複数のリソース・プロファイル内のリソース・プロファイル間の複数の従属関係を含む階層を表示させるためのコンピュータ可読プログラム・コード手段であって、前記リソース・プロファイルが、ネットワークで接続しているリソースを表すコンピュータ可読プログラム・コード手段と、
    前記コンピュータに前記複数のリソース・プロファイル内の監視下のリソース・プロファイルの状態を入手させるためのコンピュータ可読プログラム・コード手段と、
    前記コンピュータに、前記監視下のリソース・プロファイルの状態の視覚的表現のレンダリングを含む、前記階層をフィッシュボーン・レイアウト内にレンダリングさせるためのコンピュータ可読プログラム・コード手段とを備える計算装置。
30. ネットワークで接続しているリソースの状態を表示するためのコンピュータをベースとする方法であって、
    スノーフレーク・レイアウト内に、それぞれが、複数のリソース・プロファイルと、前記複数のリソース・プロファイル内のリソース・プロファイル間の複数の従属関係を含む階層を特徴とする複数のフィッシュボーン・レイアウトをレンダリングするステップを含み、前記リソース・プロファイルが、各階層が共通の根を共有するように、ネットワークで接続しているリソースを表す方法。
31. さらに、
    監視下のリソースの状態を入手するステップと、
    前記入手した状態を反映するために、前記スノーフレーク・レイアウト内の前記監視下のリソースの監視下のリソース・プロファイルを更新するステップとを含む、請求項３０に記載の方法。
32. 状態を入手するステップが、一定の時間間隔で、前記状態を反復して入手するステップを含む、請求項３１に記載の方法。
33. 前記状態を反復して入手するステップが、前記一定の時間間隔内の最も最近の時間間隔中に変化した前記監視下のリソースの特性に関する情報を入手するステップを含む、請求項３２に記載の方法。
34. 前記監視下のリソース・プロファイルが、前記監視下のリソース・プロファイルとのコンシューマの従属関係の従属リソース・プロファイルに、前記入手した状態をどのように伝搬すべきかについての伝搬規則を含み、
    前記スノーフレーク・レイアウトを更新するステップが、前記従属リソース・プロファイルのレンダリングを更新するステップを含む、請求項３１に記載の方法。
35. 前記レンダリングが、最初に、フィッシュボーン・レイアウトの第１の密度モードで、表示パネルに前記複数のフィッシュボーン・レイアウトのうちの１つのフィッシュボーン・レイアウトを表示し、さらに、
    前記第１の密度モードを第２の密度モードで置換するステップを含む、請求項３０に記載の方法。
36. 前記置換ステップが、前記表示パネルのサイズに対する前記フィッシュボーン・レイアウトの部材の比率で変化に応じる、請求項３５に記載の方法。
37. 前記フィッシュボーン・レイアウトの前記第１の密度モードが、層２のリソース・プロファイルを背骨としてレンダリングする標準モードであり、前記第２の密度モードが、前記第１の密度モードに対して、もっと高い密度で前記フィッシュボーン・レイアウトの構成要素をレンダリングするためのモードである、請求項３５に記載の方法。
38. 前記フィッシュボーン・レイアウトの前記第１の密度モードが、前記第２の密度モードに対して、もっと高い密度で前記フィッシュボーン・レイアウトの構成要素をレンダリングするためのモードであり、前記第２の密度モードが、層２のリソース・プロファイルを背骨としてレンダリングする標準モードである、請求項３５に記載の方法。
39. 前記フィッシュボーン・レイアウトの第１のリソース・プロファイルのレンダリングと第２のリソース・プロファイルのレンダリングとの間の位相的接続が、前記第１のリソース・プロファイルと前記第２のリソース・プロファイルとの間の直接の従属関係に対応し、
    前記フィッシュボーン・レイアウトの第１のリソース・プロファイルの前記レンダリングと第３のリソース・プロファイルのレンダリングとの間の位相的接続が存在しないことが、前記第１のリソース・プロファイルと前記第３のリソース・プロファイルとの間の任意の直接の従属関係が存在しないことに対応する、請求項３５に記載の方法。
40. 前記フィッシュボーン・レイアウトの前記第２の密度モードが、層２のリソース・プロファイルを平行四辺形としてレンダリングする稠密モードである、請求項３６に記載の方法。
41. さらに、
    継続したマウスオーバに応答して、前記フィッシュボーン・レイアウトの構成要素を記述するダイアログの要約を提示するステップを含む、請求項３０に記載の方法。
42. さらに、
    前記構成要素上での右クリックに応じて、前記フィッシュボーン・レイアウトの構成要素に対するコンテキスト・メニューを表示するステップを含み、前記コンテキスト・メニューが、前記構成要素を呼び出す手順を提供するドリル・ダウン・リストを含む、請求項３０に記載の方法。
43. 前記コンテキスト・メニューが、前記構成要素に対してカスタマイズされる、請求項４２に記載の方法。
44. 前記ドリル・ダウン・リスト内のある手順が、ユーザの選択に応じて、ネットワーク分析ツール内の報告を呼び出す、請求項４２に記載の方法。
45. 前記ドリル・ダウン・リスト内のある手順が、ユーザの選択に応じて前記フィッシュボーン・レイアウトを再度レンダリングさせ、前記フィッシュボーン・レイアウトが根を有し、前記構成要素が前記フィッシュボーン・レイアウトの根になる、請求項４２に記載の方法。
46. 前記ドリル・ダウン・リスト内のある手順が、ユーザの選択に応じて、根を有し、前記構成要素を前記根として使用するフィッシュボーン・レイアウトを有する新しい表示パネルを開く、請求項４２に記載の方法。
47. 前記ドリル・ダウン・リスト内のある手順が、ユーザの選択に応じて、根を有し、前記構成要素を前記根として使用する新しいスノーフレーク表示を開く、請求項４２に記載の方法。
48. ネットワークで接続しているリソースの状態を表示するための計算装置であって、
    プロセッサ、主記憶装置、視覚的表示装置、記憶装置およびネットワーク接続を含む、その中で実施されたコンピュータ可読プログラム・コード手段を有するコンピュータが使用することができる媒体を備え、前記プログラム・コード手段が、
    コンピュータに、スノーフレーク・レイアウト内に、それぞれが、複数のリソース・プロファイルおよび前記複数のリソース・プロファイル内のリソース・プロファイル間の複数の従属関係を含む階層を特徴とする複数のフィッシュボーン・レイアウトをレンダリングさせるためのコンピュータ可読プログラム・コード手段を備え、各階層が共通の根を共有するように、前記リソース・プロファイルが、ネットワークで接続しているリソースを表す計算装置。

Images