CA Spectrum

は、Linux、および Windows プラットフォームで実行される統合管理システムです。

CA Spectrum

設計は、クライアント/サーバ モデルに基づいています。

SpectroSERVER

と呼ばれるサーバには、ネットワーク情報をすべて取得および格納する

CA Spectrum

ナレッジ ベースが含まれます。クライアントは、OneClick と呼ばれる

CA Spectrum

ユーザ インターフェースであり、ネットワーク環境のグラフィック表示を提供します。

SpectroSERVER

はインテリジェンスを提供し、実際のネットワークおよびそれらの関係のモデルが含まれています。これらモデルは、表すエンティティに関するデータを継続的に収集し、包括的なネットワーク管理の観点を集合的に提供します。ポーリングにより、

CA Spectrum

データベースは、ネットワーク デバイス、それらの関係、およびそれらのパフォーマンスに関する広範な情報を取得します。

OneClick クライアント アプリケーションは、

SpectroSERVER

データベースの多次元ビューを提供します。ユーザは、

SpectroSERVER

データベースで管理された情報を取得および表示したり、

SpectroSERVER

を呼び出してネットワーク上のオブジェクトを制御することができます。ネットワーク情報は、トポロジ的ビューや地理的ビューなどのさまざまな観点から表すことができます。

CA Spectrum

はモデル タイプ、モデル、属性、関係、およびメタルールを展開して、ネットワーク インフラストラクチャを監視します。

モデル タイプ

は、モデルの作成に使用されるテンプレートです。

モデル

は、モデル タイプの特定のインスタンスです （用語「モデル タイプ」と「テンプレート」は、

CA Spectrum

ドキュメントで同じ意味で使用されます）。

属性

は、特定のモデル タイプの特性です。

関係

および

メタルール

は、モデル タイプがどのように相互に対話するかを定義します。モデルおよび関連付けは OneClick を使用して定義されますが、Model Type Editor では、ユーザがモデル タイプ、ルール、関係、および属性を定義できます。

Model Type Editor は Java ベースのアプリケーションで、モデリング カタログ オブジェクトを作成、変更、および削除するために使用します。これは

SpectroSERVER

データベースにアクセスするシック クライアント アプリケーションなので、

SpectroSERVER

プラットフォームから実行する必要があります。

モデル タイプ

は、モデルの作成に使用されるテンプレートであり、属性の特定のセットによって定義されます。一方、

属性

は、モデル タイプによって表される現実世界のオブジェクトを集合的に特徴づけるデータベース変数です。モデル タイプには、わずかな属性および関係を持つ単純なものから、多くの属性および関係を持つ非常に複雑なものまであります。

複雑なモデル タイプは、多くの場合、より単純な複数のモデル タイプから属性を継承することによって派生します。結果として生じる組み合わせが、モデル タイプの階層を構成します。親モデル タイプ（1 つ以上の他のモデル タイプが派生したモデル タイプ）は、

ベース モデル タイプ

と呼ばれます。子モデル タイプ（1 つ以上の他のタイプから派生したモデル タイプ）は、

派生モデル タイプ

と呼ばれます。以下の図は、モデル タイプの派生を表すサンプル モデル タイプ階層を示しています。

この図で、Device は 3 つのモデル タイプ（PC Card、Hub、および Bridge）のベース モデル タイプです。したがって、3 つの派生モデル タイプはすべて、Device の属性を継承します。

一方、PC Card、Hub、および Bridge は、別のモデル タイプ（それぞれ SNMP PC Card、SNMP MMAC、および SNMP Bridge）のベース モデル タイプとして使用されます、。これらの派生モデル タイプはすべて、直接の親モデル タイプの属性を継承し、また、拡張によって Device モデル タイプの属性を継承します。また、これらは SNMP Protocol という名前のモデル タイプの属性も継承します。

Model Type Editor で、［階層］タブを使用してモデル タイプ階層内のモデル タイプの位置を識別できます。このタブには、現在のモデル タイプに関する以下の内容が表示されます。

また、Model Type Editor には、モデル タイプの属性およびそれらのデフォルト値を表示する［属性］タブもあります。

属性に関するさまざまな論理が存在します。ルータの名前やその IP アドレスなどの特定の属性は、

CA Spectrum

データベース内で生成されるモデルを一意に識別するために必要です。その他の属性は、モデルでサポートされている SNMP オブジェクト識別子（OID）にモデルを関連付けます。また、

CA Spectrum

の機能をサポートする属性もあります。たとえば、Discovery_Precedence はディスカバリ プログラムによって使用され、Value_When_Red はアラーム ロールアップに使用されます。また、Polling_Interval は、

CA Spectrum

が所定のデバイスをポーリングして情報を取得する頻度を決定するために使用されます。

モデル

は、

SpectroSERVER

によってモデル タイプをインスタンス化したものです。同じモデル タイプからインスタンス化されたモデルはすべて、属性および

CA Spectrum

インテリジェンスの同じセットを持ちます。ただし、属性の値は、共有属性（すなわち、［共有］フラグが設定された属性）の場合を除いてモデルごとに一意です。

単純な例として、以下の図は、ビルという名前のモデル タイプから派生した 3 つのモデルを示しています。このモデル タイプには、Modeltype_Name、Model_Name、および Floors の 3 つの属性があります。モデルはそれぞれ同じモデル タイプからインスタンス化されるので、各モデルは Modeltype_Name （共有属性）に対して同じ値を持ちます。ただし、Model_Name および Floors の値は変わります。

関係

は、モデル タイプ間の特定タイプの関係を定義するデータベース構成です。関係の例を以下に示します。

各関係は、1 つのルールによって、またはより一般的には、メタ ルールと呼ばれる複数のルールによって定義されます。関係の

メタルール

は、特定のモデル タイプに関係を適用することにより、モデル タイプがどのように相互に対話できるかを定義します。例として、Contains 関係に対して定義されたいくつかのメタルールを以下に示します。

各メタルールには、厳密に 1 つの先行のモデル タイプ（左側のエントリ）および厳密に 1 つの述語モデル タイプ（右側のエントリ）が必要です。すべてのモデル タイプが、任意の数のメタルールの先行または述語のモデル タイプになりえます。

OneClick は、モデル タイプに対するメタルールを使用して、そのモデル タイプからインスタンス化された特定のモデル間のインタラクションに対するルールを確立します。

CA Spectrum

の用語では、2 つのモデル間でメタルールをインスタンス化すると、モデル間の

関連付け

が作成されます。また、各モデルは、もう一方のモデルに関連付けられるというナレッジに反応できます。たとえば、以下のメタルールを考慮します。

Country Contains Building

これにより、2 つの特定のモデル間に以下の関連付けが生じる可能性があります。

France contains Corporation001

関係には、以下の 2 つのタイプがあります。

Model Type Editor には、特定の関係に対して定義されたメタルールを表示する［関係］タブがあります。

基本

CA Spectrum

パッケージに付属したモデリング カタログ内のほとんどの関係には、関係を適用できるモデル タイプを指定するメタルールが含まれます。

ユーザが既存のモデル タイプから新しいモデル タイプを派生させる場合、各モデル タイプの機能はその継承に依存するので、モデル タイプおよび属性継承の詳細を理解しておくことが重要です。

このセクションでは、継承に関連する重要な概念、すなわち属性記述子、標準的な階層と特殊化された階層、モデル タイプの優先順位、および属性の折り畳みについて説明します。

属性記述子は、属性（たとえば、ブール値、整数、テキスト文字列などのタイプ）およびデフォルト値を定義する特性です。

属性には、以下の 2 つのタイプの記述子があります。

以下の図は、属性およびそれらのデフォルト値が標準的な階層シーケンスによって継承されるモデル タイプ階層を示しています。

この図で、モデル タイプ A はベース モデル タイプから派生し、その結果、モデル タイプ A はベース モデル タイプから属性 X およびそのデフォルト値 1 を継承します。同様に、モデル タイプ B はモデル タイプ A から派生し、その結果、モデル タイプ B はモデル タイプ A から属性 X およびそのデフォルト値 1 を継承します。

この継承の階層関係は、モデル タイプ A、モデル タイプ B、またはそれらのいずれかの子孫から派生した他のすべてのモデル タイプに適用されます。さらに、元のモデル タイプ内の［デフォルト値］属性記述子の値に対して行なわれたすべての変更が、記述子値を継承したすべての派生モデル タイプに即時に適用されるように、データベースによって関係が管理されます。

単純な例として、電話番号をデフォルト値として、Technical_Assistance テキスト文字列属性をベース モデル タイプに追加すると仮定します。モデル タイプ A、モデル タイプ B、およびそれらから派生した他のすべてのモデル タイプは Technical_Assistance 属性を継承し、その結果、［デフォルト値］属性記述子の値（電話番号）を継承します。その後電話番号を変更した場合、ベース モデル タイプから直接または間接的に派生したすべてのモデル タイプは、新しい電話番号を即時に継承します。

標準的な階層とは対照的に、以下の図は、1 つの派生モデル タイプはそのデフォルト値を継承するが、もう 1 つの派生モデル タイプはこの値を継承しないというモデル タイプ階層を示しています。

この場合、モデル タイプ A 内の属性 X のデフォルト値（具体的には、属性 X の［デフォルト値］属性記述子の値）は指定されており、継承されたものではありません。つまり、ベース モデル タイプから継承された値はオーバーライドされ、使用されなくなりました。このセクションで前述したように、このプロセスは

特殊化

と呼ばれます。

継承された記述子値をオーバーライドすると、

その属性記述子のみ

に関してベース（親）モデル タイプとの関係が破棄されます。他のすべての属性記述子の値に関する継承関係は、影響を受けません。さらに、特殊化されたモデル タイプから派生したモデル タイプは、特殊化されていないモデル タイプから派生した場合と全く同様に動作します。この図で、モデル タイプ B は、モデル タイプ A が特殊化されていない場合と同様に、モデル タイプ A から属性 X のデフォルト値を継承します。モデル タイプ A 内の属性 x のデフォルト値を変更した場合、モデル タイプ B 内の同じ属性のデフォルト値も即時に変更されます。継承関係が有効なので、変更する前にモデル タイプ B を派生させた場合でも、結果は同じになります。

実際には、特に共通のベース モデル タイプから複数のモデル タイプが派生した場合、多くの属性階層は、継承された値と特殊化された値の組み合わせで構成されます。さらに、特殊化は［デフォルト値］属性記述子に関して最も一般的ですが、特殊化可能な他のいずれかの記述子に対しても適用できます。以下の図は、属性（属性 X）に対して継承と特殊化の両方を使用するモデル タイプ階層を示しています。

この図で、新しい属性 Y の導入により、モデル タイプ C が特殊化されています。そのため、この属性は派生モデル タイプ D によって継承されます。

ベース モデル タイプから属性を継承するプロセスは、派生モデル タイプが、共通の元のモデル タイプを含む 2 つ以上の継承パスから同じ属性を継承できることを意味します。この状況のあいまいさを回避するために、ベース モデル タイプは、派生モデル タイプのベース モデル タイプとして追加される順序に従ってランク付けされます。また、このモデル タイプのランク付けにより、派生モデル タイプが複数のパスから属性を継承できる場合に使用する継承パスが決定されます。より具体的には、派生モデル タイプは、ランクが

最小

のベース モデル タイプから属性を継承します。

ベース モデル タイプから最初にモデル タイプを派生させる際、そのベース モデル タイプにはランク 1 が指定されます。その後、2 番目のベース モデル タイプを派生モデル タイプに追加する場合、その 2 番目のベース モデル タイプにはランク 2 が指定されます。後続のベース モデル タイプには、同様の方式でランクが割り当てられます。

例として、以下のモデル タイプの派生ワークフローを考えてみます。

できるだけ単純な属性階層を維持するために、Model Type Editor には、不要な特殊化を除去する機能が含まれます。すなわち、直接（つまり、直接の親モデル タイプから）属性を継承したベース モデル タイプ内の対応する記述子の値と

一致

するように、派生モデル タイプ内の［デフォルト値］記述子（または、特殊化可能な他のいずれかの記述子）を変更した場合、データベースは変更を破棄し、代わりにベース モデル タイプから記述子値を継承します。このプロセスは「属性の折りたたみ」と呼ばれ、不要なカスタマイズを削除することにより、特殊化された階層をできるだけ簡略化することを目標としています。

いったん記述子値が継承値に戻った後で、ベース モデル タイプ内の記述子値を変更した場合、派生モデル タイプもこの変更を受け取ります（これは通常の継承動作です）。

以下の図に示されるように、コンポーネント詳細画面の［値の定義先］フィールドで、現在のモデル タイプがそのデフォルト値を取得した元のモデル タイプを識別できます。