As a matter of fact, many projects fail due to lack of software quality. Therefore, having an eye on code quality is not just an option, but may well prove mission critical. Furthermore, it’s not appropriate to push quality control to the end of the software engineering process. Since early detection of quality issues makes them easy to resolve, monitoring quality should be placed as close as possible to the developer.
Over the past few years we observe that more and more companies recognize the importance of software quality. As part of this trend, testing has been widely accepted as an integral part of development. However, testing alone is only one step to go on our way to high quality software products. Equally important, we need to continuously validate our software against well established design principles, helping us to improve maintainability, flexibility as well as – testability.
When looking for solutions to ease development, control design and improve quality, it is worth considering the integration of structure analysis into the software engineering process. This is where STAN comes into play. STAN puts quality assurance to the hand of the developer, thereby achieving these goals with minimal effort.
Software Structure
Artifacts are the things that make up a code base. For example, in Java, methods and fields are the building blocks for classes. Classes are organized into packages and packages are bundled into libraries. Finally, a set of libraries makes up an application. Members and classes lie on the code layer, whereas packages and libraries lie on the design layer.
Software Structure is understood as the way
- how artifacts build into higher level artifacts
- how artifacts depend on each other.
During development, the structure constantly changes. E. g., a new class is placed into a particular package or a new method adds dependencies to other classes and packages. Structure is not just something hidden in the background. Structure reflects our design. Structure is our design!
Rotten versus Good Design
As long as a project is small, developers have a vital image of their design in mind. They know every corner of their code and everything seems to be under control. As the project size evolves, however, things change: suddenly the software is hard to test, extend and maintain. It tends to be monolithic and somehow everything seems to depend on everything else. Robert C. Martin describes this as “The software starts to rot like a piece of bad meat”. Moreover, he identifies the following odors (among others):
- Rigidity – The system is hard to change because every change forces many other changes.
- Fragility – Changes cause the system to break in conceptually unrelated places.
- Immobility – It’s hard to disentangle the system into reusable components.
- Viscosity – Doing things right is harder than doing things wrong.
- Opacity – It is hard to read and understand. It does not express its intent well.
To the contrary, a good design turns out to be flexible, solid, mobile, fluid and transparent.
Fighting Complexity
The structure of large code bases tends to become very complex. Over-complex systems are hard to understand and maintain and thus do often break. Keeping complexity on a manageable level is a challenge.
We certainly must fail if we let our software structure evolve arbitrarily. It is therefore essential to keep an eye on it. Fortunately, there are common design principles which – if we follow them – can help us to succeed. We need to continuously validate our structure against these principles. And we need to discover and fix design violations early, before our software starts to rot!
Basic Settings
While analyzing Java byte code, STAN collects all the information needed to build a detailed model of the application’s structure. The code base is determined by choosing Java archive (JAR) files and class folders. Exclusion Patterns may be provided to ignore specific parts, e. g. test classes.
The Level of Detail specifies if our model shall include the member layer with all the classes’ fields and methods or if it shall be limited to the class layer and above.
We have already mentioned Java’s package concept as the basic way for grouping classes into higher level units. However, the package structure also builds a tree. For example, the packages com.stan4j.db and com.stan4j.ui are sub-packages of package com.foo. To take this into account, STAN allows you to toggle between the Flat Packages and Package Tree modes.
As another point, you might want to look at your application as one big code base or you might want to pay respect to the library layer. By switching to Show Libraries mode, you can inspect each library on its own as well as how the libraries are related to each other.