Aby właściwie to wyjaśnić, potrzebujemy krótkiej lekcji historii. We wczesnych latach inżynierii oprogramowania często stosowaną analogią było budowanie domu. Architekt i inżynier budowlany omawiają plany z klientem i opracowują projekt. Następnie budowniczowie wykonują ten projekt, aby zbudować rzeczywisty dom. Pisanie kodu było postrzegane jako odpowiednik budowy rzeczywistego domu. Tak więc istniała potrzeba wcześniejszego zaprojektowania, zanim ta kompilacja będzie mogła mieć miejsce. Stworzono różne narzędzia do projektowania graficznego, w tym UML.
Pierwotnie pomysł z UML polegał na tym, że należałoby w pełni zaprojektować system z UML, a następnie przekazać go programistom, aby przełożyły ten projekt na kod. W rzeczywistości to po prostu nie działa i doprowadziło do tego, że lata programistów były postrzegane jako „realizatorzy”, a nie „projektanci”, projekty były spóźnione, projekty musiały się ciągle zmieniać po tym, jak miały być ukończone itp.
Powód jest prosty. Kodowanie to projektowanie . W przypadku analogii domu kod jest rysunkiem architekta. Kompilator jest konstruktorem, który bierze te projekty i tworzy z nich program. Ta realizacja doprowadziła następnie do powstania zwinnych technik, narodzin TDD itp.: Narzędzi pomagających poprawić jakość tego projektu kodu.
Tak jak architekt może przygotować wstępne szkice, aby pomóc jej i jej zespołowi wizualizować ogólny projekt, tak programista może użyć UML lub innych narzędzi, aby pomóc w wizualizacji potrzebnego projektu. Tak jak te szkice nie są ślepo przestrzegane, tak nie należy ślepo przestrzegać UML. Projekt kodu powinien ewoluować w oparciu o zwinne iteracje i używanie TDD. Podsumowując, tak jak architekt może zbudować model domu, aby pomóc jej i jej zespołowi w wizualizacji rysunków, tak też UML może pomóc w wizualizacji struktury kodu.
Jak mówi wujek Bob, nie możesz sprawdzić poprawności UML, możesz jedynie zweryfikować kod. Dlatego kod jest główną dokumentacją projektową, a UML, jeśli jest używany, jest jedynie dokumentacją wtórną.