Esistono diversi modi per utilizzare UML. Martin Fowler chiama queste modalità UML e ne identifica quattro: UML come Note , UML come Sketch , UML come Blueprint e UML come linguaggio di programmazione .
UML come linguaggio di programmazione non è mai decollato. C'è stato un po 'di lavoro in questo settore con nomi diversi, come Model Driven Architecture o Model Based Software Engineering. In questo approccio, crei modelli altamente dettagliati del tuo sistema software e generi il codice da tali modelli. Ci possono essere alcuni casi d'uso in cui questo approccio è utile, ma non per software generici e soprattutto non al di fuori di grandi aziende che possono permettersi gli strumenti che alimentano questo approccio. È anche un processo che richiede tempo: posso digitare il codice per una classe più velocemente di quanto possa creare tutti i modelli grafici necessari per implementarlo.
UML come progetto è spesso indicativo di un progetto "big design up front" . Non deve essere, ovviamente. Il modello può essere completamente descritto anche per un determinato incremento. Ma l'idea è che il tempo è trascorso a creare un design sotto forma di modelli UML che vengono poi passati a qualcuno per convertirli in codice. Tutti i dettagli sono esplicitati e la conversione in codice tende ad essere più meccanica.
UML come Sketch e UML come Notes sono simili per natura, ma differiscono in base a quando vengono utilizzati. L'uso di UML come schizzo significa che disegnerai i disegni usando le notazioni UML, ma è probabile che i diagrammi non siano completi, ma ti concentrerai su aspetti particolari del disegno che devi comunicare con gli altri. UML come Notes è simile, ma i modelli vengono creati dopo il codice per aiutare a comprendere la base di codice.
Quando stai considerando questo, penso che tutto quanto sopra sia vero per qualsiasi tipo di notazione di modellazione. È possibile applicarlo a diagrammi entità-relazione, diagrammi IDEF , notazione di modellazione dei processi aziendali e così via. Indipendentemente dalla notazione di modellazione, è possibile scegliere quando applicarla (prima come una specifica, dopo come una rappresentazione alternativa) e quanti dettagli (dettagli completi sugli aspetti chiave).
L'altro lato di questo è la cultura open source.
Spesso, i progetti open source iniziano per risolvere un problema che un individuo (o, oggi, un'azienda) sta vivendo. Se viene lanciato da un individuo, il numero di sviluppatori è 1. In questo caso, l'overhead di comunicazione è estremamente basso e non è necessario comunicare i requisiti e il design. In un'azienda, è probabile che ci sia una piccola squadra. In questo caso, probabilmente dovrai comunicare le possibilità di progettazione e discutere i compromessi. Tuttavia, una volta prese le decisioni di progettazione, è necessario mantenere i modelli man mano che la base di codice cambia nel tempo o eliminarli. In termini di modellazione agile , "documentare continuamente" e mantenere una "singola fonte di informazioni" .
In breve, c'è l'idea che il codice sia design e che i modelli siano solo viste alternative del design. Jack Reeves ha scritto tre saggi sul codice come design e ci sono anche discussioni sul wiki di C2, discutendo delle idee secondo cui il codice sorgente è il design , il design è il codice sorgente , codice sorgente e modellazione . Se ti abboni a questa convinzione (cosa che faccio), allora il codice sorgente è la realtà e qualsiasi diagramma dovrebbe esistere per rendere più comprensibile il codice e, soprattutto, la logica alla base del perché il codice è quello che è.
Un progetto open source di successo, come quelli che hai citato, ha collaboratori in tutto il mondo. Questi collaboratori tendono ad essere tecnicamente competenti nelle tecnologie che alimentano il software e sono probabilmente anche utenti del software. I collaboratori sono persone in grado di leggere il codice sorgente con la stessa facilità dei modelli e di utilizzare strumenti (IDE e strumenti di reverse engineering) per comprendere il codice (incluso la generazione di modelli, se ne sentono la necessità). Possono anche creare schizzi del flusso da soli.
Delle quattro modalità descritte da Fowler, non credo che troverai un progetto open source, o molti progetti ovunque, che usano linguaggi di modellazione come linguaggi di programmazione o progetti. Questo lascia note e schizzi come possibili usi per UML. Le note verrebbero create dal collaboratore del collaboratore, quindi probabilmente non le troverai caricate da nessuna parte. Gli schizzi diminuiscono di valore man mano che il codice diventa più completo e probabilmente non verrà mantenuto in quanto ciò comporterebbe solo uno sforzo da parte dei collaboratori.
Molti progetti open source non hanno modelli resi disponibili perché non aggiungono valore. Tuttavia, ciò non significa che i modelli non siano stati creati da qualcuno all'inizio del progetto o che le persone non abbiano creato i propri modelli del sistema. È solo più tempo efficace per mantenere una fonte di informazioni di progettazione: il codice sorgente.
Se vuoi trovare persone che si scambiano informazioni di progettazione, ti consiglio di consultare qualsiasi tipo di forum o mailing list utilizzato dai collaboratori. Spesso, questi forum e mailing list fungono da documentazione di progettazione per progetti. Potresti non trovare UML formale, ma potresti trovare una sorta di rappresentazione grafica delle informazioni di progettazione e dei modelli lì. Puoi anche entrare nelle chat room o in altri canali di comunicazione per il progetto: se vedi persone che parlano di decisioni di progettazione, potrebbero comunicare con i modelli grafici. Ma probabilmente non entreranno a far parte di un repository poiché non sono utili una volta raggiunto il loro scopo nella comunicazione.