The maven-dependency-graph plugin generates a transitive dependency graph of a maven project. This can be helpful in identifying unnecessary and unwanted dependencies.

The plugin generates a graphml file that can be viewed using a tool like

In this blog entry, I present a maven plug in that generates an XMI model from a pom.xml file and it's dependencies. XMI is an XML standard most commonly used to represent UML models. Most professional modeling tools can read XMI files. The XMI itself is not directly a visualization of the dependencies, but with a decent modeling tool, all kinds of fancy visualizations are possible.

Object-oriented programming has worked quite well – so far. [...] However, objects can deceive us. They can lure us into a false sense of understanding.


This article discusses two examples, a Pacman game and a soccer simulation where antiobjects are employed as part of a game AI called Collaborative Diffusion. In Collaborative-Diffusion based soccer the player and grass tile agents are antiobjects. Counter to the intuition of most programmers the grass tile agents, on top of which all the players are moving, are doing the vast majority of the computation, while the soccer player agents are doing almost no computation. This article illustrates that this role reversal is not only a different way to look at objects but, for instance, in the case with Collaborative Diffusion, is simple to implement, incremental in nature and more robust than traditional approaches.

Here's what most people got out of Design Patterns: "blah blah blah blah SINGLETON blah blah blah blah". I kid you not. I've seen this so many times that it's become a full-fledged pattern in its own right; patterns need a name, so let's call it the Simpleton Pattern.


I'll close by saying that if you still feel the need to use Singleton objects, consider using the Factory Method pattern instead. It gives you all of the flexibility of the Singleton, with nowhere near as many problems. Using the Singleton is usually just a sign of premature optimization - I know you dread instantiating objects; you've heard it's way slow. But just relax, take a deep breath, and treat yourself to a few extra instances. You'll be amazed at how fast computers have gotten these days, and you'll be pleased at the extra flexibility using real objects gives you. Enjoy!

ArgoUML is the leading open source UML modeling tool and includes support for all standard UML 1.4 diagrams. It runs on any Java platform and is available in ten languages. See the feature list for more details.

ArgoUML 0.26 and 0.26.2 were downloaded over 80,000 times and are in use all over the world. See the download statistics.

ArgoUML is distributed under the Eclipse Public License (EPL) 1.0.

When I worked as the lead designer on Microsoft Money, I eventually came across its scary basement: the elaborate checkbook register control for viewing and editing account transactions. This register control was first created around 1990 by legendary Microsoft engineer Doug Klunder. To get the most performance out of the PCs of the day, I believe he had the register itself more or less directly read and write transaction data from disk. In this capacity, this specific UI control was entirely and solely responsible for validating all transaction data; there was no separation between presentation, business logic, and on-disk representation.

Yup, sounds like MS to me. Bashing aside:

To prevent a critically important aspect of your UI metastasize into a scary basement means investing time in refactoring as you go, and this means moving more slowly that you would like. UI changes need to be evaluated in terms of the degree to which they compromise the solidity of the foundation.

A vast proportion of software at work today is horribly over-engineered for its task. And I’m not talking about the interfaces, about having too many controls or options for the users. These are, indeed, terrible sins but they are the visible ones. The worst of the overengineering goes on under the surface, in the code itself.


The most insidious cause of overengineering is over-generalizing. We will over-generalize anything given half a chance. Writing code to work with a list of students? Well, we might want to work with teachers and the general public someday, better add a base People class and subclass Student from that. Or Person and then EducationPerson and then Student. Yes, that’s better, right?

Only, now we have three classes to maintain each with their own virtual methods and interfaces and probably split across three different files plus the one we were working in when a one-line dictionary would have been fine.

Over time, though, my initially rosy feelings towards ORMs have begun to sour. I gradually realised I was spending a disproportionate amount of time trying to coax the ORM into doing my bidding - and when I succeeded, the results were often ugly, slow and needlessly opaque. Analysing the performance of some of the more complicated portions of my data access layer was often painful, and I spent cumulative hours poring over generated SQL, trying to figure out what the ORM was doing and why. Usually, improving performance involved side-stepping the ORM altogether. Recently, a particularly gnarly performance issue prompted me to ditch the ORM from a project altogether, with surprisingly pleasant results.

This paper examines this most frequently deployed of software architectures: the BIG BALL OF MUD. A BIG BALL OF MUD is a casually, even haphazardly, structured system. Its organization, if one can call it that, is dictated more by expediency than design. Yet, its enduring popularity cannot merely be indicative of a general disregard for architecture.

UMLGraph allows the declarative specification and drawing of UML class and sequence diagrams. The current features are part of an ongoing effort aiming to provide support for all types UML diagrams. An IEEE Software article titled On the declarative specification of models explains the rationale behind this approach. The tehnology behind UMLGraph was used to draw many of the diagrams appearing in the award-winning books Code Quality: The Open Source Perspective (Addison Wesley, 2006) and Code Reading: The Open Source Perspective (Addison Wesley, 2003). In addition, the UMLGraphDoc doclet included in this distribution automatically adds UML diagrams to javadoc documentation.

1–10 (12)   Next >   Last >|