Improved Eclipse Integrated Structure Analysis
This article gives a brief introduction to structure analysis using STAN, a static code analysis tool bringing together Java development and quality assurance in a natural way. STAN encourages developers and project managers in visualizing their design, understanding code, measuring quality and reporting design fl aws. STAN supports a set of carefully selected metrics, suitable to cover the most important Aspects of structural quality. Special focus has been set on visual dependency analysis, a key to structure analysis. STAN seamlessly integrates into the development process. That way, developers take care about design quality right from the start. Project managers use STAN as a monitoring and reporting tool.
As a matter of fact, many projects fail due to lack of soft ware 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 soft ware 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 soft ware engineering process. This is where STAN, a new structure analysis tool for Java, comes into play. STAN puts quality assurance to the hand of the developer, thereby achieving these goals with minimal eff ort.
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 soft ware 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 identifi es the following odors (among others):
- Rigidity – The system is hard to change because every change forces many ther 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 intend well. To the contrary, a good design turns out to be flexible, solid, mobile, fl uid and transparent.
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 soft ware 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!
What is structure Analysis
Structure analysis is more than just measuring metrics and listing threshold violations. Structure analysis is about breaking down the system’s complexity and letting the user inspect its artifacts at any level, from different perspectives. An important aspect is visualization. A picture says more than 1000 numbers! A good structure analysis tool presents and visualizes the structural design in a way that is easy to understand for humans. If you need to learn the tool’s language, there’s something wrong. When it comes to dependencies, a good structure analysis tool needs advanced graph layout capabilities to create neatly arranged dependency graphs. The user should be able to navigate through these graphs, to drill down, and so on. A good structure analysis tool should support “modern” metrics. For each artifact, metric violations should be listed and ranked, allowing the user to distinguish important issues from negligible ones. Not forget to mention, a good structure analysis tool should be easy to handle and useful from the beginning. It will be a natural part of daily development, because it’s fun! So far we focused on structure analysis as a development task. From time to time, it is also desirable to measure the overall quality of our structural design. Project managers need reporting functionality at the touch of a button.
Reports should contain meaningful information about the structural quality of a code base. Of cause, metric violations should be listed. However, reports may also include visualizations of certain design Aspects or selected design violations. Reports also provide an easy way to trace structural quality over time.
STAN provides you with structure analysis for Java. STAN analyzes byte code rather than source code. You don’t need the sources and you can directly analyze any compiled Java code, whether it’s yours or not.
STAN is available in two variants:
- as a standalone application for Windows and Mac OS
- as an extension to the Eclipse Integrated Development Environment (IDE) The standalone application is targeted to architects and project managers who are typically not using the IDE. The Eclipse extension integrates STAN seamlessly into the IDE and allows the developer to quickly explore the structure for any bunch of code she desires.
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.stan4j. 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.
When dealing with software structure, dependency analysis becomes a central topic. For nontrivial applications, it’s almost impossible to understand or even control how classes, packages and package trees interact with each other by just examining source code. However, understanding how things depend on each other is crucial for making the right design decisions during development. We cannot expect to have a good design if we don’t know it! What we really want is to look at our artifacts, see what they need and what needs them. Given this, we can make better decisions and will end up with a better design. Sometimes we discover the need for refactoring to improve our design. Sometimes we just want to discuss some design issues. Instead of stumbling through the code, isn’t it much better to look at a dependency graph?
Unfortunately, it’s impossible to look at everything at once. To get useful graphs, we have to carefully select the perspectives and scopes. Otherwise we’ll end up with very big and clumsy graphs. For example, we may want to look at an artifact to see how its contained artifacts interact or how the artifact itself interacts with the rest of the application. Another issue is graph layout. Without sophisticated layout capabilities, even rather small graphs cannot be put into a picture we want to look at. At the same time, graph layout is a complex task and much eff ort has been put into STAN’s graph layout engine to obtain good and fast results.
STAN shows dependency graphs for all levels of abstraction. Generally, nodes denote artifacts and edges denote dependencies. An edge’s weight refl ects the dependency’s strength, which is the number of underlying code dependencies
Selecting an edge will show you those dependencies.
Graphs may be zoomed, narrowed and their orientation may be fl ipped to get optimal insight into the dependency relations of the artifact under consideration.
The Composition View allows to look into the selected artifact, to see all its contained children and the dependencies between them. You may investigate dependencies between members of a class, classes of a package, packages, children of a package tree and between libraries. STAN’s layout engine guarantees, that – as far as possible – edges point into the same direction, either top to bottom or left to right, depending on the chosen layout orientation. Artifacts can be expanded to arbitrary depth to dive deeper into the structure. Additionally you may navigate into any of the displayed artifacts as well as up and down the artifact hierarchy.
The Couplings View allows to look around the selected artifact, to see all its incoming and outgoing dependencies. You may investigate dependencies to and from classes, packages, package trees or libraries.
In addition to the direct dependencies one can optionally make visible intermediate dependencies between the displayed artifacts. Here, artifacts can be split to explore how its children contribute to the shown dependencies.
If the graph is too large to fit in your view, the dependency graph overview simplifi es navigation.
- The Graph Thumbnail lets you choose the shown region visually.
- The Graph Contents allows you to reveal a particular node by selecting it from a list.
The Dependency Landscape serves as a quick indicator for an artifact’s dependency relations. The shown area represents the entire code base. Generally, the code represented by
Read more in Eclipse Magazine Vol. 17 (2007)