First Steps With Zügel

Setup in 5 Minutes

Zügel consists of a small launcher jar, which you download once from www.hello2morrow.com, and one entry in your agent’s MCP configuration that tells the agent how to start it. There are two ways to set it up, and you can combine them:

  • Project-based: the entry and the launcher live in the repository. Recommended for teams: commit both, and everyone who clones the project gets Zügel without any setup of their own.
  • User-based: the entry lives in your personal agent configuration. Recommended if you work across many repositories: set it up once, and Zügel is available in every session, whichever repository you are in.

Project-based setup

Put the launcher into a directory named .mcp at the root of your project, and create the agent’s configuration file next to it. For Claude Code that is .mcp.json:

{
"mcpServers": {
"zugel": {
"command": "java",
"args": [
"-jar",
".mcp/zugel-launcher.jar",
"<your-activation-code-or-license-file>",
"--project_root", "."
]
}
}
}
Read More

ArcTree Tutorial

Free Trial and Licensing

ArcTree is a plugin for IntelliJ IDEA that visualizes code dependencies for Java and Kotlin projects in a unique and powerful way. It is a commercial product which needs a subscription to run after a free evaluation period. To test the plugin just download it from the JetBrains marketplace. When it is started the first time it will automatically acquire an evaluation license that allows you to test the plugin for free for a period of two weeks. If you cannot access the Internet from IntelliJ you will need a file-based evaluation license. To do so you must register on www.hello2morrow.com and click on the red “Try Now” button.

If you want to continue using it after that you can buy a subscription (under 100 USD per year) from our website www.hello2morrow.com. Otherwise just uninstall the plugin. The different license options are described in more detail later in this article.

Read More

Spring Modulith & Sonargraph – Better Together

We created Sonargraph with the vision in mind, that it would allow architects to formally specify an enforceable architectural model. Another goal was to provide exceptional dependency visualization capabilities, so that issues could be easily detected not only in a formal way, but also by just looking at a dependency graph. Sonargraph’s architecture DSL (domain specific language) solved the first problem, while our exploration view solved the second one in a very unique and scalable way. The DSL is quite powerful and easy to learn. For an introduction you could read “How to Organize your Code” on this very site.

But obviously we were not the only ones thinking about a way to formally define architectural rules. Spring Modulith turned out to be a very powerful and successful solution to define domain driven architectures for Spring-Boot applications. Spring Modulith follows a pretty simple hands-off approach that allows the checking of architectural boundaries with a minimum configuration approach.

Read More

Identify the Most Relevant Issues to Fix

Using Sonargraph to analyse a large code base usually reveals a lot of issues. The “System Diff” helps to keep the quality level by highlighting new and worsened issues as described in a previous blog post. But up to now there has been no recommendation about which of the already existing issues should be fixed first.
The new “Ranking” view available in Sonargraph 11.5 does exactly that and this blog post describes how it works.

Read More

Motivation for Code Quality

The main idea behind Sonargraph has always been to provide a tool that eases the creation and maintenance of high-quality software. For any serious project that must live longer than a couple of months, it is actually cheaper to spend a part of your resources to keep your software constantly at a good level of quality than using all your time to create new features. Martin Fowler explains this very well in his article “Is High Quality Worth the Cost?”. The bottom line is, that apart from the very early development stages, high-quality software is actually cheaper to develop, because it allows adding new features at almost constant speed, whereas it becomes more and more time consuming to add new features into a code base with low quality. According to our experience the most successful teams spend about 15% to 20% of their time on code hygiene.

We at hello2morrow believe that a consistent architecture is a fundamental part of software quality. When we use the term “architecture”, we think of it in terms of the IEEE 1471 standard:

“The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.”

This blog post describes why architectural design as an activity is needed, why conformance checks need to be done automatically by a tool and how Sonargraph supports you as a developer and architect during these activities.

Read More

Visualizing an Architecture Aspect as a UML Component Diagram

Sonargraph’s domain specific language (DSL) to describe architecture aspects is very powerful. An architecture aspect consists at least of 1 top-level architecture file that has been added to the architecture configuration and is checked automatically. Such a top-level architecture file can include other architecture files reusing common definitions. With our latest release (11.4.0) we complemented the strictly text based representation of architecture aspects with a UML component generator.

A generated UML component diagram complements in several ways our text based architecture aspects:

  • It is a commonly accepted form of communicating architecture definitions
  • It shows the resulting architecture aspect event if it is spread over several files in 1 diagram
  • It can be used to cross-check the underlying text based architecture aspect (i.e. are the resulting restrictions the intended ones?)
Read More

Using Sonargraph’s “System Diff” for Continuous Code Quality Improvements

Sonargraph often discovers a huge number of issues for large software projects. This is especially the case for projects that do not use static code analysis tools and that have many contributors. The analysis results can be overwhelming because it is not obvious where to start with quality improvements.

A common best practice to improve code quality is “to keep a lid on it” by preventing further issues to be introduced in new code and gradually improving existing code where it needs to be changed. This is described by Robert Martin as the boyscout rule: “Always leave the campground cleaner than you found it.” [KH]

This blog post explains how Sonargraph’s “System Diff” feature helps to focus on recently introduced issues that need the developer’s attention.

Read More

Designing Generic Architectures Using Templates

Many companies already have some established architectural design patterns which are supposed to be used in most of their applications. For example it makes sense to standardize the layering of business components. It also makes sense to establish specific rules how one business component can access another one. In the upcoming 9.4 release of Sonargraph-Architect we implemented a new feature in our architecture DSL which should make it very easy to add generic architectural blueprints to a quality model which would allow automatic verification of those architectural design patterns on any business component without having to create a component specific architecture.

Read More