UML è pratico?[Chiuso]

https://stackoverflow.com/questions/18803

09-06-2019
|

Domanda

Al college ho avuto numerosi design e UML corsi orientati e riconosco che UML può essere utilizzato a vantaggio di un progetto software, in particolare caso d'uso mappatura, ma è davvero pratica?Ho studiato alcuni termini di lavoro cooperativo e sembra che UML non sia molto utilizzato nel settore.Vale la pena dedicare tempo alla creazione di diagrammi UML durante un progetto?Inoltre, trovo che i diagrammi delle classi generalmente non siano utili, perché è semplicemente più veloce guardare il file di intestazione di una classe.Nello specifico quali sono i diagrammi più utili?

Modificare: La mia esperienza è limitata a piccoli progetti di sviluppo con meno di 10 anni.

Modificare: Molte buone risposte e, sebbene non siano le più dettagliate, credo che quella selezionata sia la più equilibrata.

Soluzione

In un sistema sufficientemente complesso ci sono alcuni posti in cui un po' di UML è considerato utile.

I diagrammi utili per un sistema variano in base all'applicabilità.Ma quelli più utilizzati sono i diagrammi di stato, i diagrammi di attività e il diagramma di sequenza.

Ci sono molte aziende che li sostengono e molte che li respingono 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.

Altri suggerimenti

Usare UML è come guardarsi i piedi mentre si cammina.È rendere conscio 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 sta facendo.Nella maggior parte dei casi, scrivere il codice stesso è più rapido ed efficace che scrivere il codice, perché la loro intuizione di programmazione è sintonizzata sul compito.

Non è solo questione di quello che stai facendo, però.Che dire del nuovo assunto che arriverà tra sei mesi e dovrà aggiornarsi sul codice?Che ne dici di tra cinque anni quando tutti coloro che attualmente lavorano al progetto se ne saranno andati?

È incredibilmente utile avere a disposizione della documentazione di base aggiornata per chiunque si unisca al progetto in un secondo momento.Non sostengo diagrammi UML completi con nomi di metodi e parametri (MOLTO troppo difficili da mantenere), ma penso che un diagramma di base dei componenti del sistema con le loro relazioni e comportamenti di base abbia un valore inestimabile.A meno che la progettazione 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 completi con documentazione di progettazione senza addormentarsi dopo qualche pagina.D'altra parte, la maggior parte delle persone vorrebbe ricevere 5-10 pagine di semplici diagrammi di classe con alcune descrizioni di base di come è messo insieme il sistema.

L'altro caso in cui ho trovato utile UML è 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 guardarsi i piedi mentre si cammina.È rendere conscio 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 sta facendo.Nella maggior parte dei casi, scrivere il codice stesso è più rapido ed efficace che scrivere il codice, perché la loro intuizione di programmazione è sintonizzata sul compito.

L'eccezione è perché di notte ti ritrovi nel bosco senza torcia e inizia a piovere: allora devi guardare i tuoi piedi per evitare di cadere.Ci sono momenti in cui il compito che hai intrapreso è più complicato di quanto la tua intuizione possa gestire e devi rallentare e dichiarare esplicitamente la struttura del tuo programma.Quindi UML è uno dei tanti strumenti che puoi utilizzare.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), nella mia esperienza, sono stati, senza eccezioni, una dolorosa perdita di tempo e fatica.

Dovrei non essere d'accordo, UML è usato ovunque: ovunque venga progettato un progetto IT, UML di solito sarà lì.

Ora se viene utilizzato BENE è un'altra questione.

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

Il diagramma delle classi può essere molto utile quando si tenta di mostrare le relazioni, nonché 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 scritto il codice.

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 che 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 il Processo razionale unificato è che è di più PARLANDO su quello che farai piuttosto che sulla realtà FACENDO cosa farai

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

Da buttare solo secondo me.UML è un ottimo strumento per comunicare idee, l'unico problema è quando lo archivi e lo mantieni perché stai essenzialmente 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 mantenersi aggiornato.

Ho co-insegnato un corso su progetti di sviluppo di livello senior nei miei ultimi due semestri di scuola.Il progetto doveva essere utilizzato in un ambiente di produzione con organizzazioni no-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 in classe era limitato, così come il tempo trascorso fuori dall’aula.Pertanto, dovevamo eseguire revisioni del codice ad ogni riunione di classe, ma con 25 studenti iscritti, il tempo di revisione individuale era molto breve.Gli strumenti che abbiamo trovato più preziosi in queste sessioni di revisione sono stati gli ERD, i diagrammi di classe e i diagrammi di sequenza.Gli ERD e i diagrammi di classe sono stati realizzati solo in Visual Studio, quindi il tempo necessario per crearli era banale per gli studenti.

I diagrammi comunicavano una grande quantità di 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 utilizzare i diagrammi, avremmo dovuto prenderci il tempo di esaminare uno per uno i file di codice degli studenti alla ricerca di problemi.

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

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

Dato l'elenco degli usi sopra, il post di Pascal non è sufficiente in quanto parla solo della creazione del diagramma.Un progetto potrebbe trarre vantaggio da UML se uno qualsiasi dei suddetti fattori costituisce un fattore critico di successo o rappresenta un'area problematica che necessita di una soluzione standardizzata.

La discussione dovrebbe estendersi dal modo in cui UML può essere eliminato o applicato a piccoli progetti per discutere quando UML ha senso o migliorerà effettivamente il prodotto/soluzione in quanto è allora che UML dovrebbe essere utilizzato.Ci sono situazioni in cui anche UML per uno sviluppatore potrebbe rilevare, come l'applicazione di pattern o la generazione di codice.

UML ha funzionato per me per anni.Quando ho iniziato ho letto Fowler's UML distillato dove dice "fai abbastanza modellismo/architettura/ecc.".Usa quello che vuoi Bisogno!

Dal punto di vista di un ingegnere del controllo qualità, i diagrammi UML evidenziano potenziali difetti nella logica e nel pensiero.Mi semplifica il lavoro :)

Penso che UML sia utile, anche se penso che le specifiche 2.0 abbiano reso quella che una volta era una specifica chiara un po' gonfia e macchinosa.Sono d'accordo con l'edizione dei diagrammi temporali ecc. poiché hanno riempito un vuoto...

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

Detto questo mi piacciono i seguenti strumenti UML:

Viola - Se fosse più semplice sarebbe un pezzo di carta
Altova UModel: ottimo strumento per la modellazione Java e C#
MagicDraw: il mio strumento commerciale preferito per la modellazione
Poseidon: strumento decente con un buon rapporto qualità-prezzo
StarUML: il 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 le varie fasi di pianificazione, progettazione, sviluppo e test.

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

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

Potresti anche voler leggere la mia risposta al seguente post:

Come apprendere una “buona progettazione/architettura software”? A https://stackoverflow.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489

Sebbene questa discussione sia rimasta inattiva per molto tempo, ho un paio di punti, a mio avviso importanti, da aggiungere.

Il codice difettoso è una cosa.Lasciati andare alla deriva, possono verificarsi errori di progettazione molto davvero gonfio e brutto.UML, tuttavia, si auto-convalida.Con questo intendo dire che, consentendoti di esplorare i tuoi modelli in dimensioni multiple, matematicamente chiuse e che si controllano reciprocamente, si genera una progettazione robusta.

UML ha un altro aspetto importante:"parla" direttamente con la nostra capacità più forte, quella della visualizzazione.Se, ad esempio, ITIL V3 (in fondo abbastanza semplice) fosse stato comunicato sotto forma di diagrammi UML, avrebbe potuto essere pubblicato su poche decine 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 "in tempo reale" e integrati 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 molte persone che li ritengano utili.

Mi sono spesso chiesto se Rational Rose sia un buon esempio del tipo di applicazioni che si ottengono dalla progettazione basata su modello UML.È gonfio, pieno di bachi, lento, brutto,...

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

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

Vuoi una sorta di pianificazione architettonica
Vuoi essere sicuro che tutti i membri del team utilizzino effettivamente 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 conoscano gli standard esistenti, che si tratti di UML, Flowchard, Nassi-Schneiderman, qualunque cosa, piuttosto che le tue cose interne esistenti.

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

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

Brainstorming sul modo 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 lezione.
Documentare qualsiasi modello architetturale utilizzato su tutti i tuoi sistemi, per gli stessi motivi del punto precedente

Non sono d'accordo solo con Michael quando lo dice usare UML per un singolo sviluppatore e/o un semplice progetto software sembra eccessivo a lui.L'ho usato nei miei piccoli progetti personali e averli documentati utilizzando UML mi ha fatto risparmiare 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 potrebbe esserci un modo per utilizzare casi di utilizzo UML in stile Cockburn, aquilone e a livello di mare 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.

Quindi ho fatto un esperimento e c'è un post qui con il tag "UML" o "Fowler". È stata una semplice idea per C#.Trovare un modo per incorporare i casi d'uso di Cockburn negli spazi dei nomi dei costrutti di programmazione (come gli spazi dei nomi delle classi e delle classi interne o utilizzando gli 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 verifichino.Potrebbe essere utile per programmi semplici che necessitano di una sorta di linguaggio pseudo-specifico del dominio che può esistere proprio nel mezzo del codice C# senza estensioni del linguaggio.

Se sei interessato, controlla il post.Andare Qui.

Uno dei problemi che ho con UML è la comprensibilità delle specifiche.Quando provo a comprendere veramente la semantica di un particolare diagramma mi perdo rapidamente nel labirinto di metamodelli e metametamodelli.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, l'obiettivo non viene raggiunto.

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

Venendo da studente, trovo che UML sia di scarsa utilità.Trovo ironico che i PROGRAMMATORI debbano ancora sviluppare un programma in grado di generare automaticamente le cose che hai detto essere necessarie.Sarebbe estremamente semplice progettare una funzionalità in Visual Studio in grado di estrarre parti di dati, cercare definizioni e risposte al prodotto sufficienti in modo che chiunque possa guardarlo, grande o piccolo, 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 rappresenti una classe con i suoi campi e metodi sebbene sia solo una sorta 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 girovagare per l'API del codice per cercare di ottenere il quadro generale.

UML ha il suo posto.Diventa sempre più importante man mano che crescono le dimensioni del progetto.Se hai un progetto a lungo termine, è meglio documentare tutto in UML.

UML sembra adatto a progetti di grandi dimensioni con grandi team di persone.Tuttavia ho lavorato in piccoli team dove la comunicazione è migliore.

Tuttavia, l'uso di diagrammi in stile UML è utile, 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 siano gli sviluppatori a progettare la parte centrale.

Nella mia esperienza:

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

Conoscere le specifiche di UML (quando utilizzare una linea tratteggiata o un punto finale circolare) non è altrettanto necessario, ma è comunque utile averlo.

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.

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 scrivere codice, dopo aver eseguito il debug e la correzione.La sincronizzazione dei diagrammi UML con il codice e l'analisi obbliga a comprendere bene le richieste del cliente;
Lato gestionale:i diagrammi UML sono specchio delle esigenze del cliente che risulta impreciso:se codifichi senza UML, forse puoi trovare un bug nelle richieste dopo molte ore di lavoro.I diagrammi UML ti permettono di trovare i possibili punti controversi e di risolverli prima della codifica =>aiutano la tua pianificazione.

Generalmente tutti i progetti senza diagrammi UML hanno un'analisi superficiale o hanno dimensioni ridotte.

se sei nel gruppo linkedin INGEGNERI DI SISTEMI, Vedere la mia vecchia discussione.

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

UML no, grazie.

UML è sicuramente utile così come Junit è essenziale.Dipende tutto da come vendi l'idea.Il tuo programma funzionerà senza UML proprio come funzionerebbe senza test unitari.Detto questo, dovresti creare do UML poiché è collegato al tuo codice, ovvero quando aggiorni i diagrammi UML aggiorna il tuo codice o quando aggiorni il tuo codice genera automaticamente l'UML.Non fare solo per il gusto di farlo.

UML ha sicuramente il suo posto nel settore.Immagina di creare software per aerei Boing o qualche altro sistema complesso.UML e RUP sarebbero di grande aiuto in questo caso.

UML è solo uno dei metodi di comunicazione tra le persone.La lavagna è migliore.

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow