Potentially revise terminology for configurable software

[ekuiter]

Currently, the course promises to teach implementation techniques for software product lines. However, not all presented implementation techniques are specific to software product lines (i.e., they do not fit the definition of a software product line well).

For example:

• Clone-and-own is not a implementation technique for software product lines, I think. It can even be considered its antithesis.
• While frameworks, components, services or microservices can be used to implement configurable systems, they do not fit the vision of a completely automated software product line IMO. Also, there are basically no case studies using these techniques that we would identify as a software product line (and could refer to in the exercise).
• Runtime variability abounds in all software, everywhere. For example, the Windows registry or Firefox's about:config implement a lot of variability - but we would not consider Windows or Firefox to be a software product line for this reason.

This is somewhat problematic, as I find myself struggling to delineate what a software product line is or is not in the exercise. I also find myself arguing that the lecture presents a somewhat idealized image of a software product line, which does not necessarily correspond to what students will encounter and build in practice.

I think this is mostly a philosophical/semantic issue of terminology and could probably be fixed or at least improved by (briefly) discussing and comparing (for example) the following concepts in the (first?) lecture, for example in a picture (e.g., a Venn diagram):

• (highly) configurable (software) system, variant-rich system, variable system/software
• software product line, software platform, family
• adaptive systems, dynamic software product line, reconfigurable system, digital twin
• software ecosystem, multi software product line
• software variability/configurability, features, feature toggles/flags, configuration options

... and then concluding this philosophical discussion with the remark that we basically consider these all to be the same thing and that we won't distinguish them in the remainder of the lecture. Or even better, we could distinguish them in the remainder of the lecture by fitting them into the picture, respectively (which also enables students to name a kind of variability correctly when they see it).

I think the lecture is currently needlessly restrictive with its titular focus on "software product lines". We actually teach all kinds of techniques for implementing software variability in general, which kind of muddles the concept of what a software product line actually is. In principle, one could argue that the lecture could even be renamed to "software variability" or "configurable systems" (although I probably would not go that far).

(partially inspired by reading Bringing Together Configuration Research: Towards a Common Ground, and other papers arguing/giving up arguing about terminology)

[tthuem]

I do not think that throwing more terms to students is the right way to go here. However, we could do this in Lecture 8 when we compare the different techniques and could provide an overview in terms of a Venn diagramm.

The term SPL is more used as that of a vision and we are not claiming that every technique is actually leading to a product line, especially for the ad-hoc techniques.

[ekuiter]

A small addition: I got feedback that students were confused about the inconsistent of some terminology.

Mostly, this can probably be fixed by improving the exercises (which still refer to old terms sometimes) and making them more consistent with the lectures.

One thing I noticed is that we group if's, global variables, parameters, and design patterns under the umbrella term runtime variability, but this term also refers to a particular binding time (runtime). This can be confusing when talking about frameworks, which may also load/unload plugins at runtime. As discussed in #32, I also do not really see any real difference to components, which could in principle also be loaded or unloaded during runtime. Same goes for services.

So, depending on how you understand it, the term runtime variability may or may not include the modular techniques (frameworks, components and services).