A year ago we released the first version of our web-based architecture editor. It was lacking one major feature: saving architectures directly into Teamscale from the browser. This will change with the upcoming release 2.1:

In this post I will outline how to create a new architecture for an existing system, demonstrating the usage and usefulness of real-time architecture analysis.

Creating a new architecture

We start of with a new, empty architecture specification:

To get started, we take a look at the existing orphans (classes/files that have not yet been included in the architecture) at the bottom. We can easily create new components (a collection of classes/files from our system, mapped by simple regular expressions) by dragging an orphan onto the canvas:

As we continue to add additional components, Teamscale will automatically assess the newly created architecture with every update. This way we can easily view dependencies between the created components and decide whether we accept them or mark them as illegal.

We can decide between 3 distinct dependency policies between two components A and B:

• Allow - Accept all dependencies, classes in A may access classes in B
• Deny - Deny all dependencies, classes in A may not access classes in B
• Accept - Accept all current dependencies, but create a violation for any new dependency between A and B. This is useful in existing systems, where we can not easily reach a clean state right away, but want to make sure that we at least maintain the current state (or ideally improve).

After we have finished modeling our first architecture, we can press the Save button to save the architecture in Teamscale. This will create a new entry on the activity perspective, which will also inform us about any findings created for the new architecture:

From now on, all new changes to the code will be assessed against the architecture we created and new findings will be created if we introduce dependencies along deny policies or fail to cover new classes in our architecture.

Architecture Metrics

With Teamscale 2.0 we added the concept of Architecture Metrics. They can be used to see how the code metrics calculated by Teamscale are distributed along the components you have modeled:

This is a useful concept if you have different views on your code, than just the folder structure. In big projects it is common to have different teams working on different parts of the same code base. Using architecture metrics you can create extremely tailored views onto the source code, for example modeled by logical components instead of folders.

Of course you can re-use these architecture paths in the dashboards as well:

Summary

Teamscale provides powerful facilities to easily model your code’s architecture. By creating findings for newly introduced problems detected with your architecture, it motivates to continuously update the architecture specifications, making sure they don’t end up as dead documents.

Teamscale includes architecture analysis for C#, Java, C++, ABAP, JavaScript (some flavors) and PHP (2.1 only). If you want to try Teamscale yourself, download your free trial today!