Two key aspects
make these diagrams useful.First, they isolate the parts and relationships in the program
relevant to the intended changes, which keeps them simple.This makes it easy
tovisually reason about the
current and future state of the software, which has been called ``reasoning
in the diagram’’.Although the
programmer might be aware of other parts of the program which might be
impacted, they aren’t necessarily represented, again to keep the diagram
simple.
The second
aspect is that they record problems and intended changes in the program, so
they can serve as a visual `to-do’ list when later implementing the changes.
These hand-drawn
diagrams are very flexible, but take effort to produce, may be an inaccurate,
and can’t easily represent redesigns (unless the programmer goes to the
trouble of drawing multiple diagrams).