Sì, gli strumenti UML CASE erano uno degli elementi caldi degli anni '90 ... e poi non sono riusciti a fornire.

La ragione fondamentale per questo è che i diagrammi UML (o quasi tutti gli altri tipi) aiutano a capire il problema e / o il programma lo risolve solo nella misura in cui il astrazione allontana i dettagli di implementazione di il codice attuale. Quindi (per ogni pezzo di codice non banale), un diagramma che è facile da capire è intrinsecamente inutile per la generazione del codice , perché manca dei dettagli necessari. E viceversa, un diagramma che è direttamente utilizzabile per la generazione del codice non ti aiuta molto a capire il programma meglio del codice stesso. Se hai mai visto un diagramma di classe UML in reverse engineered dal codice di produzione, probabilmente sai cosa intendo.

L'unica possibile eccezione a ciò che so sono i diagrammi Entità-Relazione, che non comprendono il codice di per sé, solo (come suggerisce il loro nome) pezzi di dati e le loro relazioni. Ma non ho mai sentito di un tentativo riuscito di usare qualsiasi tipo di diagramma UML per la generazione di codice reale [Aggiornamento] - vale a dire più di scheletri di classe e codice banale come getter / setter -, tranne che in strumenti per scopi speciali / aree come ORM, come testimoniato da Doc Brown sotto [/ Update] , e penso che questo 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 sul design o per visualizzare l'architettura della tua app. Ma è meglio tenerli a questo, e non provare a usarli per cose in cui non sono bravi.

So when I was at uni (a while ago now), I was told that UML was the future, UML will replace programming and we'll just generate code from diagrams etc.

Erano sbagliati. Ciò succederà nel momento in cui le persone abbandonano la parola e tornano 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 diagrammatico potrebbe essere più efficace di un linguaggio di programmazione testuale. Abbiamo sperimentato con la programmazione diagrammatica per circa trent'anni, e finora le prove sono schiaccianti a favore della programmazione testuale. Non sono a conoscenza di alcuna applicazione importante che è stata prodotta dalla generazione del codice dai diagrammi.

NO

La legenda era basata sul presupposto errato che scrivere:

class ClassName extends SomeThing
{

}

... è difficile e richiede l'automazione .

Potresti ancora trovare credenti occasionali o folle di credenti.
Ma è così che va con le religioni e le sette.

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

Generalmente i diagrammi abbastanza specifici da generare codice da essi, principalmente diagramma di classe, non aggiungono molto nel modo di comprendere realmente il programma e non puoi generare codice dai diagrammi di panoramica come use case o livello di panoramica attività che sono cruciali per la documentazione. Un diagramma che è utile per capire e può avere il codice generato da un diagramma di stato, che è utile quando hai davvero bisogno di una macchina a stati. Ma in generale dovresti cercare di evitarli, perché sono intrinsecamente inclini agli errori.

In un progetto ci è stato richiesto di progettare il codice in modellatore UML (Rhapsody) e di generarlo da lì. Funzionava in un certo modo ed era probabilmente molto più semplice della semplice digitazione delle intestazioni (era C ++) e dei prototipi a mano. La possibilità di mantenere automaticamente questi due elementi coerenti era piuttosto utile.

I corpi del metodo dovevano ancora essere compilati a mano, perché i diagrammi non possono realmente rappresentare ciò con l'eccezione degli scheletri macchina di stato.

D'altra parte è piuttosto complesso, quindi devi imparare molte cose extra e, cosa più importante, è stato doloroso unire. L'unione è ben studiata per i file di testo e funziona con loro, ma nessuno ha inventato un modo semplice per unire ancora le modifiche ai diagrammi. Rhapsody in realtà mantiene parte delle informazioni nel codice generato e le analizza indietro, quindi non era totalmente 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 utilizzato in questo modo.

Nella mia esperienza, la maggior parte delle aziende sembra utilizzarlo 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 consente di creare un singolo modello del 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 effettivi sono semplicemente diverse prospettive su parti del modello, consentendo di evidenziare diversi aspetti del sistema.

all of it (modeling diagrams) is for communication purposes

La modellazione ha 4 utilizzi 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 della parola reale (ho imparato questo dalla risposta di @kevin cline sopra)

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

La modellazione secondo me è fondamentale per la creazione di database (diagrammi ER), la comprensione dei flussi di processo (diagrammi di attività) e la comprensione delle interazioni utente-sistema (utilizzare i diagrammi dei casi).

Do people use UML to do more sophisicated things such as code or database generation?

Sì, certo. È possibile utilizzare ERD (non un diagramma UML) e Class Diagram (a seconda delle capacità del tuo strumento) per generare:

1 - Data Definition Language (DDL)

2 - Stored procedure per CRUD e Class Diagrams nella tua lingua preferita (meno utile dato che gli strumenti ORM fanno di più su questo)

Tra le funzionalità più importanti degli strumenti di modellazione ci sono:

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

2 - Capacità di rispondere alle domande usate (dove si trova l''account' usato nel mio modello?)

3 - Possibilità di consentire agli utenti concorrenti di lavorare sul modello

4 - Cerca all'interno di rappresentazioni grafiche

5 - Controllo di stampa

6 - Layering (organizza i tuoi elementi del diagramma a strati) in modo che tu possa concentrarti su un layer alla volta

7 - Generazione del codice del 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 più di Paint.

Usiamo Software Architect per fare progetti di alto livello e per documentare alcune delle interazioni tra componenti più arcane nelle nostre cose. A volte generiamo lo scheletro dell'app dai diagrammi, ma una volta fatto questo manteniamo entrambi separatamente, non proviamo a reingegnerizzare il codice in un diagramma dopo che è stato completato. Usavo uno strumento chiamato Rational XDE che funzionava abbastanza bene per i piccoli programmi, ma andava perso quando avevi iniziato ad aggiungere i gestori di eventi di Swing o provato a lavorare con Struts.

Penso che gran parte del motivo per cui le persone non scrivono in UML è che richiede molto più lavoro per specificare completamente tutto in UML e quindi generare il codice dal diagramma. So che il Dipartimento della Difesa statunitense sta lavorando con l'OMG per sviluppare alcuni strumenti che genereranno codice "provata" da diagrammi che sono stati verificati corretti, ma la mia impressione è che finirai con un ordine di grandezza più metadata del codice effettivo. Probabilmente è buono (è documentazione, dopotutto), ma generare metadati non è più rapido della scrittura del codice, quindi finisci per spendere in proporzione più tempo.

Lo stesso UML è un sistema di notazione, quindi è motivo di comunicazione e documentazione. È raro che generi 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 piacevole che consente di decodificare il modello. Lo strumento genera codice java e persino le annotazioni JPA che sono abbastanza accurate.

La sfida è quando si lavora in una squadra. 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, che è un buon momento per esplorare e confrontare con altri se stai indagando.

Questa è la prima volta che vedo un prodotto che esegue la modellazione degli oggetti e la modellazione dei dati in un'unica operazione insieme alla generazione del codice.

Altrimenti, nei miei progetti passati, ho sempre visto modelli stantii imprecisi o troppo dettagliati.

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

Penso che possiamo usare UML per generare codice. Non logica aziendale, poiché la logica aziendale non è uno standard e varia l'applicazione all'applicazione. I diagrammi delle classi insieme ai diagrammi ER possono essere utilizzati per generare interfacce, classi, entità di ibernazione, metodi dao di base, ecc. Un altro codice boilerplate come l'implementazione della facciata, i convertitori di tipi di dati (ad esempio entità per il trasferimento di oggetti) possono anche essere generati con l'ausilio di oggetti di riferimento.

Inoltre, come menzionato nei commenti precedenti, lo schema del database, gli script DDL, ecc. possono essere generati usando i modelli.

Utilizzando OAW e lo strumento di modellazione come Enterprise Architect, possiamo scrivere generatori di codice più potenti, che possono persino aiutare a generare file di configurazione, codice factory usando stereotipi e valori taggati.

Ancora non capisco perché la business intelligence con strumenti come Business Object sia in grado di analizzare e trarre vantaggio da tutte le informazioni aziendali mentre a livello tecnologico stiamo ancora lavorando a livello di codice solo o a livello astratto con UML !!

Il problema non è l'UML, ma la trasformazione del modello tra UML e MOF e la generazione del codice da un diagramma di clas o xmi utilizzando i modelli. Si dice che UML dia una visione astratta del mondo reale, quindi si vede 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 dal modello che genererebbe codice da un modello ha fallito.

La soluzione è trasformare per mappare il mondo reale e quindi tutto il codice del progetto in un singolo modello UML. Disponendo di un singolo modello e della logica completa del progetto, è possibile generare visualizzazioni dal modello e non dal codice ogni volta. C'è una coraggiosa iniziativa fatta da Omondo all'interno della tecnologia Java / Jee. Il concetto è live sincronizzato MOF e UML direttamente con il codice e ORM. Il diagramma UML ora è solo una vista di alto livello del modello che sta mappando l'intero progetto. Puoi creare centinaia di visualizzazioni, aggiungere centinaia di note, ecc. Per avere una migliore comprensione del progetto. Il codice verrà generato solo se l'elemento è stato modificato o creato. Tecnologia meravigliosa in cui l'ID Java è mappato all'ID UML senza il tradizionale ponte di trasformazione tra MOF e UML. Il modello sta diventando una specie di datawarehouse di progetto all'interno del quale è possibile navigare e prendere decisioni accurate.

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 usare Hibernate Posso creare, cancellare, creare il mio database, distribuire ecc ... in un continuo permanente integrazione in cui UML è parte di tutta l'architettura e non dell'architettura stessa del progetto.

Non sono mai stato deluso da UML come visualizzatore di alto livello se sincronizzato dal vivo con il codice, ma è stato assolutamente devastato dal tradizionale utilizzo di MDA con la generazione di codice dei modelli di sviluppo basati su Model. La generazione del codice da un modello è come una pagina HTML proveniente da un documento word. Come cambiarlo una volta generato? È semplicemente impossibile aggiornare e dedicare più tempo a pulire il codice che a scrivere da zero!