Figure SO.11 - Modeling Stand-Alone and Aggregate ServiceSpecifications

There are two basic ways to define and use a ServiceSpecification. One is to define a stand-alone ServiceSpecification, while the other is to define an aggregate ServiceSpecification. The difference is straightforward – aggregate ServiceSpecifications are used to define collections of ServiceSpecifications, whereas stand-alone ServiceSpecifications define all the functionality that is needed by themselves.<br/>If we did this, then the ServiceSpecAtomic would be defined as an abstract base class for defining ServiceSpecifications that do not have any subordinate ServiceSpecifications. These ServiceSpecifications are stand-alone in definition and use, and don’t require any supporting ServiceSpecifications to define the common characteristics of Services that it serves as a template for.<br/>Similarly, a ServiceSpecComposite class would be defined as an abstract base class for defining ServiceSpecifications that are formed by aggregating other ServiceSpecifications. The types of ServiceSpecifications that are aggregated may be ServiceSpecAtomic and/or ServiceSpecComposite instances. A ServiceSpecComposite collectively defines all of the common characteristics of Services that it serves as a template for.<br/>However, we already have defined two subclasses of ServiceSpecification, called CustomerFacingService and ResourceFacingService. We can just as easily apply the composite pattern to these classes instead of defining a ServiceSpecAtomic and a ServiceSpecComposite class. This is exactly what is done in the model shown in the following Figure. We can reserve the right to define generic ServiceSpecAtomic and ServiceSpecComposite classes that are not CustomerFacingServices or ResourceFacingServices in the future. Note that at this time, no examples of such ServiceSpecifications exist. <br/>Therefore, we will proceed with the definition of CustomerFacingServiceSpecs and ResourceFacingServiceSpecs using the composite pattern to model this.<br/>