Views and Interactions

The possible views and their filtering are largely dependent on your actual architecture description in the architecture metamodel definition, but the core concepts and their interaction are the same for any model. When initially viewing any project model, a view context model according to your view context metamodel definition is created, from where interaction modifies that view context and allows you to browse through the entire project. The following images show the general interaction path and how that modifies the underlying view context and the initial view of an unaltered view context.

Adapted from Niklas Rentz, Christian Dams, and Reinhard von Hanxleden. “Interactive visualization for OSGi-based projects”. In: 2020 Working Conference on Software Visualization (VISSOFT). Adelaide, Australia: IEEE, Sept. 2020, pp. 84–88, Copyright 2020 IEEE.

The view context model can also be stored on disc via the options sidebar to restore a view. This requires the project model to be located next to the stored view context model. The project model can also be updated and the stored view context model will show the same view configurations, as long as the differences between the model the view context was stored with does not differ too much from the updated version.

Clicking the expand button on any of the configured views expand that view and shows its contained artifacts, each in their collapsed form initially.

Clicking the collapse button in turn collapses that view again.

Any single artifact can also be expanded with the expand button and collapsed back with the collapse button . Depending on the possible connections shown in the view and on artifact views for this type of artifact, the expanded artifact may look different. The following images show an expanded bundle that shows connection ports to the left and right side because it is shown in a view that also shows its dependencies. This ...ui bundle has a dependency (the port to the right) and other bundles have a dependency to it (left port).

The next image shows an external bundle, i.e., a bundle that is part of the project model, but marked as external in the extractor or model DSL and therefore is less opaque and can be filtered in a sidebar option.

The next image shows an artifact that has a defined artifact view. With the option for this artifact view enabled in the options sidebar, this feature shows a view of bundles, filtered to show only the bundles contained in this feature.

The expand all button expands all elements contained in an overview.

All collapsed artifacts in an overview can be hidden and restored with the collapse and expand buttons that are shown inside the overview.

A selected node is highlighted with a blue border color. Furthermore, any directly connected elements and equal elements in different views are highlighted the same way. I clicked the .ui.view bundle on the left in this following image, all directly connected dependency edges and dependencies are highlighted in blue as well.

Views are usually expanded and connected in-place. That means, the overview node from the initial view context is shown around the content per default. To focus on a particular view, the focus button focuses a view and removes the container around it, while the unfocus button unfocuses that element again and shows the view inside the main overview.

As seen above, bundles with connections to other elements have black filled rectangles as ports on their left or right sides. Hovering the mouse over such a port indicates the number of connected elements in that direction, while clicking the port expands and connects all required bundles (right bundle ports), requiring bundles (left bundle ports), or the corresponding connections from other artifacts. This is the resulting view from clicking once on the right port of the ...ui bundle from above.

If all available connections related to a specific port are shown in the view, that port’s fill color changes from black to white. To simplify this common use case, clicking the port while holding down the ctrl key expands all connections in that direction recursively.

The entire dependency or service hierarchy in a view can be connected at once with the connect all button . This icon is shown in all overviews that can show some connections, i.e., it is shown in the bundle dependencies and services view due to direct connections of their shown artifacts and in the features view due to the implicit dependencies of the contained bundles.

Any type of artifact can be filtered in an overview with a regular expression matching against its identifier.

The common prefixes of all shown element names can be removed from the view. For example, all bundle identifiers in many images here do not show the common prefix "de.cau.cs.kieler.klighd." but only an ellipsis. The full identifier can still be read in a tooltip on mouse hover.

Elements can either show their descriptive names, their unique identifiers, or no label at all for very large hierarchies.

Finally, the sidebar has actions to undo/redo the last interactions that changed the VCM.

Styling Customization

SPViz generates code with default styling for all artifacts and connections. It is a goal for future releases of SPViz to support easy customizable styling. For now, the generated code can be modified directly to apply style changes. When you regenerate your code, any manual changes to the generated code may be overwritten again by SPViz, so back up manual modifications in a separate folder to be safe.

The main style modifications can be applied to the code in the generated [your chosen unique view context metamodel package identifier root].viz folder generated by your view context metamodel. The src-gen/[your/id/in/folders/] folder is the root for such modifications. For example, the colors used by all artifact types are defined in the file Styles.xtend. Each artifact has four defined constants for its colors, two for the gradient for the normal artifacts and for the lighter external elements as well called COLOR_[artifact name], SECONDARY_COLOR_[artifact name], EXTERNAL_COLOR_[artifact name], and EXTERNAL_SECONDARY_COLOR_[artifact name]. If you change these in the code and rebuild the generated visualization tool, the new colors will be used instead.

Another example style modification is the modification of the port shapes. This following example modifies the default rectangular ports to circles / half-circles using KLighD's synthesis API to mimick the ball-and-socket notation of services in UML. The automatically-generated method with the name addConnectedServiceInterfaceConnectsServiceComponentNamedProvidedByPortRendering in Styles.xtend that defines the port rendering of a service interface with the service component that provides that service can be modified to show circle instead by replacing this line

return port.addRectangle => [

with this one

return port.addEllipse => [

Furthermore, to make this circle a little larger than the rectangle, the subsyntheses/ServiceInterfaceSynthesis.xtend needs to be modified in the section that calls the addConnectedServiceInterfaceConnectsServiceComponentNamedProvidedByPortRendering method from

width = 12
height = 12

to

width = 16
height = 16

The corresponding slightly larger half-circle for the connection of service components requiring a service interface requires these changes:

A change in Styles.xtend in the addConnectingServiceComponentConnectsServiceInterfaceNamedRequiredPortRendering method from

return port.addRectangle => [

to

return port.addArc => [
    startAngle = 90
    arcAngle = 180
    arcType = Arc.OPEN
    setAreaPlacementData => [
        topLeft = createKPosition(LEFT, 0, 0, TOP, 0, 0)
        bottomRight = createKPosition(RIGHT, 0, -1, BOTTOM, 0, 0)
    ]

and a change after calling the addConnectingServiceComponentConnectsServiceInterfaceNamedRequiredPortRendering method in subsyntheses/ServiceInterfaceSynthesis.xtend from