Graphical Visualization of UVL Feature Models

[SundermannC]

While the LSP is intended to edit UVL in textual format, it would still be helpful to somehow export a visual representation. A simple way to achieve an export may be a transformation to an existing format such as mermaid.

For visual studio code, it would also be great to have a similar integration to Markdown and LaTex to show the visual representation as seen below.

[TobiUUlm]

The export to various visualization scripts/languages should be manageable.
However, is it necessary to include an own implementation of a visualizer if there are already extensions that visualize mermaid scripts?

I would suggest that we implement the (on-the-fly?) export to a mermaid.js file first and then look forward to implementing a visualization tool.

Regarding mermaid:
We would have to use a work-around to implement feature model diagrams. For example flowcharts:

flowchart LR
    A[Hard edge] -->|Link text| B(Round edge)
    B --> C{Decision}
    C -->|One| D[Result one]
    C -->|Two| E[Result two]

[TobiUUlm]

We've added a command that will generate a Diagram-Script for Graphviz.

Why did we choose Grapviz?

Mermaid does not offer great customizability and has poor support for VSCode Extensions.
Graphviz (and the DOT Language) can be customized quite easily and with this extension for example it also offers real-time re-rendering.
This allows us to enable realtime-rendering in the future.

Additionally, we found a colleague of the team who visualized FeatureIDE Models in Graphviz already: https://github.com/ekuiter/feature-model-viz
We try to reconstruct this previous work.

Currently a Model looks like this:

What needs to be done:

• [x] Add a Legend
• [x] Add constraints
• [ ] Show cardinality
• [ ] Add information as a tooltip
• [ ] Add configuration support
• [ ] Clean the graph generating (Tree-Walking) code

[TobiUUlm]

It seems like Non-Windows Systems encounter an issue and can not generate any .dot files.
This is probably due to some invalid paths being parsed or passed through the system.
Probably responsible are these code places:

• Either directly in the vscode extension where the URI of the active document is passed to the uvls this would mean that the document is not parsed at all (for the graph) and it should throw some error in the UVLS.log where it says that the URI is invalid
• Or within the main.rs where the URL is parsed and used to create a .dot file.

@pascalfoerster Please add some logs to see where the filepath/URI is corrupted or if the uvls simply does not have enough rights/privileges to create a new file.
In the past we already has some issues with the rust-url crate and Windows File Systems. This lets us suspect that this is again part of the issue.

Since we developed this feature on a Windows, this feature just worked and we did not think about any problems regarding the Filesystem.

[pascalfoerster]

The problem is, if you use Linux and want to create a graphic, the method serde_json::from_value (in main::365) can only deserialize a url if the string in the value starts with "file://....". Why, I don't know, but without "file://" a uvl object cannot be created on Linux, and unwrap() causes a panic. (For some reason the server restarts again, but that doesn't really belong to this point).

So in the client, we no longer use uri.fsPath as an argument, which only returns authority/path, but instead use uri.toString(), which returns the complete uri. I hope the changes I've made don't cause any problems on Windows, but this should actually work on Windows as well.

[TobiUUlm]

I've used uri.toString() before and it did/does not work on my machine or Windows Systems in general.
But it's great to know what the problem is. Maybe we can check for the OS within the extension and pass values to the uvls according to this information.

Problem is: Windows seems to need a file-path without file:// scheme to create the file but needs file:// to create the correct file id and Uri. Maybe I should look into this instead of trying to have specialized code for each platform..

[TobiUUlm]

Now I first added conditional behvaior based on the platform. However, this seemed very odd.
Therefore I added some 'fallback' mechanism that first tries the file creation that should work on non-windows systems and if that fails tries to create a file as it should work on windows machines.
@pascalfoerster please test the newest commits of mine (should only need to build new server)
As soon as this works, the PR can be done.

It seems like there were two problems: Again, the percent encoding and additionally a leading slash (/) which windows unfortunately cannot handle. Both lead to a fail when trying to create a new file.
Now I added some additional fallback: If the file creation fails in any way, i will simply pass the graph-code to the extension client and display it without a file. This is possible with the Graphviz extension which is recommended.
Also I added some Information/Warning as soon as the recommended Extension is not installed/activated.

[h3ssto]

Hi everybody, as mentioned yesterday, we have a model2SVG renderer in variability.dev, which produces SVG (via D3) that look like this: and has a rich feature set for, e.g., coloring features by defect / commonality / ..., visualizing CTCs, legend, ...

We are currently in the process of exposing the model2SVG via the RestAPI and are working on deploying the viewer together with the RestAPI. I will keep you posted.