付録 A Common Information Model (CIM) の用語と概念

CIM の概念

ネットワークエンティティと管理機能が CIM のコンテキスト内でどのように表現され関連しているかを理解する上で重要な、CIM の基本的な用語と概念について説明します。Common Information Model とオブジェクト指向モデルの慣例 (独自のスキーマのモデル化など) の詳細は、Distributed Management Task Force が提供している http://dmtf.org/spec/cim_tutorial の CIM Tutorial を参照してください。

オブジェクト指向モデル

CIM では、物理的または論理的に存在するオブジェクト、エンティティ、概念、または機能の表現手段として、オブジェクト指向モデルの原理を使用しています。オブジェクト指向モデルの目的は、物理的なエンティティをフレームワーク (モデル) で設定し、エンティティの特性と機能、およびエンティティとほかのエンティティとの関係を表現することです。CIM では、オブジェクト指向モデルを使用して、ハードウェア要素とソフトウェア要素をモデル化します。

Uniform Modeling Language

Uniform Modeling Language (UML) モデルは、図と言語で表されます。モデルを表現するための CIM 規則は、UML の図示概念に基づいています。UML は、図を使用して物理的なエンティティを表現し、線を使用して関係を表現します。たとえば、UML ではクラスは矩形として表されます。各矩形には、表現対象であるクラスの名前が入ります。2 つの矩形間の線は、それらのクラスの関係を示します。2 つのクラスを上位クラスに結合するために分岐する線は、関連を示します。

CIM ダイアグラムは、色を使用して関係を詳しく説明します。

• 赤色の線 -> 関連

• 青色の線 -> 継承関係

• 緑色の線 -> 集合

CIM の用語

次の用語は、CIM スキーマ固有の意味を持ちます。

スキーマ

モデル、スキーマ、およびフレームワークは同義語です。これらはそれぞれ、物理的または論理的に存在するエンティティの抽象表現です。CIM では、スキーマはクラスの名前付けと管理に使用される、名前の付けられたクラスの集まりを意味します。スキーマ内では、クラスとそのサブクラスは構文 Schemaname_classname によって階層的に表現されます。スキーマ内の各クラス名は、一意である必要があります。Solaris WBEM Services には、Solaris スキーマが付属しています。Solaris スキーマには、CIM 機能を Solaris 用に独自に拡張したすべてのクラスが含まれます。

クラスとインスタンス

WBEM では、クラスは最も基本的な管理ユニットを表現するオブジェクトの集まりを意味します。たとえば、Solaris WBEM Services の主要な機能クラスとして、CIMClass、CIMProperty、CIMInstance が挙げられます。

クラスは、管理対象オブジェクトを作成するために使用される抽象的な概念です。クラスの特性は、そのクラスから作成される子オブジェクト (インスタンス) によって継承されます。たとえば、CIMClass を使用してインスタンス CIMClass (Solaris_Computer_System) を作成できます。

この CIMClass インスタンスは、「そのコンピュータシステムは何か」という質問に答えます。インスタンスの値は、Solaris_Computer_System です。同じクラスタイプのインスタンスはすべて、同じクラステンプレートから作成されます。この例では、CIMClass が、タイプ Computer_System の管理対象オブジェクトを作成するテンプレートを提供します。

クラスには、静的クラスと動的クラスがあります。静的クラスのインスタンスは、CIM Object Manager によって格納され、要求がある場合に CIM Repository から取り出すことができます。動的クラス (システム使用量のような常に変化するデータを含むクラス) のインスタンスは、データの変化に伴いプロバイダアプリケーションによって作成されます。

カスタムクラス: CIM の拡張機能

管理環境に固有の管理対象オブジェクトをサポートするために、CIM の拡張機能としてカスタムクラスを開発できます。CIM Object Manager API は、Solaris オペレーティング環境向けに CIM を拡張する新しいクラスを提供します。

プロパティ

プロパティは、クラスの特性を定義し、Schemaname_classname.propertyname として階層的に示されます。たとえば、CIMProperty クラスを使用して、キーを特定の CIM クラスのプロパティとして定義できます。プロパティの値は、文字列、またはプロパティ範囲のベクトルとして CIM Object Manager から渡すことができます。各プロパティは、固有の名前と 1 つのドメイン (そのプロパティを所有するクラス) を持ちます。一定のクラスのプロパティは、そのサブクラスのプロパティによってオーバーライドすることができます。

プロパティには、CIMClass のプロパティである CIMProperty などがあります。

メソッド

プロパティと同様に、メソッドはそれらを所有するクラスに属します。メソッドは、一定のクラスのオブジェクトが実行するアクションです。たとえば、メソッド public String getName() は、インスタンスの名前を、そのキーとキーの値を連続した値として返します。これらのアクションは、集合的にクラスの動作を表現します。メソッドは、そのメソッドを所有するクラスにしか属すことができません。1 つのクラスのコンテキスト内では、各メソッドは固有の名前を持つ必要があります。一定のクラスのメソッドは、そのサブクラスのメソッドによってオーバーライドすることができます。

新しいクラスはスーパークラスからメソッドの定義を継承しますが、スーパークラスの実装は継承しません。修飾子によって示されるメソッドの定義は、実装される新しいメソッドを提供できるプレースホルダとしての役割を果たします。CIM Object Manager は、ツリー内で下位レベルクラスからルートクラスの方向にメソッドを順に検査し、メソッドを示す修飾子型を検索します。

ドメイン

プロパティおよびメソッドは、クラス内で宣言されます。プロパティまたはメソッドを所有するクラスは、プロパティまたはメソッドのドメインと呼ばれます。

修飾子とフレーバ

CIM 修飾子は、CIM のクラス、プロパティ、メソッド、およびパラメータの特性を示すために使用されます。修飾子は、新しいクラスによって継承される固有の属性 (名前、型、値など) を持ちます。

インジケーション

インジケーション (オブジェクトとクラスのタイプ) は、イベント発生の結果として作成され、タイプ階層で示されます。インジケーションは、プロパティ、メソッド、およびトリガーを持つことができます。トリガーは、既存のクラスに対する変更や、新しいインジケーションインスタンスの作成を引き起こすイベントなどのシステムオペレーションです。

関連

関連は、2 つ以上のクラス間の関係を表現するクラスです。関連を使用すると、一定のクラスに複数の関連インスタンスを作成し、システムコンポーネントをさまざまな方法で関連付けることができます。関連は、システムコンポーネントの関係を表現する手段を提供します。

関連の定義方法のおかげで、関係するどのクラスにも影響を与えずにクラス間の関係を構築できます。関連を追加しても、関係するクラスのインタフェースには影響しません。関連だけが、参照を含むことができます。

参照と範囲

参照はプロパティの一種で、関連に関係するオブジェクトの役割を定義します。参照は、関連におけるクラスの役割名を指定します。参照のドメインは、関連です。参照の範囲は、参照の種類を示す文字列で表されます。

オーバーライド

オーバーライド関係は、スーパークラスから継承されたプロパティまたはメソッドを、サブクラスから継承されたプロパティまたはメソッドで置換することを示すために使用されます。CIM では、プロパティとメソッドのどの修飾子がオーバーライドできるかをガイドラインで定めています。たとえば、CIM ガイドラインはキープロパティはオーバーライドできないと定めているため、クラスの修飾子型がキーと設定される場合、キーをオーバーライドできません。

コアモデルの概念

次の節では、CIM のコアモデルについて説明しています。

システムとしてのコアモデル

コアモデルでは、システムとそれらの機能が管理対象オブジェクトとして記述されるアプリケーションを開発するために使用できるクラスと関連を提供します。これらのクラスと関連は、システムを構成するすべての要素 (物理的な要素および論理的な要素) に固有の特性を与えています。物理的な特性とは、空間を占有し、物理的な基本原則に従う性質を意味します。論理的な特性とは、物理的な環境面 (システム状態やシステムの能力など) を管理、調整するために使用される抽象概念を意味します。

コアモデルには次の論理要素が存在します。

表 A-1 コアモデルの要素

要素名	説明
システム	ほかの論理要素をグループ化したもの。システムはそれ自体が論理要素であるため、ほかのシステムのコンポーネントとなり得る
ネットワークコンポーネント	ネットワークの接続形態を提供するクラス
サービスとアクセスポイント	システム機能にアクセスできる構造を構成するための機構を提供する
デバイス	ハードウェアエンティティの抽象概念またはエミュレーション。デバイスは、実際のハードウェアとしての形をとらないこともある

次の節では、システムの特性をエミュレートするためにコアモデルに提供されているクラスと関連について説明します。

コアモデルが提供するシステムクラス

次の表は、システムとしてのコアスキーマを表すクラスを示しています。これらのクラスのインスタンスは、通常、そのクラスに含まれるオブジェクトの下位に属します。

表 A-2 コアモデルのシステムクラス

クラス名	説明	例
Managed System Element	システム要素階層の基底クラス。識別可能なシステムコンポーネントはすべて、このクラスに含めることができる	ファイルやデバイス (ディスクドライブやコントローラなど) のようなソフトウェアコンポーネント、およびチップやカードのような物理的なコンポーネント
Logical Element	抽象的なシステムコンポーネントを表すすべてのシステムコンポーネントの基底クラス	論理デバイスの形をしたプロファイル、プロセス、またはシステム機能
System	一連の管理対象システム要素の集合である論理要素。この集合は、機能的に一体として動作する。System のすべてのサブクラスには、インスタンスの集合が必要な Managed System Element クラスの明確なリストが存在する	LAN、WAN、サブネット、イントラネット
Service	デバイスまたはソフトウェア機能 (あるいはこの両方) によって提供される機能の記述と管理に必要な情報を含む論理要素。Service は、機能の実装を設定、管理する多目的オブジェクトである。Service 自体は機能ではない	プリンタ、モデム、ファックスマシン

コアモデルが提供するシステム関連

関連は、ほかのクラスによって共有される関係を定義するクラスです。関連クラスには、そのクラスの目的を示す ASSOCIATION 修飾子が付けられます。関連クラスは、2 つ以上の参照 (特定の関係を共有するクラスの名前) を持つ必要があります。関連のインスタンスは、常に関連クラスに属します。

関連には、次のような形式があります。

• 1 対 1

• 1 対多

• 1 対ゼロ

• 集約 (システムとそのコンポーネント間の包含関係など)

関連は、システムとそのコンポーネントである管理対象要素との間の関係を表現します。クラス間の関係の定義には、一般的な 2 種類の関連が使用されます。

CIM スキーマは、次に示す基本的な 2 種類の関連を定義します。

• コンポーネント関連 - あるクラスが別のクラスの一部であることを示す

• 依存関連 - あるクラスが別のクラスなしには機能することも、存在することも不可能であることを示す

これらの関連タイプは抽象型です。つまり、関連クラスは、インスタンスを単独では所有しません。インスタンスはその下位クラスのうちの 1 つに属す必要があります。

コンポーネント関連

コンポーネント関連は、システムのコンポーネントとシステム自体の関係を表します。コンポーネント関連は、どの要素がシステムを構成するかを示します。コンポーネント関連を表す abstract クラスは、下位クラスにこのタイプの具体的な関連を作成するために使用されます。下位の具体的な関連は、「コンポーネント (クラス) が、ほかのコンポーネントとどのような構成関係にあるか」を表します。

コンポーネント関連は、その特有の役割として、システムと、システムの論理的なコンポーネントおよび物理的なコンポーネント間の関係を表します。

依存関連

依存関連は、互いに依存し合うオブジェクト間の関係を確立します。コアモデルは、次の依存関係を提供します。

• 機能的-依存オブジェクトは、依存対象であるオブジェクトなしでは機能できない

• 存在 - 依存オブジェクトは、依存対象であるオブジェクトなしでは存在できない

コアモデルには、次の依存関係があります。

表 A-3 Core Model の依存関係

依存関連	説明
HostedService	サービスとその機能が存在するシステム間の関連。この関連の多重度は、1 対多である。1 つのシステムは、多くのサービスを管理できるため、サービスは、それらを管理しているシステムに強く依存している。  一般に、サービスは、そのサービスを実装する論理デバイスまたはソフトウェア機能が入ったシステム上で管理されるので、このモデルでは、複数のシステムに渡って管理されるサービスは表されない。この場合システムは、単一のホストにそれぞれ置かれているサービスの集合ポイントの役割を果たすアプリケーションシステムとしてモデル化される
HostedAccessPoint	サービスアクセスポイント (SAP) と SAP 上で提供されているシステム間の関連。この関連の多重度は 1 対多であり、システムに強く依存している。各システムは多数の SAP を管理できる。  このモデルの特徴は、サービスアクセスポイントを、サービスがアクセスできるシステムと同じホストに置くことも別のホストに置くこともできることである。このため、このモデルは分散システム (コンポーネントサービスが複数のホストに置かれるアプリケーションシステム) と分散アクセス (アクセスポイントがほかのシステム上で管理されるサービス) の両方を表すことができる
ServiceSAPDependency	サービスとサービスアクセスポイント間の関連。この関連は、サービスがその機能を提供するためには参照されている SAP が必要であることを示す
SAPSAPDependency	2 つの SAP 間の関連のある SAP がそのサービスを利用またはそのサービスに接続するためには別の SAP が必要であることを示す。
ServiceAccessBySAP	サービスのアクセスポイントを識別する関連。たとえば、プリンタは、複数のシステム上で管理される Netware、Apple Macintosh、または Windows のサービスアクセスポイントによってアクセスされる可能性がある

コアモデルの拡張例

コアモデルから、多数の拡張機能を開発できます。たとえば、Managed System Element クラスの抽象化した Managed Element クラスを追加できます。コアモデルには、この Managed Element クラスの下位クラス (ユーザーや管理者など、管理対象のシステムドメインに含まれないオブジェクトを表現するクラス) を追加できます。

共通モデルスキーマ

共通モデルスキーマは、以下のようなモデルを提供します。

システムモデル

システムモデルは、管理対象の環境を構成する最上位レベルのシステムオブジェクトであるコンピュータ、アプリケーション、およびネットワークシステムを表しています。

デバイスモデル

デバイスモデルは、システムの基本機能 (ストレージ、処理、通信、入出力など) を提供しているシステム上の個々の論理ユニットを表します。システムデバイスはシステムの物理的なコンポーネントそのものと考えがちですが、これは誤りです。これは、管理されるのは実際のコンポーネント自体ではなく、オペレーティングシステム上でのデバイスの記述であるためです。

オペレーティングシステムの記述は、システムの実際のコンポーネントと 1 対 1 では対応していません。たとえば、モデムは個々の実際のコンポーネントに対応できます。モデムは、LAN アダプタとモデムをサポートする多機能カードによって提供することも、システム上で動作する通常のプロセスによって提供することもできます。このモデルを使用または拡張するためには、論理的なデバイスと物理的なコンポーネント間の違いを混同することなく理解することが必要です。

アプリケーション管理モデル

CIM アプリケーション管理モデルは、ソフトウェア製品とアプリケーションの管理に通常必要な情報を詳細に記述した情報モデルです。このモデルは、スタンドアロンのデスクトップアプリケーションから、高性能、マルチプラットフォーム、分散型、インターネットベースのアプリケーションなど、多様なアプリケーション構造に使用できます。このモデルは、単一のソフトウェア製品を記述するのにも、ビジネスシステムを形成している相互に依存した複数のアプリケーションを記述するのにも使用できます。

このアプリケーションモデルの主要な特性の 1 つに、アプリケーションのライフサイクルという考えがあります。アプリケーションは、配付可能、インストール可能、実行可能、実行中のいずれかの状態にあります。各種のオブジェクトの解釈と特性は、アプリケーションをある状態から別の状態に変換するために使用される機構と多くの場合関連づけられて、アプリケーションを記述しています。

ネットワークモデル

ネットワークモデルは、ネットワークトポロジ、ネットワークの接続性、ネットワークアクセスの制御と提供に必要な各種のプロトコルとサービスなど、ネットワーク環境のさまざまな側面を表現します。

物理モデル

物理モデルは、実際の物理的な環境を表します。管理される環境のほとんどは、論理オブジェクト (実際のオブジェクトではなく環境の情報面を記述するオブジェクト) で表されます。システム管理のほとんどは、システム状態を表現、制御する情報の操作に関係しています。実際の物理的な環境に対する操作 (物理ドライブの読み取りヘッドの移動やファンの起動など) はすべて、通常、論理的な環境の操作による間接的な結果として発生するにすぎません。そのため、物理的な環境は一般に直接的な重要性はありません。

一般にシステムの物理的な各部には、計測機構は付けられていません。それらの現在の状態 (およびそれらの存在そのもの) は、システムについてのほかの情報から間接的に推測できるだけです。CIM では、物理モデルは環境のこの側面を表します。このモデルは、システムごとに大きく異なり、また技術の進展に伴い劇的に変化すると考えられます。また、管理環境の物理的な側面についての情報提供を具体的な目的として、アプリケーション、ツール、および環境を個別に使用するために、物理的な環境を追跡、計測することは、常に困難を極めると予測されます。