Resolving feature interactions

[ekuiter]

(sorry for the wall of text, I just wanted to preserve my thoughts from yesterday's exercise before they vanish 🙂)

I think we could and should revise the part 9b on resolving feature interactions.

• The Venn diagrams are only partially helpful. They only visualize positive interactions (e.g., a and b) and not negative ones(e.g., a and not b), which my students were confused about. Also, the images have been taken from the previous lecture, which we wanted to avoid.
• S1: The lightning bolt for variability suggests that adding constraints to the feature model to forbid interactions is something bad. But reducing variability can be good or bad, depending on whether the functionality is actually needed. The entire point of feature models is to forbid interactions. Maybe switching out the symbol would already help.
• S1b: I don't understand slide 24 (why have weights in shortest path at all if they are 1.0?). Maybe we should choose another example for this strategy? Not all the strategies are really good for handling the given interaction. Maybe it would be more convincing to find a real-world example for each strategy. I think the advantages and disadvantages will still get clear this way.
• S2: This strategy seems misleading. By ignoring the weights in shortest path, we do not handle the interaction, but remove it entirely, in my understanding. Maybe we could rephrase the description.
• S3: This strategy only really applies to modular techniques like FOP. If I already chose the preprocessor as my main implementation technique, why should I use this strategy?
• S4: On slide 30, which source code has been moved where?
• S4: This looks to me to result in runtime variability for the coordination code. This suggests that we assume a compile-time variability technique for the coordinated features, right? I think this is a bit too abstract.
• S5: Part 9b of the lecture does not make clear which strategy is compatible with/appropriate for which implementation technique. In fact, S5 is just an implementation technique, conditional compilation (actually preprocessors? not build systems, anyway). I find this confusing. Usually, I would first choose my implementation technique (i.e., it is fixed for a given project) and then find ways to resolve interactions that come up. Here, it looks the other way round: I choose the right implementation technique to handle an interaction. Maybe it would be easier to understand if we switch this around.
• S5: I don't think that the impact on code quality is as bad as suggested. There are many interactions in the Linux kernel (e.g., nested preprocessor code). It only gets problematic under certain circumstances. Subjectively, I think this is a rather honest and elegant way to coordinate feature interactions, which are hard to modularize by nature. I would suggest to remove one lightning bolt.
• S5: It looks weird to see FOP and preprocessors combined like that. We never showed such combinations before, why here? To students, I think this might look like S5 = FOP+preprocessors, which is not really accurate.
• S6: I'd add that this may even be impossible for some interactions. Also, I do not think that code quality is always good for this strategy (forced/unnatural modularization is not necessarily good).

Consequently, I also think that slide 35 is too simplistic (in my experience, students will memorize it and take it as law). Why not describe key characteristics of the strategies with words or images, as we do in other parts of the lecture? We should also describe assumptions/guarantees of the strategies, maybe a bit like design patterns: Not every design pattern/feature interactional strategy is suitable for every design problem/feature interaction. So I think the biggest improvement would be to use different examples and not the same for every strategy (maybe one situation where this strategy is very appropriate, and one where it is inappropriate, to illustrate the (dis-)advantages).

[ekuiter]

@skrieter also had some ideas about merging some strategies (or renaming them?). For example, there are multiple strategies that try to extract the coordination code into a distinct unit (either an #ifdef block or a module), which could be combined under one term (and then compared, like S1a and b).

[tthuem]

If we apply such significant changes, we should (a) probably discuss them in a meeting and (b) update our recordings on respective lectures.