次の節では、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 クラスは、下位クラスにこのタイプの具体的な関連を作成するために使用されます。下位の具体的な関連は、「コンポーネント (クラス) が、ほかのコンポーネントとどのような構成関係にあるか」という疑問に答えます。
コンポーネント関連は、その特有の役割として、システムと、システムの論理的なコンポーネントおよび物理的なコンポーネント間の関係を表します。
依存関連は、互いに依存し合うオブジェクト間の関係を確立します。コアモデルは、次の依存関係を提供します。
機能的-依存オブジェクトは、依存対象であるオブジェクトなしでは機能できない
存在 - 依存オブジェクトは、依存対象であるオブジェクトなしでは存在できない
依存関連 |
説明 |
HostedService |
サービスとその機能が存在するシステム間の関連。この関連の多重度は、1 対多である。1 つのシステムは、多くのサービスを管理できるためサービスは、それらを管理しているシステムに強く依存している。一般に、サービスは、そのサービスを実装する論理デバイスまたはソフトウェア機能が入ったシステム上で管理される。このモデルでは、複数のシステムに渡って管理されるサービスは表されない。これは、単一のホストにそれぞれ置かれているサービスの集合ポイントの役割を果たすアプリケーションシステムとしてモデル化される |
HostedAccessPoint |
サービスアクセスポイント (SAP) と SAP 上で提供されているシステム間の関連。この関連の多重度は 1 対多であり、システムに強く依存している。各システムは多数の SAP を管理できる。このモデルの特徴は、サービスアクセスポイントを、サービスがアクセスできるシステムと同じホストに置くことも別のホストに置くこともできることである。このため、このモデルは分散システム (コンポーネントサービスが複数のホストに置かれるアプリケーションシステム) と分散アクセス (アクセスポイントがほかのシステム上で管理されるサービス) の両方を表すことができる |
ServiceSAPDependency |
サービスとサービスアクセスポイント間の関連。この関連は、サービスがその機能を提供するためには参照されている SAP が必要であることを示す |
SAPSAPDependency |
ある SAP がそのサービスを利用またはそのサービスに接続するためには別の SAP が必要であることを示す、2 つの SAP 間の関連 |
ServiceAccessBySAP |
サービスのアクセスポイントを識別する関連。たとえば、プリンタは、複数のシステム上で管理される Netware、Apple Macintosh、または Windows のサービスアクセスポイントによってアクセスされる可能性がある |
コアモデルから、多数の拡張機能を開発できます。たとえば、Managed System Element クラスの抽象化した Managed Element クラスを追加できます。コアモデルには、この Managed Element クラスの下位クラス (ユーザーや管理者など、管理対象のシステムドメインに含まれないオブジェクトを表現するクラス) を追加できます。