Architectural Analyses

CodeScene’s architectural analyses lets you run Hotspots, Temporal Coupling and more on the architectural level of your high level design. The results give you the power to evaluate how well your architecture supports the evolution of your system.

What’s an Architectural Component?

An Architectural Component is a logical building block in your system. For example, if you build a Microservices architecture, each microservice could be considered a logical block. Similarly, if you organize your code in layers (MVC-, MVP-, MVVM-patterns, etc), each layer would be a logical block.

Fig. 49 An example of architectural components.

An Architectural Component could also be much more coarse. For example, let’s say that you’re interested in the co-evolution of your application code versus the test code. Perhaps because you suspect that you spend way too much effort on keeping your automated tests up to date. In that case, you’d define two Architectural Components: Application Code and Automated Tests.

So, the short answer is that what you consider an Architectural Component depends upon your architectural style. You want to specify components that help you answer the questions you have. For example, do the change patterns in the code match the intent of the architecture? Often, the potential for large maintenance savings are found in these architectural analyses once you spot patterns that violate your architectural principles.

Define your Architectural Components

You need to configure your Architectural Components in order to enable the corresponding analyses.

CodeScene offers flexibility in how you define your components. The tool uses glob patterns to identify the files that belong to a specific component as illustrated in Fig. 50.

Fig. 50 Configure architectural components by specifying glob patterns for each logical component.

As you see in the picture above, you need to specify a pattern and the name of your component. All content in your codebase that matches your glob pattern will be assigned to an architectural component with the name you specified.

Let’s consider the example above to learn more about the format. The configuration in Fig. 50 specifies the pattern spaceinvaders/source/sprites/**. That means that all content under the folder spaceinvaders/source/sprites will be considered as the architectural/logical component Sprites.

In general, you want to match architectural components on the level of the different sub-folders of your codebase. But you can of course provide much more granular filters and, with the power of glob patterns, even match individual files.

You can also map multiple folders to the same architectural component. A common example on this is when you want to consider the application code and its associated unit tests as one logical unit. In this case you’d add a second pattern to the Sprites component in Fig. 50: spaceinvaders/test/sprites/**.

Import Architectural Component Definitions from a File

Instead of specifying the patterns manually in the section above, you can import a CSV file with the definitions. This is a simpler option in a large system where you can script the generation of the CSV to import:

• Your CSV file must not include a header row.
• The CSV file shall contain two columns: 1. the Component Name and 2. its Glob Pattern.
• The fields in your CSV are separated by commas.

Fig. 51 provides an example on a CSV file used to import architectural components.

Fig. 51 Import your definitions of architectural component from a CSV file with this format.

The file content above defines five architectural components and maps each one of the to a logical architectural name. As you see, you can map several folders to the same architectural component. The Workbench component above is an example on this. As we import the file, CodeScene will generate a definition for Workbench as illustrated in Fig. 52.

Fig. 52 Map two separate folders to the same architectural component.

System Complexity Trend

CodeScene calculates a trend of how your system, as a whole, has evolved over time.

Please note that you need to enable this analysis; It’s expensive in terms of analysis time, which is why it’s optional. Fig. 53 shows how to enable the trends.

Fig. 53 Enable the trend analysis of architectural components in your project configuration.

Once you’ve enabled the architectural trends, CodeScene will calculate an overall view of the evolution of your system as illustrated in Fig. 54.

Fig. 54 The evolution of the complete codebase.

You use this information to see if the system has stabilized and entered a maintenance phase or if it still evolves rapidly. You can also correlate the growth patterns to how the staffing has looked over time - did more people really resulted in a faster growth?

CodeScene also presents a breakdown of the system complexity per architectural component as illustrated in Fig. 55.

Fig. 55 The architectural trends let you view how the development effort has shifted over the years.

Know the Biases in System Complexity Trends

The system/architectural complexity trends don’t take all your historic development into consideration. The trends are based upon the active amount of code. That is, only the code that’s included in your repositories today will be considered. More specific, this means that:

• If you have deleted whole files and folders in your codebase it won’t reflect in the trends.

We also want you to be careful when interpreting the results of an analysis that use a shorter timespan than that of the whole repository lifetime. In such a shorter analysis period, only the files with active development activity are included in the codebase. You’ll still be able to see a trend and reason about possible complexity growth in your code. However, the absolute numbers are likely to be lower than the total amount of code; Only files that you have modified are included in the trends.

Interpret the Architectural Analysis Results

The Architectural Analyses lets you focus on logical building blocks rather than individual files. This allows you to identify architectural Hotspots, as shown in Fig. 56.

Fig. 56 Using the hotspot analysis for architectural components.

The architectural analyses also lets you inspect the complexity trends of architectural hotspots. Note that you need to enable the architectural trends in your project configuration as noted above.

Finally, the architectural analyses also let you identify expensive modification patterns where code changes ripple through multiple logical components, as seen in in Fig. 57.

Fig. 57 Temporal coupling between architectural components.