Figure PR.10 - Attributes of a PhysicalResource

<b>Filling in the Details</b><br/>We’re now at the stage where we can add some detail. Given that we are building a Business Model, we will simply strive to identify certain essential attributes and relationships for PhysicalDevice as well as Hardware. We will not define methods, low-level attributes, association classes, and in general all of the detail that fully describe these entities. This detail will be provided in an accompanying System model. This model has already been built and is currently being refined. It will be formalized as part of a future phase of the SID work.<br/>The following rules were used to define the set of attributes and relationships for this model:<br/>Keep to high-level, business-oriented concepts (e.g., while some applications might need to know specific details about a physical object, the purpose of this model is to simply identify the key concepts necessary for the purposes specified in our use cases)<br/>This is intended as a “minimalist” model. Subtypes and attributes should be added as required to suit the needs of a particular application. The attributes shown should be considered as suggested, not required, unless they are specified as mandatory.<br/><b>PhysicalResource attributes</b><br/>We’re now at the stage where we can add some detail. Given that we are building a Business Model, we will simply strive to identify certain essential attributes and relationships for PhysicalDevice as well as Hardware. We will not define methods, low-level attributes, association classes, and in general all of the detail that fully describe these entities. This detail will be provided in an accompanying System model. This model has already been built and is currently being refined. It will be formalized as part of a future phase of the SID work.<br/>The following rules were used to define the set of attributes and relationships for this model:<br/>Keep to high-level, business-oriented concepts (e.g., while some applications might need to know specific details about a physical object, the purpose of this model is to simply identify the key concepts necessary for the purposes specified in our use cases)<br/>Note that these entities represent business concepts in a Service Provider that conforms to the eTOM process model [eTOM] (specifically, the Resource Development and Operations processes).<br/>This is intended as a “minimalist” model. Subtypes and attributes should be added as required to suit the needs of a particular application. The attributes shown should be considered as suggested, not required, unless they are specified as mandatory.<br/>Parent attributes are not repeated in their subclasses<br/>Only significant entities are shown in the “related business entities” cells<br/>We already introduced the notion of this entity as a superclass of our two main categories of physical objects: Device and Hardware. Hardware defined three types of objects – Equipment, EquipmentHolder, and AuxiliaryComponent. We abstracted this set of entities into a single entity, called PhysicalResource. This is defined as 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.<br/>Now, it’s time to see if we can discover common attributes that these three types of entities have in common. We’ll tie this into the concept of a PhysicalResourceSpecification in a minute.<br/>The most obvious types of attributes that physical objects have in common are the set of attributes that define specific characteristics about a given physical object. These include who manufactured it and when, and what the model number of the object is. To this, inventory encourages us to add part number, SKU number, and serial number. <br/>These six attributes are inherited by all subclasses of PhysicalResource.<br/>The key in making the above model extensible and reusable is to use the concept of a Specification. A Specification is a way of defining the invariant characteristics and behavior (attributes and relationships in the Business View, along with methods and constraints in the System View) of a managed entity.<br/><br/>