Why Design Visually?

We'd like to divide that question into two parts: Why design at all, rather than just code? And why design visually?

To answer the first question, we can draw on the common analogy of building complex physical structures, such as bridges. Crossing a small stream requires only a plank of wood—no architect, no workers, and no plans. Building a bridge across a wide river requires a lot more: a set of plans drawn up by an architect so that you can order the right materials; planning the work; communicating the details of the complex structure to the builders, and getting a safety certificate from the local authority. It's the same with software. You can write a small program by diving straight into code, but building a complex software system requires some forethought. You must plan it, communicate it, and document it to gain approval.

The four aims of visual design are therefore as follows:

• To help you visualize a system you want

• To enable you to specify the structure or behavior of a system

• To provide you with a template that guides you in constructing a system

• To document the decisions you have made

Traditionally, design processes like the Rational Unified Process have treated design and programming as separate disciplines, at least in terms of tools support. You use a visual modeling tool for design, and a separate IDE for coding. This makes sense if you treat software development like bridge building and assume that the cost of fixing problems during implementation is much higher than the cost of fixing those problems during design. For bridges that is undoubtedly true; but in the realm of software development, is it really more costly to change a line of code than it is to change a design diagram? Moreover, just as bridge designers might want to prototype aspects of their design using real materials, so might software designers want to prototype certain aspects of their design in real code. For these reasons, the trend has been toward tools that enable visual design and coding within the same environment, with easy switching between the two representations, thus treating design and coding as essentially two views of the same activity. The precedent was set originally in the Java space by tools such as Together-J, and more recently in the .NET space by IBM-Rational XDE, and this approach has been embraced fully by the Team Edition for Software Architects.

Now the second part of the question: If the pictorial design view and the code view are alternative but equivalent representations, then why design visually at all? The answer to the second part of the question is simple: A picture paints a thousand words. To test that theory, just look at the figures in this chapter and imagine what the same information would look like in code. Then imagine trying to explain the information to someone else using nothing but a code listing.

Of course, if we're going to use visual modeling as a communication tool, the notation must be commonly understood. In UML terms, this means an industry-standard, general-purpose notation that is all things to all people. In Visual Studio 2005 terms, this means a set of domain-specific notations that are highly tuned for the information they are designed to convey. Nonetheless, the first version notations are familiar enough to be immediately accessible to most UML-trained software designers.