Building the feature model

Here a model of the example system is built with both tools. The scope is limited to only the ’Cards’ branch of the tree (see picture from earlier) due to PV starting to malfunction while it was being made. Pictures of the models can be found in the

appendix.

PV

Adding a large amount of features quickly gets cumbersome in PV and takes a lot of time due to the large amount of pointing and clicking required. The user interface often lags a bit, and sometimes very badly, making the experience even worse and increasing the time it takes to add many features. This was definitely a problem when adding the features for the Cards module, as the list of features and their relationships was already mostly known. The task could have been completed in much shorter time if the UI would have allowed it. The lag in the UI probably partly results from automatic validation, but it was not possible to make it disappear or negligibly small on the tested setup. The positive thing about the feature addition dialogue is that it isn’t any more complex than it needs to be, and the amount of options is kept to a minimum. This makes it easy for beginners.

The human readable names are useful, and greatly improve the readability of the model. In addition, they do not need to be unique, so they also make it possible to refer to same exact functionality in many places by using the same human-readable name in all of them. In some situations this could make more sense than adding actual references to features defined elsewhere due to it being more simple. In the model the ’Auto place’ and ’Selectable place’ feature names are used in two places even though they are separate features with different unique names. The free-text descriptions for features would probably be useful for anyone trying to understand the model, when there is no external documentation of the feature model available.

In our case we assume a very small, co-located team, so the benefits from creating and managing the descriptions might not be worth the time it takes.

Adding attributes and constraints is much more cumbersome and harder than adding features. The user interface for adding or editing an attribute or constraint functions quite poorly on the tested system. Usually fields need to be clicked many times before they can be edited, and the fields are very small. Additionally the user is presented with unnecessary and potentially confusing information like internal attributes such as ’source’. Furthermore, PV seems to make the assumption that the user building or managing the feature model wants to add multiple values for attributes and constraints into the feature model. This is not always true, like in our case just an acceptable range was defined for attributes (varHandLimMax and varHandLimMin). Finally, only exact values for attributes and constraints can be

given easily from the user interface. For everything else, the user is given a big editor window, where code for determining the values must be written with pvProlog or pvSCL. This is quite slow and cumbersome for expressing many simple things such as maximum and minimum values for attributes, like in our model. In addition, it adds significantly to the amount of learning required to use PV efficiently.

Figure 4: A board game feature tree

When it comes to features in the feature tree, the visual syntax is quite intuitive and easy to understand (see figure 4). If the structure of the model is not easy enough to see from the tree view, there is also the graph view (figure 5) that emphasizes it. Features can be added or edited and any other modifications of the tree can be made directly from the graph view as well. It quickly becomes obvious that it doesn’t scale as well as the tree view, but the ability to hide children of any element by clicking its upper right corner helps with the scalability. Nevertheless, folding and unfolding elements is additional work, and the graph might be better suited for just visualization. Additionally, elements are placed in the graph without any intelligence (e.g. on top of each other) and need to be manually dragged to places that make more sense. Attributes and constraints are presented in the tree view in

Figure 5: An FD graph generated by PV and then hand-tuned

a way that is not optimal for our model, as there are only single values that get repeated on another row pointlessly. The way they are represented in the graph view makes much more sense for our model.

CT

The Clafer model is quick to write and edit in SublimeText, thanks to the simple and concise syntax. There naturally are no more wait times or lag either while editing the model than what would be experienced while editing any text file on SublimeText, since there is no on-the-fly checking of model validity or even syntax of the text file. The syntax and basic validity is checked when the model is compiled, which can be easily done with a keyboard shortcut. The errors caught are what could be expected of resulting in compiler errors with programming languages, like trying to instantiate a nonexistent abstract clafer. The compiler errors that are shown in the editor window are easy to understand and thus to locate as well. The partial model having been done here (see figure 6) took 0.7 seconds to compile on the tested system.

There are multiple ways to present most ideas in CT, as the language is quite

flexible but also rather abstract or high level. Building a feature model without any abstract or reference clafers would be quite straight-forward when one is familiar with the syntax, but even from just the Cards branch of the feature model, we can see that it would be impractical. One obvious drawback would be complexity and manageability of the model code. Perhaps a bigger problem would be inability to create different types of card piles for example without repeating a lot of code.

However, coming up with the best or even reasonably good ways to modularize the model with abstract and reference clafers is not simple. The developers of CT have a wiki that includes many examples that help, but many of them are closer to domain models or models of concepts than feature models applicable for SPLE. For example, there are example solutions for a book, and a railway network. Such examples’

usefulness is limited apart from showcasing the syntax. Furthermore, there exists alternative syntax for many things, and there have also been some changes to the syntax since some of the examples and some other material in the wiki has been written, which reduces the wiki’s usefulness as a learning material. Finally, it can be said that the wiki is not very well organized.

Since features, attributes and constraints are all handled by the compiler similarly to variables, their names cannot contain spaces for example. A naming scheme such as camel-cased names like in our model (figure 6) is needed. Shortening the names might be a good idea as well instead of just camel-casing full descriptions of them, because the latter is inconvenient to reference and makes the model look messy. The drawback of this is that the meaning of the features, attributes and constraints is hard to understand from looking at the model alone. There is probably need for some external descriptions of the clafers in many cases, and possibly even in our example context as well. Same variable names are allowed in different scopes, which seems to make sense for things such as ’maxSize’ in our example, but there is a drawback to that approach, as discussed in the next section.

The instance generator that is directly accessible from the editor through a keyboard shortcut is useful for seeing whether the model you have made is indeed what you meant to do. This was the case with our model as well. Several times cycling between generated instances revealed that the structure or syntax of the model was wrong even though the model or syntax was not invalid. Even with a large amount of instances as with our model, cycling between them is surprisingly practical, as there is virtually no lag.

Figure 6: A generic model for a variety of board games

4.2.3 Product configuration