Puoi usare UML in un progetto TDD?

Can you use UML in a TDD project?

L'uso di TDD non impedisce l'uso di UML, né l'uso di UML impedisce il TDD. In effetti, sospetto che l'utilizzo di UML come strumento di progettazione per catturare il comportamento e le interazioni del sistema renderebbe più semplice scrivere i test prima. Avresti un modello di riferimento dell'implementazione da utilizzare. Tuttavia, mentre implementi, dovresti anche tenere aggiornato il tuo UML, altrimenti perderà rapidamente il suo valore.

If so, at what stage? or it is also an iterative process?

Se applichi UML in un progetto, ci sono tre punti in cui sarebbe più utile.

Il primo sarebbe quando si progetta l'architettura del sistema, in cui si vorrebbe probabilmente usare diagrammi di componenti, di implementazione e di comunicazione per mostrare quanto pezzi grandi del sistema si adatteranno insieme e dove ciascun componente verrà implementato. Un diagramma di distribuzione sarebbe particolarmente utile in un sistema distribuito, in cui i nodi avranno responsabilità e capacità diverse.

Il prossimo punto sarebbe una fase di progettazione più dettagliata, quando inizierai a pianificare le interazioni a livello di classe e metodo. In questo caso, probabilmente troverai utile la classe, la struttura composita, la sequenza, l'oggetto e i diagrammi di stato. I diagrammi specifici di cui avresti bisogno dipendono molto dalla complessità del sistema e da ciò che desideri mostrare.

In ciascuna di queste due fasi, l'uso di UML consente di eseguire revisioni del design. Puoi convalidare il tuo design in base alle tue esigenze per assicurarti di non mancare nulla. In un ambiente TDD, potresti voler utilizzare queste recensioni per identificare potenziali problemi con l'implementazione dei test.

Le fasi finali saranno durante lo sviluppo, la manutenzione e la valorizzazione. Hai un'architettura e un design catturati a cui puoi fare riferimento. Questo dovrebbe anche catturare il tuo ragionamento. Mentre continui a far crescere il tuo sistema, puoi vedere le tue vecchie decisioni di progettazione insieme al motivo per cui le hai create, per determinare la fattibilità e l'entità delle modifiche apportate all'aggiunta di nuove funzionalità. Fornisce anche un progetto da cui partire quando si sviluppa il sistema - hai fatto almeno parte del pensiero in anticipo, quindi non devi preoccuparti di connettere i tuoi moduli al volo.

La modellazione iterativa è sicuramente qualcosa a cui aspirare. Non solo dovresti rivedere i tuoi modelli all'inizio di ogni iterazione mentre stai progettando e pianificando nuove funzionalità, ma dovresti anche considerare il reverse engineering per cercare di mantenere i tuoi modelli aggiornati. Non tutti gli strumenti possono automaticamente decodificare tutti i tipi di diagrammi, ma puoi provare a mantenere gli altri manualmente aggiornati. Se lasci che un diagramma diventi obsoleto, assicurati di denotarlo o annullarlo da qualsiasi repository o documento in modo da non prendere decisioni basate su dati non validi.

If iterative, how formal?

Dipende.

Tendo ad essere più informale con i miei modelli UML. Uso la notazione che ho bisogno di trasmettere a me stesso e agli altri esattamente ciò che il sistema sta facendo. Tendo ad essere più minimalista, concentrandomi sull'ottenere un messaggio particolare per me e per altri ingegneri da utilizzare durante lo sviluppo del sistema. Catturo il messaggio nel testo (come le note sul diagramma o incorporando il diagramma in un documento Word insieme a un testo esplicativo) L'idea è che mentre sviluppo il sistema, sto anche sviluppando la documentazione per me stesso e gli altri.

Also, how useful is UML for a solo programmer doing open source?

Se si tratta di un piccolo sistema che sarà costruito abbastanza rapidamente (< 6 mesi di sviluppo coerente, o così, proprio come una stima immediata) da uno o due sviluppatori, l'impatto di UML sarebbe probabilmente minimo. Per un periodo di tempo più lungo, per sistemi più complessi o con un team più grande, ti aiuterà a prendere decisioni architettoniche e di design e a comunicarle attraverso il team di sviluppo.

Il punto di UML non riguarda te, ma la comunicazione. Se e quando altre persone si uniscono al tuo progetto come tester o sviluppatori, avere modelli UML aggiornati può aiutarli a capire meglio il loro sistema. Una comprensione più veloce significa che sono più facilmente in grado di mettersi al passo e iniziare a contribuire, un vantaggio per tutti.

Certo che puoi! Puoi utilizzare UML se e quando ritieni che sarebbe utile. È solo uno strumento e come tale può essere utilizzato indipendentemente dal ciclo di vita dello sviluppo / tecniche che stai utilizzando.

Con TDD (e agile, che di solito non è molto lontano) sarebbe utile se, quando si implementa una nuova funzione, una visualizzazione della base di codice esistente ti aiuterebbe o desideri visualizzare le modifiche / aggiunte del tuo nuova caratteristica. Non dovrebbe essere usato per "definire" il code-base in questo contesto, ma solo per aiutarti a capirlo. Potresti semplicemente disegnarlo a mano libera su un pezzo di carta. Lo sviluppo Agile / TDD è piuttosto fluido e un diagramma UML stratificato sarebbe senza dubbio pensato non diversamente dal diavolo.

La tua domanda riflette la voragine percepita tra il pensiero "cascata" e "agile", in cui UML è considerata una tecnica utilizzata in BDUF (Big Design Up Front), che è un NO assoluto in cerchi agili.

Tuttavia, il manifesto agile non ha mai stabilito che non si dovrebbe fare alcuna documentazione o progetto o architettura in anticipo. Dice solo "Basta abbastanza" e "stimiamo il codice di lavoro più della documentazione".

Ci sono progetti che richiedono un po 'di design e architettura all'avanguardia, e UML è una scelta ovvia quando si cerca di affrontare questi problemi. Il trucco è usarlo "appena sufficiente". Quanto esattamente "appena abbastanza" è, dipende dal progetto e dalla squadra, quindi dovrai capirlo da solo, temo.