The View Context Metamodel (VC2M)

The second SPViz DSL lets you model the desired structure and filtering possibilities for your modeled architecture metamodel from the previous step. The modeled view context metamodel (VC2M) is an abstract definition of the views that should be explorable in for your software architecture.

This time we are on the right side of this metamodeling hierarchy of SPViz. Taking the KLighD project as an example project for this visualization, one possible view of a project model from the previous step visualized with the tool generated by SPViz is above image. It shows the dependency hierarchy originating from the ui.view bundle of the KLighD project. It was configured from an initial view of the tool like the following one, from where the entire project can be browsed and the view can be configured.

Typically, not all possible connections should be shown in any view, and not all artifacts of the same type should be in the same view part. Just showing everything at once is typically not the best visualization for project structures, but filtered subsets are. Therefore, the definition of a custom view context metamodel allows you to further structure your visualization.

The basic structure of any view context description using SPViz looks like this:

package [unique package identifier root for the generated Java packages, for example "de.cau.cs.kieler.spviz.osgiviz"]

import "[file name of your A2M, for example "osgi.spvizmodel"]"
SPViz [Name of the visualization tool, for example "OSGiViz"] {
    [A list of all views and their filters, see below]
}

This example shows the types of views that can be defined for this OSGi architecture model and configured views of example projects for them.

The first type to define are the views. For the OSGi architecture, this example wants to visualize the dependency hierarchy between bundles, the service hierarchy between its service interfaces and components, as well as an overview of the features and the cross-dependencies between the features based on their contained bundles. Therefore, we define three views in this view context metamodel:

BundleDependencies {
    ...
}
Services {
    ...
}
Features {
    ...
}

This results in the initial browsable overview from the last image. Clicking on the expand buttons would not do anything yet, because we have to tell SPViz what each view should display.

The bundle dependencies view is supposed to show all bundles and their connections, so that the bundle dependency view from above can be shown. For that, fill the view with references to the artifacts and connections that should be able to be connected from the architecture metamodel:

BundleDepenencies {
    show OSGi.Bundle
    connect OSGi.Bundle.Dependency
}

show and connect are key words of the DSL, the following part are direct references to the artifact and connection names that you defined in your A2M. Generating a visualization tool from this view context metamodel lets you browse your bundles and their dependencies as described on this page, one example view is the bundle dependencies view from above.

The same concept can be used to define a view for the services, only that this time multiple artifacts and connection types should be shown in the view:

Services {
    show OSGi.ServiceInterface
    show OSGi.ServiceComponent
    connect OSGi.ServiceInterface.ProvidedBy
    connect OSGi.ServiceComponent.Required
}

An example view of the services inside the language demo program is shown in this image.

For the overview of Features that can show their contained bundles, we need to use the concept of artifact views. An artifact view defines what other views can be shown inside an artifact and which contained elements are shown inside such a nested view.

OSGi.Feature shows {
    BundleDependencies with {
        OSGi.Bundle from OSGi.Feature>OSGi.Bundle
    }
}

This code needs to be added after the definition of all views. It says that each feature from the OSGi A2M can also show an inner bundle dependencies view as defined above. As the bundle dependencies view shows bundles, this artifact view definition needs to define how the artifact view should filter its bundles from all bundles in the entire project. The chain OSGi.Feature>OSGi.Bundle defines that this feature (always the first element in the chain) should show the bundles that are in a direct containment relation of the features. The last element in the chain always needs to be the target artifact in front of the from. Indirect chains are also possible, as used in the full OSGi example.

This allows for filtered views that only show the dependencies of the bundles contained in a feature and can be applied to any other type of artifact. An example artifact view is shown in this image.

To show the connections between features in terms of the dependencies of their contained bundles, a category connection is required. It can be defined inside the view for features as follows:

    Features {
        show OSGi.Feature
        connect OSGi.Bundle.Dependency via OSGi.Feature in BundleDependencies
    }

Its basic definition is the same as other shown connections, as it is defined inside a view and references a specific connection from the architecture metamodel. However, the connection is not defined by the artifact shown in the view (in this case, the bundle dependency is not defined by the shown feature), so the relation of the connection to the artifact is defined after the via part. This view context metamodel defines an artifact view for bundle dependencies inside features (see above), so the bundle dependencies can be shown and connected via the bundle dependencies view of features shown in this view. An example view configuration featuring this category connection is shown in this following image. It shows the same bundle dependency hierarchy as in the other bundle dependency image above, now categorized and connected by their defining features.

This code combined in a single .spviz file can be used to generate a few folders with Java/Xtend code and build configuration using SPViz.

[your chosen unique package identifier root].build: The main entry point to build the model and visualization code and package it into different executable artifacts. Start a Maven build process via mvn clean package inside this folder to build the entire project. This will build 1. Maven artifacts for all generated packages listed in the architecture metamodel and from this list, 2. an Eclipse update site with the generated and built code inside the nested [package identifier root].repository/target/repository folder, and 3. a language server in one folder up in the [package identifier root].language.server/target/[package identifier root].language.server-0.1.0-SNAPSHOT-shaded.jar file to be used together with the KLighD CLI. It will also build the model generator template with your manual modifications when calling the Maven build process with the additional -P generator arguments.
[your chosen unique package identifier root].language.server: Code for the configuration of the above-mentioned language server packaging your modeled visualization tool into an executable language server jar to be used in combination with the KLighD CLI.
[your chosen unique package identifier root].model: Model code of your view context. This represents all views and their shown connections and filters defined in your view context metamodel.
[your chosen unique package identifier root].viz: A KLighD synthesis with all views and interactive features of SPViz according to your view context metamodel.
[your chosen unique package identifier root].diffviz: Configurations and an additional KLighD synthesis for the difference visualization of different project revisions.