Perché UML non viene utilizzato nella maggior parte dei software gratuiti (ad es. Su Linux)?


29

Sto cercando di capire perché UML non viene utilizzato nella maggior parte dei progetti di software libero . Ad esempio, il mio sistema Debian / Linux ha probabilmente più di diecimila pacchetti software gratuiti e non posso nominarne nemmeno uno che è stato sviluppato usando il framework e la metodologia UML espliciti . Ad esempio, Qt , GCC , Linux kernel , bash , GNU make , OCaml , Gnome , Unison , lighttpd , libonion , finestra mobile sono progetti di software libero, che (per quanto ne so) non menzionano affatto UML.

(La mia ipotesi è che UML sia molto adatto per il subappalto formale delle attività di sviluppo, e non è così che viene sviluppato il software libero)

Si noti che mentre leggevo del materiale su UML, non pretendo di averne una buona comprensione.

In realtà, non posso facilmente nominare un software gratuito in cui è stato utilizzato UML (tranne forse alcuni strumenti UML implementati come software libero). Forse openstack è un'eccezione (qualcosa che menziona UML).

(anche i vecchi progetti di software libero potrebbero aver adottato UML dopo che sono stati avviati, ma non lo hanno fatto)


Alcuni colleghi che lavorano su Papyrus hanno affermato che la maggior parte dei progetti di software libero non aveva all'inizio un modello formalizzato esplicitamente (e abbastanza approfondito). Inoltre, UML sembra molto più correlato a Java di quanto affermi (non sono del tutto sicuro che avrebbe senso per Ocaml o Common Lisp o Haskell o Javascript, e forse nemmeno per C ++ 11 ....). Forse lo sviluppo di software agile non è molto compatibile con UML.

Vedi anche questa risposta a una domanda in qualche modo correlata. Il blog di M.Fowler Is Design Dead? è perspicace.

PS. Non penso che sia principalmente una questione di opinione; ci dovrebbero essere alcune ragioni oggettive e alcune caratteristiche essenziali del software libero, che spiegano il perché. Tendo a indovinare che UML è utile solo per il subappalto formalizzato ed è utile solo quando una parte del software sviluppato è nascosta, come nei progetti proprietari. Se ciò fosse vero, UML sarebbe incompatibile con lo sviluppo del software libero.

NB: Io stesso non sono un fan di UML. Non definisco UML solo come documentazione cartacea, ma anche come formato [meta-] di dati per strumenti software


30
Forse perché UML è una schifezza? O è perché alla maggior parte dei software gratuiti manca una buona documentazione?
BЈовић,

19
Hai il contrario. Ci deve essere un motivo oggettivo per usare UML, non viceversa. FOSS non utilizza UML, o non esiste alcun motivo oggettivo o tutti i motivi non sono accettati dalla comunità FOSS.
Euforico,

18
Per alcuni dei progetti che hai elencato, i motivi sono piuttosto ovvi: perché i viaggi nel tempo non sono ancora stati inventati. UML è stato standardizzato per la prima volta nel 1997. Il progetto GNU è del 1983, GCC 1987, Bash 1988, GNU make 1989, Qt 1991, OCaml 196, Gnome 1997. Solo lighttpd e Unison sono persino abbastanza giovani da essere stati sviluppati usando UML, ma lighttpd è scritto in C e Unison in OCaml, entrambi linguaggi che non possono essere descritti bene in UML. Inoltre, gli sviluppatori di software libero generalmente credono nella scrittura del codice in modo tale da poter essere compreso senza l'aiuto di strumenti esterni.
Jörg W Mittag,

26
UML non è molto utilizzato nello sviluppo di software open source o chiuso. È utilizzato principalmente da persone che parlano dello sviluppo di software.
Karl Bielefeldt,

16
Lo stesso motivo per cui UML non è molto utilizzato nello sviluppo di software non libero. Suona bene sulla carta, ma in pratica non sembra offrire alcun vero vantaggio.
Giovanni B

Risposte:


37

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.


1
Un sacco di testo, ma solo l'ultimo ma un paragrafo risponde effettivamente alla domanda. Inoltre, hai riaperto la domanda solo per poter rispondere?
Euforico,

6
@Euforico Sebbene l'ultimo paragrafo risponda alla domanda, il resto è necessario per impostare lo sfondo e normalizzare termini e concetti. E no, aveva già 4 voti di riapertura: ho lanciato il 5 ° e ho risposto.
Thomas Owens

3
+1 Risposta molto completa. A mio avviso, i paragrafi precedenti spiegano la conclusione. Molto bene!
Andres F.

8

Usiamo Linux come esempio,

  • Non è un progetto orientato agli oggetti, alcune parti, come il VFS, possono essere modellate in UML, ma altre non possono essere o non essere molto efficaci, cioè in pratica solo una traduzione diretta da structun diagramma di classe senza relazioni.
  • UML è utile per la documentazione, per ottenere qualcosa di nuovo in un progetto si aggiorna. Questo non è qualcosa che si è adattato davvero a Linux, ci si aspetta che le persone lo imparino da soli.
  • Non sono sicuro di quale strumento UML utilizzare, le persone devono essere d'accordo su qualcosa se dovesse essere mantenuto. C'era un'applicazione java gratuita per questo, ma non credo che molti vorrebbero usarlo.
  • Negli anni '90 la GUI era ancora una sfida su Linux. Basta andare a scavare nell'archivio della mailing list, scommetto che non troverai alcun tipo di grafica diversa dal logo per Linux stesso in formato xpm da mostrare al momento dell'avvio. Il testo normale è il formato preferito.
  • Non credo che a nessuno importasse davvero del design. Le persone si preoccupano delle funzionalità e se vengono accettate, il codice verrà esaminato. I casi d'uso sono ancora meglio descritti a parole, proprio come vengono scritti standard come POSIX e SUS.
  • Molti oggetti nel dominio dei sistemi operativi sono ben compresi e standardizzati all'interno della comunità. Ad esempio, le persone saprebbero come struct in_addrappare in memoria, nessun diagramma potrebbe renderlo più chiaro.
  • UML non aiuta molto nella modellistica dell'algoritmo, come l'allocatore di memoria, lo scheduler, i gestori di interrupt, ecc. La fonte è probabilmente più facile da capire.

Queste sono le cose che mi vengono in mente nelle impostazioni del progetto Linux. Si tratta più di praticità, immagino. Curiosamente, non ricordo che Tanenbaum abbia usato alcun UML nel suo libro di testo del SO per descrivere Minix.

Probabilmente vale la pena menzionare, anche io non uso UML al lavoro. Probabilmente il 20% delle persone con cui lavoro conosce un sottoinsieme di UML.


4
Linux usa l' orientamento agli oggetti, semplicemente non usa un linguaggio orientato agli oggetti . È vero, Linux contiene anche parti scritte in uno stile molto procedurale, ma altre parti, come l'interfaccia del modulo del kernel, sono decisamente orientate agli oggetti.
cmaster

Ci sono più di diagrammi di classe in UML.
Michael Dorner,

Ogni grande progetto software richiede una progettazione orientata agli oggetti.
Kais,

I collaboratori devono comprendere un linguaggio di modellazione standard prima di lavorare al progetto, ed è ciò che giustifica la necessità di una documentazione di modellazione software sia in UML, SysML, IDEF0, ODL o OCL.
Kais,

2

UML è una rappresentazione, quindi è una forma di linguaggio, e per l'argomentazione supponiamo che il suo scopo sia quello di comunicare un modello mentale da una persona all'altra.

Quello che cerco in una lingua è la sua efficienza nel catturare i cambiamenti nel proprio modello mentale. Supponiamo che dopo aver scritto la descrizione del proprio modello, sia necessario apportare una piccola modifica. Quanto deve essere grande la modifica della rappresentazione? In un linguaggio testuale, un modo per misurare è quello di eseguire un difftra il codice prima e dopo e contare le differenze. In un linguaggio grafico, ci dovrebbe essere un modo simile per misurare la differenza.

IMHO, chiamo un linguaggio "dominio specifico" (DSL) nella misura in cui minimizza la misura di cui sopra, il che ha evidenti vantaggi nel ridurre i costi di manutenzione e i bug. Come creare una DSL? Esistono diversi modi. Uno dei più semplici è semplicemente definire strutture e metodi di dati in un linguaggio di programmazione esistente. Ciò aggiunge nomi e verbi alla lingua di base, rendendo più facile dire ciò che si desidera. (Nota: non cerco un DSL che non abbia una curva di apprendimento. È possibile che il lettore di un DSL debba investire il costo una tantum di apprendimento.)

Il punto importante è: in tutti i casi, la DSL deve contenere i termini che rendono conveniente l'espressione del proprio modello e le modifiche al modello. Dal momento che non esiste un limite evidente alla gamma di domini possibili, nessun DSL singolo può servirli tutti.

La mia impressione di UML è ciò che ha cercato di fare.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.