The Architecture Metamodel (A2M)

With the first SPViz DSL you can model the architecture of your own software project in a simple textual format. The modeled architecture metamodel (A2M) is an abstract definition of your concrete software architecture and can define arbitrary projects or models of arbitrary software revisions of your project.

metamodeling-hierarchy

This image shows the metamodeling hierarchy of SPViz. Taking the KLighD project as an example project for that we want to visualize its architecture, a project generator written with SPViz can extract a project model (PM) from the source code repository to be visualized by the tooling generated by SPViz. Alternatively, this model can also be written manually with the generated model DSL.

The basic structure of any architecture description using the SPViz architecture metamodel looks like this:

package [unique package identifier root for the generated Java packages, for example "de.cau.cs.kieler.spviz.osgi"]
SPVizModel [Name of the architecture, for example "OSGi"] {
    [A list of all types of artifacts in the architecture and their relationships]
}

This example models artifacts of the OSGi architecture from its different layers in the OSGi specification, specifically the module layer and the service layer. OSGi's module layer defines so-called bundles that combine classes and packages of the Java world and connect to other bundles via dependencies. To model this in SPViz, the following lines are added to the architecture metamodel:

Bundle {
    Dependency connects Bundle
}

The top-level elements define the name of the new artifact, here Bundle. The definitions inside the bundle model the relations from the bundle to other artifacts. Here it shows that bundles can connect to other bundles via a connection defined as Dependency.

OSGi also defines some hierarchical structuring of its bundles into larger structures, for example via features and bundle categories. We can add these artifacts to the model as well and define that they contain and structure sets of bundles.

Feature {
    contains Bundle
}
BundleCategory {
    contains Bundle
}

Connections between different types of artifacts are also possible and can be shown for the service layer of OSGi. Bundles cooperate via services that are declared by service interfaces and implemented in service components. Service components implement service interfaces and therefore provide services via those interfaces that other service components may in turn require. We add these new contained artifacts to the above-defined bundle artifact and add the remaining connections according to this description.

Bundle {
    ...
    contains ServiceInterface
    contains ServiceComponent
}

ServiceInterface {
    ProvidedBy connects ServiceComponent
}
ServiceComponent {
    Required connects ServiceInterface
}

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

spviz.build: A generic folder generated the same for any .spvizmodel file with build information for the Maven build process and a target platform for those developing and adapting the generated code in their Eclipse IDE.
[your chosen unique package identifier root].model: Model code of your architecture. This represents all artifacts, connections, and containments defined in your architecture metamodel.
[your chosen unique package identifier root].generate: Template Java code that you can extend to extract a project model of your software project that conforms to the generated model code from the last point. To extend this code, start in the generated ReadProjectFiles.java file, which contains a list of the artifacts and connections that need to be extracted to fit your architecture metamodel. See the example implementation.
Multiple folders starting with [your chosen unique package identifier root].model.dsl: A textual syntax for your architecture metamodel, see the corresponding wiki site. The generation of these folders can be turned off with the --no-model-dsl CLI flag.
Multiple folders starting with [your chosen unique package identifier root].diff.dsl: A textual syntax for comparative views between different revisions of a project, see the corresponding wiki site. The generation of these folders can be turned off with the --no-diff CLI flag.