Quanto sono efficaci gli strumenti round-trip automatizzati per la modellazione UML? Aiutano a programmare codice veloce, pulito ed efficiente? In che modo questi strumenti si adattano alla metodologia Agile?
Parte del Manifesto Agile afferma:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Tutto si riduce al motivo che stai usando UML. Ovunque ho lavorato che l'ha usato, è stato usato come artefatto per "dimostrare" che hai completato la fase di progettazione, quindi sono state generate le classi e non è mai stato rivisto perché era troppo lavoro per mantenere i due in sincronia. Se è così che lo stai usando, è decisamente non agile.
D'altro canto, se la tua squadra è quella creatura mitica che in realtà riesce a mantenere la loro UML in sincronia, che si riferisce costantemente ad essa durante l'intero ciclo di vita, e che mancherebbe quando se ne sarà andata, che sicuramente si adatta con agilità. Ricorda che gli strumenti e la documentazione vanno bene, anche incoraggiati in modo agile, purché non interferiscano con le interazioni e il software di lavoro.
Non riesco a vedere come uno strumento di sincronizzazione round-trip UML "aiuti a codificare codice veloce, pulito ed efficiente".
Dal momento che stiamo parlando di pratiche agili, per quanto riguarda il TDD, ciò che vedi spesso (ed è promosso da persone come Bob Martin) è che i diagrammi UML sono usati semplicemente come uno strumento per disegnare le classi principali prima iniziando la tua sessione TDD. Ma questi modelli molto spesso non si dimostrano totalmente sbagliati e diventano invalidi quando il tuo design del codice emerge in modo incrementale attraverso il processo TDD.
È la fase TDD Refactor combinata con buone pratiche di codifica che ti permettono di scrivere "codice veloce, pulito ed efficiente", non avendo diagrammi UML pronti e incollati durante la codifica.
Per quanto riguarda il fatto che i modelli UML debbano essere perfettamente sincronizzati con il codice in un dato momento, ritengo che i vantaggi siano di gran lunga meno importanti del costo. I test unitari sono di solito un modo migliore per documentare il codice IMO.
Questo non vuol dire che i diagrammi UML di livello superiore che descrivono l'architettura oi casi d'uso dell'applicazione non sono utili, comunque. Ma questi sono precisamente di livello troppo alto per essere utilizzati nella generazione di andata e ritorno.
Penso che ci sia una confusione quando si parla di codice live e sincronizzazione del modello. Non è una buona idea sincronizzare in modo permanente il tuo modello con il tuo codice. Ricordo ancora Togethersoft che era il miglior strumento di andata e ritorno, ma era così lento e se l'editor UML non era aperto, il tuo modello non veniva aggiornato se la nuova generazione di classificatori veniva creata a livello di codice, ecc ....
C'è una nuova iniziativa che è un mix di round trip e generazione di codice on demand con codice java e fusione di modelli. Il meccanismo si basa sulla mappatura di ciascun ID di classificatori java su un Id elemento del modello. Intendo che tu rovesci la prima volta il progetto e ottieni un singolo modello. Crea ID UML per ogni classificatore e sottoelemento java che è correlato all'id Java. Una volta che questo lavoro è stato fatto, puoi modellare o codificare con UID eidtor. Quando si desidera aggiornare, è sufficiente selezionare l'opzione di unione che creerà in modo incrementale nuovi classificatori aggiunti a livello di codice con classificatori esistenti già creati nel modello. Puoi quindi avere il numero necessario di iterazioni tra codice e modello.
Quello che mi piace con questo approccio Id che associa ogni id java all'ID UML è che UML ora è come un editor java e puoi modificare graficamente in 5 secondi ciò che sarà oltre 30mn a livello di codice perché tutto viene rifattorizzato immediatamente e l'integrità del modello dai un'occhiata. Significa che se ciò che fai non è corretto, puoi immediatamente ricevere un avvertimento. È solo a livello di modello quindi nessun altro strumento da installare. Molto semplice, basta un clic sull'opzione Verifica modello.
Quello che mi piace anche è creare un modello indipendente dal mio codice. Nessun tag nel mio codice java perché tutte le informazioni del modello sono il modello UML che è un singolo modello. Posso quindi estrarre graficamente le viste del modello. Queste viste sono costruite su un modello che rappresenta l'intera applicazione e aggiornate su richiesta quando viene selezionata l'unione dei modelli.
Ecco perché gli ID UML si fondono con gli ID java rendono UML efficiente, più veloce da scrivere codice ma non tenta di sostituire il codice utilizzando i modelli di generazione del codice. Voglio dire che gli ID UML sono fatti come se si stesse codificando a livello grafico e certamente non provassimo a generare il codice.
Direi che UML tradizionale con i modelli di generazione del codice è come quando provi a creare automaticamente una pagina HTML da un documento Word. Funziona sicuramente bene ma poi sei bloccato e non puoi cambiare nulla. È anche la qualità HTML del codice orribile. Per evitare questo problema con l'utilizzo di modelli di generazione del codice, gli ID UML e gli ID Java si fondono, rendendo il codice come se fosse stato codificato manualmente. Davvero di buona qualità.
Molto poco l'iniziativa UML è stata fatta su id UML perché il livello grafico sta gestendo la mappatura (ad esempio il progetto GMF usato da Topcased o Papyrus) sul metamodello mentre dovrebbe essere il modello che gestisce direttamente ogni id di UML e java lavorando in modo nativo senza strati intermedi !!