Quanto sono importanti i diagrammi UML per un progetto di successo? [chiuso]

Sono nel mezzo di un progetto e mi è stato chiesto di scrivere diagrammi UML (casi d'uso, diagramma di classe, ecc.). Il progetto non è molto complesso.

Mi chiedevo se questo fosse uno spreco di tempo? Dovrei semplicemente fare altre cose divertenti come scrivere codice? E quando non va bene costruire qualcosa senza passare attraverso tutta la fase concettuale? Si tratta di complessità? E se sì, come misurarlo?

Ero un grande fan di UML qualche tempo fa. Sono persino certificato OMG. L'ho usato ampiamente in progetti di grandi imprese in cui ero coinvolto.

Oggi ho smesso di UML quasi completamente. A volte, uso il diagramma di sequenza che trovo molto utile per descrivere le interazioni tra i sistemi, ma nessun altro diagramma.

Ora preferisco lavorare con le storie degli utenti, supportate sia dalla (unica) documentazione necessaria scritta dal proprietario del prodotto (o dagli analisti) sia dalla sua (loro) dedizione al team di sviluppo per fornire ulteriori dettagli in base alle necessità.

UML è uno strumento che puoi usare, ma certamente non è un fattore critico per il successo dei tuoi progetti. Dopo molti anni, ora penso che il fattore critico sia il team di sviluppo, indipendentemente dagli strumenti che utilizza.

La pianificazione è fondamentale, ma come avverte il famoso stratega Carl von Clausewitz

Nessun piano di campagna sopravvive al primo contatto con il nemico

Quindi non è una grande perdita di tempo per pianificare come attaccare inizialmente i problemi. Ma probabilmente una perdita di tempo per documentare il codice per i futuri programmatori. Per usare una metafora militare, hai bisogno di un piano di battaglia, ma non lo daresti agli storici da usare come rapporto post-azione.

Più concretamente, puoi usare questi diagrammi per comunicare le tue intenzioni tra la tua squadra e pensare al tuo piano di attacco prima e durante il progetto. Ma le probabilità sono che ciò che ti viene in mente dovrà essere modificato mentre scrivi e impari di più sul problema. Quasi sempre il tuo piano / progetto iniziale deve essere modificato perché non puoi sapere tutto in anticipo.

Penso che i diagrammi UML possano essere utili solo se esprimono qualcosa in un livello di astrazione più elevato del tuo codice .

Scrivere UML solo per motivi di scrittura UML diventa una burocrazia non necessaria e rende il progetto e il codice meno adattabili ai cambiamenti senza alcun beneficio.

Ad esempio, un diagramma di classe UML che mostra tutte le classi in un pacchetto, con tutti i loro attributi e metodi - qualcosa che può essere facilmente generato automaticamente - non fornisce alcun valore: è allo stesso livello di astrazione del codice . Inoltre, il codice sarà sicuramente una fonte migliore per tali informazioni perché sarà sempre aggiornato e probabilmente sarà documentato e organizzato in un modo che è più facile sapere quali metodi / attributi / cose sono più importanti.

D'altra parte, se si hanno concetti di un livello di astrazione superiore a quello che può essere espresso espresso sul codice, documentare quelli su un diagramma può essere una buona idea.

Ad esempio, un diagramma che mostra i moduli astratti di livello superiore su un sistema complesso, con le loro dipendenze e forse una piccola descrizione delle loro responsabilità e su quale pacchetto / spazio dei nomi mappano nel codice sorgente può essere davvero utile per un nuovo membro del team che deve essere introdotto nel progetto o può anche essere usato per capire dove dovrebbe essere lanciata una nuova classe / funzionalità.

Un altro esempio di diagramma utile potrebbe essere un diagramma di sequenza che mostra le fasi di alto livello da adottare in un protocollo di comunicazione. Forse ogni passaggio di questi ha piccole stranezze e complessità, ma probabilmente è abbastanza per descriverli nel codice stesso. Il diagramma di livello superiore può aiutare un programmatore a comprendere facilmente il "quadro generale" delle cose senza preoccuparsi della complessità di ogni interazione.

Comunque, questi sono solo alcuni esempi; ci sono molti casi in cui un semplice diagramma può essere di grande aiuto. Ricorda solo che dovresti farlo solo quando non puoi esprimere qualcosa nel codice stesso. Se ti ritrovi a utilizzare i diagrammi UML per spiegare il codice sorgente stesso, rendi invece il codice sorgo più auto-documentante.

Infine, alcune delle regole generali che si applicano al codice possono applicarsi anche ai diagrammi: evitare di ripetersi, mantenerlo semplice, non temere di cambiare le cose (solo perché qualcosa è documentato su un diagramma UML non significa che non può essere cambiato) e pensa sempre a chi leggerà / manterrà quei diagrammi in futuro (probabilmente il tuo io futuro) quando li scrivi :)

UML ha valore se i membri del team lo comprendono collettivamente e lo considerano un modo utile per riassumere e comunicare le decisioni di progettazione. Non hai bisogno di sapere tutto, solo quel sottoinsieme che la squadra trova utile.

Inoltre, non è necessario disegnare diagrammi perfetti e lucidi. Un diagramma di sequenza approssimativamente abbozzato su una lavagna o un diagramma di classe in cui le classi sono note post-it attaccate a quella lavagna potrebbe essere sufficiente, a seconda del contesto.

Una volta ho lavorato a un concerto in cui avevo bisogno di gestire un team di sviluppatori di contratti all'estero.

Alcune delle cose che stavano producendo erano piuttosto orrende (un sintomo comune dei programmatori di contratti remoti - a loro non importa molto per il tuo codice, vogliono solo farlo in fretta).

Per gestire il progetto, mi sono ritrovato a produrre diagrammi UML e consegnarli a loro per codificare. Ha avuto molto successo - non mi ci è voluto molto tempo per scrivere un programma in UML, molto più velocemente che in Java, ed era qualcosa su cui gli appaltatori potevano seguire e su cui misurare.

Un avvertimento: a volte volevano diventare creativi e deviare dai miei modelli, tuttavia in quei casi erano effettivamente corretti e nel complesso l'UML ha migliorato la qualità del prodotto finale

Se qualcuno ti ha chiesto di preparare diagrammi UML e che qualcuno sta pagando il tuo stipendio, allora non è davvero una perdita di tempo. Potrebbe essere o meno una perdita di tempo per quella persona.

Se qualcuno sta pianificando di capire il tuo progetto leggendo i tuoi diagrammi UML, probabilmente non è una perdita di tempo.

Lo trovo utile nella fase iniziale di progettazione per ottenere idee su carta o sulla lavagna. Ho usato principalmente diagrammi di classe UML, senza una stretta aderenza agli standard. È utile rivisitare il tuo design originale UML quando sei a metà strada e anche alla fine del progetto. Mi ha aiutato a guardare una base di codice con un livello di astrazione più elevato che tu possa mai solo leggendo il codice e ha persino aiutato a individuare potenziali bug.

C'è un buon punto qui sottolineato da ragu.pattabi che distingue due tipi di UML ...

Penso che il sapore agile di UML (ad es. Schizzo rapido della lavagna bianca) abbia più successo del sapore a cascata di UML (ad es. Diagramma elaborato con tutti i dettagli cruenti per la documentazione, generazione di codice, ecc. Per rendere felici i gestori esperti del documento).

Quando UML è stato visto come un'abilità 'must have' (10 anni fa o più) probabilmente ero contro di esso a causa delle opinioni supposte dei suoi numerosi fan in quel momento. Ma ora che è caduto in disgrazia, mi ritrovo a vederlo per quello che è - uno strumento utile che ha merito ma non è il proiettile d'argento dello sviluppo del software.

Uso UML (o sth simile a UML :)) quando parlo con gli amici di qualcosa che stiamo per fare. Per discutere di idee. Non preparare il progetto UML che genererà automaticamente il codice per me. Non riesco a immaginare di creare le mie classi in UML, quindi generare codice e non modificarlo in seguito. Questo non succede mai. Quindi dovrai apportare modifiche dal codice a UML. E quando uso UML disegno su lavagna o carta. Mai in uno strumento come Enterprise Architect.

L'unico motivo per documentare il mio intero codice in UML sarebbe un contratto in cui il cliente lo richiede. Ad esempio, quando vuole avere un'opzione per cambiare negozio di software dopo che una parte del software è terminata.

La documentazione del lavoro di progetto è un prodotto fondamentale di un progetto professionale. Quanto è abbastanza? Beh, dipende ovviamente da molti fattori. Tuttavia, a mio avviso, i casi d'uso, i diagrammi di classe, i diagrammi di flusso del processo, ecc. Non sono affatto una perdita di tempo. Hanno valore in varie fasi del progetto. L'unico problema con la documentazione è di solito le risorse.

Alcuni programmatori ritengono che la documentazione sia una perdita di tempo. Ma questo non è vero. Se visualizzi la documentazione come una visualizzazione del tuo progetto e delle regole di sistema in modo elegante e chiaro, potresti apprezzarla di più. Inoltre, è necessario mettere se stessi nella posizione delle persone che hanno bisogno di mantenere il sistema. Essere lanciati 500 file di codice e essere chiesto loro di risolvere i problemi con loro è un po 'brutto ma non raro.

Ti suggerisco di allocare tempo nel tuo progetto e produrre i diagrammi in cicli. Il primo riguarderebbe gli aspetti di alto livello del progetto e i livelli successivi potrebbero soffermarsi maggiormente sui dettagli.

I casi d'uso in particolare non possono essere facilmente dedotti dal codice (diversamente da molti altri aspetti di un sistema). Assicurati di fare quelli.

UML è uno strumento, niente di più, e se sia utile o addirittura cruciale dipende esclusivamente dal flusso di lavoro di sviluppo e progettazione. Esistono molti modi per raggiungere Roma e alcuni coinvolgono UML, mentre altri no.

Se il tuo flusso di lavoro si basa su UML per documentare o pianificare la tua architettura, lasciarlo cadere sarebbe sciocco. Se UML è il modo migliore per comunicare la struttura del progetto ad altri membri del team (in senso lato), allora usalo. Ma se il progetto funziona bene senza UML, allora fare diagrammi UML solo per il gusto di farlo non ha senso.

Ho dei pensieri su questo. Il linguaggio può essere usato e abusato, costringere e distrarre, innescare e cullare. UML è solo un'altra lingua adatta per una serie specifica di problemi e proprio come qualsiasi altra lingua, ci vorrà tempo e fatica per imparare a parlarlo fluentemente e capirlo correttamente.

La decisione su cosa comunicare è incredibilmente più importante della lingua in cui viene comunicata. UML non renderà magicamente comprensibili i tuoi cattivi progetti. Proprio come qualsiasi altra lingua, è facile perdersi nei dettagli o lasciare troppo all'immaginazione.

UML ha avuto un brutto nome a causa dei numerosi IDE orribili, che consente la prototipazione di andata e ritorno, la manipolazione dei grafici ad alta intensità di clic e la difficoltà di cambiare qualcosa. UML 2.0 potrebbe essere abbastanza complesso da soddisfare determinati accademici, ma il suo meta-modello non sembra attrarre molte applicazioni pratiche.

Tuttavia, utilizzo UML di volta in volta. Valutare un design di alto livello (un buon design ha complessità ai margini e semplicità al centro). Per comunicare un'idea a un collega e ricevere feedback. Per trovare relazioni nascoste, normalizzare, ecc. Ma è sempre un riflesso di qualcosa che è già nella mia testa. In genere, disegno UML con carta e penna, preferibilmente lontano da qualsiasi computer. Se necessario, quando un disegno si cristallizza, faccio una rappresentazione visiva in un programma di disegno.

UML è assolutamente fantastico per avere una visione grafica della tua architettura usando un diagramma di classe. L'interazione con il diagramma di sequenza è magica per me. Il problema non è quindi UML ma MDD per me.

Voglio dire che se UML è un visualizzatore del codice, allora è davvero utile per scopi di documentazione ma certamente non per la generazione di codice. Il progetto dovrebbe essere incentrato sul codice e certamente non incentrato sul modello. UML dovrebbe essere utilizzato in fase di implementazione utilizzando un codice in tempo reale e la sincronizzazione del modello. Intendo non solo a livello di requisito che richiede troppi investimenti per un piccolo ritorno in produttività e qualità.

Li trovo molto sopravvalutati. Li considero le uniche immagini che non dipingono più di mille parole.

UML ha valore solo se le persone che progettano il sistema non possono scrivere da sole il codice. cioè, UML è un "linguaggio" che comunica i concetti di architettura a qualcun altro, ora se sei la persona che sta progettando il codice e lo sta implementando, allora perché dovresti mostrarti cosa farai ?! Sali e vai dritto per la codifica invece. Dovrai comunque documentare ciò che hai fatto in seguito, ma l'efficienza complessiva è più rapida.

Ma se tu fossi un architetto di sistema che voleva dire al tuo team di sviluppatori in outsourcing ciò che volevi, allora dovresti dirglielo in qualche modo, ed è qui che entra in gioco UML. Tuttavia, penso che ci siano molti modi alternativi di esibirsi questo compito al giorno d'oggi, e francamente, la complessità del diagramma UML significa che tutti devono capire come leggerlo, il che è un po 'autolesionistico se non lo fanno.

Non sono mai stato un fan di UML, ma ho imparato a valutare un buon diagramma di sequenza per descrivere le interazioni tra sistemi o attività.

Tuttavia, il diagramma di classe è obsoleto prima della nascita. Una progettazione approssimativa non richiede UML e una documentazione approfondita viene estratta automaticamente (in tempo reale) dalla base di codice. Javadoc e Doxygen hanno completamente superato la necessità di diagrammi di classe manuali.

La cosa sulla documentazione è che ci sono due livelli:

• le decisioni di alto livello (architettonico) devono essere documentate manualmente
• i fatti di basso livello (relazioni tra entità) dovrebbero essere estratti automaticamente

Di solito eseguo l'iterazione tra i diagrammi di codice e UML. Trovo che i diagrammi aiutino a mostrare il quadro generale e un solido percorso in avanti e possono essere cambiati piuttosto rapidamente quando vengono scoperti problemi. Inoltre, quando ho i diagrammi, la codifica tende a diventare banale.

Al contrario, quando disegno il codice in immagini, espone i problemi di dipendenza e rende palesemente evidenti le opportunità di miglioramento del design, che probabilmente non sarebbero state notate se avessimo avuto il codice su cui lavorare. In particolare, se è un dolore disegnare, allora sarà anche un dolore da programmare e un incubo da mantenere.

Ho scoperto che è necessaria l'iterazione, perché il semplice disegno delle immagini manca sempre di aspetti importanti, mentre la semplice codifica comporta progetti problematici.

Tuttavia, come ha detto un altro poster, tutto si riduce alla gente. Se sono abili "usando" i diagrammi UML, allora UML è prezioso. In caso contrario, i diagrammi non hanno alcun valore.

Quindi, la risposta alla tua domanda è davvero "dipende". In questo caso, dipende dalle persone, dalla complessità del progetto e da quanto sia importante che il sistema funzioni correttamente.

Dalla mia esperienza, UML è importante per la comunicazione tra gli sviluppatori sui modelli di codice e per l'architettura in generale dell'applicazione.

Adoro i diagrammi, ma se mi chiedessero di crearne uno (specialmente UML!), Farei due domande:

1. Per chi è?
2. Ne hanno bisogno adesso?

I diagrammi non sono più aggiornati. Quindi, a meno che tu non lo stia usando per comunicare con qualcuno adesso, marcirà. E se la persona con cui stai comunicando farebbe meglio con una descrizione testuale, una telefonata o un digram informale su una lavagna, suggeriscilo invece.

Una delle maggiori lamentele per me sui diagrammi UML che ho visto finora usati è che tendono principalmente a servire solo come "belle immagini" sul muro di qualcuno o come pagina piegata in un'associazione da qualche parte e raramente servono come base per un codice di produzione.

In questo tipo di scenario, i diagrammi UML (o qualsiasi tipo di linguaggio di modellazione utilizzato) sono raramente utili a lungo termine, poiché tendono a soffrire di perdita di pertinenza con il passare del tempo e con l'evoluzione del progetto. Questi disegni iniziali sono per lo più inutili e errati in pochi anni e averli in giro è per lo più dannoso.

Detto questo, l'utilizzo di strumenti di modellazione (non necessariamente UML) non è una pratica del tutto inutile, se i modelli forniscono un input reale e pertinente al codice corrente. Se la descrizione del modello è un utile artefatto del codice, deve essere trattato come codice:

O usandolo come fonte diretta di metadati per prendere decisioni dinamiche basate sui concetti modellati, o usando la generazione di codice per generare artefatti di codice statici che vengono utilizzati nel codice di lavoro effettivo.

Non so se la domanda riguarda il merito di UML o il merito di progettare l'architettura dei programmi.

Informazioni su UML. Di solito hai solo bisogno di: casi d'uso, diagrammi di classe e diagrammi di sequenza. Semplice e facile, anche se potresti farlo sicuramente con i tuoi tipi di diagrammi. A questo proposito UML è uno standard che tutti capiranno.

Informazioni sulla progettazione di programmi.

1. Ogni programma ha un design, anche se non lo pianifichi. Quando il codice viene scritto, basta decodificarlo. Se non l'hai pianificato, scommetti che sarà un cattivo design.

2. Il design ti farà risparmiare tempo, usando schemi noti per problemi ricorrenti.

3. Se lavori in gruppo, è necessario progettare per discutere di soluzioni, trasmettere idee e molto pratico ma necessario per distribuire lavoro.