A2M

    architecture meta model
A3M

    architecture meta meta model
ADL

    Architecture Description Language
API

    application programming interface
CD

    continuous deployment
CI

    continuous integration
CLI

    Command Line Interface
DI

    Dependency Injection
DSL

    Domain Specific Language
EBNF

    extended Backus–Naur form
ELK

    Eclipse Layout Kernel
EMF

    Eclipse Modeling Framework
GLSP

    Graphical Language Server Platform
ID

    identifier
IDE

    Integrated Development Environment
JSON

    JavaScript Object Notation
KDM

    Knowledge Discovery Meta-Model
KLighD

    KIELER Lightweight Diagrams
KIELER

    Kiel Integrated Environment for Layout Eclipse Rich Client
LoC

    lines of code
LSP

    Language Server Protocol
MDE

    Model Driven Engineering
MIL

    Module Interconnection Language
MOF

    Meta Object Facility
MVC

    Model-View-Controller
OSGi

    Open Services Gateway initiative
PM

    project model
SPViz

    Software Project Visualization
UI

    user interface
UML

    Unified Modeling Language
VCM

    view context model
VC2M

    view context meta model
VC3M

    view context meta meta model
VS Code

    Visual Studio Code
XMI

     XML Metadata Interchange
XML

    Extensible Markup Language

morekeywords=package, SPVizModel, contains, connects, otherkeywords=,
morecomment=[l]//, morecomment=[s]/**/ morekeywords=package, import, SPViz,
shows, with, from, ¿, show, in, connect, via, and, connected, otherkeywords=,
morecomment=[l]//, morecomment=[s]/**/ morekeywords=, otherkeywords=,
morecomment=[s]??

# SPViz: A DSL-Driven Approach
for Software Project Visualization Tooling ††thanks: This work has been
supported by the project _Visible Code_ , a cooperation between Kiel
University and Scheidt & Bachmann System Technik GmbH.

Niklas Rentz and Reinhard von Hanxleden  Department of Computer Science
Kiel University, Kiel, Germany
<EMAIL_ADDRESS>
###### Abstract

For most service architectures, such as Open Services Gateway initiative
(OSGi) and Spring, architecture-specific tools allow software developers and
architects to visualize otherwise obscure configurations hidden in the project
files. Such visualization tools are often used for documentation purposes and
help to better understand programs than with source code alone. However, such
tools often do not address project-specific peculiarities or do not exist at
all for less common architectures, requiring developers to use different
visualization and analysis tools within the same architecture. Furthermore,
many generic modeling tools and architecture visualization tools require their
users to create and maintain models manually.

We here propose a DSL-driven approach that allows software architects to
define and adapt their own project visualization tool. The approach, which we
refer to as Software Project Visualization (SPViz), uses two DSLs, one to
describe architectural elements and their relationships, and one to describe
how these should be visualized. We demonstrate how SPViz can then
automatically synthesize a customized, project-specific visualization tool
that can adapt to changes in the underlying project automatically.

We implemented our approach in an open-source library, also termed SPViz and
discuss and analyze four different tools that follow this concept, including
open-source projects and projects from an industrial partner in the railway
domain.

##  I Introduction

This is joint work with the industrial partner _Scheidt & Bachmann System
Technik GmbH_ who has to maintain large software projects for a long duration,
a setting that is quite common in industry. To maintain a good understanding
of complex software architectures is a non-trivial task. Furthermore, one
regularly has to make new team members familiar with the existing software.
_Diagrams_ can aid understanding concrete connections and ideas and the
broader architecture of a system [1, 2]. However, it is still common practice
to create such diagrams manually. This requires significant maintenance effort
[3] and bears the risk of becoming inconsistent with the actual project.

There are multiple approaches to combat this issue. There are tools to
reverse-engineer the actual architecture of projects to compare it to the
modeled architecture and adapt them to each other [4, 5]. Other solutions
require a direct inclusion of the architecture design into the actual source
artifacts. Such architecture inclusion is usually done via extended languages
[6], Architecture Description Languages that are developed alongside the
architecture [7], or language-specific architecture systems such as OSGi111
OSGi™ is a trademark of the OSGi Alliance in the US and other countries.  [8,
9]. For example, Figure 1, a view of a tool generated by SPViz, provides a
very high-level view of a specific OSGi project highlighting its architecture
consisting of services, features, products, and bundle dependencies that can
be browsed to provide customizable views as shown later in the paper.

Figure 1: Screenshot of an architecture visualization tool synthesized by
SPViz, here for OSGi projects. The overviews can be interactively expanded to
show connections as shown in Figures 4 and 3. The view can be customized with
filters and interactive features in the open sidebar. Figure 2: View of the
internal bundle dependencies originating from the _klighd.ui.view_ bundle of
the KLighD444https://github.com/kieler/klighd project, synthesized by the tool
generated by SPViz based on structural and visual descriptions in s 8 and 12.
Figure 3: View on the same bundle dependency hierarchy as in footnote 4,
filtered by their categorizing features.

Irrespective of the taken approach, architecture visualization tools [10, 9,
11, 12] provide insights into legacy code. However, most of them are
_specific_ for one task or project style, making them unusable for most other
projects. As the use of programming languages and project structures
surrounding them changes over time, new tools to work with those languages and
structures must be developed. The problem for the developers is not only to
keep up with the technology, but also with all tool support outside of rather
general IDE and debugging tooling. For each new project structure, developers
will ask how project artifacts relate to each other and which hierarchies
exist, to explore and explain the projects. Alternatively to that project-
specific approach, one may use tools that support very _generic_ visual
languages such as defined in the UML standard. As stated by a survey by Lange
et al. [13], such languages can be used and understood by many developers,
architects, and other users of code. However, such generic techniques may fail
to be specific enough to describe the needs of domain experts and require too
much manual effort to yield pleasing and meaningful diagrams. Another survey
by Malavolta et al. [14] highlights what industry lacks in current
architectural tools. They mention _support for multiple views_ for
architectures and adequate _support for specific architectural styles and
patterns_.

Users want visualizations to automatically update to changes in the actual
project structure, removing the need to manually craft and update visual
descriptions by hand. Enabling a quick way to implement a new tool or tool
support for software projects to visualize their architecture offers the
different use cases of visualizations such as exploration, comprehension, and
documentation to any software project.

Tools using web technologies are increasingly popular for their superior
versatility and quick turnaround time with low to no installation
requirements. Interactive visualizations are no exception and should be usable
on any device in any environment, for example in online documentation about
systems. Advancements in that area for example with the generic visualization
framework Sprotty222 https://github.com/eclipse/sprotty/ , the Graphical
Language Server Platform (GLSP)333 https://www.eclipse.org/glsp/ , and a
Language Server Protocol (LSP) infrastructure for graphical modeling
infrastructure [15] show the feasibility of using diagrams in the web.

In the current state of the practice, for projects where no good specific
tools exist and architects do not want to use the traditional way of using
manually designed Unified Modeling Language (UML) diagrams, they need other
tool support. Thus, the research question we address in this paper is: How can
one create customized architecture visualization tools with minimal effort. In
answer to that question, we here propose a Domain Specific Language
(DSL)-driven approach, referred to as Software Project Visualization (SPViz).
SPViz uses project meta modeling with two DSLs, one to describe architectural
elements and their relationships, and one to describe how these should be
visualized. Provided with such architecture and visualization descriptions, we
propose to automatically synthesize a customized, project-specific
visualization tool. We have validated this approach with an open-source
library, also termed
SPViz555https://github.com/kieler/SoftwareProjectViz/tree/spviz24. An outline
of an initial view for further configuration of a concrete architecture
visualization tool synthesized by SPViz is shown in Figure 1.

As proposed in our previous work [9] for architecture visualization specific
to OSGi, the concept for that specific tool follows the _modeling pragmatics_
approach [16]. Specifically, it uses the Model-View-Controller (MVC) paradigm
[17] as a guiding principle. The approach separates the _views_ for
exploration and navigation from the _models_ of the underlying projects and
applies filtering and interaction possibilities as the _controller_. This
previous work only works for a single architecture and therefore lacks the
applicability to other architectures. SPViz automates the process of designing
such tools and adapts the concepts to arbitrary architectures. A dependency
hierarchy of an example OSGi project, where the visualization tool was
generated by SPViz can be seen in s 4 and 3. Here we emphasize the importance
of filtering in both the architectural description and visualization tooling
to not show everything at once, but focus on individual components of a system
and their context. The figures are interesting and readable, because they do
_not_ show many details, but filtered views, here for the investigation of the
project-internal dependency hierarchy of a specific bundle artifact.

_Outline:_ In Section II we recapitulate how the visualization and interaction
style proposed in our previous work [9] works for OSGi projects. Next, we
cover the main contributions:

  * •

We present the SPViz approach via two DSLs describing arbitrary architectures
and their visualization as a generalization of the OSGi visualization tool in
Section III.

  * •

We propose how to automatically generate a complete visualization tool, as
well as template code for a model generator akin to the OSGi visualization
using the DSLs based on example project architectures in Section IV.

  * •

We illustrate the DSLs using example projects, both open source and ones from
industrial partners, and present the generated tools with their feedback in
Section V.

Finally, we compare related work in Section VI, discuss further directions in
Section VII and conclude in Section VIII.

##  II Visualizing Specific Project Architectures

Figure 4: The usage process of the view tools with its core, the view context
model. It is used to configure and filter views for later reuse. Solid arrows
depict data flow, dashed ones the interaction paths to control the VCM.
Adapted from Rentz et al. [9]. Figure 5: Collapsed (klingontranslator) and
expanded (englishtranslator) products. Expanded product shows filtered views
(services, bundle dependencies), here in their current collapsed form. Figure
6: The meta modeling hierarchy of SPViz. The shaded top is our proposed
abstraction, the center contains examples for the different models.

In our previous work [9], we presented a visualization tool specific to the
OSGi architecture to aid developers understand legacy OSGi projects and to
document actively developed systems. The use of the diagrams, according to the
previous paper, allows users to move from manually drawn diagrams such as UML
to automatically created diagrams that are useful for system documentation
purposes. The visualization tool utilizes the tooling of the KIELER
Lightweight Diagrams (KLighD) framework [18] with automatic layout by the
Eclipse Layout Kernel (ELK)666https://www.eclipse.org/elk/. KLighD provides a
visualization of OSGi projects given a _model synthesis_ , which is
implemented in that tool. This visualization uses node-link diagrams to
represent structural relationships between architectural artifacts. This
follows the _graph-based_ visualization technique, a term coined by Shahin et
al. in a systematic literature review of software visualization [1]. This
section summarizes the concepts and visualization techniques, the later
sections generalize these concepts for arbitrary architectures.

The _ view context model (VCM)_, depicted in Figure 4, is the central model
for interaction with the tool by modifying and filtering views to be reusable
for documentation purposes in evolving (software) projects. This model is
entirely hidden from the user and only modified by interaction with the UI.
The _ project model (PM)_ contains the extracted data of a concrete project,
here for an OSGi project. It is the data source of the VCM and describes the
project at its state in time when the PM was generated. The PM conforms to the
meta model of the OSGi architecture, therefore we also call this the _
architecture meta model (A2M)_. It models all possible PMs for OSGi projects.
When initially visualizing a PM, a VCM is created. Together with the model
synthesis and KLighD, this allows visually browsing different views sensible
in the OSGi environment.

Figure 1 shows the view of such an initial VCM as it is initially created for
any OSGi project. Interacting with the view via the options, filters, or the
user interface (UI) will change the VCM directly to reflect the currently
shown and connected elements. footnote 4 is such a configured view
investigating the KLighD framework, which also uses OSGi as its project
architecture. The view is configured to focus on the bundle dependencies view
to show all bundles that are directly or indirectly required by its
_klighd.ui.view_ bundle. All connections of the project as defined in the A2M
and configured to be shown in the meta model for the VCM, the view context
meta model (VC2M) can be interactively added or removed to show any hierarchy.

Filtered views based on e.g. OSGi products can be browsed as shown in s 3 and
5. In Figure 5 the products show child views for their services and for their
bundle dependencies, which can be expanded to browse only the service
artifacts/bundles used in that product.

By interacting with the views with the mouse, the VCM and with that the view
can be modified. Overall, the user can

  * •

(un-)focus and expand/collapse views,

  * •

show/hide all collapsed artifacts,

  * •

connect the connected artifacts of an artifact following a connection once, or
for all artifacts at once,

  * •

remove all connections of an artifact,

  * •

undo/redo the last action or reset the view to its default,

  * •

filter to show or hide the individual artifact views,

  * •

filter artifacts based on their IDs,

  * •

export a VCM to document specific parts,

  * •

and more standard browsing interactions.

Of these, showing/hiding the collapsed artifacts, connecting artifact
connections recursively, and removing all connections from an artifact are not
in the previous work and newly implemented in SPViz based on feedback by our
industrial partner.

The collapsed and expanded artifacts are always shown beneath each other in
two separate areas, as shown in Figure 5. On top the collapsed artifacts are
packed together, where the tool features a search and filter of the artifacts
to be inspected further. On the bottom the expanded artifacts are shown with
their filtered artifact views or their connections to other artifacts in the
view as in footnote 4. Furthermore, in footnote 4 the collapsed artifacts are
also hidden and the interactive buttons are deactivated, to allow the export
of such a VCM as part of the documentation for that project without cluttering
the view.

In SPViz, the colors of all artifacts are picked in a way to have a low
saturation to have a good contrast to black text, while trying to not collide
with the colors of other artifacts. This is done by choosing the hue of the
color based the low-discrepancy sequence on remainders mod 1 of integer
multiples of the golden ratio [19], to have consistent colors with good
contrast between them, no matter how many different artifacts are used in the
A2M. The colors could also be manually picked by the visualzation tool
designer to match known styles for the specific architecture.

Overall, this previous work [9] can be used for OSGi projects, but lacks usage
for any other architecture. We now further generalize this visualization tool
and make it applicable to arbitrary architectures.

##  III The SPViz DSLs as Architecture
and View Meta Meta Models

To allow domain experts to conceptualize a visualization for software projects
following arbitrary architecture meta models (A2Ms), we define meta meta
models to describe the general structure of a software architecture and an
abstract way of visualizing that architecture. We illustrate the meta modeling
hierarchy of visualization tools relative to our previous work [9] with our
proposed abstraction in Figure 6. Section II explains the project, view, and
their respective project model (PM) and view context model (VCM). We refer to
the meta model for describing the architecture the _ architecture meta model
(A2M)_, and the meta model for the possible types of shown connections and
views the _ view context meta model (VC2M)_. This section introduces two DSLs
for defining such A2Ms and VC2Ms, thus making the DSLs themselves an _
architecture meta meta model (A3M)_ and a _ view context meta meta model
(VC3M)_.

###  III-A The Architecture Meta Meta Model

Domain experts can describe a project architecture using our definition of the
_ architecture meta meta model (A3M)_ DSL. The grammar is defined using the
Xtext [20] framework and shown in extended Backus–Naur form (EBNF) in Figure
7.

All project structures are different in their concrete realization in the
sense of which files and which configurations define the underlying project.
However, in an abstract sense projects always contain different _artifacts_
and _references_ between these artifacts. _Artifacts_ can be coarse- or fine-
grained parts of a software system such as entire products, features, classes,
or even statements, which may refer to other artifacts. _References_ can be
further specialized into _connections_ , e.g. dependencies connecting
different artifacts, and _containments_ , e.g. some product artifact
containing a set of packages. We define these components as the A3M. The A3M
can be applied to most architectures to show how all their different artifacts
relate to each other. This concept is comparable to other meta models used for
Model Driven Engineering (MDE) such as the Meta Object Facility (MOF) [21], in
a simplified version. We do not need its relations special to object
orientation, such as class inheritance to describe arbitrary software
architectures. We have found that the A3M suffices to describe interrelations.
In fact, class inheritance can be modeled with our model through the use of
references from a class artifact to itself. This is due to the A3M being self-
describing, just as the MOF. Furthermore, the A3M restricts the designer to
design their architecture in a minimal way and to restrict it to a unique way
for later code generation.

⬇ SPVizModel = ”package” Name ”SPVizModel” Name ”{”{Artifact}”}” Artifact =
Name [”{”{Reference}”}”] Reference = Containment|Connection Containment =
”contains” Artifact Connection = Name ”connects” Artifact Name = ? Letters,
numbers, full stop ?

(a)  Figure 7: a3m DSL grammar.

⬇ // generate code into this package package de.cau.cs.kieler.spviz.osgi //
name of the project structure is OSGi SPVizModel OSGi { // the artifacts the
project contains Feature { // features give structure to their bundles
contains Bundle } Bundle { // bundles may connect to other bundles // as a
connection called ”Dependency” Dependency connects Bundle // services are
defined within bundles contains ServiceInterface contains ServiceComponent }
// service components can require and provide // other service interfaces.
Inverting the // provision for a consistent ”requires” direction
ServiceInterface { ProvidedBy connects ServiceComponent } ServiceComponent {
Required connects ServiceInterface } }

(a)  Figure 8: Example A3M DSL usage. Figure 9: Class structure as generated
for the example OSGi A2M. Figure 10: Abstract class structure of the generated
code for the A2M.

Figure 8 shows an example use of the A3M DSL to describe the OSGi architecture
A2M. This example intentionally re-visits the OSGi architecture to show that
the previous tool [9] can entirely be generalized. The information in the
example consists of the name, artifacts, their hierarchy, and connections. The
resulting meta model describes coarse- and fine-granular artifacts of the OSGi
architecture modeling bundle dependencies and service hierarchies. Blocks
within the _SPVizModel_ block define the artifacts that the architecture
contains, here _features_ , _bundles_ , _service interfaces_ , and _service
components_. These artifacts are structured according to the artifacts that
they contain. In this example, the features are structured by the bundles that
they contain. This artifact structure can be used to automatically generate a
class hierarchy, which is part of the subsequent code synthesis. A
corresponding class diagram with containments modeled as references is shown
in Figure 9. Figure 10 shows the pattern for the class structure for any A2M
in general. Every artifact type gets its own class and the connections and
containments are handled via reference lists.

PM instances of this OSGi A2M describe information of the structure of
concrete projects to model dependencies between bundles from the project
itself and external ones. One can also get an insight into otherwise more
obscure connections of different service components, as defined in the service
layer of the OSGi specification [8], in the specification with the name
_service objects_.

This example OSGi A2M taken from the A3M DSL is now comparable to the manually
described one from Section II. However, only using the A3M is insufficient to
define how different views should be configured and filtered. For that, we
define the _VC3M_ as another DSL.

###  III-B The View Context Meta Meta Model

The _ view context meta meta model (VC3M)_ makes it possible to describe which
of the artifacts and their connections from the A3M should be visualized in
different views. 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.

⬇ SPViz = ”package” Name ”import” URI ”SPViz” Name ”{” {View} {ArtifactShows}
”}” View = Name ”{” {ShownElement} {ShownConnection} {ShownCategoryConnection}
”}” ShownElement = ”show” Artifact ShownConnection = ”connect” Connection
ShownCategoryConnection = ”connect” Connection ”via” Artifact {”>”Artifact}
”in” View ArtifactShows = Artifact ”shows” ”{” {ArtifactView} ”}” ArtifactView
= View ”with” ”{” {Artifact ”from” Artifact {”>”Artifact}} ”}”

(a)  Figure 11: VC3M DSL grammar, referring to the A3M DSL grammar in Figure
7.

⬇ // generate code into this package package de.cau.cs.kieler.spviz.osgiviz //
refer to the ”OSGi” model above import ”osgi.spvizmodel” // this visualization
is called ”OSGiViz” SPViz OSGiViz { // the available views for OSGiViz // this
is the view for services Services { // show the service hierarchy with all //
its artifacts and connections show OSGi.ServiceInterface show
OSGi.ServiceComponent connect OSGi.ServiceInterface.ProvidedBy connect
OSGi.ServiceComponent.Required } // view for bundles and their dependencies
BundleDependencies { show OSGi.Bundle connect OSGi.Bundle.Dependency } // view
of features, for filtering Features { show OSGi.Feature //connect features via
their bundle dependencies connect OSGi.Bundle.Dependency via OSGi.Feature in
BundleDependencies } // features can show filtered artifact views,
OSGi.Feature shows { // inner views connected as defined above
BundleDependencies with { // only bundles contained in the feature OSGi.Bundle
from OSGi.Feature¿OSGi.Bundle } } }

(a)  Figure 12: Example VC3M DSL usage, referring to the example in Figure 8.

Therefore the VC3M allows the architects to further structure their
visualization. Its grammar defined by an Xtext DSL is shown in Figure 11. The
VC3M, connecting to an existing A3M, describes _views_. These views refer to
the A3M and define which artifacts and which of their connections can be
visualized within them. This allows for configurability, to have views
specifically intended to show one kind of connection between artifacts, or
multiple connection types for broader overviews. Furthermore, the VC3M makes a
configuration of how the artifacts themselves should be visualized possible.
As artifacts from the A3M may contain other artifacts, we allow the definition
of _artifact views_ as views filtered to the context of this parent artifact.
Artifact views can be used especially for artifacts that have the purpose of
organizing other artifacts, such as bundle categories as subsets for bundles
in the OSGi specification [8]. The artifact views refer to the views defined
above with their artifact and connection types and filter the artifacts to the
context of this artifact view’s parent artifact. Finally, the _category
connections_ are another way of organizing and filtering views. They are part
of views and show the implicit connections between categorizing artifacts that
are in a relation to each other via some contained artifact type. Category
connections are defined by the connection they represent, the artifact
hierarchy following the parent-child hierarchy to get from the connected
artifacts to the defined connection, as well as the inner view to connect to.
The following example will further illustrate this concept.

Figure 13: Traditional (left, gray) and proposed (red) process for developing
a new software project visualization tool. A2M and VC2M are written in the
DSLs proposed here. Boxes represent files, software packages, and applications
in UML style.

Continuing the OSGi example, Figure 12 shows a possible use of the VC3M DSL to
describe a VC2M for the OSGi A2M. The configuration matches and extends the
OSGi visualization described in Section II, thus showing that the previously
manually designed OSGi visualization can be generalized using our DSLs. The
example defines a new visualization for the OSGi architecture called _OSGiViz_
and defines what views can be shown in general, as well as how artifacts can
reuse these views to filter views down into a sensible context. The views
called _services_ and _bundle dependencies_ clarify that the artifacts and the
connections related to them from the underlying OSGi model should be shown. An
example view of the bundle dependencies can be seen in footnote 4. The view
named _features_ shows an overview of all possible features and a category
connection.

Through configuration of an _artifact view_ , the features displayed in their
overview show filtered views specific to the individual features defined
within an OSGi project. This artifact view defines the filters for a bundle
dependencies view. It defines how the bundles that should be shown in a bundle
dependencies view as defined above are filtered. The DSL allows referring to
the requested artifacts by chaining the artifacts together via their
_contains_ relation of the A3M. In this example it means that all bundles are
shown that are listed in the feature’s child bundles. This way, whereas a
general view for bundle dependencies would show all bundles as they are used
and defined in the whole project, the feature-specific artifact view for
bundle dependencies shows the filtered view, only with bundles relevant for
the feature. Figure 3 illustrates this, as each feature only shows the bundles
in their bundle dependencies view that the feature contains.

The _category connection_ defined in the features view makes it possible to
show a relation between features, although the OSGi A2M does not define any
direct connections for features. Because features contain bundles, which
themselves define the bundle dependencies connection, this category connection
enables showing the relation between the features in terms of their bundle
dependencies. That is, a connection between features will be shown, if a
bundle contained in one feature has a connection to a bundle contained in
another feature. Figure 3 illustrates this. Here the _view_ and _ide_ features
have a shown dependency, because the _ui.view_ bundle within the _view_
feature has a dependency to the _ide_ bundle within the _ide_ feature, as also
seen in footnote 4. Edges are drawn thicker if they bundle multiple
dependencies into a single edge. This is an important filtering view that does
not require more effort in the later PM extraction, but just a single line in
the VC2M.

##  IV Project Visualization Tool Synthesis with SPViz

Figure 13 shows the proposed development process for software architects who
want to apply the visualization technique from our previous work [9] to their
project. They need to describe the architecture and its visualization as
described in Section III and extract information about the real artifacts of
the project on their file system into a PM. To design the models, questions
such as ‘What connections and hierarchies in the code should be made visible?’
and ‘What kinds of artifacts define and order these?’ need to be answered.
This first layer of modeling a visualization and the architecture is the main
task of an architect when using SPViz. Traditionally, the architect does not
have access to this first layer and needs to develop all code in the second
layer manually or use an entirely different approach. This traditional way was
done in our previous work [9], showing the simplification the DSLs provide
compared to that process.

###  IV-A Visualization Framework Generated from the DSLs

Our implementation of the SPViz approach separates the generated visualization
into multiple parts and uses Integrated Development Environment (IDE) support
and the code generation features of Xtext for DSLs for that purpose. This code
generation is the second layer of steps in Figure 13 and will be automatically
executed when developing the DSLs in Eclipse. Once the user is finished
designing their A2M, SPViz will create an Eclipse Modeling Framework (EMF)
model of that A2M following the class structure in Figure 10. Such a model
contains a single project class containing lists of all artifacts defined for
that project. For the OSGi example from above, this results in the project
class _OSGiProject_ as in Figure 9 containing lists of its features, bundles,
service interfaces, and service components. Every artifact then has lists that
refer to all artifacts they are in a containment or connection relation to.
I.e. each artifact refers to the source or target artifact for each connection
it is used in, as well as the parent or child artifact for each containment it
is used in. More specifically, bundles refer to their contained service
interfaces and components, to the features they are contained by, as well as
the bundles they refer to and are referred by the dependency connection. That
means that every relation can be followed both ways in this model and any
change to any of the lists will automatically update its opposing list by EMF.

The second part created by SPViz is a template for a PM generator. The
template is a complete program with a dependency on the generated EMF model of
the A2M. It comes with a Maven build, which can bundle it into an executable.
The template contains a file _ReadProjectFiles.java_ which is missing the
architecture-specific extraction of data from the project’s sources. It
provides methods to create and connect all artifacts as defined in the A2M as
well as a checklist of all artifacts, connections, and containments that need
to be extracted in the generator. Examples described in Section V implement
this template to show its feasibility. Alternatively, an extractor can be a
separate program or tool. Our application programming interface (API) requires
an EMF model instance following the class structure of Figure 10 in the open
Metadata Interchange (XMI) format proposed by OMG [22], which can be
implemented by any tool. For more information about the XMI model API, see the
EMF book [23]. This open format allows other code mining and reverse
engineering tools to work together with our A2M and therefore with the
visualization tool.

Because the A2M and its generator can be used isolated from the VC2M, this
allows users to write different VC2Ms for the same A2M. This is useful so that
a single model generator can create a model of the current state of a project,
which can be visualized using different VC2Ms.

Once the user is finished designing their possible views in the VC2M, SPViz
will create four more modules: the EMF model and code to support that VC2M
that yields a visualization using the KLighD framework [18], a language server
to enable viewing KLighD diagrams in web environments [24], as well as a Maven
build system. This can be packaged together either as Eclipse plug-ins or as a
standalone application to be used together with the KLighD CLI [25]777
Available on GitHub: https://github.com/kieler/klighd-vscode .

As a different concept, one could think of visualizing systems just using the
DSLs without code generation, thus having a single generic SPViz tool that
could handle all visualizations, given the DSLs. However, that would
complicate writing a model generator, as it could not programmatically depend
on the A2M model code, but would require more complex meta-parsing of models
and it would ignore the benefits of the MDE workflow with the EMF models.
Furthermore, the tool itself would need the DSLs to run and parse the
configurations, making the tool less concise for its use case. However, such a
generic tool would remove the need to generate, build, and execute the built
tool first from the DSLs and allow the direct execution of such a tool, thus
creating a tradeoff. We opted for the generation approach, mainly to make the
subsequent implementation/adaption of the model generator simpler.

###  IV-B View Your Visualization Anywhere

SPViz is designed to work with any project architecture, causing the range of
such an architecture’s main development IDE to be pretty much any IDE. The
tool support for development in any language should try to follow the IDE, as
for example requested by Charters et al. [26] for visualization tools or
presented in tools such as VisUML [11]. As there is no widely-adopted
framework or API to add diagrams in many IDEs yet, such an integrated support
is not feasible. However, the use of web tools and tools developed with web
technology in mind is growing and allows for an easy access. Therefore, we
also make use of web technologies for the configuration and deployment of
architectural views.

While individual deployment of tools such as the individual tools generated by
SPViz can vary between projects, they can be integrated and configured into of
a largely automated process after their initial setup to view the models in
the web or some IDEs directly.

The initial setup of the individual visualization tool is supported mainly in
the Eclipse IDE. This includes the development of both DSLs and the
implementation/adaption of a model generator for the PM. From there, most
other use cases can be automated and integrated into existing web
documentation. We think that after the initial setup, the tool is best used by
first integrating the model generator into the continuous integration (CI)/
continuous deployment (CD) chain of the project. The model generator template
has a Maven build, which will create an executable to call in CI/CD for every
iteration where it should update the documentation. Architects can use the
generated PM as well as the visualization tool to configure some specific
views and to put their corresponding VCMs into the documentation. Here the
architects are free to configure the views anywhere the final visualizations
can be displayed as well. That is, the diagrams can currently be shown in the
Eclipse IDE, in Visual Studio Code (VS Code), or embedded in web sites (see
Figure 1) by using KLighD or the KLighD Command Line Interface (CLI). The view
configuration of that PM can be stored as its VCM and deployed to the
documentation, making it possible to update the PM generated by the CI/CD to
always have most up-to-date documentation without the need to adapt the VCM.

As another use case, the visualization applications and PM generator designed
for the architecture can also be distributed to other developers of the
project for exploration outside of the pre-configured documentary views.

##  V Preliminary Evaluation and Validation

We evaluate our proposed concept in two ways. First, we show its flexibility
and usability for diverse project architectures by realizing four different
A2Ms and VC2Ms via the DSLs, motivated by open source projects and projects
developed by our industrial partner. For each resulting tool, we evaluate the
tool usability with these open source and industrial projects and do a
quantitative analysis on the effort reduction using SPViz for the OSGi
example. Second, we evaluated different user stories for different user groups
of SPViz and asked two users of different projects of our industrial partner
for feedback on their goals with the generated project visualizations and
their successes and criticisms.

###  V-A Testing with Real-World Examples

We answered the design questions as mentioned in Section IV for four different
project architectures and modeled the A2Ms and VC2Ms accordingly. As some
examples are rather specific on the project configurations, e.g. being for a
specific build and dependency system with a specific Dependency Injection (DI)
framework, they do not directly apply to most other projects. However, they
are easily configurable and combinable, so that tools working for other
architectures with their specific use cases are built quickly. The models and
generators for the examples can be found in the SPViz examples repository888
https://github.com/kieler/SoftwareProjectViz-examples/tree/spviz24 .

####  V-A1 OSGi

For the OSGi visualization, the created models aim to visualize dependencies
within the _module layer_ and service relations within the _service layer_ of
the OSGi specification [8]. The example, which is slightly extended compared
to the OSGi example from s 8 and 12, also uses _products_ to further organize
the individual components and allows the view of service connections in
relation to their parent bundle artifacts as category connections. This
example architecture visualization was designed as a first proof of concept.
It indicates that the interactive visualizations can in fact be generalized
from the implementation of our previous work [9] and result in equivalent
views conveying the information that the architecture-specific visualization
does. The PM generator for OSGi projects scans through a repository and parses
the data of _META-INF/MANIFEST.MF_ files for bundles, _feature.xml_ files for
features, and _*.product_ files for products. Furthermore, it parses _OSGI-
INF/_ folders and the Java files for definitions and connections of service
components and interfaces and creates an OSGi PM based on that data for any
OSGi project.

Figure 14: The interfaces and resolved classes providing those interfaces for
the _SvgExporter_ class as they are pre-configured by Sprotty’s main
repository.

This example was verified with a project from our industrial partner, as well
as the KLighD and Semantics frameworks of the
KIELER999https://github.com/kieler project. The partner project consists of
144 bundles plus 109 additional dependent bundles, as well as 285 service
artifacts. The KLighD and Semantics frameworks consist of 25 plus 196 bundles
and 166 plus 144 bundles, respectively. Example views of this are shown in s 4
and 3.

To compare the effort of a manual architecture-specific implementation and the
SPViz approach, we compare the manually written lines of code (LoC) using the
SPViz approach for the OSGi example and the code generated from our tool. We
compare to the generated code instead of the manual implementation because of
slight differences and improvements between the tools and similar LoC in the
generated and manual tools. The A2M and VC2M descriptions using the DSLs for
this OSGi example have a combined 76 LoC and the PM generator template was
extended by 466 LoC in Java to extract all OSGi-specific artifacts, their
connections, and containments of any such OSGi project. The generated project
consists of 318 LoC of EMF model code and 8654 LoC of Xtend and Java code that
would have to be written manually without SPViz, plus the 466 LoC of above to
make the generator template functional. These numbers do not include the 25
000 lines of Java code that are further generated from the generated EMF
models, as they do not add to manual work in either setup. Comparing the
effort on a LoC basis, this yields a reduction in the manually written LoC of
$1-\frac{76+466}{318+8654+466}=94.3\%$. The effort is further reduced because
the generated tool comes with a release engineering configuration that builds
and packages the generated tool as an Eclipse plugin or as a web tool to run
in web pages in conjunction with the KLighD CLI.

####  V-A2 Maven and Spring DI

A second example visualization using SPViz has the goal to visualize two kinds
of connections that may occur within Java projects—dependencies between
_modules_ as defined by its Maven101010 https://maven.apache.org/ build
system, as well as dependencies and provisions of _service components_ and
_interfaces_ using DI as defined in the Spring Framework111111
https://spring.io/projects/spring-framework . These connections are structured
via _Maven artifacts_ bundling together multiple child modules. We want to
clarify to not confuse these Maven artifacts with the artifacts of our A3M.
The modeled Maven artifacts are one kind of artifact as defined by the A3M.
This modeled structure is similar to the OSGi example and shows that different
systems can be modeled and therefore visualized. The main difference here is
how both examples have their different artifacts persisted in the file system.
For the Maven modules and artifacts, the generator parses the _pom.xml_ files
to build the PM of the hierarchy and the module dependencies. The DI artifacts
are extracted by parsing the Java files looking for interfaces and classes
with @Inject and @Named annotations.

This example was designed by our industrial partner and verified by them with
a project consisting of 34 modules and 175 service artifacts. Their goal was
to use such a visualization tool for automatically updating documentation and
for onboarding of new developers and maintenance. Other projects can also
reuse parts of this design and model extractor, as the project structure based
on the Maven build and the DI information are separate and can be used with
other systems. This example does not visualize all possible DI configurations
of the Spring Framework, as the use case of our partner only uses the
annotation-based configuration of components and requirements via @Inject and
@Named annotations directly in the Java code. Therefore this example supports
to extract these annotations, but no further Extensible Markup Language
(XML)-based configuration or other annotations.

####  V-A3 Gradle

Many projects use build tools such as Gradle121212 https://gradle.org/ to
define the project structure, dependencies, and to automate the build process
and tests. This build system is extensible and features a look into the
project structure, dependencies, etc. as a direct part of the build process,
thus making it easier to reuse that data for analysis tools. Designing the
DSLs and generating the visualization code for any project architecture can be
done quite quickly. However, programming an extractor for any project style
can require deeper insight into the project structure and its build tools and
used frameworks. Reusing the data provided by frameworks and build tools such
as Gradle can cut down the cost to develop such an extractor and also make it
less error-prone. With Gradle, data can be extracted by the same tool that is
used to execute or build the project.

This Gradle example was verified with the open source project Spring
Boot131313 https://github.com/spring-projects/spring-boot , which contains a
total of 187 so-called _projects_ plus 729 further dependent projects. To make
this example work together with its Gradle build system, we added a task to be
executed for each sub-project during the build. This collects the information
of the _Configuration API_ of Gradle and presents it to the model generator in
a more accessible JavaScript Object Notation (JSON) format. Similarly, other
code miners and extensible project build systems can be used to extract the
project information for other project types. This example shows the
feasibility of using the build system to our advantage and can be combined
with other hierarchies as shown in the other examples.

####  V-A4 Yarn and InversifyJS

Finally, to show another full visualization combining dependencies and
services outside of the Java programming language, we combined the dependency
management of TypeScript projects using Yarn141414 https://yarnpkg.com/ with
the InversifyJS151515 https://github.com/inversify/InversifyJS DI framework.
The artifacts for this example are parsed by analyzing the _yarn.lock_ file
generated by Yarn to extract the packages and their dependencies and by
parsing the TypeScript source files to search for interface-to-class bindings
and @inject and @injectable annotations to create the hierarchy as described
in the other examples.

We verified this with the open source framework Sprotty161616
https://github.com/eclipse/sprotty with a dependency tree of 906 packages and
126 defined service artifacts. An example view showing the configuration of
injected services as they are required by the _SvgExporter_ class is shown in
Figure 14. Here every other layer represents either a class (green), which was
configured to provide its service to some interface, or an interface (blue)
that is injected to a class. Being a quite small framework, InversifyJS has no
tool to visualize such hierarchies to our knowledge, so this is a good
showcase to implement novel visualizations. However, this example shows a
possible usability issue. The PM is defined as an EMF model, which can be best
extracted in Java, as the framework supports programmatically building the
model, whereas writing generators in other languages would require manually
conforming to the XMI definition of the PM, which is more effort than using
the framework directly. Future work can circumvent this issue by providing or
reusing another exchange format.

###  V-B User Stories and Industry Feedback

SPViz can be used by varying user groups with different goals and desires for
a tool solution. Next, we present and analyze three such groups and their
implications for the tool design.

As a first user group we identify the _software developers_ , or _end users_.
They want to learn and understand the system they are developing to be able to
improve and extend it. For this, they need reliable and up-to-date information
about the system and a way to filter that information to some context.
Furthermore, the effort for acquiring such information should be low. A
technical solution for the software developers should allow for different
representations [14]. The information should furthermore update automatically,
for example by integration into the build process, to lower the effort to use
the solution and always have up-to-date information. Finally, the solution
should be close to or integrated into their development IDE or the
documentation [26] to avoid bloating their workflows.

In the second user group we identify the _technology experts_ as the tool
designers for individual architectures. They need a tool that is tailored to
their domain technology (e.g. OSGi). If there is no such tool, or a tool is
not specific enough, development of a new one should be a one-time-effort with
low maintenance cost. A solution should therefore enable experts to convert
their domain knowledge into a usable tool and extract the data from the
underlying project. Its setup should furthermore be easy and understandable
and work with any technology.

Lastly, we identify the _software architects_ as a third user group. They need
to be able to configure views and highlight parts of projects. They also want
to integrate such views in the documentation and presentations for on-boarding
new developers. Their solution requirement is that view should be
interactively configurable, that this configuration can be persisted and that
views based on such a configuration automatically update to changes in the
underlying system.

Users can be in multiple of these groups and therefore require a combined
solution. We gathered feedback from our industrial partner on the usage of the
OSGi and Maven + Spring DI examples, being applied to internal projects. We
interviewed two participants, the product owner and one of the architects of
the projects, which are summarized here. One of them fits in the software
architect and partly in the software developer user group, while the other
fits in the technology expert and software architect groups.

One visualization goal the participants want to solve is to _explore_ the
modules of their architecture to get an overview, either overall or from some
specific view point. Another goal is to _explain_ the architecture and
specific hierarchies to others by creating architectural descriptions, without
the need to update such descriptions manually. Both participants stated that
previously such diagrams were crafted and updated by hand. While there are
many visualizations out there, this shows that at least for this questionnaire
the architects were not happy with other tools they used so far. Other tools
did not provide exactly what was required, because they were not usable as
well, or because the architects did not find the right tool yet.

Both had the problem that views for larger projects start to require more
effort to use and that clustering or pooling of artifacts into categories can
induce a better hierarchical view on parts of the system. This is especially
the case when there are many artifacts of the same type being visualized in
the same view. The artifact views and category connections we described help
to find the right context, as long as the model provides enough context via
some categorizations. Further ideas indicate that diagram layouts can become a
little too large for what is shown, which can be solved in future work.

Overall, their feedback indicates that the tool can and already has been used
to understand parts of different system architectures. As mentioned above and
further discussed in Section VII, some improvements regarding the actual views
and their interaction can be added, though that does not impair the proposed
approach to create visualizations for any project.

##  VI Further Related Work

As elaborated in the following, many related proposals go in the direction of
visualization for software architectures or using meta models to describe and
visualize architectures.

Following definitions used for software architecture, our tool mostly adheres
to them as well and supports tooling for software architectures. Citing Shaw
and Garlan [27], software architecture “involves the description of elements
from which systems are built, interactions among those elements, patterns that
guide their composition, and constraints on these patterns”. Especially the
composition and interaction among any element of systems is what we also try
to focus on, fitting to this definition of elements as we allow them to be as
fine-granular as methods and statements. Bass et al. [28] summarize multiple
definitions, quoting that “architecture is high-level, the overall structure,
structure of components and their interrelations, or components and
connectors,” indicating that our visualizations fit into the category of
architecture visualizations.

According to Clements et al. [29], “modern software architecture practice
embraces the concept of architectural views. A view is a representation of a
set of system elements and relations associated with them.” Views are the main
part in which architectures are perceived and mostly also designed. We here
interpret a view differently, in that it is a visual representation that
emerges from the underlying architecture. We aim to let users of SPViz use an
explicit architecture following these definitions, or implicit connections
through third parties through dependencies.

Shahin et al. [30] show how understanding architectural design decisions as
communicated by software architects needs to be visualized. They are however
manually created and do not allow the extraction of data for new
visualizations from the code alone. Shahin et al. [1] further discuss software
architecture visualization techniques and highlight how the architectural
design, architectural patterns, and architectural design decisions influence
what the real code will result in and how tool support is critical for
practical applicability of their visualization.

Architectures of projects are often described by Architecture Description
Languages (ADLs) in the literature. Medvidovic and Taylor [31] classify and
describe the use of ADLs in general. Using their words, at one end of the
spectrum, it can be argued that the primary role of architectural descriptions
is to aid understanding and communication about a software system. At the
other end of the spectrum, the tendency has been to provide formal syntax and
semantics of ADLs, powerful analysis tools, model checkers, parsers,
compilers, code synthesis tools, runtime support tools, and so on. Our
approach is not an ADL, but a way to describe project-specific architecture
descriptions to create an easier step-in into creating project-specific
visualizations, or a _meta ADL_. SPViz can be used for existing software
architectures, ADLs and Module Interconnection Languages [32].

A related tool for general architecture visualization using an ADL is
described in work by Buchgeher et al. and Weinreich et al. [7, 33]. They
“emphasize the architectural description of a system as a central element
during the whole software development process. The main idea is to incorporate
a formalized architecture description model into a software system which is
always kept up-to-date during software development.” While they focus on
continuous co-development of the software and a formal architecture
description of it, they require such a direct integration and only partly
enable the analysis of legacy code that was not initially designed with their
tool. Furthermore, as their tooling is restricted to the Eclipse IDE, its use
for projects developed outside the Eclipse environment is limited. However,
they allow constraint analysis to automatically detect architectural errors
and inconsistencies and have immediate visual feedback on system change,
giving them some advantages in such an integrated system. We want to bridge
the gap of generic architecture ADLs and an easy way to describe meaningful
visualizations for them. Our tool can interface with existing architectures to
provide visualizations, while not requiring any concrete language or syntax on
the architecture description itself. Other ADLs tightly integrated into
specific languages, requiring the underlying projects to conform to their
constraints are for example ArchJava [6] for Java and Codoc [34] for Python.
There are other similar tools for domain-specific graphical modeling tools,
partly based on DSLs applicable to different architectures.

Nimeta [35] is a tool for architecture reconstruction based on views. They
build graphical views based on so-called _view-points_ for arbitrary
descriptions. They clearly split the data extraction from the visualization
step to allow different tools to visualize the same data, whereas we with
SPViz integrate the architectural description in the view descriptions,
allowing for further filtering based on the architecture.

The CINCO tool [36] generates domain-specific graphical modeling tools from
abstract specifications. They use a similar meta meta modeling hierarchy to
describe architectures. Their use case, however, is to generate a full
modeling suite for such a model with the graphs editing to modify the
underlying models. They do not aim to visualize existing architectures in a
way SPViz does. Other graphical editors for models such as Epsilon [37],
Sirius [38], and Spray [39] map domain-specific models to graphical views, but
require explicit descriptions on how views should be displayed and model
elements should be connected in the first place. The models to graphical views
concept is similar to the KLighD framework that we use, while we utilize the
KLighD framework to make the way of connecting elements more implicit via the
VC3M DSL. These related papers style different parts of the visualizations for
more configurability. The SPViz approach may also support similar individual
stylings beyond the current box and arrow graphs as shown above, but the tool
currently does not support such individual element styling.

Another term under which visualizing architecture is understood is the
reconstruction of software architecture from the area of reverse engineering.
El-Boussaidi et al. [40] use the Knowledge Discovery Meta-Model (KDM) [41] to
describe legacy projects to visualize them, while other use clustering
algorithms to try to infer architectural meaning from otherwise non-structured
code [42, 43, 44]. We think approaches like these are a good way to reverse
engineer and structure unstructured legacy code which can be combinable with
our visualization techniques, if they can output the results to be imported in
some PM generator described with our approach.

Petre [45] analyzed what expert programmers want from visualizations. E.g.,
they need to be specific enough to get good insight into the architecture and
allow a good focus on parts that are currently interesting for the user.
Gallagher et al. [46] analyzed key areas for software visualization practice
such as representation, navigation and interaction. We analyzed the
visualizations and interactions with the OSGi tool in our previous work [9].
Most of that analysis is also applicable to the generalization of this paper.
However, the specificity and its focus are dependent on the concrete A2M and
VC2M. In general, we allow for the tools to be as specific as they need to be
to satisfy the specificity requirement.

##  VII Discussion

While this paper presents our proposed concept for describing arbitrary
architectures and their visualization, some parts in the configurability, the
visualization, and the handling of the DSLs can be improved in the future. We
would like the generated visualization modules to be extensible to make the
final visualizations more configurable to fit aesthetics criteria of the
architecture to visualize. A first idea is to open up an API that allows the
individual renderings for the overviews, the artifacts, or even the
connections or the arrow heads to be configurable. This could be achieved for
example via some injection mechanism similar to the configurability of many
functional aspects in the Xtext framework or an extension to the DSL syntax.
This could also enable the modification of automatic artifact colors. Another
part that could be configurable is mapping the visualized artifacts to some
web-link leading to documentation of that artifact or being integrated into
different IDEs such as Eclipse and VS Code.

An improvement to the tooling to design a new visualization would be to allow
using the DSLs outside of Eclipse in e.g. VS Code or a command line tool, and
generate the required code from there. Furthermore, support to write a model
generator using other languages could help developers. Another improvement
would be to make the A3M compatible with other meta models such as the KDM
[41].

In the VC3M DSL we would like to enable further configuration. The bundle
dependencies view in Figure 12 only permits a direct connection of bundles to
other bundles. However, bundles may be indirectly connected via a different
_package_ artifact, whose connections should be shown, without showing the
package artifacts themselves. An extension to the DSL could allow writing
something like connect OSGi.Bundle via OSGi.Bundle.PackageDependency, to
indicate that the parent bundle artifact of the connected package dependency
should be connected instead. A different syntax to better distinguish it from
the category connection could be used as well. Another extension would enable
(recursive) connections of filtered artifacts in artifact views. The bundle
dependencies artifact view of products in Figure 12 for example could show the
project-known dependencies of all filtered bundles with some syntax such as
OSGi.Bundle from OSGi.Product>OSGi.Bundle and connected. This would not only
show the bundle hierarchy of all bundles defined in the product, but also
their (recursive) dependencies, as they are always part of a deployed product
anyways.

To solve another issue that the texts for the artifact names can get quite
long and bloat the required size for the diagram, we would like to add an
option to only show hints of the names and expand the names with hover
feedback or to use automatic label management to reduce the layout footprint
of the individual artifacts [47].

Lastly, the stored VCM could be improved as well. Currently a stored VCM
restores the last visualized state by the identifiers of each artifact and
their connections to make it possible that a change in the project updates the
model and restores the previous view. For a VCM which was configured to show
all connections of some specific element, while an update to the project
introduces some new connected element, that connection will not be shown in
the updated visualization. Instead, the port which was white before to
indicate that there are no further elements to connect to would be black in
the updated version, indicating there are further connections currently not
shown. This change is not easily recognizable. However, restoring the VCM by
connecting all elements where all elements were connected before could
mitigate that issue.

To address threats to validity of the industry feedback, that part of the
evaluation is not meant to be the final study to validate the usability of our
proposed SPViz tool. The questionnaire was not structured in a controlled
manner and is meant to be viewed as a initial argument towards showing the
usefulness of SPViz for generating customized visualization tools. We plan on
conducting a further user study investigating how users design and adapt new
visualization tools using our proposed approach in the future.

##  VIII Conclusion

SPViz is a new approach for software architects to quickly create a
visualization tool they can use to explore any otherwise obscure architecture.
It enables its users to create automatically updating architectural views for
documentation purposes and to explain relations to others. We built a tool
following this approach to make a previously presented approach for
visualizing, exploring, and documenting OSGi projects available for arbitrary
software architectures, highlighting the usability of such a concept. The
visualizations use state-of-the-art and well-accepted views on connections
within software systems such as dependencies and service structures. We
compared the tool to other meta modeling tools and architectural
visualizations, such as ADLs, which usually require projects to adapt to. We
do not require projects to use any specific architecture, but support the
description of the architecture for any project. SPViz can be used as a
visualization tool generator for legacy systems to visualize specific parts
that other tools do not cover. It can also be used to quickly set up a
visualization for new and emerging languages and system structures. To be
applicable to projects that have no real own architecture and are just a
collection of source files, a combination with other tools clustering and
organizing specific artifacts is recommended.

Overall, the tool has been used and evaluated on multiple projects, showing
its benefits. However, as discussed in Section VII, some areas can still be
improved in future research to widen the use cases of this architecture-
agnostic software visualization tool generator.

## References

  * [1] M. Shahin, P. Liang, and M. Ali Babar, “A systematic review of software architecture visualization techniques,” _Journal of Systems and Software_ , vol. 94, pp. 161–185, Aug. 2014.
  * [2] P. Eades and K. Zhang, _Software Visualisation_ , ser. Software Engineering and Knowledge Engineering. Singapore: World Scientific, 1996, vol. 7.
  * [3] B. P. Lientz, E. B. Swanson, and G. E. Tompkins, “Characteristics of application software maintenance,” _Communications of the ACM_ , vol. 21, no. 6, pp. 466–471, Jun. 1978.
  * [4] G. C. Murphy, D. Notkin, and K. J. Sullivan, “Software reflexion models: Bridging the gap between design and implementation,” _IEEE Transactions on Software Engineering_ , vol. 27, no. 4, pp. 364–380, 2001.
  * [5] J. B. Tran, M. W. Godfrey, E. H. Lee, and R. C. Holt, “Architectural repair of open source software,” in _Proceedings IWPC 2000. 8th International Workshop on Program Comprehension_. IEEE Computer Society, Jun. 2000, pp. 48–59.
  * [6] J. Aldrich, C. Chambers, and D. Notkin, “ArchJava: Connecting software architecture to implementation,” in _Proceedings of the 24th International Conference on Software Engineering. ICSE 2002_ , W. Tracz, M. Young, and J. Magee, Eds. ACM, May 2002, pp. 187–197.
  * [7] G. Buchgeher and R. Weinreich, “Integrated software architecture management and validation,” in _Proceedings of the Third International Conference on Software Engineering Advances_. IEEE Computer Society, Oct 2008, pp. 427–436. [Online]. Available: https://doi.org/10.1109/ICSEA.2008.21
  * [8] _OSGi Core Release 8 Specification_ , The OSGi Alliance, Oct. 2020, Accessed: Dec. 16, 2022. [Online]. Available: https://docs.osgi.org/download/r8/osgi.core-8.0.0.pdf.
  * [9] N. Rentz, C. Dams, and R. von Hanxleden, “Interactive visualization for OSGi-based projects,” in _2020 Working Conference on Software Visualization (VISSOFT)_. Adelaide, Australia: IEEE, Sep. 2020, pp. 84–88.
  * [10] S. Boersma and M. Lungu, “React-bratus: Visualising react component hierarchies,” in _2021 Working Conference on Software Visualization (VISSOFT)_. Luxembourg: IEEE, Sep. 2021, pp. 130–134.
  * [11] M. Duruisseau, J.-C. Tarby, X. Le Pallec, and S. Gérard, “VisUML: a live UML visualization to help developers in their programming task,” in _Human Interface and the Management of Information. Interaction, Visualization, and Analytics - 20th International Conference, HIMI 2018_ , ser. Lecture Notes in Computer Science, vol. 10904. Springer, Jul. 2018, pp. 3–22.
  * [12] L. Georget, F. Tronel, and V. V. T. Tong, “Kayrebt: An activity diagram extraction and visualization toolset designed for the Linux codebase,” in _2015 IEEE 3rd Working Conference on Software Visualization (VISSOFT)_. IEEE, Sep. 2015, pp. 170–174.
  * [13] C. F. J. Lange, M. R. V. Chaudron, and J. Muskens, “In practice: UML software architecture and design description,” _IEEE Software_ , vol. 23, no. 2, pp. 40–46, 2006. [Online]. Available: https://doi.org/10.1109/MS.2006.50
  * [14] I. Malavolta, P. Lago, H. Muccini, P. Pelliccione, and A. Tang, “What industry needs from architectural languages: A survey,” _IEEE Transactions on Software Engineering_ , vol. 39, no. 6, pp. 869–891, 2013.
  * [15] R. Rodriguez-Echeverria, J. L. C. Izquierdo, M. Wimmer, and J. Cabot, “Towards a Language Server Protocol Infrastructure for Graphical Modeling,” in _Proceedings of the 21th ACM/IEEE International Conference on Model Driven Engineering Languages and Systems_ , ser. MODELS ’18. New York, NY, USA: ACM, 2018, pp. 370–380.
  * [16] H. Fuhrmann and R. von Hanxleden, “On the pragmatics of model-based design,” in _Proceedings of the 15th Monterey Workshop 2008 on the Foundations of Computer Software. Future Trends and Techniques for Development, Revised Selected Papers_ , ser. LNCS, vol. 6028. Budapest, Hungary: Springer, 2010, pp. 116–140.
  * [17] T. Reenskaug, “Models – Views – Controllers,” Dec. 1979, xerox PARC technical note.
  * [18] C. Schneider, M. Spönemann, and R. von Hanxleden, “Just model! – Putting automatic synthesis of node-link-diagrams into practice,” in _Proceedings of the IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC ’13)_. San Jose, CA, USA: IEEE, Sep. 2013, pp. 75–82.
  * [19] C. Schretter, L. Kobbelt, and P.-O. Dehaye, “Golden ratio sequences for low-discrepancy sampling,” _Journal of Graphics Tools_ , vol. 16, no. 2, pp. 95–104, 2012. [Online]. Available: https://doi.org/10.1080/2165347X.2012.679555
  * [20] S. Efftinge and M. Voelter, “oAW xText: A framework for textual DSLs,” in _Eclipse Summit Europe_ , Esslingen, Germany, Oct. 2006.
  * [21] Object Management Group, “Meta Object Facility (MOF) Core Specification, Version 2.5.1,” Oct. 2019, https://www.omg.org/spec/MOF/2.5.1/PDF.
  * [22] ——, “XML metadata interchange (XMI) specification, version 2.5.1,” Jun. 2015, https://www.omg.org/spec/XMI/2.5.1/PDF.
  * [23] D. Steinberg, F. Budinsky, M. Paternostro, and E. Merks, _EMF – Eclipse Modeling Framework_ , second edition ed., ser. Eclipse Series. Addison-Wesley, 2009.
  * [24] N. Rentz, “Moving transient views from Eclipse to web technologies,” Master’s thesis, Kiel University, Department of Computer Science, Nov. 2018, https://rtsys.informatik.uni-kiel.de/~biblio/downloads/theses/nir-mt.pdf.
  * [25] C. Fricke, “Standalone web diagrams and lightweight plugins for web-IDEs such as Visual Studio Code and Theia,” Bachelor’s thesis, Kiel University, Department of Computer Science, Sep. 2021, https://rtsys.informatik.uni-kiel.de/~biblio/downloads/theses/fricke-bt.pdf.
  * [26] S. M. Charters, N. Thomas, and M. Munro, “The end of the line for software visualisation?” in _Proc. 2nd IEEE International Workshop on Visualizing Software for Understanding and Analysis (VISSOFT)_. Amsterdam, The Netherlands: IEEE, Sep. 2003, pp. 110–112.
  * [27] M. Shaw and D. Garlan, _Software architecture: perspectives on an emerging discipline_. Prentice-Hall, Inc., Apr. 1996\.
  * [28] L. Bass, P. Clements, and R. Kazman, _Software Architecture in Practice_. Addison-Wesley Professional, 2003.
  * [29] P. C. Clements, D. Garlan, R. Little, R. L. Nord, and J. A. Stafford, “Documenting software architectures: Views and beyond,” in _25th International Conference on Software Engineering, 2003. Proceedings._ , L. A. Clarke, L. Dillon, and W. F. Tichy, Eds. IEEE Computer Society, May 2003, pp. 740–741.
  * [30] M. Shahin, P. Liang, and M. R. Khayyambashi, “Improving understandability of architecture design through visualization of architectural design decision,” in _Proceedings of the 2010 ICSE Workshop on Sharing and Reusing Architectural Knowledge_ , ser. SHARK ’10. New York, NY, USA: Association for Computing Machinery, May 2010, pp. 88–95. [Online]. Available: https://doi.org/10.1145/1833335.1833348
  * [31] N. Medvidovic and R. N. Taylor, “A classification and comparison framework for software architecture description languages,” _IEEE Transactions on Software Engineering_ , vol. 26, no. 1, pp. 70–93, Jan. 2000.
  * [32] R. Prieto-Díaz and J. M. Neighbors, “Module interconnection languages,” _Journal of Systems and Software_ , vol. 6, no. 4, pp. 307–334, 1986.
  * [33] R. Weinreich, C. Miesbauer, G. Buchgeher, and T. Kriechbaum, “Extracting and facilitating architecture in service-oriented software systems,” in _2012 Joint Working IEEE/IFIP Conference on Software Architecture and European Conference on Software Architecture_. IEEE, Aug. 2012, pp. 81–90.
  * [34] C. W. Bang and M. Lungu, “Codoc: Code-driven architectural view specification framework in Python,” in _2021 Working Conference on Software Visualization (VISSOFT)_. IEEE, Sep. 2021, pp. 120–124.
  * [35] C. Riva, “View-based software architecture reconstruction,” Dissertation, Technische Universität Wien, Oct. 2004.
  * [36] S. Naujokat, M. Lybecait, D. Kopetzki, and B. Steffen, “Cinco: a simplicity-driven approach to full generation of domain-specific graphical modeling tools,” _International Journal on Software Tools for Technology Transfer_ , vol. 20, no. 3, pp. 327–354, Jun 2018.
  * [37] D. S. Kolovos, R. F. Paige, and F. A. Polack, “Eclipse development tools for Epsilon,” in _Eclipse summit Europe, Eclipse modeling symposium_ , vol. 20062, 2006, p. 200.
  * [38] V. Vujović, M. Maksimović, and B. Perišić, “Sirius: A rapid development of DSM graphical editor,” in _IEEE 18th International Conference on Intelligent Engineering Systems INES 2014_ , 2014, pp. 233–238.
  * [39] M. Gerhart and M. Boger, “Concepts for the model-driven generation of graphical editors in Eclipse by using the Graphiti framework,” _International Journal of Computer Techniques (IJCT)_ , vol. 3, no. 4, pp. 11–20, Aug. 2016.
  * [40] G. El Boussaidi, A. B. Belle, S. Vaucher, and H. Mili, “Reconstructing architectural views from legacy systems,” in _2012 19th Working Conference on Reverse Engineering_. IEEE Computer Society, Oct. 2012, pp. 345–354.
  * [41] Object Management Group, “Architecture-Driven Modernization: Knowledge Discovery Meta-Model (KDM), Version 1.4,” Sep. 2016, https://www.omg.org/spec/KDM/1.4/PDF.
  * [42] C. Stoermer, L. O’Brien, and C. Verhoef, “Moving towards quality attribute driven software architecture reconstruction,” in _10th Working Conference on Reverse Engineering_ , A. van Deursen, E. Stroulia, and M. D. Storey, Eds. IEEE Computer Society, 2003, pp. 46–56.
  * [43] C. Riva, _Architecture Reconstruction in Practice_. Boston, MA: Springer US, 2002, pp. 159–173.
  * [44] T. A. Wiggerts, “Using clustering algorithms in legacy systems remodularization,” in _Proceedings of the Fourth Working Conference on Reverse Engineering_ , I. D. Baxter, A. Quilici, and C. Verhoef, Eds. IEEE Computer Society, Oct. 1997, pp. 33–43.
  * [45] M. Petre, “Mental imagery, visualisation tools and team work,” in _Second Program Visualization Workshop_ , M. Ben-Ari, Ed. Aarhus, Denmark: University of Aarhus, Dec. 2002, pp. 2–13.
  * [46] K. Gallagher, A. Hatch, and M. Munro, “Software architecture visualization: An evaluation framework and its application,” _IEEE Transactions on Software Engineering_ , vol. 34, no. 2, pp. 260–270, Mar. 2008.
  * [47] C. D. Schulze, Y. Lasch, and R. von Hanxleden, “Label management: Keeping complex diagrams usable,” in _Proceedings of the IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC ’16)_ , Sep. 2016, pp. 3–11.

  *[XML]: Extensible Markup Language
  *[OSGi]: Open Services Gateway initiative
  *[DSL]: Domain Specific Language
  *[SPViz]: Software Project Visualization
  *[DSLs]: Domain Specific Language
  *[IDE]: Integrated Development Environment
  *[UML]: Unified Modeling Language
  *[GLSP]: Graphical Language Server Platform
  *[LSP]: Language Server Protocol
  *[MVC]: Model-View-Controller
  *[VCM]: view context model
  *[KLighD]: KIELER Lightweight Diagrams
  *[ELK]: Eclipse Layout Kernel
  *[PM]: project model
  *[A2M]: architecture meta model
  *[PMs]: project model
  *[UI]: user interface
  *[VC2M]: view context meta model
  *[A2Ms]: architecture meta model
  *[VC2Ms]: view context meta model
  *[A3M]: architecture meta meta model
  *[VC3M]: view context meta meta model
  *[EBNF]: extended Backus–Naur form
  *[MDE]: Model Driven Engineering
  *[MOF]: Meta Object Facility
  *[EMF]: Eclipse Modeling Framework
  *[API]: application programming interface
  *[]:
  *[XMI]:  Metadata Interchange
  *[CLI]: Command Line Interface
  *[IDEs]: Integrated Development Environment
  *[CI]: continuous integration
  *[CD]: continuous deployment
  *[VCMs]: view context model
  *[VS Code]: Visual Studio Code
  *[DI]: Dependency Injection
  *[LoC]: lines of code
  *[ API]: application programming interface
  *[JSON]: JavaScript Object Notation
  *[ADLs]: Architecture Description Language
  *[ADL]: Architecture Description Language
  *[ ADL]: Architecture Description Language
  *[KDM]: Knowledge Discovery Meta-Model