This repository holds test models for the KIELER project. These test files are used while developing our layout algorithms, to reproduce and fix bugs, and to run automated tests to ensure the bugs remain fixed.
On the top level, the repository contains the following folders:
Folder | Description |
---|---|
tests |
Test graphs written or generated by us or others. |
realworld |
Models obtained by converting examples from the real world into formats we can use. |
tickets |
Models that reproduce problems described in tickets. |
collections |
Somewhere in-between tests and realworld : Larger collections of models that are usually derived from real world models and may serve as a basis for evaluations. |
Both tests
and tickets
are further subdivided
into folders specific to the models' context (e.g. 'ptolemy', 'sccharts').
In the test
tree,
these folders may contain further folders specific to the respective tickets
if more than one file is produced for a given ticket.
The file types we use are the following:
Type | Description |
---|---|
.elkt |
Textual ELK graph language. See the specification. |
.elkg |
EMF's XMI-based representation of ELK graphs. |
.json |
JSON files. See the specification. |
.md |
Readme files can be placed in folders to describe their purpose. |
Next, the available collections are described. The collections may be subject to change both in terms of structural changes of the graphs itself and in terms of the graph instances that are included within a collection. Thus, when referencing a certain collection in a post or an article, it is a good idea to include the git commit id of the used state.
The following table provides an overview, and the sections below describe the properties of the graphs in further detail.
Collection | Description |
---|---|
rome, north | Taken from the graphdrawing.org website, these two collections are well-known within the graph drawing community. As opposed to the other collections, the graphs' nodes do not have dimensions. |
ptolemy | Taken from UC Berkeley's Ptolemy II project, the graphs represent dataflow diagrams with ports. |
sccharts | SCCharts are a type of control flow diagram, representing state machines with hierarchy. The provided graphs have been created by university students during practical courses. |
scgs | SCGraphs occur during the compilation of SCCharts. The provided graphs originate from the previously mentioned SCCharts. |
Variants:
original
flattened
: the hierarchy has been removed by moving all simple nodes to the top-most level
There are two *._map.txt
files in the corresponding directory that can be used to identify the original model.
Interesting features:
- Ports
- Different node dimensions
- Hyperedges
- Node labels
- Hierarchy
- Disconnected graphs
Desired layout style:
- Left-to-right layout direction
- Orthogonally routed edges
Preserved layout options:
portConstraints
portSide
portIndex
nodeLabels.placement
What to do:
- Simple nodes have a dimension, the dimension of hierarchical nodes must be determined
- Nodes have labels, which have a dimension, that are to be positioned properly
- Nodes have ports that are to be positioned according to their port constraints
- Simple nodes have fixed order port constraints
- Hierarchical nodes have free port constraints
Variants:
original
core
: the original SCCharts are transformed to only comprise of core features, which usually results in a larger number of nodes and edges
Interesting features:
- Different node dimensions
- Hierarchy
- Mixture of a regular layout algorithm and a packing algorithm.
The latter has explicitly been configured to
org.eclipse.elk.box
- Edge labels
Desired layout style:
- Spline edge routes
- Even node distribution
Preserved layout options:
- Layout algorithm as mentioned above
SCGs emerge during the compilation of SCCharts.
Variants:
original
bb
: at some point, several nodes are combined to basic blocks, which are modeled using hierarchyseq
: sequentialized SCGs are acyclic and may become very long
Interesting features:
- Different node dimensions
- Hyperedges
- Node labels
- Hierarchy
Desired layout style:
- Top-down layout direction
- Orthogonally routed edges
Preserved
portConstraints
portSide
portIndex
nodeLabels.placement
layerConstraint