System Associations Provided by the Core Model

Associations are classes that define the relationships shared by other classes. Association classes are flagged with an ASSOCIATION qualifer that denotes the purpose of the class. An association class must have at least two references, the names of the classes that share a particular relationship. Instances of an association always belong to the association class.

Associations can have the following types of relationships:

• One to one

• One to many

• One to zero

• Aggregation, such as a containment relationship between a system and its parts

Associations express the relationship between a system and the managed elements that make up the system. Two broad types of associations are used to define the relationships between classes:

The CIM Schema defines two basic types of associations:

• Component associations, which indicate that one class is part of another

• Dependency associations, which indicate that a class cannot function or exist without another class

These association types are abstract, which means that association classes do not have instances alone. Instances must belong to one of their descendent classes.

Component Associations

Component associations express the relationship between the parts of a system and the system itself. Component associations describe what elements make up a system. Abstract classes that express component associations are used to create concrete associations of this type in descendent classes. The descendent concrete associations answer the question: "What composition relationships does the component, or class, have with other components?"

In its most specialized role, the component association expresses the relationship between a system and its logical and physical parts.

Dependency Associations

Dependency associations establish the relationships between objects that rely on one another. The Core Model provides for the following types of dependencies:

• Functional—the dependent object cannot function without the object on which it depends

• Existence—the dependent object cannot exist without the object on which it depends

The following types of dependencies are included in the Core Model.

Table A–3 Core Model Dependencies

Dependency Association	Description
HostedService	An association between a Service and the System on which the functionality resides. The cardinality of this association is one-to-many. A System may host many Services. Services are weak with respect to their hosting System. Generally speaking, a Service is hosted on the System where the LogicalDevices or SoftwareFeatures that implement the Service are located. The model does not represent Services hosted across multiple systems. This is modeled as an ApplicationSystem that acts as an aggregation point for Services that are each located on a single host.
HostedAccessPoint	An association between a ServiceAccessPoint (SAP) and the System on which it is provided. The cardinality of this association is one-to-many and is weak with respect to the System. Each System may host many SAPs. A feature of the model is that the access point of a service can be located on the same or a different host from the system to which the service provides access. This allows the model to depict both distributed systems (an ApplicationSystem with component Service on multiple hosts) and distributed access (a Service with access points hosted on other systems).
ServiceSAPDependency	An association between a Service and a ServiceAccessPoint indicating that the referenced SAP is required for the Service to provide its functionality.
SAPSAPDependency	An association between a SAP and another SAP indicating that the latter is required in order for the former to utilize or connect with its Service.
ServiceAccessBySAP	An association that identifies the access points for a Service. For example, a printer may be accessed by Netware, Apple Macintosh, or Windows ServiceAccessPoints, potentially hosted on different Systems.