PhysicalResource

PhysicalResource : public abstract class

Created:	3/12/2005 12:00:00 AM
Modified:	7/30/2007 10:23:26 AM

Project:
Author:	AutoMagic KB LLC
Version:	6.2
Phase:	SID
Status:	Approved
Complexity:	Easy
Advanced:
UUID:	{43BCA197-B79F-4251-8104-5179DED52F9A}
Appears In:	ManagedEntity Generalization Tree, Resource Generalization Tree, Figure Pr.02 - Product, Service, Resource Domain Relationships, Product-Service-Resource Relationships, Service Class Diagram, Service-PhysicalResource Interaction, Service-Resource-Product Summary, Simplified Service Class Diagram, Fig 4SO-06 - High Level Product-Service-Resource, Fig 4SO-17 - PhysicalRoles, Resource and Role Summary, Resource-Service-PartyRole, ResourceSpec-Resource-ResourceRole, Fig 5LR-05 - Resource split, Fig 5LR-07 - Resource - Product, Fig 5LR-09 - Product - Resource - Service, Fig 5LR-13 - Resources and ResourceSpecification Overview, Fig 5LR-32 - CompoundResource Model, Fig 5LR-33 - CompoundResource Instance Example, Fig 5LR-45 - ResourcePort Detail, Fig 5LR-51 - Resource-ResourceRoles, Fig 5LR-75 - ResourceSpecXXXX Biz Model, Fig 5LR-87 - LogicalResourceSpec Detailed Biz Model, Fig 5LR-88 - ResourceCharacteristic Biz Model, Fig 5LR-74- LogicalResourceSpec Biz Model, Fig 5LR-61 - CompoundResource Biz Model, Fig 5LR-77 - LRSpec Subclasses Biz Model, Fig 5LR-78 - LRSpecChar Biz Model, Logical Resource Role Summary, Fig 5PR-05 , Fig 5PR-11 - PhysicalResourceSpec, Fig 5PR-12 - PhysicalDevice, Fig 5PR-13 - Hardware, Fig 5PR-18 - PhysicalDeviceRole and HardwareRole, Fig 5PR-31 - Location, Fig 5PR-36 - PhysicalResourceSpec Biz Model, Fig 5PR-37 - PhysicalResourceRole, Fig 5PR-38 - Holder Role, Fig 5PR-39 - Hardware Biz Model, Fig 5PR-42 - PhysicalDevice Biz Model, Fig 5PR-43 - PhysicalConnector Biz Model, PhysicalCapacity Summary, PhysicalDeviceRoleSummary, Router, Fig 5PR-06, Fig 5PR-07, Fig 5PR-08, Resource Trouble Info, Root Business Entities, AMKB-BusinessInteraction, fig4, fig5, fig7, fig8, fig11d, fig15, Trouble Ticket Detail, Trouble Ticket, Fig 35 - DEN-ng Location, Fig 37 - Resource Overview, Fig 38 - Contracts and Resources, Fig 39 - Service Overview, Fig 40 - Contracts and Services, Fig 41 - Contracts and Products-Resources-Services

Copyright TM Forum 2005 This is an abstract base class for describing different types of hardware that constitute a Product. It has two main purposes: (1) to collect common attributes and relationships for all hardware, and (2) to provide a convenient, single point where relationships with other managed objects can be defined. The HasWarrantyInfo association (not shown) describes warranty information of hardware.

Attributes
Associations To
Associations From
Other Links

Attribute

Details

public String
manufactureDate

Notes:

This is a string attribute that defines the date of manufacture of this item in the fixed format "dd/mm/yyyy". This is an optional attribute.

public String
otherIdentifier

Notes:

This is a string that is used to contain other important identifying data, such as a bar code, of the hardware item. This is an optional attribute.

public Integer
powerState

Notes:

This is an enumerated integer that defines the current power status of the hardware item. Values include: 0: Unknown 1: Not Applicable 2: No Power Applied 3: Full Power Applied 4: Power Save - Normal 5: Power Save - Degraded 6: Power Save - Standby 7: Power Save - Critical 8: Power Save - Low Power Mode 9: Power Save - Unknown 10: Power Cycle 11: Power Warning 12: Power Off Value 1 means that the hardware item doesn't require the direct application of power (e.g., a but or bolt). If the value for this item is 3, then the PowerCapability class will describe the particular power requirements of this item through the HasPower association. This is an optional attribute.

public String
serialNumber

Notes:

This is a string that represents a manufacturer-allocated number used to identify different instances of the same hardware item. The ModelNumber and PartNumber attributes are used to identify different types of hardware items. This is a REQUIRED attribute.

public String
versionNumber

Notes:

This is a string that identifies the version of this object. This is an optional attribute.

Element	Source Role	Target Role	Details
Location Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This association defines the Location(s) that a particular PhysicalResource can be found at. Note that there can be multiple Locations assigned for a particular PhysicalResource. For example, a Router can be installed in a POSITION in a Rack, which is in a particular PLACE (e.g., a Room in a Floor) which is in a particular STRUCTURE (e.g., a building) at a particular ADDRESS (e.g., the postal address that the main building is located at).<br/></p><p> <br/></p><p>These four concepts (which are all in CAPS) are the four main subclasses of Location. More precise relationships can be made between the appropriate subclasses of PhysicalResource and the appropriate subclasses of Location. Please see the DEN-ng Location model for more information.<br/></p><p><br/></p><p>Note that this relationship is semantically different than the LogicalResourceLocatedAt association. This is because PhysicalResources are tangible objects that have different types of locations, whereas LogicalResources are intangible objects that are hosted by, or contained within, a PhysicalResource.<br/></p><p><br/></p><p>The semantics of this association are represented by the PhysicalResourceLocationDetails association class.<br/></p>
Network Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This aggregation defines the set of PhysicalResources that make up this Network.<br/></p>
ReplacementSet Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This aggregation defines the set of PhysicalResources that must be replaced as a set.<br/></p>
ResourceFacingService Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This aggregation defines the set of PhysicalResources that are required for this particular ResourceFacingService to function correctly. This includes as a minimum the set of PhysicalResources that are required to host this particular ResourceFacingService.<br/></p><p><br/></p><p>The PhysicalResourcesHostRFS aggregation describes a hosting relationship, which is essentially passive in nature - the PhysicalResource exists so that the LogicalResource can be hosted on it.<br/></p><p><br/></p><p>The cardinality of the LogicalResourcesImplementRFS and PhysicalResourcesHostRFS aggregations are both 0..1 on the aggregate side, because PhysicalResources can be installed which use LogicalResources before a ResourceFacingService is actually implemented. However, a ResourceFacingService must have at least one PhysicalResource and one LogicalResource for it to be instantiated. Hence, both of the aggregations have a 1..n cardinality on their component ends.<br/></p>
Product Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>No documentation available<br/></p>

Element	Source Role	Target Role	Details
Representation Class	Name: uniqueRepresentation	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>No documentation available<br/></p>
Place Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>No documentation available<br/></p>
PhysicalResourceRole Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This aggregation defines the set of logical roles that are used to describe an instance of a particular PhysicalResource.<br/></p><p><br/></p><p>The difference between this aggregation and the SpecifiesPhysicalResourceRoles aggregation is that this aggregation enables instances of a PhysicalResource to be described using PhysicalResourceRoles. In contrast, the SpecifiesPhysicalResourceRoles aggregation defines functionality of a PhysicalResource using PhysicalResourceRoles.<br/></p><p><br/></p><p>Please see the DEN-ng Resource model for more details.<br/></p>
LocalPlace Class	Name:	Name: holder	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>No documentation available<br/></p>
PhysicalResourceCharacteristic Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This composition defines the set of PhysicalResourceCharacteristics that are used to distinguish this PhysicalResource from other PhysicalResources.<br/></p>
LogicalResource Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This association represents the binding between a PhysicalResource and a LogicalResource. The semantics of this binding are represented by the LogicalPhysicalResource associationClass.<br/></p><p><br/></p><p>This association defines the set of LogicalResources that a particular PhysicalResource supports.<br/></p><p><br/></p><p>Please see the DEN-ng Resource model for more details.<br/></p>

Object	Type	Connection	Notes
Hardware	Class	Tree
PhysicalLink	Class	Generalization
PhysicalDevice	Class	Tree
Representation	Class	Weak	Copyright TM Forum 2005 No documentation available
PhysicalResourceRole	Class	Class	Copyright TM Forum 2005 This aggregation defines the set of logical roles that are used to describe an instance of a particular PhysicalResource. The difference between this aggregation and the SpecifiesPhysicalResourceRoles aggregation is that this aggregation enables instances of a PhysicalResource to be described using PhysicalResourceRoles. In contrast, the SpecifiesPhysicalResourceRoles aggregation defines functionality of a PhysicalResource using PhysicalResourceRoles. Please see the DEN-ng Resource model for more details.
LocalPlace	Class	Weak	Copyright TM Forum 2005 No documentation available
PhysicalResourceCharacteristic	Class	Strong	Copyright TM Forum 2005 This composition defines the set of PhysicalResourceCharacteristics that are used to distinguish this PhysicalResource from other PhysicalResources.
Location	Class	Class	Copyright TM Forum 2005 This association defines the Location(s) that a particular PhysicalResource can be found at. Note that there can be multiple Locations assigned for a particular PhysicalResource. For example, a Router can be installed in a POSITION in a Rack, which is in a particular PLACE (e.g., a Room in a Floor) which is in a particular STRUCTURE (e.g., a building) at a particular ADDRESS (e.g., the postal address that the main building is located at). These four concepts (which are all in CAPS) are the four main subclasses of Location. More precise relationships can be made between the appropriate subclasses of PhysicalResource and the appropriate subclasses of Location. Please see the DEN-ng Location model for more information. Note that this relationship is semantically different than the LogicalResourceLocatedAt association. This is because PhysicalResources are tangible objects that have different types of locations, whereas LogicalResources are intangible objects that are hosted by, or contained within, a PhysicalResource. The semantics of this association are represented by the PhysicalResourceLocationDetails association class.
Network	Class	Weak	Copyright TM Forum 2005 This aggregation defines the set of PhysicalResources that make up this Network.
ReplacementSet	Class	Weak	Copyright TM Forum 2005 This aggregation defines the set of PhysicalResources that must be replaced as a set.
LogicalResource	Class	Class	Copyright TM Forum 2005 This association represents the binding between a PhysicalResource and a LogicalResource. The semantics of this binding are represented by the LogicalPhysicalResource associationClass. This association defines the set of LogicalResources that a particular PhysicalResource supports. Please see the DEN-ng Resource model for more details.
Resource	Class	Tree
ResourceFacingService	Class	Class	Copyright TM Forum 2005 This aggregation defines the set of PhysicalResources that are required for this particular ResourceFacingService to function correctly. This includes as a minimum the set of PhysicalResources that are required to host this particular ResourceFacingService. The PhysicalResourcesHostRFS aggregation describes a hosting relationship, which is essentially passive in nature - the PhysicalResource exists so that the LogicalResource can be hosted on it. The cardinality of the LogicalResourcesImplementRFS and PhysicalResourcesHostRFS aggregations are both 0..1 on the aggregate side, because PhysicalResources can be installed which use LogicalResources before a ResourceFacingService is actually implemented. However, a ResourceFacingService must have at least one PhysicalResource and one LogicalResource for it to be instantiated. Hence, both of the aggregations have a 1..n cardinality on their component ends.
Product	Class	Weak	Copyright TM Forum 2005 No documentation available