2.2 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.

^[2] This is not a judgment against highly formalized development lifecycles. Depending on the project requirements and the team available, appropriate documentation can vary from the back of a few napkins (rare) to thousands of pages (equally rare).

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 can make broad concepts and implementation details clear in a language-independent way that doesn't require working through large chunks of sample code. There are relatively few programming patterns that don't lend themselves to some sort of UML representation.

Coupling modeling with design patterns has a number of advantages. The model provides context for choosing the right design patterns, although the presence of effective design patterns will also, perhaps somewhat recursively, influence the development of the model. In most circumstances, the result is simpler, smaller, more manageable software.

Enterprise developers are faced with challenges in the area of software validation, particularly in industries that are highly regulated or in which systems are a major business asset.^[3] Software validation efforts can be time-consuming and require clear documentation at the design and implementation levels—and in some cases, provable correctness. In these environments, proven patterns and documented design make it easier to create software that passes muster.

^[3] This is an issue that is particularly near to Will's heart.

When introducing new developers to effective enterprise design, we like to combine the modeling approach of the Three Amigos and the patterns approach of the Gang of Four. We feel strongly that effective software engineering can't take place with just one approach or the other. Luckily, the two approaches are not contradictory, and we see no reason to separate them. Hence, the Three Amigos join up with the Gang of Four and become the Magnificent Seven. Or so we hope.