UML è ancora considerato un modo valido per documentare un progetto software?UML è ancora visto come un modo valido per documentare una progettazione software?
Punti extra per i riferimenti che eseguono il backup eventuali reclami :)
Sto rispondendo alla nuova versione della domanda che parla di UML come strumento di documentazione. Cercherò anche di interpretare UML come uno strumento di comunicazione, perché sono tutti uguali.
Contesto: Questa prospettiva è guidata dal mio lavoro quotidiano come architetto che deve progettare centinaia di sistemi/software, 10.000 ore + sforzi e mantenere una documentazione e pratiche coerenti per un portafoglio di sistemi. Ciò significa che ho dovuto confrontarmi con la qualità, l'uniformità e la definizione della documentazione molte volte.
Riepilogo: Che altro c'è? Certo, puoi discutere dei livelli di documentazione, l'UML è davvero meglio della lettura del codice per la logica condizionale? Probabilmente no, ma nel complesso non esiste una vera alternativa se lo spazio del problema è abbastanza grande.
Se UML non è nient'altro, è per documentazione e comunicazione."UML Distilled" scritto da Martin Fowler, che è quasi lo standard de facto per i libri UML, porta questa opinione. Fowler, se leggo correttamente, crede che l'uso primario di UML sia per la comunicazione, che è la documentazione, solo il tipo statico. Non tanto le specifiche di basso livello e la generazione del codice.
IBM, Borland, Microsoft ed Eclipse supportano UML con strumenti complessi di grandi dimensioni. Molti altri fornitori più piccoli o mirati forniscono anche strumenti UML. Non sono a conoscenza di uno standard di diagrammi/schemi più accettato/implementato.
Inoltre considerare le alternative, quale notazione diagramma è più comune? Perché non usare ciò che molti sanno. La maggior parte delle università/università, se insegnano qualsiasi tipo di diagrammi o modelli, usano UML. Oltre ad alcuni stili di diagrammi logici di flusso o condizionali, non c'è molto altro là fuori, ben documentato e standardizzato.
La notazione standard è ancora più importante di ciò che molti sanno. Nei progetti di grandi dimensioni non è sempre possibile leggere il codice, parlare con la persona che lo ha scritto o chiedere al business partner ciò che desideravano di nuovo. Questo è dove gli standard sono fondamentali. L'uso incoerente causerà confusione e lo sarà davvero se le persone sono autorizzate a inventare o aggiungere simboli in modo informale. Inoltre, non vuoi creare un documento e devi sempre spiegare cosa intendi.
Non inventare mai se non lo hai anche tu, che è l'alternativa più probabile a UML. Pensa ogni volta che una nuova persona si unisce al team o alla compagnia. Cosa significa una scatola, freccia? Questa freccia può collegarsi a questo triangolo in questa direzione e cosa significa? Fondamentalmente devi inventare un linguaggio/modello specifico per un dominio. Quindi hai bisogno di una presentazione di formazione, tutorial, esempi, lavori di revisione, programma sessioni di formazione, mantieni il metodo di documentazione inventato ecc. Quindi, naturalmente, cambierai partner di attività o assumerai una nuova persona e dovrai farlo di nuovo. Lascia che le persone si concentrino sull'apprendimento dei sistemi, non sul metodo di documentazione, o se devono rendere trasferibili conoscenze o abilità come UML. Lascia che gli esperti si concentrino sulla codifica e sulla progettazione, senza inventare uno standard di documentazione/diagramma.
Per tutti i critici UML Io non vivo in una torre d'avorio o una bolla di vetro, devo vivere con centinaia di diversi metodi di documentazione ogni giorno mentre la gente li inventa o sto guardando alla tecnologia del prossimo fornitore. UML è non perfetto, ma è il più comune, è abbastanza buono e non banalmente sostituibile.
validi ulteriori domande:
Ottima risposta/post - grazie per aver dedicato del tempo a comporlo. – Jamo
L'UML è solo una notazione standard per rappresentare un progetto, non è un processo o di un approccio.
da aggiungere a questo, UML è lì per aiutarti a esprimere il vostro disegno, non di farla rispettare. –
Parlato da un uomo che non ha utilizzato Enterprise Architect (http://www.sparxsystems.com.au)! Provalo ... È fantastico. – Kieveli
Buon punto. Ho modificato la domanda per riflettere questo :) –
Thinking è l'unico modo valido di progettare software.
UML è talvolta visto come un modo praticabile per descrivere parzialmente il design che è venuto fuori.
D'accordo con il punto sul pensare, ma trovo che alcuni dei diagrammi di UML (i diagrammi di sequenza per esempio) siano molto utili nei problemi di pensiero che implicano interazioni ragionevolmente complesse. Non sarei d'accordo con l'idea di usarlo esclusivamente come sistema di documentazione post-progettazione. –
Una volta ho lavorato con un ragazzo che non riusciva a pensare senza avere le notazioni UML. Lo ha confuso per avere due scatole su una lavagna con una linea che li connette senza denotare la loro relazione tramite un'icona specificata UML. – Kieveli
Come strumento per la visualizzazione personalmente ho trovato UML * drammaticamente * utile in fase di progettazione. – annakata
UML è un modo di presentare visivamente un progetto, non il vero metodo di progettazione stesso. È solo uno strumento che usi durante i tuoi viaggi. Per quanto ne so, è ancora piuttosto diffuso nel mondo dell'ingegneria del software perché è uno standard e può essere utilizzato per trasmettere idee tra due persone in modo efficace (motivo per cui viene indicato come lingua).
UML, come ha sottolineato @John Topley, è solo una notazione standard per descrivere gli aspetti di un design orientato agli oggetti, quindi la tua domanda non ha molto senso.
Personalmente, trovo che i diagrammi di classe siano l'aspetto più utile di UML; Raramente mi preoccupo della maggior parte delle altre cose, perché trovo più facile scrivere una documentazione breve e descrittiva che spieghi le interazioni e i comportamenti. I diagrammi delle classi, tuttavia, forniscono una ragionevole panoramica dell'architettura.
Una cosa da tenere a mente è che non dovresti necessariamente preoccuparti troppo di scrivere UML "perfetto" (cioè normativo); la cosa più importante è assicurarsi che le persone capiscano il tuo design. Detto questo, fai attenzione alla notazione accidentale che abusa, perché ciò potrebbe confondere le persone che si aspettano che le cose abbiano un significato specifico. In caso di dubbio, annotare con il testo per chiarire cosa sta succedendo.
UML è più di un modo per visualizzare il progetto di un sistema, non proprio un processo per eseguire tale progetto. Sebbene essere in grado di visualizzare aiuta il processo di progettazione.
Ciò detto mi piace e utilizzo UML quando si progetta più di un'architettura di base.
È molto utile quando si progetta di essere in grado di vedere come tutte le parti combaciano. Molte volte un progetto mostra carenze architettoniche quando si esegue l'UML, prima che qualsiasi codifica sia iniziata.
Serve come un buon riferimento per rendere le persone più veloci su come funziona un sistema, ed è utile quando torni a quel codice più tardi e dici "Come l'ho progettato di nuovo?"
Fondamentalmente per rispondere alla domanda modificata, sì, è utile documentare un progetto di sistema perché molte persone lo conoscono già e, come già sottolineato, ci sono molti strumenti che lo supportano.
UML deve essere utilizzato come strumento di comunicazione. È sicuramente un mezzo valido per comunicare i progetti e offre agli sviluppatori un linguaggio comune per discutere di questi progetti prima dell'implementazione.
Il modo migliore per documentare il progetto è scrivere codice pulito. UML, come tutta la documentazione, tende all'entropia.
Sono d'accordo. Ho usato UML per "discutere" (ad esempio, la lavagna), ma usarlo per "documentare" un disegno diventa rapidamente un problema di manutenzione. "Nessun piano di battaglia sopravvive al contatto con il nemico." - Colin Powell –
La domanda suona un po 'back-to-front a me ... Non credo che UML è inteso come uno strumento per la progettazione di software, così tanto come strumento per documentare un disegno (in corso).
A mio parere, UML può essere uno strumento prezioso per tale documentazione poiché standardizza un numero di viste su un progetto ... ma non è l'unico valido. Qualsiasi documento di progettazione che sia sufficientemente chiaro e ben scritto farà il lavoro, anche se non contiene UML.
IMO, UML ha perso gran parte della sua immagine come la soluzione migliore e sempre migliore per lo sviluppo del software. Mentre gli entusiasti all'inizio sono (e alcuni lo sono ancora) nell'opinione che UML sarà risolvere i problemi di progettazione e tutto dovrebbe idealmente essere disegnato con UML. La realtà ha dimostrato che non è molto meglio di qualsiasi altro tipo di diagramma.
IMO, UML è ora ampiamente visto come ciò che è in realtà: uno standard per molti diagrammi necessari nell'analisi e nella progettazione. È infatti lo standard di diagramma più diffuso in uso. Ci sono più strumenti in giro e più persone conoscono UML di qualsiasi altro stile di diagramma.
UML può diventare parte del processo di progettazione e implementazione. Enterprise Architect ha alcuni ottimi strumenti per la progettazione iniziale. UML si riduce quando non viene eseguito il backup con gli strumenti aggiuntivi di reimportazione dopo la personalizzazione per aggiornare il progetto. Fa davvero un buon lavoro di visualizzazione della struttura attuale e consente di aggiungere dettagli in termini di altri diagrammi UML (casi d'uso, diagrammi di stato, modelli di interfaccia utente e altro).
Purtroppo però, UML non è abituato al suo pieno potenziale nella pratica.
Preferisco utilizzare UML autogenerato (codice sorgente -> UML) per visualizzare l'implementazione di un sistema. Trovo che la documentazione statica sia spesso inutile e talvolta fuorviante.
Il talk How to Represent the Architecture of Your Enterprise Application Using UML 2.0 and More tenuto da Paulo Merson a JavaOne 2006 descrive vari approcci per documentare un'architettura, con e senza UML. Ci sono ulteriori informazioni allo Architecture Documentation, Views and Beyond (V&B) Approach, che descrivono un approccio sostenuto dal Software Engineering Institute (SEI).
UML è solo un metodo per visualizzare alcuni aspetti di una progettazione software. Non può essere usato da solo per documentare un design.
Edit: Cambiato domanda per chiedere di fattibilità di UML per la documentazione, invece di progettazione, sulla base dei suggerimenti di risposte –