Use > Configuration Management > Configuration Management overview > Configuration Item Relationship Types

Configuration Item Relationship Types

Relationship type Description
Aggregation The "Aggregation" relationship describes a whole-part structured relationship between two elements that does NOT include any impact or dependency.
ClientServer This Relationship represents a Client-Server dependency between, for example, two RunningSoftware instances.
Composition The "Composition" relationship represents a strictly structured relationship, which means that the composite (part) is part of the lifecycle of the whole and that someone would percieve the "whole" as a different thing when a part is taken away.
Connection The "Connection" relationship type represents a (potentially) undirected relationship between two elements that does not represent any kind of structure or dependency. Both participating elements have an independent lifecycle. There is no status propagation or health impact between connected elements.
Containment The "Containment" relationship describes the case where containee is contained in a container. The key aspect of this relationship is the notion of exclusivity. This means that container is the sole user of the contained object and other objects are not allowed to use the containee.
Dependency The "Dependency" relationship describes the logical dependency of one element on another. A dependency is a semantic relationship where a change to the influent or independent element may affect the semantics of the dependent modeling element.
ExecutionEnvironment The "ExecutionEnvironment" is a kind of dependency relation where an instance of the end1 class runs in an instance of the end2 class and therefore depends on the end2 instance. Example: "A J2eeApplication isRunBy a J2eeServer" and a "J2eeServer runs a J2eeApplication"
ManagedRelationship PSEUDO-RELATIONSHIP. DO NOT USE! This relationship type is provided solely to establish the attribute inheritance down to the core relationship types (Dependency, Composition, etc). Class relationships should not be based off of this type.
Membership The "Membership" relationship describes a non-structural relationship between two elements (called member and group). Examples: A NodeGroup contains Nodes. NodeGroup A may contain all nodes of DNS domain "*.deu.hp.com". Another NodeGroup B may contain all nodes with Windows operating system. A specific node may be member of both groups.
Ownership The "Ownership" relationship is a connection that expresses that an instance of the end1 class owns an instance of the end2 class. Ownership is distinguished from Responsibility, in that ownership means 'accountability'. E.g. A person owns a project (is accountable for driving the project) or a person owns the incident/problem (is accountable for its resolution).
Realization An instance of the end1 class realizes an instance of the end2 class. Realization is has a stronger connotation than just "dependency" from which is a specialization. Often the user sees the two entities as not being different on the first glance.Example: A filesystem is an exported filesystem
Responsibility The "Responsibility" relationship is a connection that expresses that an instance of the end1 class isResponsibleFor an instance of the end2 class. Responsibility is distinguished from Ownership in that it is NOT about "accountability", but rather "assignment". E.g. A person may 'own' a project, or a person may be 'responsible' for a project.
TimeBoundConnection Assets are connected to Contracts: a Contract may mention and involve zero or more Assets. An Asset may be mentioned in zero or more Contracts. This RelationshipType permits attributes such as contract start and end date to be attached to the relationship, which is necessary because the contract may involve different assets at different times.
Usage The "Usage" relationship is a kind of "Dependency" where one element uses (and thus depends on) another element.

Send Help Center feedback