J2EE Design Patterns

The Magnificent Seven

Remember that UML is not the be-all and end-all of software development methodology. It’s just an extremely useful tool for communications between and within user groups, development teams, and deployment staff. It’s possible to go overboard on modeling, particularly in areas that don’t map directly to code, such as when building use cases during the requirements gathering phase.

UML is complex. The specification itself is dense, and as a result much of the available literature must address the complexities in detail. (Since this isn’t a book on UML, we’re saved from that particular fate.) The complexity can work for your project, but it can also result in massive expenditures of time and effort, particularly in “high ceremony” development environments that produce vast quantities of paper.^[2] Most teams find a comfortable middle ground in which modeling, via UML or other methods, serves the team’s underlying goals rather than becoming an end in itself.

The UML isn’t the only tool that can be misused, of course. Design patterns can also be misapplied, making simple problems more complex than necessary, or encouraging code-first design-later development cycles as developers assume that the presence of patterns (with their promises of easy extensibility and maintenance) allow requirements to be dealt with as they come up.

To be useful, design patterns need to be expressed. While there are a variety of ways to do this, a UML diagram is part of most of them. The diagram ...