Dove lavoro, i diagrammi vengono fatti prima, durante e dopo la costruzione del prodotto.
Prima
I diagrammi creati prima sono usati per discutere delle possibili dipendenze con altri team (che devono essere coordinati il prima possibile), i sistemi di alto livello che dobbiamo costruire (interfaccia utente, servizio, API, ecc.) e le funzionalità dell'utente ogni componente soddisfa.
Sono costruiti in modo che il team si trovi sulla stessa pagina e possano parlare con gli altri team di ciò che verrà costruito, ad alto livello.
Durante
Durante lo sviluppo, costruiremo diagrammi quando avremo bisogno di discutere su come interagiscono i componenti di livello inferiore, su come i componenti si parleranno nel tempo e sui diversi contratti esistenti (tra interfaccia utente, servizio, database, ecc.).
Di solito sono costruiti in modo che il team possa capire e parlare tra di loro su come il sistema si sta evolvendo e notare cambiamenti dal progetto originale. Sono fatti NECESSARI, quando il team ha bisogno di discutere un problema complesso o un nuovo sistema.
Dopo
Questi sono di solito i meno utili. Questi diagrammi sono fatti a scopo di documentazione e aiutano i team futuri a capire come funziona il sistema come si presenta oggi. Non sono così preziosi perché, a questo punto, il team ha già costruito il sistema. Anche di fronte a un importante refactoring, il codice sarà più dettagliato e sfumato rispetto alla maggior parte dei diagrammi.
I diagrammi creati durante lo sviluppo del sistema saranno sempre i più preziosi perché è lì che vedrete difetti, potenziali miglioramenti e discussioni reali su come dovrebbe essere il sistema.
Detto questo, è completamente possibile in linguaggi come Java fare quasi tutto il tuo design orientato agli oggetti. I diagrammi delle classi si prestano a questo, e la costruzione di diagrammi può aiutarti a esercitarti a parlare del tuo sistema, prima di costruirlo (qualcosa di molto comune nelle interviste alla lavagna).
NB. Gli schemi di progettazione non dovrebbero essere "usati", sono emergenti. Quando noti qualcosa che stai facendo sembra uno schema di progettazione (il più delle volte in un diagramma) puoi iniziare a parlare delle preoccupazioni che sono associate a loro. L'introduzione preventiva di un modello di progettazione è una ricetta per il cattivo design.