35.2. Suggestions for UML Drawing Within the Development Process

Level of Effort

As a guideline, consider diagramming in pairs for the following period, before serious programming in the iteration.

In both cases, drawing does not have to stop after this early focussed effort. During the iteration, developers may head—ideally in pairs—“to the whiteboard” for short sessions to sketch out ideas before more programming. And they may do another longer half-day session partway through the iteration, as they hit a complex problem within the scope of their initial task, or finish their first task and move on to a second.

Other Suggestions

• Draw in pairs, not alone. Most importantly, the synergy leads to better designs. Secondly, the pair quickly learns design skills from each other, and thus both become better designers. It is hard to grow as a software designer when one designs in isolation. Regularly rotate with new drawing/design partners to gain broad exposure to another's knowledge.

• To clarify a point alluded to several times, in iterative processes (such as the UP), the programmers are also the designers; there is not a separate team that draws designs and hands them over to programmers. The developers put on their UML hats, and draw a little. Then they put on their programmer hats and implement, and continue to design while programming.

• If there are ten developers, suppose that there are five drawing teams working for one day at different whiteboards. If the architect spends time rotating through the five teams, he or she will come to see points of dependency, conflict, and cross-pollinating ideas. The architect can then act as a liaison to bring the designs into some harmony, and clarify the dependencies.

• Hire a technical writer for the project and educate the writer in some UML notation and basic OOA/D concepts (so he or she understand the context). Have the writer help by doing the “fussy work” with UML CASE tools, reverse-engineering diagrams from code, printing and displaying large plotter prints of diagrams, and so forth. The developers spend their (more expensive) time doing what they do best: figuring out designs and programming. A technical writer supports them by handling diagram management, in addition to true technical writing responsibilities such as working on the end-user documents. This is known as the Mercenary Analyst pattern [Coplien95a].

• Arrange the development area with many large whiteboards in close proximity.

• To generalize, maximize the work environment for convenient drawing on walls. Create a “drawing-friendly” and “hanging diagrams”-friendly environment. You can't expect a successful visual modeling culture in an environment where developers are struggling to draw on small two-foot by three-foot whiteboards, regular size computer monitors, or pieces of paper. Comfortable drawing takes very large, open drawing spaces—physical or virtual.

• As an adjunct to whiteboards, use thin plastic “static cling” white sheets (they come in packages of 20 or more) that can be placed on the walls; they are available at many stationary stores. They remain attached to the wall by static cling, and can be used like a whiteboard with an erasable marker. These can be plastered across a wall space to create massive, temporary “whiteboards.” I have coached groups where we wallpapered every wall—top to bottom—of the project room with these, and found them a great communication aid.

• If using a whiteboard for UML drawings, use a device (there is at least one on the market) that captures the hand drawings and transmits them to a computer as a graphics file. One design involves a receiving part that snaps on to a corner of the whiteboard and special transmitting sleeves that marker pens insert into.

• Alternatively, if using a whiteboard for UML drawings, use a digital camera to capture the images, usually in two or three sections. This is a fairly common and effective diagramming practice.

• Another whiteboard technology is a “printing” whiteboard, which is usually a two-sided whiteboard with a scanner and attached printer. These are also useful.

• Print out the hand-drawn UML images (captured by camera or whiteboard device) and hang them visibly very near to the programming workstation. The point of the diagrams is to provide some inspiration for the direction of the programming, so that the programmers can glance at them while programming. If they are drawn but “buried,” there was little point in drawing them.

• If drawing UML by hand, use simple notation chosen for speed and ease of drawing.

• Even if doing creative design on a whiteboard, use a UML CASE tool to generate package and class diagrams by reverse-engineering the source code (from the last iteration) at least at the beginning of each subsequent iteration. Then, use these reverse-engineered diagrams as the starting point for subsequent creative design.

• Periodically print out freshly reverse-engineered interesting/unstable/difficult package and class diagrams in an enlarged size (for viewing ease) on a plotter that can print on a continuous sheet of three- or four-foot-wide paper. Hang these on walls very close to the developers as visual aids. The technical writer, if present, can do this work. Encourage developers to draw and scribble on the plots during creative design work.

• With respect to reverse-engineering, a few UML tools support reverse-engineering of sequence diagrams—not just class diagrams—from source code. If available, use one to generate sequence diagrams for architecturally significant scenarios, print them in large size on the plotter, and hang them for easy viewing.

• If using a UML CASE tool (indeed, do this for all programming work), use a dual-monitor workstation (two regular-size flat-panel displays are cheaper than a single large flat-panel display). Modern operating systems support (at least) dual video cards and thus two displays. Organize your windows within the UML tool across the two displays. Why? One small monitor is psychologically or creatively inhibiting in terms of drawing and visual languages because the visual canvas space is too small and cramped. A developer can get into the discouraged attitude of “the design is finished because the window is full, and it looks too cluttered.”

• When using a UML CASE tool and doing creative design in pairs or small groups, attach two computer projectors to the two video cards of the computer and align the projections on the wall so that the team can see and work with a large visual canvas space. A small canvas and hard-to-see diagrams are a psychological and social impediment to small-group collaborative visual design.