Architecture-Rules
Introduction
http://architecturerules.googlecode.com/svn/docs/index.html
JDepend traverses Java class file directories and generates design quality metrics for each Java package. JDepend allows you to automatically measure the quality of a design in terms of its extensibility, reusability, and maintainability to manage package dependencies effectively.
However, in my experience has been that JDepend configuration and execution are difficult to maintain and difficult to get a quick overview of once a have defined a handful of rules.
Enter: Architecture-Rules
Quick Links
This library leverages an xml configuration fileto test your code's architecture via unit tests. It is able to assert that specific packages do not depend on each other and able to check for cyclic redundancies among your project's packages.
Benefits
* Assert your architecture through unit tests.
* Allow any IDE with unit testing capabilities to enforce an architecture.
* Allow continuous integration servers to enforce an architecture.
* Easy to read architecture rules and configuration.
* Easy to read, easy to maintain.
* Multiple architecture configuration. One for each module.
Why assert your architecture?
JDepend explains why you should design a good architecture and why you should monitor it.
Identify Package Dependency Cycles
Packages participating in a package dependency cycle are in a deadly embrace with respect to reusability and their release cycle. Package dependency cycles can be easily identified by reviewing the textual reports of dependency cycles. Once these dependency cycles have been identified with JDepend, they can be broken by employing various object-oriented techniques.
Package Release Modules
Packages that are cohesive and independent can be released as autonomous modules with their own release schedules and version numbers. Single packages, or groups of related packages collaborating in a framework, that are candidates for independent release can be harvested by evaluating their design quality metrics using JDepend.
Isolate Third-Party Package Dependencies
Third-party package dependencies can be easily identified and isolated by examining the afferent couplings to those packages. Once the dependency on these third-party packages has been measured with JDepend, the dependency can be managed by effectively designing abstract and stable packages that encapsulate the third-party package implementation details.
Invert Dependencies
The goal of using JDepend is to ultimately invert package dependencies such that low-abstraction packages depend upon high-abstraction packages. This inversion of dependencies allows the high-abstraction packages to be reused independently while being extensible to an open set of implementations. In general, dependencies upon stable packages are desirable, while dependencies upon instable packages are undesirable. JDepend allows dependencies to be iteratively examined and refactored as an integral part of software design and development.
