Per spiegarlo correttamente, abbiamo bisogno di una breve lezione di storia. Nei primi tempi dell'ingegneria del software, un'analogia usata spesso era la costruzione di una casa. Un architetto e un ingegnere strutturale discutono i piani con un cliente e escogitano un progetto. I costruttori seguono quindi il progetto per costruire la casa vera e propria. Il codice di scrittura è stato visto come l'equivalente di costruire la casa reale. Quindi, c'era una percezione della necessità di una progettazione anteriore prima che quella costruzione potesse aver luogo. Sono stati creati vari strumenti di progettazione grafica, con UML come uno di questi.
L'idea originariamente di UML era che si progetterebbe un sistema con UML, quindi lo si consegnerebbe ai programmatori per tradurre quel progetto in codice. In realtà, questo non funziona e ha portato ad anni di programmatori considerati "implementatori", piuttosto che "progettisti", i progetti sono in ritardo, i progetti devono cambiare costantemente dopo che avrebbero dovuto essere completi ecc.
La ragione è semplice. La codifica è design . Con l'analogia della casa, il codice è i disegni dell'architetto. Il compilatore è il costruttore che prende quei progetti e crea un programma da loro. Questa consapevolezza portò quindi a tecniche agili, alla nascita di TDD ecc.: Strumenti per aiutare a migliorare la qualità di quel design di codice.
Proprio come un architetto potrebbe produrre schizzi preliminari per aiutare lei e il suo team a visualizzare il progetto generale, così uno sviluppatore potrebbe usare UML o altri strumenti per aiutare a visualizzare il progetto necessario. Proprio come quegli schizzi non sono seguiti ciecamente, quindi l'UML non dovrebbe essere seguito ciecamente. La progettazione del codice dovrebbe evolversi da iterazioni agili e utilizzando TDD. Allo stesso modo, proprio come un architetto potrebbe costruire un modello della casa per aiutare lei e il suo team a visualizzare i disegni, così UML può essere usato per aiutare a visualizzare la struttura del codice.
Come dice lo zio Bob, non puoi convalidare l'UML, puoi solo convalidare il codice. Pertanto, il codice è la documentazione di progettazione principale e UML, se utilizzato, è solo documentazione secondaria.