A ResourceSpecification represents a generic means for implementing a particular type of Resource. In essence, a ResourceSpecification defines the common attributes and relationships of a set of related Resources, while Resource defines a specific instance that is based on a particular ResourceSpecification.<br/>The SpecifiesEntity association defines the set of Entities, including both managed and unmanaged Entities, whose shared attributes, methods, relationships, constraints and behavior are specified by this particular EntitySpecification. <br/>ResourceSpecifications are generic in nature, just as Resources are. The SpecifiesEntity relationship uses the generic Entity-EntitySpec pattern described in the Common Domain guide book Root Entities section. This particular relationship defines the ResourceSpecification that is used to provide the shared characteristics and relationships (and methods and constraints in the system view) of a given Resource. This enables multiple Resources that each use a common set of attributes and/or relationships (and methods and constraints in the system view) to be related to a single invariant specification of those characteristics and behavior. <br/>The cardinality of the SpecifiesEntity relationship is 0..1 on the ResourceSpecification side and * on the Resource side.<br/>A Resource presumably adds its own instance-specific attributes and associations.<br/><i>Note: In the figure the association between EntitySpecification and Entity is implied and not a UML association. This was done so that the association between EntitySpecification and Entity is not inherited by all their subclasses. This would cause a problem, because any instance of an EntitySpecification could be associated to any instance of an Entity. For example, an instance of ProductSpecification could be associated to an instance of Service. The 0..1 association multiplicity on the association means that not every entity has to have an associated EntitySpecification. For example, an instance of a discovered Resource may not have a known instance of ResourceSpecification associated to it.</i><br/><i>The SID team strongly recommends the use of ResourceSpecifications, because their use helps ensure a consistent, repeatable design. If ResourceSpecifications aren’t used, then it will be impossible to realize the full benefit of the SID. In some of the subclasses of this pattern, the ResourceSpecification contains critical information (e.g., modelNumber and partNumber are two of four critical attributes defined in a PhysicalResourceSpecificationAttribute entity that might be related to a PhysicalResourceSpecification, as documented in the Physical Resource guide book).</i><br/>PhysicalResources and LogicalResources both require their own ResourceSpecifications. Rather than build separate hierarchies for PhysicalResources and LogicalResources, this design takes advantages of their similarities. This ensures that both types of specifications inherit the same behavior. <br/>PhysicalResourceSpec and LogicalResourceSpec are subclasses of ResourceSpecification and are both used to define the shared characteristics and behavior (attributes, methods, constraints, and relationships) of a PhysicalResource and a LogicalResource, respectively. <br/>PhysicalResourceSpec and LogicalResourceSpec are defined more in this section.<br/>The ResourceSpecificationRelationship and the two associations with Resource (ResourceSpecificationReferences and ResourceSpecificationReferencedBy) enables defining for example a set of ResourceSpecifications that are involved with, or related to, each other in order to build a particular type of ResourceSpecification. This entity might also be used to specify relationships such as “requires” or “incompatible with” or even “composed of”.<br/><i>Note: Since SID 16.0 the Composite / Atomic pattern has been removed from the three subclasses of ResourceSpecification as it can be replaced by using the ResourceSpecificationRelationship with a type “composed of”.</i><br/>