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
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
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
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
- 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)