Core Model Concepts

The following sections provide descriptive information about the Core Model of CIM.

System Aspects of the Core Model

The Core Model provides classes and associations you can use to develop applications in which systems and their functions are represented as managed objects. These classes and associations embody the characteristics unique to all elements that comprise a system: physical and logical elements. Physical characteristics refer to the qualities of occupying space and conforming to the elementary laws of physics. Logical characteristics represent abstractions used to manage and coordinate aspects of the physical environment, such as system state or the capabilities of a system.

In the Core Model, logical elements can include the following.

Table A-1 Core Model Elements

Element Name	Description
Systems	A grouping of other logical elements. Because systems are themselves logical elements, a system can be composed of other systems.
Network Components	Classes that provide a topological view of a network.
Services and Access Points	Provide a mechanism for organizing the structures that provide access to the capabilities of a system.
Devices	An abstraction or emulation of a hardware entity, that may or may not be realized in physical hardware.

The following sections describe the classes and associations provided by the Core Model to emulate the qualities of systems.

System Classes Provided by the Core Model

The following table lists the classes that represent system aspects of the Core schema. The instances of these classes will most often belong to the descendents of the objects contained within the class.

Table A-2 Core Model System Classes

Class Name	Description	Example
Managed System Element	Base class for the system element hierarchy. Any distinguishable component of a system is a candidate for inclusion in this class.	Software components, such as files; and devices, such as disk drives and controllers, and physical components, such as chips and cards.
Logical Element	Base class for all the components of the system that represent abstract system components	Profiles, processes, or system capabilities in the form of logical devices.
System	Logical Element that aggregates an enumerable set of ManagedSystemElements. The aggregation operates as a functional whole. Within any particular subclass of System, there is a well-defined list of Managed System Element classes, whose instances must be aggregated.	Local Area Network, Wide Area Network, subnet, intranet
Service	Logical Element that contains the information necessary to represent and manage the functionality provided by a Device and/or SoftwareFeature. A Service is a general-purpose object to configure and manage the implementation of functionality. It is not the functionality itself.	Printer, modem, fax machine

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.

Example of an Extension into the Core Model

It is possible to develop many extensions into the Core Model. One possible extension includes the addition of a Managed Element class as an abstraction of the Managed System Element class. Descendents of this Managed Element class--classes that represent objects outside the managed system domain, such as Users or Administrators--may be added to the Core Model.