Strange dependency on feature configuration

[rbonifacio]

Why? Why does transformUcm for BindParameter depend on the FeatureConfiguration? See module HplAssets.UseCases. Not so clear. By comparison, transformBpm does not depend on the FC for BindParameterBpm. Generally, how does it make sense that an asset-level transformation depends on the feature configuration. I don't mind much, but I just would like to know. Because this single dependency implies that the variable-managed transformation function now has this extra parameter for the feature configuration. Previously (before yesterday), this dependency was hidden in the fact that the transformation function of an asset module would operate at the level of the complete InstanceModel, whereby it could look up the feature configuration when necessary. However, as I said above, the dependency on SPLModel and InstanceModul had to be removed for the good.

[rbonifacio]

The bindParameter transformation binds the parameter values of the use case model to the selected options of an "Alternative" or "Or" feature of a product configuration.

For instance, let's assume that there is a mandatory, or-feature ShippingMethod, with two options Saver Shipping, and Worldwide Expedited Shipping. Let's also assume that a use case specification declares a parameter "SM" and the configuration knowledge has an entry "bindParameter ShippingMethod SM. In this case, the SM parameter within the resulting |use case model might assume the values (Saver Shipping), (Worldwide Expedited Shipping), or (Saver Shipping, Worldwide Expedited Shipping), depending on the selected options of the ShippingMethod feature.

Although there are some benefits of this approach, for some reason the corresponding transformation of the business process model uses a different approach.