Per spiegarlo correttamente, abbiamo bisogno di una breve lezione di storia. All'inizio dell'ingegneria del software, un'analogia spesso usata era la costruzione di una casa. Un architetto e un ingegnere strutturale discutono i piani con un cliente e escogitano un progetto. I costruttori quindi seguono quel disegno per costruire la casa reale. La scrittura del codice era vista come l'equivalente della costruzione della casa reale. Pertanto, è stata percepita la necessità di progettare in anticipo prima che quella costruzione potesse aver luogo. Sono stati creati vari strumenti di progettazione grafica, di cui UML è uno di questi.
L'idea originariamente con UML era che si progettasse completamente un sistema con UML, quindi lo si passasse ai programmatori per tradurlo in codice. In realtà, questo non funziona e ha portato a anni in cui i programmatori venivano visti come "implementatori", piuttosto che "progettisti", i progetti in ritardo, i progetti che dovevano cambiare costantemente dopo che dovevano essere completi ecc.
Il motivo è semplice La codifica è design . Con l'analogia della casa, il codice sono i disegni dell'architetto. Il compilatore è il costruttore che prende quei progetti e crea un programma da essi. Questa realizzazione ha quindi portato alla nascita di tecniche agili, TDD ecc.: Strumenti per aiutare a migliorare la qualità della progettazione di quel codice.
Proprio come un architetto potrebbe produrre schizzi preliminari per aiutare lei e il suo team a visualizzare il design complessivo, così uno sviluppatore potrebbe utilizzare UML o altri strumenti per aiutare a visualizzare il design necessario. Proprio come quegli schizzi non sono seguiti ciecamente, così UML non dovrebbe essere seguito ciecamente. Il design del codice dovrebbe evolversi da iterazioni agili e usando 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 utilizzato per aiutare a visualizzare la struttura del codice.
Come dice lo zio Bob, non puoi validare l'UML, puoi solo validare il codice. Pertanto il codice è la documentazione di progettazione principale e UML, se utilizzato, è solo documentazione secondaria.