Reuse Modeling Objects
Reusing Configuration Processes and forms
In some circumstances it is useful to reuse a Configuration Process (or a part of a Configuration Process). The result of this reusability is that nested Configuration Processes will be created.
Definition: A nested Configuration Process contains nodes (Configuration Processes or forms) which are either reused multiple times inside the nested Configuration Process, or which are reused in other external Configuration Processes.
There are multiple ways to reuse Configuration Processes or forms. In this section we will cover pure nesting, meaning that one root Configuration Process will be called inside another one.
Example
We can easily imagine Telco companies sell a “wireless subscription Configuration Process” which calls a “mobile phone Configuration Process”. Both Configuration Processes can be run independently, but one can call another.
Let’s say that an additional business rule is added to the model; this business rule is an inter Configuration Process rule, meaning that it is only applicable when rootCP_B is called inside rootCP_A. This can be represented as follows:
In this case, it could be that specific inter-model business rules should be implemented. Let’s say that the value of FO4/FP1 in rootCP_B depends on the value of FO2/FP2 in rootCP_A, in the case that the rootCP_B is run inside rootCP_A.
As you can see in the above example, reusing forms and Configuration Processes can clearly be very efficient in terms of maintenance (because the modeling work only has to be done once) but can, in some cases, make the CPE more complex.
It is also noteworthy that some situations require to somewhat extend the object which is to be reused. For instance, consider the following situation:
In this situation, it is clear that FO3_a and FO3_b are very resembling.
However, FO3_b contains an additional form property FP_3. In order to reuse the same form, it will be necessary to make a more generic FO3_c which has an additional business rule, which states that FP_3 only “exists” if the root Configuration Process is “rootCP_B”:
Reuse BRC
In order to reuse BRC, it is important to understand that once a BRC has been used, you can reuse it, but you cannot change it without accessing the BRC Dictionary step.
Example:
Suppose that a form property FP3 has a domain BRC. This domain BRC uses only 1 alias pointing to CPE.currentFP.value, and issues 3 values {A, B, C}.
| ALIASCURRENTFP | EXPLANATION | |
|---|---|---|
| = | A | |
| = | B | |
| = | C |
If you want to reuse this BRC on another form property FP2, you can do this providing that the scope (the aliases involved) and the content (the values generated) don’t change. Typically, you can reassign the same BRC to another form property, in order to generate an identical domain.
However, if you want to extend the BRC, for instance by adding an alias in order to say that the
values {A, B, C} depend on another form property FP1, you will have to generalize it. This means that you will have to make sure that the scope (the involved aliases) and content (the generated values) will work and will be consistent for each usage.
Example:
Suppose that the same domain BRC has to generate the values {A,B} for FP2 if FP1 = X, and {B, C} if FP1 = Y. The BRC is now represented as follows:
The content of the BRC will have to be reviewed in order to make sure that the correct values are generated in every case:
| ALIASFP1 | ALIASFP2ORFP3 | EXPLANATION | ||
|---|---|---|---|---|
| = | B | |||
| = | X | = | A | |
| = | Y | = | C |
Thirdly, and most importantly, the CPE of each alias needs to be reviewed in order to make sure that the BRC will correctly execute in every case. In this case, the resulting CPE would be
CPE.currentFP.value
and the “input” CPE would be
CPE.rootCP.CP/CP1.FO/FO1.FP/FP1.value
In order to make sure that the domain BRC also would work for rootCP_B, the mustExist attribute of this CPE needs to be set to false.
In some circumstances, it might seem beneficial to reuse a BRC because the scope is exactly the same. Have a look at the following example:
- Form property FP1 has a domain which consists of the values {A, B, C}
- Form property FP2 has a domain which consists of the values {E, F, G}
It could seem interesting to reuse the same domain BRC for both form properties, because the scope is the same: both BRC contain only one CPE which is the following:
CPE.currentFP.value
However, in this case, this would be a bad choice, because the domains are clearly not the same.
(2) the business meaning of the BRC is the same.
Basically, you should privilege the reuse of BRC when:
- The meaning of the content is the same
It is clear that a BRC which issues the possible colors for a car cannot be reused in order to generate the colors of the seats. Although both BRC concern a color, the meaning is not the same and therefore they risk evolving in other directions.
- The scope is the same or will not change drastically
If the scope is not the same, other CPE will need to be added in order to generalize the BRC. Generalizing the BRC will make the BRC somewhat more difficult to understand and thus somewhat more difficult to maintain.