Quindi, quando ero all'università, ero istruito sui vantaggi di UML e del suo futuro nello sviluppo del codice.

Ma dalla mia esperienza nel settore, ho scoperto che mentre usiamo i diagrammi - che vanno dai diagrammi ER, ai diagrammi di classe, ai diagrammi di stato, ai diagrammi di flusso di lavoro - tutto ciò è a fini di comunicazione.

Cioè, non ho mai generato codice automaticamente dai diagrammi e, dal punto di vista della comunicazione, generalmente cerco di mantenere i miei diagrammi il più semplice e facile da capire possibile.

Ma quando guardo Visio ed Enterprise Architect, sembra che abbiano molti tipi diversi di grafici, forme, oggetti di proprietà, la maggior parte dei quali non uso.

Le persone usano UML per fare cose più sofisticate come la generazione di codice o database?

Sì, gli strumenti UML CASE erano uno degli articoli più interessanti degli anni '90 ... e quindi non sono riusciti a consegnare.

La ragione fondamentale di ciò è che i diagrammi UML (o quasi tutti gli altri tipi di) aiutano a comprendere il problema e / o il programma a risolverlo solo nella misura in cui il diagramma sta sottraggendo i dettagli di implementazione del codice attuale. Pertanto (per qualsiasi pezzo di codice non banale), un diagramma di facile comprensione è intrinsecamente inutile per la generazione del codice , perché privo dei dettagli necessari. E viceversa, un diagramma che è direttamente utilizzabile per la generazione del codice non aiuta molto a capire il programma meglio del codice stesso. Se hai mai visto un diagramma di classe UML retroingegnerizzato dal codice di produzione, probabilmente sai cosa intendo.

L'unica potenziale eccezione a ciò che conosco sono i diagrammi Entità-Relazione, che non comprendono il codice in sé, solo (come suggerisce il nome) pezzi di dati e le loro relazioni. Ma non ho mai sentito parlare di un tentativo riuscito di utilizzare qualsiasi tipo di diagrammi UML per la generazione di codice reale [Aggiornamento] - vale a dire più di scheletri di classe e codice banale come getter / setter -, tranne in strumenti / aree per scopi speciali come ORM, come testimoniato di Doc Brown sotto [/ Update] , e penso che non sia un caso.

Personalmente non odio UML - penso che i diagrammi UML possano essere un ottimo strumento di comunicazione - per mostrare le tue intenzioni e idee durante le discussioni di progettazione o per visualizzare l'architettura della tua app. Ma è meglio tenerli a questo, e non cercare di usarli per cose in cui non sono bravi.

Quindi, quando ero alla uni (poco fa), mi è stato detto che UML era il futuro, UML sostituirà la programmazione e genereremo semplicemente il codice dai diagrammi ecc.

Avevano torto. Ciò accadrà nel momento in cui le persone abbandoneranno il discorso e torneranno alla pittura rupestre.

I problemi del mondo reale e i programmi che li risolvono hanno una complessità essenziale che non può essere ridotta. Per produrre un programma di lavoro, tale complessità deve essere catturata ed espressa in un linguaggio eseguibile. La domanda è se un linguaggio di programmazione schematico potrebbe essere più efficace di un linguaggio di programmazione testuale. Abbiamo sperimentato la programmazione schematica per circa trenta anni, e finora le prove sono in stragrande maggioranza a favore della programmazione testuale. Non sono a conoscenza di alcuna importante applicazione prodotta dalla generazione di codice dai diagrammi.

NO

La leggenda era basata sul presupposto fallito che la scrittura:

class ClassName extends SomeThing
{

}

... è difficile e necessita di automazione .

Potresti ancora trovare il credente occasionale o la folla di credenti.
Ma è così che vanno le religioni e i culti.

Ci sono stato, non l'ho trovato troppo utile.

Generalmente i diagrammi abbastanza specifici da generare un po 'di codice da essi, principalmente il diagramma di classe, non aggiungono molto in termini di comprensione effettiva del programma e non è possibile generare codice dai diagrammi di panoramica come caso d'uso o attività a livello di panoramica che sono cruciale per la documentazione. Un diagramma che è utile per comprendere e da cui può essere generato il codice è il diagramma di stato, che risulta utile quando è realmente necessaria una macchina a stati. Ma generalmente dovresti cercare di evitarli, perché sono intrinsecamente soggetti a errori.

In un progetto ci è stato richiesto di progettare il codice nel modellatore UML (Rhapsody) e di generarlo da lì. In un certo senso ha funzionato ed è stato probabilmente leggermente più semplice rispetto alla digitazione manuale delle intestazioni (era C ++) e dei prototipi. La capacità di mantenere quei due coerenti automaticamente era in qualche modo utile.

I corpi del metodo dovevano ancora essere compilati a mano, perché i diagrammi non possono davvero rappresentarlo, ad eccezione degli scheletri delle macchine a stati.

D'altra parte è piuttosto complesso, quindi devi imparare un sacco di cose extra e, soprattutto, è stato un dolore fondersi. La fusione è ben studiata per i file di testo e funziona con essi, ma nessuno ha ancora inventato un modo semplice per unire le modifiche ai diagrammi. Rhapsody mantiene in realtà parte delle informazioni nel codice generato e le analizza, quindi non era del tutto inutilizzabile, ma era ancora una seria complicazione.

Sebbene sia certamente possibile generare codice (e persino interi sistemi) direttamente dai modelli UML, non l'ho mai visto essere utilizzato in questo modo.

Nella mia esperienza, la maggior parte delle aziende sembra usarlo come strumento di comunicazione per i requisiti, o "MS Paint per disegnare diagrammi".

Una distinzione importante che vorrei fare è che la maggior parte degli strumenti di modellazione UML ti consente di creare un singolo modello del tuo sistema. Visio, ad esempio, ha una buona conoscenza di come funziona UML e ci sono molte cose che puoi aggiungere che non sono direttamente correlate al diagramma. I diagrammi reali sono semplicemente diverse prospettive su parti del modello, consentendo di evidenziare diversi aspetti del sistema.

tutto ciò (schemi di modellazione) è a scopo di comunicazione

La modellazione ha 4 usi importanti nel processo di sviluppo del software:

1. Strumento di progettazione integrata

2. Strumento di comunicazione

3. Un aiuto per la generazione di software

4. Un modo per ridurre la complessità del problema delle parole reali (l'ho appreso dalla risposta di @kevin cline sopra)

5. Il processo di modellazione induce alcuni designer a pensare a dettagli non considerati durante la codifica (e viceversa). La modellazione in fase di progettazione consente di considerare un'immagine più ampia rispetto alla codifica di un metodo o di una classe in una lingua.

La modellazione secondo me è vitale per la costruzione di database (diagrammi ER), la comprensione dei flussi di processo (diagrammi di attività) e la comprensione delle interazioni utente-sistema (diagrammi di casi d'uso).

Le persone usano UML per fare cose più sofisticate come la generazione di codice o database?

Si Certamente. È possibile utilizzare ERD (non un diagramma UML) e diagrammi di classe (a seconda delle capacità del proprio strumento) per generare:

1 - Data Definition Language (DDL)

2 - Stored procedure per CRUD e diagrammi di classe nella tua lingua preferita (meno utile poiché gli strumenti ORM fanno di più al riguardo)

Tra le caratteristiche più preziose degli strumenti di modellazione ci sono:

1 - Capacità di mantenere l'integrità del modello. Se si esegue una modifica, si propaga nel modello

2 - Capacità di rispondere alle domande di utilizzo (dove viene utilizzato l'account nel mio modello?)

3 - Capacità di consentire agli utenti simultanei di lavorare sul modello

4 - Ricerca all'interno di rappresentazioni grafiche

5 - Controllo della stampa

6 - Stratificazione (organizza gli elementi del diagramma in livelli) in modo che tu possa concentrarti su un livello alla volta

7 - Generazione di codice di database per diversi sistemi di database

8 - Convalida del modello (verifica coerenza, chiavi mancanti, cicli, ecc.)

Quindi, gli strumenti di modellazione, specialmente quelli buoni, fanno molto di più di Paint.

Usiamo Software Architect per realizzare progetti di alto livello e per documentare alcune delle interazioni più arcane tra i nostri componenti. A volte generiamo lo scheletro dell'app dai diagrammi, ma una volta fatto manteniamo entrambi separatamente, non proviamo a reingegnerizzare il codice in un diagramma dopo che è completo. Usavo uno strumento chiamato Rational XDE che funzionava abbastanza bene per i piccoli programmi, ma si perdeva quando si iniziava ad aggiungere gestori di eventi Swing o si cercava di lavorare con Struts.

Penso che gran parte del motivo per cui le persone non scrivono in UML sia che ci vuole molto più lavoro per specificare completamente tutto in UML e quindi generare il codice dal diagramma. So che il Dipartimento della Difesa USA sta lavorando con OMG per sviluppare alcuni strumenti che genereranno codice "comprovato" da diagrammi che sono stati verificati correttamente, ma la mia impressione è che si finirà con un ordine di grandezza più metadati rispetto al codice reale. Il che è probabilmente buono (è documentazione, dopo tutto), ma generare metadati non è più veloce della scrittura di codice, quindi finisci per spendere proporzionalmente più tempo.

UML stesso è un sistema di notazione, quindi è motivo di comunicazione e documentazione. È raro generare codice dal modello UML, ma sì, ci sono ragazzi che lo fanno. Gli utenti di Rhapsody lo fanno più spesso di Rose. La parte difficile è mantenere il modello e il codice sincronizzati, per la maggior parte dei progetti reali, il costo è troppo alto.

Nel mio ultimo progetto sto usando UML-Lab (https://www.uml-lab.com). Questo è uno strumento utile che consente anche il reverse engineering del modello. Lo strumento genera codice java e persino le annotazioni JPA che sono abbastanza accurate.

La sfida è quando si lavora in gruppo. Il modello è statico e si trova in una singola risorsa, il che rende un po 'difficile mantenerlo sincronizzato con più modifiche dello sviluppatore. C'è una versione di prova che è disponibile per 1 mese, il che è un buon momento per esplorare e confrontare con altri se stai indagando.

Questa è la prima volta che vedo un prodotto eseguire la modellazione di oggetti e la modellazione di dati in un colpo solo insieme alla generazione del codice.

Altrimenti nei miei progetti passati, ho sempre visto modelli obsoleti che sono inaccurati o troppo dettagliati.

Nei miei progetti passati a volte ho generato diagrammi con il reverse engineering. Il più delle volte ho scoperto che i diagrammi sono ingombra e ho preferito disegnarli filtrando manualmente tutto il rumore.

Penso che possiamo usare UML per generare codice. Non una logica aziendale, poiché la logica aziendale non è uno standard e varia da un'applicazione all'altra. I diagrammi di classe insieme ai diagrammi ER possono essere utilizzati per la generazione di interfacce, classi, entità di ibernazione, metodi dao di base, ecc. Altri codici di piatti come l'implementazione di facciate, convertitori di tipi di dati (ad esempio entità per il trasferimento di oggetti) possono anche essere generati con l'aiuto di digram di oggetti .

Inoltre, come indicato nei commenti precedenti, è possibile generare modelli, schemi di database, script DDL, ecc.

Usando OAW e uno strumento di modellazione come Enterprise Architect, possiamo scrivere generatori di codice più potenti, che possono anche aiutare a generare file di configurazione, codice di fabbrica utilizzando stereotipi e valori con tag.

Continuo a non capire perché la business intelligence con strumenti come Business Object sia in grado di analizzare e sfruttare tutte le informazioni dell'azienda mentre a livello tecnologico stiamo ancora lavorando a livello di codice o a livello astratto con UML !!

Il problema non è UML ma la trasformazione del modello tra UML e MOF e la generazione di codice da un diagramma clas o xmi usando i template. Si dice che UML dia una visione astratta del mondo reale, quindi vedi solo ciò che è veramente importante. Detto questo come generare codice accurato se il diagramma UML è solo una visione del mondo reale? È impossibile e quindi lo sviluppo guidato da modelli che genererebbe codice da un modello è fallito.

La soluzione è trasformare per mappare il mondo reale e quindi tutto il codice di progetto in un singolo modello UML. Avendo un singolo modello e la logica completa del progetto, è quindi possibile generare viste dal modello e non dal codice ogni volta. C'è un'iniziativa coraggiosa fatta da Omondo nell'ambito della tecnologia Java / Jee. Il concetto è MOF e UML sincronizzati dal vivo direttamente con il codice e ORM. I diagrammi UML sono ora solo una vista di alto livello del modello che sta mappando l'intero progetto. È possibile creare centinaia di visualizzazioni, aggiungere centinaia di note ecc .... per comprendere meglio il progetto. Il codice verrà generato solo se l'elemento viene modificato o creato. Tecnologia meravigliosa in cui l'ID Java è mappato sull'ID UML senza il tradizionale ponte di trasformazione tra MOF e UML.

Ciò che è anche fantastico è essere in grado di modellare il mio dominio a livello UML e ottenere le mie annotazioni ORM direttamente nel codice e quindi usando Hibernate posso creare, cancellare, creare il mio database, distribuire ecc ... in un'integrazione permanente permanente in cui UML è parte di tutta l'architettura e non l'architettura stessa del progetto.

Non sono mai stato deluso da UML come visualizzatore di alto livello se sincronizzato dal vivo con il codice, ma sono stato assolutamente devastato dall'uso tradizionale di MDA con generazione di codice di modelli di sviluppo guidata dal modello. La generazione del codice da un modello è come una pagina HTML proveniente da un documento word. Come cambiarlo una volta generato? È semplicemente impossibile aggiornarlo e dedichi più tempo alla pulizia del codice che alla scrittura da zero!