I diagrammi UML richiedono tempo e anche se forniscono conoscenze sulla progettazione del programma, il design cambia e così fanno i requisiti, e quindi diventa un compito ingrato mantenere gli UML Diagrams sincronizzati con il codice. Sto cercando di capire come dovremmo usare UML in modo ottimale.
Come già indicato dalle altre risposte ci sono molti modi per usare UML. Soprattutto lo stai usando con diversi livelli di dettaglio e tempi diversi in un progetto.
Ma stai chiedendo di sincronizzare il codice con UML. Il nostro obiettivo primario per uno dei nostri strumenti ( UML Lab ) era il ciclo tra le fasi di progettazione e implementazione. Per adattare il design UML mentre si modifica il codice sorgente diventa necessario. Essere in grado di passare avanti e indietro tra design raffinato e codice si chiama round-trip-engineering. L'uso di tali tecniche non è riuscito per un po 'di tempo, poiché esiste ancora qualche astrazione necessaria per fare veramente uso di tali tecniche. Ma ora è possibile: uno può decodificare il codice Java con modelli personalizzati e generare lo stesso codice sorgente da esso in seguito. Ciò consente agli sviluppatori (o agli architetti) di modificare la progettazione della classe mentre l'implementazione è già in esecuzione. Lo stiamo facendo solo con i diagrammi delle classi. Per quanto riguarda l'analisi del comportamento, ci sono altri strumenti, ovviamente. Ma non c'è un engineering round-trip per quelle parti di UML, per quanto posso dire.
Strumenti per la mappatura del codice di ritorno a fasi precedenti rispetto alla progettazione o addirittura i requisiti non esistono (ancora :). Solitamente questo problema viene affrontato dalla "tracciabilità": gli strumenti tengono traccia dei risultati per gli artefatti in modo che possano stabilire quali requisiti sono interessati da un codice sorgente (o qualsiasi altra cosa) cambiamento.
UML è ottimo per trasmettere idee e coinvolgere la mente in un determinato dominio problematico. Tuttavia, come QUALSIASI documentazione, va bene solo per un momento nel tempo. Torna al manifesto agile relativo alla documentazione. È più importante fornire software di lavoro che fornire una documentazione completa che deve essere aggiornata continuamente.
Quando viene indicato un problema, utilizzare UML per comprendere il problema e quindi progettare una soluzione. Puoi usarlo nelle discussioni tra colleghi per convincere i tuoi collaboratori nella tua soluzione o come catalizzatore per la collaborazione.
Costruisci la tua soluzione e poi archivia il tuo diagramma insieme alla tua storia o allegalo all'elemento di lavoro nel tuo software di gestione dei progetti. Quindi, passa alla prossima storia. Lo hai per riferimento futuro, ma non ci si dovrebbe aspettare che torni indietro e lo aggiorni.
Prendi nota comunque - Tutto questo è vero a meno che non si tratti di una sorta di software di controllo di volo per un jet da combattimento dove il governo richiede una documentazione completa - ma la maggior parte del nostro lavoro è in un ambiente aziendale in cui MIL-STD-2167A non è richiesto, grazie al cielo.
Dipende da come stai usando UML e quali informazioni hai bisogno per catturare e condividere con altre persone.
Ho visto due casi d'uso primari per UML. Il primo è come una lingua per catturare idee di design ad alto livello. Questi diagrammi non includevano tutti i dettagli del sistema, solo quelli importanti. Spesso, questi sono anche i diagrammi più astratti: usa diagrammi dei casi, diagrammi macchina dello stato, diagrammi delle attività, diagrammi di implementazione e in misura minore diagrammi dei componenti e diagrammi dei pacchetti. Si potrebbe fare del lavoro per disegnare diagrammi di classe con un'enfasi sulle interfacce pubbliche (ignorando, in questo momento, membri o funzioni privati) e diagrammi di sequenza. L'altro caso d'uso per UML è quello di acquisire lo stato attuale di un sistema, utilizzando strumenti di reverse engineering. Questi sono spesso diagrammi di classe più dettagliati, diagrammi di sequenza, diagrammi di comunicazione, diagrammi di oggetti, diagrammi di strutture composite e così via. Questo serve come documentazione sul modo in cui il sistema è in realtà per le discussioni sulle modifiche al sistema.
Per quanto riguarda il momento in cui applicare UML, dipende. Alla giusta granularità, alcuni tipi di diagrammi possono essere utilizzati non appena si inizia a discutere dell'architettura di sistema. Altri sono più adatti alle discussioni sulla progettazione dettagliata e le specifiche del sistema. Tutto si riduce alla scelta dei diagrammi giusti per visualizzare le informazioni pertinenti alle persone che ne hanno bisogno in modo tempestivo.
Riguardo ai problemi con il mantenimento di UML in sincronia con il codice, ci sono due cose da considerare. Innanzitutto, rivedi i tipi di documentazione che stai conservando. Se nessuna di queste viene attivamente consumata o aggiunta di valore, potrebbe essere una buona idea eliminarla. Se è difficile aggiornarlo, l'atto di aggiornarlo potrebbe essere qualcosa che viene messo da parte. La documentazione obsoleta è peggiore della documentazione inesistente, poiché nessuno può prendere una decisione in base a informazioni errate. In secondo luogo, se si dispone già di un codebase, esistono strumenti per facilitare la generazione di diagrammi UML dal codice, spesso chiamati strumenti CASE o strumenti di reverse engineering, considerando l'automazione del processo.
UML è un ottimo strumento da utilizzare durante e dopo la progettazione del programma, ma solo se lo usi correttamente.
Per prima cosa devi chiederti, perché stai producendo diagrammi UML? Allora devi essere onesto con te stesso e chiedere, qualcuno lo leggerà mai?
Durante la progettazione, avere un diagramma UML fornisce qualcosa per il team di sviluppo su cui possono concentrarsi e discutere. Ma questo diagramma non ha bisogno di essere formale o addirittura in alcun tipo di documento. Basta prendere una lavagna o un tovagliolo e iniziare a disegnare scatole. In questo caso, UML è solo una serie di regole che forniscono "un linguaggio comune" a tutti coloro che guardano la tua lavagna.
Dopo il design, e intendo, WAY dopo il design, quando il tuo codice si è stabilizzato e non stai spostando le classi in giro, questo è il momento in cui potresti decidere di acquisire alcune delle conoscenze in un documento di design formale per preservare la memoria organizzativa. In questo caso, suggerirei di mantenere il documento di progettazione ad un livello elevato (se le persone hanno bisogno di dettagli, è a questo che serve il codice). Ma UML potrebbe certamente essere utile per evidenziare alcune delle principali classi della tua applicazione e il modo in cui si relazionano tra loro. La chiave è che vuoi produrre questi documenti solo dopo che tutte le modifiche (o almeno la maggior parte) sono state fatte, altrimenti scoprirai che mantenere UML può essere un problema.
UML può essere utilizzato in un ampio spettro di modi: dai disegni back-of-the-envelope fino all'ingegnerizzazione round-trip, e tutto ciò che si trova tra questi due estremi. Decidere come usare UML dipende molto dalla preparazione della tua organizzazione e lo stomaco della tua gestione è a rischio.
La decisione sull'engineering di andata e ritorno risolve il problema di sincronizzazione, ma costerebbe al team in termini di curva di apprendimento e quasi certamente vi legherà a un unico costoso fornitore di strumenti software. Ciò diventa particolarmente importante quando il fornitore ha priorità più alte rispetto alla correzione di un bug che infastidisce la maggior parte degli sviluppatori nella tua organizzazione; non devi preoccuparti se la tua organizzazione è tra gli IBM del mondo, ma nella maggior parte degli altri casi la preoccupazione è molto reale.
Decidere su UML come una convenzione di disegno (cioè senza legami con il codice) porta con sé il problema della sincronizzazione del codice, ma ti dà la flessibilità di scegliere i fornitori per i tuoi strumenti UML, o anche di usare strumenti gratuiti, se lo desideri. In questo caso i diagrammi UML diventano solo un altro pezzo di documentazione che conservi insieme al codice del tuo progetto. Dovresti decidere quando questa documentazione verrà aggiornata.
Un esempio che ho visto funzionare ragionevolmente bene richiede che la documentazione di UML sia sincronizzata al momento in cui inizia la codifica e al momento in cui la codifica è completa. Durante la fase di codifica abbiamo aggiornato UML su carta, se necessario, ma non ci siamo preoccupati di aggiornare la copia elettronica ogni volta che abbiamo aggiunto un metodo o refactored una classe.
Dipende.
Nel suo libro, UML Distilled, Martin Fowler discute di UML come se avesse tre usi: un linguaggio di implementazione facilitato da generatori di codice e strumenti di ingegneria del software round-trip, una stampa blu per la creazione manuale del codice o un metodo per disegnare idee da utilizzare in un design.
Quando parliamo di UML, penso a un sistema creato da molte persone (i tre amigos, Rumbaugh, Booch e Jacobson sono i più visibili) che comprende circa 13 diversi tipi di diagrammi. Forse segue un ciclo di vita dello sviluppo descritto attraverso Rational Unified Process (RUP), ma dato il numero di diagrammi disponibili, di cosa stiamo parlando quando facciamo riferimento alla progettazione di base del programma?
Penso che iniziamo con l'elicitazione dei requisiti usando diagrammi di casi d'uso e casi d'uso. Molti sviluppatori Agile giurano per le story card, che sono anche grandiose. Quando abbiamo il diagramma del caso d'uso e l'uso dei casi, abbiamo una sorta di partizionamento del sistema, e forse non è troppo presto per un diagramma di distribuzione o un diagramma del pacchetto per identificare le parti. I diagrammi delle attività, delle sequenze e delle classi danno molti dettagli e possono essere di livello troppo basso per mostrare il design in modo basilare?
La mia interpretazione di UML è che i suoi sostenitori si aspettano che fornisca tutti gli schemi necessari. Se si desidera utilizzare un diagramma a blocchi o un diagramma del flusso di dati, probabilmente si indicherà a uno dei loro diagrammi il razionale che quei diagrammi siano residui di progettazione strutturata e abbiano dissonanza con la scomposizione orientata agli oggetti che stiamo cercando di fare. Personalmente, penso che qualsiasi schema o piano scritto che ti indichi come iniziare e procedere in modo efficace verso i tuoi obiettivi ha un merito.
Leggi altre domande sui tag uml