Figure A 1 - Instances of valid color values

Figure A 1 - Instances of valid color values : Object diagram

Created:	5/11/2022 11:20:37 AM
Modified:	6/6/2022 9:56:45 PM
Project:
Author:	Natha Paquette
Version:	1.0
Advanced:
ID:	{DB990FE4-9B4E-4077-A7B2-C46350DB4DEB}

More Details on Characteristics As stated in the introduction, the CharacteristicSpecification/CharacteristicSpecValue pattern is intended to be used to dynamically define attributes for any business entity. This pattern is very powerful but not easy to understand. Section 1.13 presents it to some level of details that may not be sufficient to understand all aspects of its expressive power. In particular, Figure Ch.01 Characteristic Specification is very complex. The purpose of this section is to try explain this pattern and the related artefacts in Figure Ch.01 in a simple and progressive way. We will illustrate our presentation with the example of Cars and CarSpecifications. While it is deliberately away from the Telecom domain, we expect that it is simple to understand, not controversial and general enough to be easily adaptable to our Telecom domain. What does “ dynamically define attributes for any business entity” mean ? The usual way to define specific attributes for a given business entity is to add these attributes in the class of the model that represents this entity. Based on this modification of the model, the implementation of the corresponding class (data base or source code) must be modified, recompiled and the corresponding run time need to be re-executed to take into consideration the modifications introduced. The approach proposed by the CharacteristicSpecification/CharacteristicSpecValue pattern is, at run time, to create instances of CharacteristicSpecification (or simply called characteristics) and instances of associated CharacteristicSpecValues. Once this is done, there are two ways these characteristics can be used: <ul>
<li>Either associate an instance of a CharacteristicSpecification to an instance of a business entity that need to be extended</li><li>Or use the RootEntityType meta approach. In this case, characteristics can be added to an instance of RootEntityType, meaning that these added characteristics will apply to the SID Entity (SID class) corresponding to the instance of the RootEntityType (remember that The RootEntityType in the SID is populated with a list of all business entities contained in the SID). Figure Ch.04 illustrates this approach with the SID Entity “Service” that is extended with two characteristics “LastStatusChange” and “StatusUpdatedBy”. It then means that any instance of this extended class will be extended with these two characteristics. From an implementation view point it can be interpreted as adding two new columns to the data base table representing this SID class. </li></ul>
 Below we will further illustrate the first way. Use Case 1: Let’s assume that the model already contains a static class “CarSpec” inheriting from EntitySpec. This class “CarSpec” will be used to create instances of models of cars that will populate a catalog (for example, the catalog of all the models of a given constructor). This class “CarSpec” has its own set of attributes that will characterize each car model instance, such as the possible energy, the possible engine power and the possible colors, among many others. Now let’s assume that for a given instance of CarSpec (representing the car model Toyota Yaris as an example) we want to differentiate the color of the roof and the color of the body. The valid values for the roof or the body will be a subset of the valid values for the general Color characteristic that is used in general for all car models of this constructor which we assume to be: Black, Blue, Green, Pink and Yellow. The general Color characteristic is represented as an instance of CharacteristicSpecification aggregating a set of instances of CharacteristicSpecValue representing the various valid colors.