UML è pratico? [chiuso]

Al college ho seguito numerosi corsi di design e UML oriented, e riconosco che UML può essere utilizzato a beneficio di un progetto software, in particolare la mappatura dei casi d'uso , ma è davvero pratico? Ho svolto alcuni termini di lavoro in cooperativa e sembra che UML non sia utilizzato molto nel settore. Vale la pena dedicare tempo durante un progetto a creare diagrammi UML? Inoltre, trovo che i diagrammi delle classi generalmente non siano utili, perché è solo più veloce guardare il file di intestazione per una classe. Nello specifico quali sono i diagrammi più utili?

Modifica: la mia esperienza è limitata a piccoli progetti di sviluppatori inferiori a 10.

Modifica: molte buone risposte e, sebbene non le più prolisse, credo che quella selezionata sia la più equilibrata.

In un sistema sufficientemente complesso ci sono alcuni punti in cui alcuni UMLsono considerati utili.

I diagrammi utili per un sistema variano in base all'applicabilità.
Ma quelli più utilizzati sono:

• Diagrammi di classe
• Diagrammi di stato
• Diagrammi di attività
• Diagrammi di sequenza

Ci sono molte imprese che giurano per loro e molte che le rifiutano apertamente come una totale perdita di tempo e fatica.

È meglio non esagerare e pensare a cosa è meglio per il progetto in cui ti trovi e scegliere le cose che sono applicabili e hanno senso.

Usare UML è come guardare i tuoi piedi mentre cammini. È rendere cosciente ed esplicito qualcosa che di solito puoi fare inconsciamente. I principianti devono riflettere attentamente su ciò che stanno facendo, ma un programmatore professionista sa già cosa stanno facendo. La maggior parte delle volte, scrivere il codice stesso è più veloce ed efficace che scrivere del codice, perché la loro intuizione di programmazione è sintonizzata sul compito.

Non si tratta solo di quello che stai facendo. E il nuovo assunto che arriverà tra sei mesi e dovrà aggiornarsi rapidamente sul codice? Che ne dici di cinque anni da adesso in cui tutti quelli che stanno attualmente lavorando al progetto se ne saranno andati?

È incredibilmente utile avere una documentazione di base aggiornata disponibile per chiunque si unisca al progetto in seguito. Non sostengo diagrammi UML in piena regola con nomi di metodi e parametri (MODO troppo difficile da mantenere), ma penso che un diagramma di base dei componenti nel sistema con le loro relazioni e il comportamento di base sia inestimabile. A meno che il design del sistema non cambi drasticamente, queste informazioni non dovrebbero cambiare molto anche se l'implementazione viene ottimizzata.

Ho scoperto che la chiave per la documentazione è la moderazione. Nessuno leggerà 50 pagine di diagrammi UML in piena regola con documentazione di progettazione senza addormentarsi per qualche pagina. D'altra parte, la maggior parte delle persone vorrebbe avere 5-10 pagine di semplici diagrammi di classe con alcune descrizioni di base di come il sistema è messo insieme.

L'altro caso in cui ho trovato che UML è utile è quando uno sviluppatore senior è responsabile della progettazione di un componente, ma poi consegna il progetto a uno sviluppatore junior per l'implementazione.

Usare UML è come guardare i tuoi piedi mentre cammini. È rendere cosciente ed esplicito qualcosa che di solito puoi fare inconsciamente. I principianti devono riflettere attentamente su ciò che stanno facendo, ma un programmatore professionista sa già cosa stanno facendo. La maggior parte delle volte, scrivere il codice stesso è più veloce ed efficace che scrivere del codice, perché la loro intuizione di programmazione è sintonizzata sul compito.

L'eccezione è perché ti ritrovi nel bosco di notte senza torcia e ha iniziato a piovere, quindi devi guardare i tuoi piedi per evitare di cadere. Ci sono momenti in cui il compito che ti sei assunto è più complicato di quanto la tua intuizione possa gestire, e devi rallentare e dichiarare esplicitamente la struttura del tuo programma. Allora UML è uno dei tanti strumenti che puoi usare. Altri includono pseudocodice, diagrammi di architettura di alto livello e strane metafore.

Il flusso di lavoro generico e i DFD possono essere molto utili per processi complessi. Tutti gli altri diagrammi (SOPRATTUTTO UML) sono stati, nella mia esperienza, senza eccezioni, una dolorosa perdita di tempo e fatica.

Non dovrei essere d'accordo, UML è utilizzato ovunque - ovunque venga progettato un progetto IT, UML di solito sarà lì.

Ora, se viene usato bene è un'altra questione.

Come ha detto Stu, trovo che sia i casi d'uso (insieme alle descrizioni dei casi d'uso) sia i diagrammi di attività siano i più utili dal punto di vista degli sviluppatori.

Il diagramma delle classi può essere molto utile quando si cerca di mostrare le relazioni, così come gli attributi degli oggetti, come la persistenza. Quando si tratta di aggiungere un singolo attributo o proprietà, di solito sono eccessivi, soprattutto perché spesso diventano obsoleti rapidamente una volta che il codice è stato scritto.

Uno dei maggiori problemi con UML è la quantità di lavoro richiesta per mantenerlo aggiornato una volta generato il codice, poiché ci sono pochi strumenti in grado di riprogettare UML dal codice e pochi ancora lo fanno bene.

Qualificherò la mia risposta menzionando che non ho esperienza in ambienti di sviluppo aziendale di grandi dimensioni (simili a IBM).

Il modo in cui vedo UML e Rational Unified Process è che è più PARLARE di ciò che farai che FARE effettivamente ciò che farai.

(In altre parole è in gran parte una perdita di tempo)

Butta via solo secondo me. UML è un ottimo strumento per comunicare idee, l'unico problema è quando lo memorizzi e lo gestisci perché essenzialmente stai creando due copie delle stesse informazioni ed è qui che di solito soffia. Dopo il ciclo iniziale di implementazione, la maggior parte dell'UML dovrebbe essere generata dal codice sorgente altrimenti diventerà obsoleto molto rapidamente o richiederà molto tempo (con errori manuali) per essere aggiornato.

Ho co-insegnato a un corso di progetto di sviluppo di livello senior nei miei ultimi due semestri a scuola. Il progetto doveva essere utilizzato in un ambiente di produzione con organizzazioni non profit locali come clienti paganti. Dovevamo essere certi che il codice facesse quello che ci aspettavamo e che gli studenti acquisissero tutti i dati necessari per soddisfare le esigenze dei clienti.

Il tempo di lezione era limitato, così come il mio tempo fuori dall'aula. Pertanto, abbiamo dovuto eseguire revisioni del codice a ogni riunione di classe, ma con 25 studenti iscritti il ​​tempo di revisione individuale è stato molto breve. Lo strumento che abbiamo trovato più prezioso in queste sessioni di revisione sono stati ERD, diagrammi di classe e diagrammi di sequenza. Gli ERD e i diagrammi delle classi venivano eseguiti solo in Visual Studio, quindi il tempo necessario per crearli era irrisorio per gli studenti.

I diagrammi hanno trasmesso molte informazioni molto rapidamente. Avendo una rapida panoramica dei progetti degli studenti, abbiamo potuto isolare rapidamente le aree problematiche nel loro codice ed eseguire una revisione più dettagliata sul posto.

Senza usare i diagrammi, avremmo dovuto prendere il tempo per esaminare uno per uno i file di codice degli studenti alla ricerca di problemi.

Arrivo a questo argomento un po 'tardi e cercherò di chiarire un paio di punti minori. Chiedere se UML è utile in quanto troppo ampio. La maggior parte delle persone sembrava rispondere alla domanda dal tipico / popolare UML come prospettiva di uno strumento di disegno / comunicazione. Nota: Martin Fowler e altri autori di libri UML ritengono che UML sia utilizzato al meglio solo per la comunicazione. Tuttavia, ci sono molti altri usi per UML. Soprattutto, UML è un linguaggio di modellazione che ha notazioni e diagrammi mappati ai concetti logici. Ecco alcuni utilizzi per UML:

• Comunicazione
• Documentazione di progettazione / soluzione standardizzata
• Definizione DSL (Domain Specific Language)
• Definizione del modello (profili UML)
• Utilizzo di pattern / risorse
• Generazione di codice
• Trasformazioni da modello a modello

Dato l'elenco degli usi sopra, l'inserimento di Pascal non è sufficiente in quanto si riferisce solo alla creazione di diagrammi. Un progetto potrebbe trarre vantaggio da UML se uno qualsiasi dei precedenti sono fattori critici di successo o sono aree problematiche che richiedono una soluzione standardizzata.

La discussione dovrebbe estendersi al modo in cui UML può essere eccessivamente ucciso o applicato a piccoli progetti per discutere quando UML ha senso o migliorerà effettivamente il prodotto / soluzione poiché è quando UML dovrebbe essere usato. Ci sono situazioni in cui anche UML per uno sviluppatore potrebbe avere senso, come Applicazione Pattern o Generazione di codice.

UML ha lavorato per me per anni. Quando ho iniziato ho letto UML Distilled di Fowler dove dice "fai abbastanza modellazione / architettura / ecc.". Usa quello che ti serve !

Dal punto di vista di un QA Engineer, i diagrammi UML evidenziano potenziali difetti nella logica e nel pensiero. Rende il mio lavoro più facile :)

Penso che l'UML sia utile, anche se penso che la specifica 2.0 abbia reso quella che una volta era una specifica chiara un po 'gonfiata e ingombrante. Sono d'accordo con l'edizione dei diagrammi dei tempi ecc. Poiché hanno riempito un vuoto ...

Imparare a usare l'UML in modo efficace richiede un po 'di pratica. Il punto più importante è comunicare chiaramente, modellare quando necessario e modellare come una squadra. Le lavagne sono lo strumento migliore che ho trovato. Non ho visto alcun "software per lavagna digitale" che sia riuscito a catturare l'utilità di una lavagna reale.

Detto questo, mi piacciono i seguenti strumenti UML:

1. Viola - Se fosse più semplice sarebbe un pezzo di carta

2. Altova UModel - Ottimo strumento per Java e C # Modeling

3. MagicDraw - Il mio strumento commerciale preferito per la modellazione

4. Poseidon - Strumento decente con un buon rapporto qualità-prezzo

5. StarUML - Miglior strumento di modellazione open source

I diagrammi UML sono utili per acquisire e comunicare i requisiti e garantire che il sistema soddisfi tali requisiti. Possono essere utilizzati in modo iterativo e durante varie fasi di pianificazione, progettazione, sviluppo e test.

Dall'argomento: Utilizzo di modelli all'interno del processo di sviluppo su http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

Un modello può aiutarti a visualizzare il mondo in cui funziona il tuo sistema, chiarire le esigenze degli utenti, definire l'architettura del tuo sistema, analizzare il codice e garantire che il tuo codice soddisfi i requisiti.

Potresti anche leggere la mia risposta al seguente post:

Come apprendere "una buona progettazione / architettura del software"? su /programming/268231/how-to-learn-good-software-design-architecture/2293489#2293489

Sebbene questa discussione sia stata a lungo inattiva, ho un paio di punti, a mio avviso importanti, da aggiungere.

Il codice difettoso è una cosa. Lasciati andare alla deriva a valle, gli errori di progettazione possono diventare davvero pesanti e brutti. L'UML, tuttavia, si auto-convalida. Con questo voglio dire che permettendoti di esplorare i tuoi modelli in dimensioni multiple, matematicamente chiuse e che si controllano reciprocamente, genera un design robusto.

UML ha un altro aspetto importante: "dialoga" direttamente con la nostra capacità più forte, quella di visualizzazione. Se, per esempio, ITIL V3 (in fondo abbastanza semplice) fosse stato comunicato sotto forma di diagrammi UML, avrebbe potuto essere pubblicato su poche dozzine di pieghevoli A3. Invece, è uscito in diversi tomi di proporzioni veramente bibliche, generando un'intera industria, costi mozzafiato e shock catatonico diffuso.

Vedo diagrammi di sequenza e diagrammi di attività usati abbastanza spesso. Lavoro molto con sistemi embedded e "real-time" che interagiscono con altri sistemi e i diagrammi di sequenza sono molto utili per visualizzare tutte le interazioni.

Mi piace creare diagrammi dei casi d'uso, ma non ho incontrato troppe persone che pensano che siano preziosi.

Mi sono spesso chiesto se Rational Rose sia un buon esempio dei tipi di applicazioni che ottieni dalla progettazione basata su modello UML. È gonfio, pieno di bug, lento, brutto, ...

Ho trovato UML non molto utile per progetti molto piccoli, ma davvero adatto per progetti più grandi.

In sostanza, non importa cosa usi, devi solo tenere a mente due cose:

• Vuoi una sorta di pianificazione dell'architettura
• Vuoi essere sicuro che tutti i membri del team stiano effettivamente utilizzando la stessa tecnologia per la pianificazione del progetto

Quindi UML è proprio questo: uno standard su come pianifichi i tuoi progetti. Se assumi nuove persone, è più probabile che tu conosca qualsiasi standard esistente - sia esso UML, Flowchard, Nassi-Schneiderman, qualunque sia - piuttosto che il tuo materiale interno esistente.

Usare UML per un singolo sviluppatore e / o un semplice progetto software mi sembra eccessivo, ma quando lavoro in un team più ampio, vorrei sicuramente uno standard per la pianificazione del software.

UML è utile, sì davvero! I principali utilizzi che ne ho fatto sono stati:

• Brainstorming sui modi in cui dovrebbe funzionare un software. Rende facile comunicare ciò che stai pensando.
• Documentare l'architettura di un sistema, i suoi modelli e le principali relazioni delle sue classi. Aiuta quando qualcuno entra nella tua squadra, quando te ne vai e vuoi assicurarti che il tuo successore lo capisca e quando alla fine dimentichi a cosa diavolo era destinata quella piccola classe.
• Documentare qualsiasi modello architettonico che utilizzi su tutti i tuoi sistemi, per le stesse ragioni del punto sopra

Non sono d'accordo con Michael solo quando dice che l' utilizzo di UML per un singolo sviluppatore e / o un semplice progetto software gli sembra eccessivo . L'ho usato nei miei piccoli progetti personali, e averli documentati usando UML mi ha risparmiato molto tempo quando sono tornato da loro sette mesi dopo e avevo completamente dimenticato come avevo costruito e messo insieme tutte quelle classi.

Credo che ci possa essere un modo per utilizzare i casi d'uso di pesce, aquiloni e livello del mare UML stile Cockburn, come descritto da Fowler nel suo libro "UML Distilled". La mia idea era di utilizzare i casi d'uso di Cockburn come aiuto per la leggibilità del codice.

Così ho fatto un esperimento e c'è un post qui a riguardo con il tag "UML" o "FOWLER". Era un'idea semplice per c #. Trova un modo per incorporare i casi d'uso di Cockburn negli spazi dei nomi dei costrutti di programmazione (come gli spazi dei nomi della classe e della classe interna o facendo uso degli spazi dei nomi per le enumerazioni). Credo che questa potrebbe essere una tecnica praticabile e semplice, ma ho ancora domande e ho bisogno che altri la esaminino. Potrebbe essere utile per programmi semplici che richiedono una sorta di linguaggio pseudo-dominio specifico che può esistere proprio nel mezzo del codice c # senza alcuna estensione di linguaggio.

Per favore controlla il post se sei interessato. Vai qui .

Uno dei problemi che ho con UML è la comprensibilità delle specifiche. Quando cerco di capire veramente la semantica di un particolare diagramma, mi perdo rapidamente nel labirinto di meta-modelli e meta-meta-modelli. Uno dei punti di forza di UML è che è meno ambiguo del linguaggio naturale. Tuttavia, se due o più ingegneri interpretano un diagramma in modo diverso, non raggiunge l'obiettivo.

Inoltre, ho provato a porre domande specifiche sul documento della super struttura su diversi forum UML e ai membri dell'OMG stesso, con risultati scarsi o nulli. Non credo che la comunità UML sia ancora abbastanza matura da sostenersi.

Provenendo da uno studente, trovo che UML sia di scarsa utilità. Trovo ironico che PROGAMERS debba ancora sviluppare un programma che generi automaticamente le cose che hai detto essere necessarie. Sarebbe estremamente semplice progettare una funzionalità in Visual Studio che potrebbe estrarre parti di dati, cercare definizioni e risposte di prodotto sufficienti in modo che chiunque possa guardarla, grande o piccola, e comprendere il programma. Ciò lo manterrebbe anche aggiornato perché prenderebbe le informazioni direttamente dal codice per produrre le informazioni.

UML viene utilizzato non appena si rappresenta una classe con i suoi campi e metodi, sebbene sia solo una specie di diagramma UML.

Il problema con UML è che il libro dei fondatori è troppo vago.

UML è solo un linguaggio, non è realmente un metodo.

Per quanto mi riguarda, trovo davvero fastidiosa la mancanza dello schema UML per i progetti opensource. Prendi qualcosa come Wordpress, hai solo uno schema di database, nient'altro. Devi vagare per l'API del codice per cercare di ottenere il quadro generale.

UML ha il suo posto. Diventa sempre più importante con l'aumentare delle dimensioni del progetto. Se hai un progetto di lunga durata, è meglio documentare tutto in UML.

UML sembra buono per grandi progetti con grandi team di persone. Tuttavia ho lavorato in piccoli team dove la comunicazione è migliore.

L'uso dei diagrammi in stile UML è buono, soprattutto nella fase di pianificazione. Tendo a pensare in codice, quindi trovo difficile scrivere specifiche di grandi dimensioni. Preferisco annotare gli input e gli output e lasciare che gli sviluppatori progettino il bit nel mezzo.

Credo che UML sia utile solo per il fatto che induce le persone a pensare alle relazioni tra le loro classi. È un buon punto di partenza per iniziare a pensare a tali relazioni, ma sicuramente non è una soluzione per tutti.

La mia convinzione è che l'uso di UML sia soggettivo alla situazione in cui sta lavorando il team di sviluppo.

Nella mia esperienza:

La capacità di creare e comunicare diagrammi di codice significativi è un'abilità necessaria per qualsiasi ingegnere del software che sta sviluppando un nuovo codice o sta tentando di comprendere il codice esistente.

Conoscere le specifiche di UML - quando usare una linea tratteggiata o un punto finale del cerchio - non è così necessario, ma è comunque utile.

UML è utile in due modi:

• Lato tecnico: molte persone (manager e alcuni analisti funzionali) pensano che UML sia una caratteristica di lusso perché il codice è la documentazione: inizi a programmare, dopo aver eseguito il debug e corretto . La sincronizzazione dei diagrammi UML con il codice e le analisi obbligano a comprendere bene le richieste del cliente;

• Lato gestionale: i diagrammi UMl sono uno specchio delle richieste del cliente che risulta impreciso: se si codifica senza UML, forse si può riscontrare un bug in richiede dopo molte ore di lavoro. I diagrammi UML ti permettono di trovare i possibili punti controversi e di risolverli prima che la codifica => aiuti la tua pianificazione.

In generale, tutti i progetti senza diagrammi UML hanno un'analisi superficiale o hanno dimensioni ridotte.

se sei nel gruppo linkedin SYSTEMS ENGINEERS , vedi la mia vecchia discussione .

Alla fine UML esiste solo a causa di RUP. Abbiamo bisogno di UML o di qualsiasi altro materiale correlato per utilizzare Java / .Net? La risposta pratica è che hanno la loro documentazione (javadoc ecc.) Che è sufficiente e ci consente di portare a termine il nostro lavoro!

UML no grazie.

UML è decisamente utile così come junit è essenziale. Tutto dipende da come vendi l'idea. Il tuo programma funzionerà senza UML proprio come funzionerebbe senza unit test. Detto questo, dovresti creare do UML mentre è connesso al tuo codice, cioè quando aggiorni i diagrammi UML aggiorna il tuo codice, o quando aggiorni il tuo codice genera automaticamente l'UML. Non farlo solo per il gusto di farlo.

UML ha sicuramente il suo posto nel settore. Immagina di creare software per aerei Boing o altri sistemi complessi. UML e RUP sarebbero di grande aiuto qui.

UML è solo uno dei metodi per la comunicazione all'interno delle persone. La lavagna è migliore.