|
Visit our blog
News & EventsSpring's Architecture - Not a Single Dependency CycleAt the Darmstadt University of Technology Ivica Aracic's research is concerned with the question: can graph-based software visualization facilitate reasoning on the quality of software architectures? In the course of Ivica's work he has analyzed the architectures of several products including Prefuse, JEdit, and The Spring Framework. On the Spring developer list Ivica noted, "after analyzing Spring I was surprised to find there is not a single cycle in the dependency graph at the architectural level." (see screenshot) His question to the Spring team followed, "how do you ensure this in your development process? Are you using metric tools or some other tools to regulary check dependencies at the architectural level?" It turns out Spring is fortunate to have an excellent gatekeeper and lead developer in Juergen Hoeller, who is employed full time by Interface21 to oversee the overall structure, quality, and consistency of the code base. Previously Juergen used JDepend to check for cycles. Today he and Rob Harrop use a tool called SonarJ to do this. In the coming weeks SonarJ will be rolled out across the entire development team as part of an ongoing effort to keep the overall quality of the Spring family of products as high as possible. |
Upcoming Training04/15 - 04/18:
Bangalore Rich Web Applications with Spring Enterprise Integration with Spring 04/16 - 04/19:
Wien Plus: Hibernate with Spring, Core Spring.NET, Groovy & Grails Newsletter SubscriptionOur monthly newsletter is packed full of techniques, tutorials, tips and tricks to get you on your way to Spring nirvana. View Archive |
Comments
No wonder: it's a framework
IT would be very surprising to me if a framework with the maturity level of spring had dependency cycles. However, comparing it with JEdit is quite unfair. Because of the totaly uncomparable usage scebnarios of the two projects IMHO it does not male sence to compare these projects.
JEdit, for instance, provides is GUI-centric which usally has impact on the architecture.
Re: No wonder: it's a framework
"IT would be very surprising to me if a framework with the maturity level of spring had dependency cycles."
Take a look into other mature framework projects like for example Eclipse's GEF 3.2 or JDT. You will be surprised how many cycles they have and how difficult it is to divide these systems in manageable chunks which can be understood in isolation.
"JEdit, for instance, provides is GUI-centric which usally has impact on the architecture."
Well "GUI-centric" or not. In any case it is not an excuse to have cycles.
---
http://www.st.informatik.tu-darmstadt.de/staff/Ivica
Is dependecy of ejb on web correct?
The ejb and remote components have a dependency on the web components. Is this correct ?
'not a single cycle in the
'...not a single cycle in the dependency graph at the architectural level...'
I'm not entirely certain what Ivica means by 'architectural level' (our proxy here denies access to the picture as it is hosted on a gaming site) but he's probably talking about the logical structure of the architectire like modules and tiers.
The source code has plenty of dependency cycles on the physical level between compilation units and packages though (try using sourceforge.net/projects/dependometer - written by one of the guys behind JProbe - hi Dietmar! ;-). From my point of view there's plenty of 'tangle' in there.
There's always room for some improvement...
Of Mice and Cycles
The source code has plenty of dependency cycles on the physical level between compilation units and packages though (try using sourceforge.net/projects/dependometer - written by one of the guys behind JProbe - hi Dietmar! ;-). From my point of view there's plenty of 'tangle' in there.
Small typo: Replace 'JProbe' with 'SonarJ'.
Being male I really shouldn't try to do two things at one time...
And Ivica is right here, I was talking about cycles on the physical level, i.e. Java packages and compilation units. I was just being picky. On the logical level of modules the Spring framework looks fine to me. With the use of SonarJ I'm certain that we'll see less cycles in future releases ;-).
The absence of cycles is no guarantee for good software quality but it is one of the basic requirements for well designed applications.
Re: not a single cycle in the
I moved the screenshot to university's server.
It should not be classified as gaming now. ;)
-> < a href="http://www.st.informatik.tu-darmstadt.de/staff/Ivica/box/spring-architecture.jpg">screenshot
"The source code has plenty of dependency cycles on the physical level between compilation units and packages though (try using sourceforge.net/projects/dependometer - written by one of the guys behind JProbe - hi Dietmar! ;-). From my point of view there's plenty of 'tangle' in there."
I've considered only the 22 top-level modules.
You probably mean cycles between packages within a module.
However, these cycles between modules are not tragical, because they are local to the module itself. Of course is this a point for the improvement. And I guess with SonarJ we will soon see improvements here.
But, even with these cyclic dependecies between packages within a single module, spring has (from my point of view) the best dependecy management and package granularity I've seen so far.
---
http://www.st.informatik.tu-darmstadt.de/staff/Ivica
working with Spring code is a pleasure
I read quite a bit of Spring source code in the last few months, and I must say it's magnificent. At first I thought it was over-engineered (some class hierarchies are very deep), but it isn't. Whenever I think 'well, Spring does ALMOST what I need, but not quite', there's usually a class in these deep hierarchies that I can extend, override one method - and voila. With most other projects, stuff like that can only be done with a good deal of copy and paste. It also helps a lot that the Spring code is documented / commented exceptionally well.
Best open source code-base
Very interesting! I've analyzed many open source projects and haven't come accross a sizable one yet that is tangle-free at the package level.
We keep our code free of package cycles, as well as limiting the complexity at all levels (the 2 aspects of good structure). Interestingly, it is very easy to do if you build a regular check into your process.
I did a check on Spring for over-complexity using structure101 and wrote it up in my blog. Even though I guess that juergen wasn't explicitly checking this, it is also good compared to other projects (presumably because it's "common sense" to anyone that cares about cycles). There is one package and a few classes and methods that you may want to simplify to make the structure totally "perfect" ;-).
Hats off to Juergen.