Implementing an SPL with the HyVar toolchain consists in:

1. Defining a feature model (as a feature diagram with cross tree constraints and context information variables);
2. Coding a Yakindu statechart representing the base program;
3. Identifying the deltas that modify the core statechart together with the application order and the activation conditions to generate the variants;
4. Coding the deltas (this step may require to go back to step 3).

One of the most challenging problem lying under deltas development is keeping track of each element across the base statechart and the deltas that manipulated it to generate the variants, in order to ensure that each variant can be generated and is a well-formed Yakindu statechart.

Doing this by trying to keep all in mind can lead to many undesired bugs! Bugs can be grouped in:

• an ill-typed expression (e.g., a string value is assigned to an integer declared variable);
• a delta applicability inconsistency (i.e., during the generation of a variant, a delta operation fails, so the generation of the variant fails);
• a dependency inconsistency (i.e., an incomplete variant is generated).

Even if one or more of them don’t affect the variant derivation process, they produce a problematic variant. While it is straightforward to check the well-formedness of a variant by opening it in the proper IDE, in the HyVar continuous integration scenario, checking the variants by generating each variant and checking it in isolation will significantly reduce the efficiency of development process. Namely, the number of variants can grow as the size of the power set of the set of features in the worst case.

Therefore the HyVar toolchain provides a static analysis tool able to check whether all variants can be generated and are correct Yakindu statecharts,  without generating any variant.

The analysis requires that all deltas must be coded following a programming pattern that we call “pre-well-formedness”—if the deltas do not follow this pattern the analysis fails. To explain what pre-well-formedness means, we first divide delta operations in three groups: the ones that add an element, remove an element, modify an element. A pre-well-formed delta cannot perform two operations of different kind on the same element. Here some cases:

• an already added element can’t be modified (either removed) in the same delta;
• an already modified element can’t be removed (either added) in the same delta;
• an already removed element can’t be added (either modified) in the same delta.

While following pre-well-formedness may looks like pretty easy, at times a delta operation can hide some modifications (e.g. the addition of a transition implies the modification of its source state, so that a delta adding a state cannot add a transition from that state in order to be pre-well-formed).

Tool support for helping the programmer to write pre-well-formed deltas, by highlighting the deltas not following the pattern, is currently under development.