Category: Software Development Process

Spring Modulith & Sonargraph – Better Together

Alexander von Zitzewitz Leave a comment

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

Ingmar Kellner Leave a comment

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

Ingmar Kellner Leave a comment

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

Dietmar Menges Leave a comment

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

Ingmar Kellner Leave a comment

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

Alexander von Zitzewitz Leave a comment

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

Evolving Sonargraph’s Architecture DSL

Alexander von Zitzewitz Leave a comment

Sonargraph’s architecture DSL is now about 18 months old and we received a lot of positive feedback from customers bundled with ideas for improving the language. There are now several projects with more than one million LOC that use this language to define and enforce their architectural blueprint. Of course this feedback is most valuable for us and we did our best to implement a good share of the ideas brought to us. This article requires some basic knowledge of our architecture DSL. An introduction can be found here. To use all the features described below you need Sonargraph-Architect version 9.3 or higher.

Expressing Architectural Patterns as Artifact Stereotypes

There are some basic patterns that are used in almost every architectural model. Those patterns describe the relationships between sibling artifacts, i.e. artifacts that have the same parent.

  • Layered architecture – here dependencies are allowed to flow top-down within an ordered list of sibling artifacts. If we use strict layering, an artifact can only access ist next sibling artifact. In the case of relaxed layering, artifacts have access to all artifacts defined beneath them.
  • Independent – here sibling artifacts are independent from each other, i.e. there should be no dependencies between them.
  • Unrestricted – here siblings artifacts have no restrictions in accessing each other. This is not very desirable because it will allow cyclic dependencies between artifacts, but can be really useful when working on a model for a legacy software system.

Read More

Automate Cross-Project Analysis

Ingmar Kellner Leave a comment

Sonargraph is our tool to quickly assess the quality of a project. I get frequently asked, how Sonargraph supports the Enterprise Architect who needs to answer quality-related questions in the broader context across several projects.
Since we recently released new functionality that allows the automation of re-occurring quality checks, it is now the right time to write a blog post.
Example questions that an enterprise architect wants to answer:

  1. How frequently does a certain anti-pattern occur?
  2. How strong is the dependency on deprecated functionality?
  3. How many of my projects suffer from high coupling?

This article will demonstrate the following core functionality of Sonargraph to answer the above questions for a couple of projects and how to automate this analysis.

  1. Use a script to detect an anti-pattern (“Supertype uses Subtype”)
  2. Create a simple reference architecture to detect usage of sun.misc.Unsafe
  3. Add a threshold for a coupling metric (NCCD)
  4. Export a quality model
  5. Use Sonargraph Build Maven integration to execute the analysis.
  6. Create a small Java project to execute the Sonargraph Maven goal, access the data in the generated XML reports and create a summary.

Read More