Figure PR.11 - The Relationship Between PhysicalResource and PhysicalResourceSpecification

Now, if we look at these attributes, we see that some of them lend themselves to being templatized, while some don’t. <br/>That is, we can use the concept of a PhysicalResourceSpecification to supply the ModelNumber, PartNumber, SKUNumber, and VendorName attributes, because these correspond to a generic specification describing a particular type of PhysicalResource. The other two attributes (ManufactureDate and SerialNumber) are specific to a particular instance of a PhysicalResource object, and therefore are not contained in the PhysicalResourceSpecification. <br/>We separate PhysicalResourceSpecs from LogicalResourceSpecs because they are fundamentally different in nature. In addition, they have different attributes, methods, constraints, and relationships in the System view.<br/>Both PhysicalResourceSpecs and LogicalResourceSpecs use the composite pattern for extensibility. Only the PhysicalResourceSpec classes are shown in The following Figure above for simplicity.<br/>A PhysicalResourceSpecAtomic class is a concrete class for describing specific attributes, behavior, relationships, constraints, and semantics for building PhysicalResource objects. The purpose of this class is to be able to track PhysicalResourceSpecifications separately from other types of ResourceSpecifications. Note that this class inherits the SpecifiesResource aggregation, and therefore can be used with the corresponding PhysicalResource class.<br/>The difference between this class and the PhysicalResourceSpecComposite class is that this class represents stand-alone PhysicalResourceSpecifications. The PhysicalResourceSpecComposite class represents a specification that is in reality made up of a set (usually a hierarchy) of PhysicalResourceSpecifications.<br/>The composite pattern is completed by defining the HasPhysicalResourceSpecs aggregation. This aggregation defines the set of PhysicalResourceSpecs that are contained by this particular PhysicalResourceSpecComposite entity.<br/>The SpecifiesResource aggregation defines the particular ResourceSpecification that is used to provide the invariant characteristics (i.e., attributes and relationships, as well as methods and constraints in the System View) 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/>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 these invariant attributes and behavior (and presumably adds its own instance-specific attributes and behavior).<br/>Since this aggregation is defined at the Resource and ResourceSpecification level, each of the subclasses of Resource and ResourceSpecification inherit its use. This is why (for example) there isn’t a relationship connecting a PhysicalResourceSpec to a PhysicalResource.<br/>The SpecifiesResource association is used to add the attributes and relationships of a ResourceSpecification to a Resource. The various subclasses of PhysicalResouce inherits the ability to have its own PhysicalResourceSpecification (or subclass of PhysicalResourceSpecification). This enables any specific needs of one of the various subclasses of PhysicalResource to be met by subclassing the PhysicalResourceSpecification corresponding to that object.<br/>We’ll look at the definitions of each of these major entities in the following sections.<br/>