Figure Pr.01 - Primary Product Domain Business Entities : Class diagram
Created: |
3/28/2022 3:51:09 PM |
Modified: |
5/17/2022 2:56:48 PM |
Project: |
|
Author: |
broth |
Version: |
22.0 |
Advanced: |
|
ID: |
{23BEC417-57B7-4af3-BA55-2F2E3B61708E} |
An overview of how the main Product domain business entities are related is shown in the figure below. This model is developed as we work through this document.<br/>The Product domain is essential to the overall SID model. Customers need to be able to express their needs in plain English in order to determine which ProductOfferings can support their requirements and Service Providers need to be able to match these requirements to technical specifications to realize the ProductOffering. <br/>A ProductOffering represents what is externally presented to the market for the market’s use. <br/>The class ProductOffering is abstract. Using the atomic/composite pattern, it further specializes into two concrete classes: SimpleProductOffering and BundledProductOffering (equivalent to atomic / composite).<br/>The class ProductSpecification is abstract. Using the atomic/composite pattern, it further specializes into two concrete classes: AtomicProductSpecification and CompositeProductSpecification.<br/><br/>A SimpleProductOffering is always associated with exactly one ProductSpecification, which itself can be atomic or composite.<br/>A BundledProductOffering is not directly associated with any ProductSpecification. Instead it contains ProductOfferings, each of which may in turn be a SimpleProductOffering that is associated with a ProductSpecification, or a BundledProductOffering.<br/>An example of a BundledProductOffering is a home-based internet service representing the aggregation of three SimpleProductOfferings: internet connection, email service, and web hosting. The home-based internet service ProductOffering is not related to any ProductSpecification, since it merely represents a grouping of other offerings.<br/><br/>Vice versa, a ProductSpecification may be made available as one or more simple ProductOfferings (which in turn may be components of a BundledProductOffering).<br/>For example, an email ProductSpecification may be used in a number of different ProductOfferings: one such offering may be bundled as part of a Broadband Internet offering, while another offering may represent stand-alone email.<br/><br/><i>Note that ProductSpecification and ProductOffering inherit the lifecycleStatus and validFor attributes from EntitySpecification, and ID, name and description from RootEntity.</i><br/>A Product represents the instantiation of a ProductOffering or ProductSpecification by a Party playing a PartyRole, such as a Customer. If the product can be used (based on a contract) over a period of time (and not for example a one-time purchase of a device), this is colloquially known as a Subscription. For example, Helen has subscribed to company ABC’s internet ProductOffering. Typically, when a Customer acquires a ProductOffering, a Product will be instantiated for the parent ProductOffering, for each contained ProductOffering, and for each ProductSpecification referred to by the contained SimpleProductOfferings in the offering tree.<br/>This enables a customer or other party to report problems about a product which was not marketed as an offering or for a product to appear on a bill, and so forth. For example, a composite high-speed internet ProductSpecification may include email and personal web pages atomic ProductSpecifications which are not instantiated as separate offerings but still must be instantiated as Products. This is also necessary if a ProductSpecification not instantiated as a ProductOffering has configurable characteristics or prices associated with one or more characteristics.<br/>