See if we can optimize the generation of sets of features and relatiuons for certain operations such as those in montecarlo methods

[jagalindo]

Currently, we trasverse the tree structure everytime we ask for the set of features within a feature model. This is convinient for scenarios in which the model evolves and multiple operations affect the imput. However, this is a cou intensive method that hinders good performance when coping with operations that iteratibely configure products (e.g. montecarlo methods)

[jmhorcas]

I was thinking about this issue. Some comments:

• The current FM metamodel mixes pure Object-Oriented Programming (OOP) mechanisms (e.g., getters/setters) with a more Pythonic way of accesing objects (e.g., accessing directly the attributes without getters/setters). This can provoke that ones modify the current status of the features and relations without control, provoking undesired collateral effects. To solve this, we may make all attributes privates (using the underscore _) and modify the objects only through the setters. If we want to do this in a more Pythonic way we could make use of existing @decorators for this purpose. Maybe it is worthy to take a look to the Clean Code book for Python.

• To improve efficiency of the structures, I propose two possible solutions: (glad to hear for other alternatives)

1. Extend the current models to make a version of them "inmutables" as other classes in Python like the frozenset. This would serve for Monte Carlo methods, but may introduce inconsistencies when mixing both structures. Also, currently there are some design inconsistencies within the FM metamodel. For example, I suggested in last version that classes offer a __hash__ method, but this method shouldn't exist because of __hash__ only makes sense with inmutable objects.

2. Changing the current structure to store the features and relations based on a more efficiency structure like dictionaries (maps). This requires a considerable effort because the current metamodel is not well encapsulated (e.g., attributes are accessed from outside in other algorithms/parsers/classes). See the first comment above about OOP.