You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+49-4Lines changed: 49 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,14 +16,16 @@ In the following we give a step by step example in how the library can be used t
16
16
- sample variants randomly, or use a predefined set of variants for simulation,
17
17
- generate variants for each step in the evolution history,
18
18
- obtain the ground truth of generated variants.
19
-
The examples source code can also be found in [GenerationExample.java](src/main/java/vevos/examples/GenerationExample.java).
20
-
We also give a brief introduction of the key features of the library we use in the following example.
19
+
20
+
The example's source code can also be found in [GenerationExample.java](src/main/java/vevos/examples/GenerationExample.java).
21
+
A similar and executable version of this example can be found in [VEVOSBenchmark.java](src/main/java/vevos/examples/VEVOSBenchmark.java), which gathers some rudimentary data on runtime performance for Linux and Busybox variant simulation.
21
22
22
23
At the very begin of your program, you have to initialize the library:
23
24
```java
24
25
VEVOS.Initialize();
25
26
```
26
27
This initializes the libraries logging and binding to FeatureIDE.
28
+
You may also set a log level for the library here via `Logger::setLogLevel`.
27
29
28
30
We can then start by specifying the necessary paths to (1) the git repository of the input software product line, (2) the directory of the extracted ground truth dataset, (3) and a directory to which we want to generate variants. (We use case sensitive paths to also allow the generation of Linux variants under Windows).
29
31
```java
@@ -47,7 +49,7 @@ From the loaded `dataset`, we can obtain the available evolution step.
47
49
An evolution step describes a commit-sized change to the input software product line, and is defined by the (child) commit performing a change to a previous (parent) commit.
48
50
Note that the evolution steps are not ordered because commits in the input product-line repository might not have been ordered as the commits might have been extracted from different branches.
49
51
Alternatively, we can also request a continuous history of evolution steps instead of an unordered set.
50
-
Therefore, a `SequenceExtractor` is used to determine how the successfully extracted commits should ordered.
52
+
Therefore, a `SequenceExtractor` is used to determine how the successfully extracted commits should be ordered.
51
53
In this example, we use the `LongestNonOverlappingSequences` extractor to sort the commits into one single continuous history.
52
54
Nevertheless, merge commits and error commits (where VEVOS/Extraction failed) are excluded from the history and thus, the returned list of commits has gaps.
53
55
Because of these gaps, we obtain a list of sub-histories, where each sub-history is continuous but sub-histories are divided by merge and error commits.
@@ -63,6 +65,16 @@ final VariabilityHistory history = dataset.getVariabilityHistory(new LongestNonO
63
65
/// Thus, we divide the history into sub-histories at each failed commit.
-_success commits_ for which the extraction of feature mappings and feature model succeeded,
75
+
-_partial success_ commits for which part of the extraction failed; Usually, a partial success commit has feature mappings but no file presence condition and no feature model,
76
+
-_error commits_ for which the extraction failed.
77
+
66
78
To generate variants, we have to specify which variants should be generated.
67
79
Therefore, a `Sampler` is used that returns the set of variants to use for a certain feature model.
68
80
Apart from the possibility of introducing custom samplers, VEVOS/Simulation comes with two built-in ways for sampling:
@@ -91,6 +103,16 @@ final Sample variantsToGenerate = new Sample(List.of(
Note that Busybox has a special subclass called `BusyboxRepository` that performs some necessary pre- and postprocessing on the product lines source code.
115
+
94
116
We are now ready to traverse the evolution history to generate variants:
95
117
```java
96
118
for (finalNonEmptyList<SPLCommit> subhistory : history.commitSequences()) {
@@ -108,6 +130,7 @@ A `Lazy` caches its loaded value so loading is only performed once.
108
130
(Loaded data that is not required anymore can and should be freed by invoking `Lazy::forget`.)
109
131
As the extraction of feature model or presence condition might have failed, both types are again wrapped in an `Optional` that contains a value if extraction was successful.
110
132
Let's assume the extraction succeeded by just invoking `orElseThrow` here.
133
+
(However, if also partial success commits are considered, one might need a more careful procedure here.)
111
134
```java
112
135
final Artefact pcs = loadPresenceConditions.run().orElseThrow();
113
136
final IFeatureModel featureModel = loadFeatureModel.run().orElseThrow();
@@ -126,6 +149,17 @@ Here, we just instruct the generation to exit in case an error happens but we co
0 commit comments