Quali diagrammi UML sono ancora ampiamente utilizzati? [chiuso]

Insegno ingegneria del software a livello universitario e ho una domanda per i professionisti UML.

La maggior parte dei libri di testo di ingegneria del software si impegna seriamente a coprire i diagrammi UML. D'altra parte, ho sentito da molti laureati che UML non sembra più essere usato nelle trincee.

Quali diagrammi UML sono ancora ampiamente utilizzati nella pratica professionale e perché? Ci sono diagrammi che non vengono più utilizzati e perché?

NB: Al fine di evitare dibattiti e discussioni basati sull'opinione, si prega di illustrare la propria risposta con elementi fattuali e oggettivi (se possibile, verificabili) o osservazioni neutre sull'esperienza personale

Dai numerosi diagrammi proposti da UML, i diagrammi di classe e i diagrammi di sequenza sono ancora ampiamente utilizzati, sicuramente seguiti da diagrammi di stato:

• possono essere facilmente utilizzati su lavagne bianche per elaborare e discutere il design prima di saltare nel codice
• consentono di trasmettere molto rapidamente una panoramica che il codice da solo non fornisce così facilmente e non è possibile sostituirlo.

Penso che i casi d'uso nella vita reale siano usati in modo più occasionale. Nei grandi progetti, con diverse centinaia di casi d'uso, i diagrammi sono dolorosi da disegnare e offrono pochi vantaggi rispetto a una forma tabulare. I BPMN per la progettazione dei processi, la mappatura delle storie utente o la decomposizione tabulare degli eventi in stile Cockburn sono molto più utilizzati. Perché ? Perché sono più facilmente condivisi con gli utenti aziendali per elaborare in modo efficiente i requisiti.

Sono sicuro che sono luoghi in cui UML è ancora pesantemente e sistematicamente utilizzato. Non immagino che il software aerospaziale o i sistemi di controllo delle centrali nucleari siano prodotti senza la serie completa di documentazione UML. Ma credo che sia più un'eccezione che una regola.

Mi sento confermato in questa affermazione quando guardo nelle librerie. Un paio di anni fa, potresti trovare molti libri su UML 2.0. Al giorno d'oggi, se stai cercando UML 2.5, la scelta è piuttosto limitata. Peggio ancora: molti autori non si sforzano nemmeno di rivedere i loro libri precedenti per tenerli aggiornati (esempio: la bella introduzione " UML distillata " di Fowler che risale ancora al 2003 con UML 2.0 e lo stesso per "Elements di Ambler " di stile UML 2.0 "!).

Non credo che questa tendenza al ribasso cambierà, osservando la generalizzazione dell'agile e la sua promozione di "Software funzionante su documentazione completa".

Alla fine, direi in modo molto provocatorio che i metodi di modellazione sembrano seguire uno schema darwinistico: sopravviverà solo la tecnica di diagramma più adatta, quelli che offrono un chiaro vantaggio rispetto agli approcci informali (ad esempio l'illustrazione del tovagliolo) e un codice dettagliato (ad es. perché disegnare un diagramma di attività A1, quando il codice corrispondente potrebbe adattarsi su un foglio A4?) ;-)

D'altra parte, ho sentito da molti laureati che UML non sembra più essere usato nelle trincee.

Sono tutti usati nella pratica. Ma non tutti li usano. Alcune persone evitano del tutto il design e passano direttamente alla programmazione. Non puoi fare affidamento su prove aneddotiche per sapere cosa fanno "tutti".

Strumenti come UML funzionano meglio se li usi quando aggiungono valore ; per esempio

• per progetti più grandi
• per parti complicate di un progetto
• quando la progettazione del progetto richiede input da più persone

La loro creazione solo per il gusto di farli (o perché il processo dice che è necessario) non è produttiva. La migliore pratica è quella di essere selettivi su ciò che diagrammi e su quali tipi usi. Usa UML quando e dove aiuta ... e questo include la selettività dei tipi di diagrammi UML che usi.

Inoltre ... UML è stato progettato principalmente come strumento di progettazione. Non è così efficace (in questi giorni) come uno strumento di documentazione. Gli IDE tipici consentono di visualizzare molti aspetti se una struttura di base di codice al volo. Questo è spesso meglio che fare affidamento su diagrammi UML che potrebbero essere diventati obsoleti / imprecisi.

UML è ancora usato nelle trincee. Ma, come sempre, le persone ne usano un sottoinsieme. Quale sottoinsieme è soggetto ai problemi attuali.

UML è disponibile in molte versioni. Ma, come sempre, le persone usano i suoi simboli in modo informale e incostante.

UML è il modo in cui comprendiamo gran parte dei modelli di libri là fuori. È anche uno dei modi in cui comunichiamo sulla lavagna. Non è sparito Ma non verrà mai utilizzato formalmente come il codice.

Invece di produrre studenti in grado di correggere qualsiasi diagramma UML per conformarsi alla versione 2.5 di UML , o qualunque sia l'ultima, produce studenti in grado di comprendere ciò che il diagramma sta cercando di comunicare anche se non è del tutto coerente con una particolare versione di UML perché è come viene usato UML nelle trincee. Si presenta in strani dialetti locali, mescolati con altri sistemi, e talvolta inventiamo solo i nostri simboli.

Insegna loro che va bene chiedere cosa significano le cose. Non insegnare loro a correggere gli altri che stanno infrangendo alcune regole immaginate. Stiamo solo cercando di comunicare qui.

Il miglior uso che ho visto è quello di lasciare che un nuovo programmatore ci mostri il suo piano per risolvere un problema. Ci ha mostrato rapidamente le parti del sistema che hanno trascurato o che non hanno realizzato esistessero.

Ho anche lavorato in luoghi che richiedevano UML anche quando non erano necessari. Usavamo sempre lo stesso modello, quindi era solo una formalità. Siamo arrivati ​​al punto in cui abbiamo semplicemente fotografato nuovi nomi in vecchi diagrammi. Non incoraggiare questo tipo di utilizzo.

Ma penso che tutti sappiamo che c'è una differenza tra la normale freccia e la freccia aperta. Giusto?

Sarò specifico in base alla mia esperienza: - Diagramma di distribuzione - Diagramma di sequenza - Diagramma di classe Questi tre sono i più utilizzati in qualsiasi progetto, forniscono un reale valore di comunicazione con il team a diversi livelli.