Resource

Resource : public abstract class

Created:	3/12/2005 12:00:00 AM
Modified:	7/30/2007 12:30:04 PM

Project:
Author:	AutoMagic KB LLC
Version:	6.2
Phase:	SID
Status:	Approved
Complexity:	Easy
Advanced:
UUID:	{CF779184-EB9F-44f0-8807-35E093C700BA}
Appears In:	ManagedEntity Generalization Tree, Resource Generalization Tree, Protocol Generalization Tree, DeviceInterface Generalization Tree, Figure Pr.02 - Product, Service, Resource Domain Relationships, Product-Service-Resource Relationships, Figure C.09 - Resource/Service Usage, Service Class Diagram, Service-PhysicalResource Interaction, Service-Resource-Product Summary, Simplified Service Class Diagram, Fig 4SO-06 - High Level Product-Service-Resource, Fig 4SO-07, Fig 4SO-08 - ServiceSpec, Fig 4SO-31 - PartyRole - Service Interaction, 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-19 - LogicalResourceRole, Fig 5LR-20 - PartyRole-ResourceRole, Fig 5LR-21 - ResourceSpec and ResourceSpecChar, Fig 5LR-22 - ResourceSpecCharValue, Fig 5LR-23 - Software, Fig 5LR-32 - CompoundResource Model, Fig 5LR-33 - CompoundResource Instance Example, Fig 5LR-45 - ResourcePort Detail, Fig 5LR-51 - Resource-ResourceRoles, Fig 5LR-56 - PartyRole-LogicalResource, 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-41 - Mapping network AccessDomain to the SID, Fig 5LR-62 - Resource Role 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-30 - Own and Administer Resources, Fig 5PR-36 - PhysicalResourceSpec Biz Model, Fig 5PR-37 - PhysicalResourceRole, PhysicalDeviceRoleSummary, Router, Figure RO.01 - Resource Order Entities, Resource Trouble Info, Figure A.6 - Agreement Item Inherited Associations with Product, Service, and Resource, Fig 1P-30 - Policy Management Overview, Root Business Entities, AMKB-BusinessInteraction, Business Interaction Business Entities, Fig BI.09 - Business Interaction Items Association with Product, Service, and Resource Domain Entities, Fig BI.08 - Relationship Between Business Interaction and Product Domain Entities, Trouble Ticket Detail, Trouble Ticket, Fig 28 - BusinessInteraction Overview, 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, Service Inventory Layout

Copyright TM Forum 2005 This is the abstract base class for all entities that are inherently manageable and make up a Product. They are used to support Services. Examples which are not Manageable include legacy Hubs that don't support any type of management protocol; rather, they must be manually managed. Entities like Policy are of course manageable, but do not make up or are found packaged inside of a Product.

Attributes
Associations To
Associations From
Other Links

Attribute

Details

public Integer
usageState

Notes:

This is an enumerated integer that defines the current usage of the object. It includes the following values: 0: Unknown 1: Not Installed 2: Installed 3: Inactive 4: Idle 5: Active, but able to communicate 6: Busy (Active and unable to communicate) Value 2 means that the object is installed (or otherwise activated) but no other information about its state is available. Values 3-6 imply that the object is Installed, and provide further information as to its state. This is an optional attribute.

Element	Source Role	Target Role	Details
ResourceSpecification Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This aggregation defines the particular ResourceSpecification that is used to provide the invariant characteristics (i.e., attributes, methods, relationships, and constraints) of a given Resource. This enables multiple Resources that each use a common set of attributes, methods, constraints, and/or relationships to be related to a single invariant specification of those characteristics and behavior. This facilitates their updating. <br/></p><p><br/></p><p>The cardinality of the SpecifiesResource aggregation is 1 on the ResourceSpecification side and 0..n on the Resource side. This means that a ResourceSpecification can be written that isn't related to any specific Resources, but if a Resource is built, it must be derived from a ResourceSpecification. Furthermore, this is an aggregation because this is a whole-part relationship: the ResourceSpecification defines the invariant attributes and behavior of zero or more Resources, and each Resource derived from the ResourceSpecification uses all of thee invariant attributes and behavior (and presumably adds its own instance-specific attributes and behavior).<br/></p>
ManagementDomain Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This aggregation defines the set of Resources (Physical and Logical) that are a part of this management domain. <br/></p><p><br/></p><p>From the physical point-of-view, the management domain contains a set of physical devices (and components of those physical devices, whether separate or modeled as a FRU) that are managed and administered by a set of people. Thus, this aggregation defines the particular set of physical resources that are a part of this management domain. <br/></p><p><br/></p><p>From the logical point-of-view, the management domain contains a set of LogicalDevices, LogicalInterfaces, and other important abstractions that can be managed and administered by a set of people. Thus, the aggregation defines the particualr set of logical resources that are a part of this management domain. <br/></p><p><br/></p><p>These semantics enable policies to be defined to manage all or part of the physical resources in this management domain.<br/></p>
ResourceCharacteristicValue Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This association defines the allowed set of values (represented as instances of the ResourceCharacteristicValue object) that a specific Resource can have when that Resource object is instantiated.<br/></p>
CompoundResource Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This aggregation defines the set of PhysicalResources and LogicalResources (and optionally, CompoundResources) that are necessary to create a particular CompoundResource. In the DEN-ng system view, OCL is used to mandate the presence of at least one PhysicalResource and at least one LogicalResource. The aggregation of CompoundResources are optional.<br/></p><p><br/></p><p>A CompoundResource is a composite entity, combining PhysicalResources and LogicalResources (and optionally, CompoundResources) into a single managed entity. In the DEN-ng system view, this is implemented as a set of aggregations - PhysicalResource(s) aggregated into a CompoundResource, LogicalResource(s) aggregated into a CompoundResource, and (optionally) CompoundResource(s) aggregated into a CompoundResource. Each of these aggregations is represented as an instantiation of this aggregation (CompoundResourceAspects).<br/></p><p><br/></p><p>The semantics of this aggregation is represented as an association class, called CompoundResourceAspectDetails. There are three subclasses of this class, which are used to represent the aggregation of PhysicalResources, LogicalResources, and CompoundResources into this particular CompoundResource. These three subclasses are called PhysicalAspectCompoundResourceDetails, LogcalAspectCompoundResourceDetails, and CompoundAspectCompoundResourceDetails, respectively. Thus, the presence of the CompoundResourceAspectDetails class enables a single relationship to be defined, instead of three different relationships.<br/></p>
Service Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>DONOTIMPLEMENT<br/></p><p>This is a conceptual relationship that defines the concept of a Service being supported by multiple Resources. DEN-ng defines this in more detail.<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
ResourceUsage Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>No documentation available<br/></p>
ResourceRole Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This aggregation defines the set of ResourceRoles that this Resource can play.<br/></p>
PartyRole Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>The OwnsResource association defines the set of Resources (PhysicalResources and/or LogicalResources) that a particular PartyRole owns. Note that this is a very different relationship than the AdministersResource association. The OwnsResource association defines the PartyRole that is the owner of the Resource. Here, "owner" is the person or group that is responsible (e.g., organizational, financial, and so forth) for the Resource. Note that the cardinality of the OwnsResource association on the PartyRole side is 1 - this means that a Resource MUST have at least one PartyRole to manage it. Furthermore, the cardinality of this association on the Resource side is 0..n, which ensures that a PartyRole doesn't have to own a Resource.<br/></p>
ValueNetworkRole Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This association defines the set of Resources (physical and/or logical) that a particular Party, playing the role of ValueNetworkRole, administers. From a business perspective, the Owner has to either appoint or give permission to the Administrator to administer the Resource that is owned.<br/></p>
BusinessInteractionItem Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>No documentation available<br/></p>
BusinessContract Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This association defines the set of functions, as specified by a BusinessContract, that apply to this particular Resource. Functions include defining how to build a Resource, how to manage it, how to operate it, how to invoke its functionality, and other related operations.<br/></p>
ResourceCharacteristic Class	Name:	Name:	<p>Copyright TM Forum 2005<br/></p><p><br/></p><p>This aggregation defines the set of characteristics, or distinguishing features, of a particular Resource.<br/></p>

Object	Type	Connection	Notes
ResourceUsage	Class	Weak	Copyright TM Forum 2005 No documentation available
ResourceRole	Class	Weak	Copyright TM Forum 2005 This aggregation defines the set of ResourceRoles that this Resource can play.
PartyRole	Class	Class	Copyright TM Forum 2005 The OwnsResource association defines the set of Resources (PhysicalResources and/or LogicalResources) that a particular PartyRole owns. Note that this is a very different relationship than the AdministersResource association. The OwnsResource association defines the PartyRole that is the owner of the Resource. Here, "owner" is the person or group that is responsible (e.g., organizational, financial, and so forth) for the Resource. Note that the cardinality of the OwnsResource association on the PartyRole side is 1 - this means that a Resource MUST have at least one PartyRole to manage it. Furthermore, the cardinality of this association on the Resource side is 0..n, which ensures that a PartyRole doesn't have to own a Resource.
ValueNetworkRole	Class	Class	Copyright TM Forum 2005 This association defines the set of Resources (physical and/or logical) that a particular Party, playing the role of ValueNetworkRole, administers. From a business perspective, the Owner has to either appoint or give permission to the Administrator to administer the Resource that is owned.
PhysicalResource	Class	Tree
BusinessContract	Class	Class	Copyright TM Forum 2005 This association defines the set of functions, as specified by a BusinessContract, that apply to this particular Resource. Functions include defining how to build a Resource, how to manage it, how to operate it, how to invoke its functionality, and other related operations.
CompoundResource	Class	Tree
LogicalResource	Class	Tree
ResourceSpecification	Class	Weak	Copyright TM Forum 2005 This aggregation defines the particular ResourceSpecification that is used to provide the invariant characteristics (i.e., attributes, methods, relationships, and constraints) of a given Resource. This enables multiple Resources that each use a common set of attributes, methods, constraints, and/or relationships to be related to a single invariant specification of those characteristics and behavior. This facilitates their updating. The cardinality of the SpecifiesResource aggregation is 1 on the ResourceSpecification side and 0..n on the Resource side. This means that a ResourceSpecification can be written that isn't related to any specific Resources, but if a Resource is built, it must be derived from a ResourceSpecification. Furthermore, this is an aggregation because this is a whole-part relationship: the ResourceSpecification defines the invariant attributes and behavior of zero or more Resources, and each Resource derived from the ResourceSpecification uses all of thee invariant attributes and behavior (and presumably adds its own instance-specific attributes and behavior).
ManagedEntity	Class	Tree
ManagementDomain	Class	Weak	Copyright TM Forum 2005 This aggregation defines the set of Resources (Physical and Logical) that are a part of this management domain. From the physical point-of-view, the management domain contains a set of physical devices (and components of those physical devices, whether separate or modeled as a FRU) that are managed and administered by a set of people. Thus, this aggregation defines the particular set of physical resources that are a part of this management domain. From the logical point-of-view, the management domain contains a set of LogicalDevices, LogicalInterfaces, and other important abstractions that can be managed and administered by a set of people. Thus, the aggregation defines the particualr set of logical resources that are a part of this management domain. These semantics enable policies to be defined to manage all or part of the physical resources in this management domain.
CompoundResource	Class	Class	Copyright TM Forum 2005 This aggregation defines the set of PhysicalResources and LogicalResources (and optionally, CompoundResources) that are necessary to create a particular CompoundResource. In the DEN-ng system view, OCL is used to mandate the presence of at least one PhysicalResource and at least one LogicalResource. The aggregation of CompoundResources are optional. A CompoundResource is a composite entity, combining PhysicalResources and LogicalResources (and optionally, CompoundResources) into a single managed entity. In the DEN-ng system view, this is implemented as a set of aggregations - PhysicalResource(s) aggregated into a CompoundResource, LogicalResource(s) aggregated into a CompoundResource, and (optionally) CompoundResource(s) aggregated into a CompoundResource. Each of these aggregations is represented as an instantiation of this aggregation (CompoundResourceAspects). The semantics of this aggregation is represented as an association class, called CompoundResourceAspectDetails. There are three subclasses of this class, which are used to represent the aggregation of PhysicalResources, LogicalResources, and CompoundResources into this particular CompoundResource. These three subclasses are called PhysicalAspectCompoundResourceDetails, LogcalAspectCompoundResourceDetails, and CompoundAspectCompoundResourceDetails, respectively. Thus, the presence of the CompoundResourceAspectDetails class enables a single relationship to be defined, instead of three different relationships.
ResourceCharacteristic	Class	Strong	Copyright TM Forum 2005 This aggregation defines the set of characteristics, or distinguishing features, of a particular Resource.
Service	Class	Weak	Copyright TM Forum 2005 DONOTIMPLEMENT This is a conceptual relationship that defines the concept of a Service being supported by multiple Resources. DEN-ng defines this in more detail.