UML è pratico?


103

Al college ho avuto numerosi corsi orientati al design e UML, e riconosco che UML può essere utilizzato a beneficio di un progetto software, in particolare la mappatura use-case, ma è davvero pratico? Ho fatto alcuni termini di lavoro cooperativo e sembra che UML non sia usato pesantemente nel settore. Vale la pena il tempo durante un progetto per creare diagrammi UML? Inoltre, trovo che i diagrammi di classe non siano in genere utili, perché è solo più veloce osservare il file di intestazione di una classe. In particolare quali sono i diagrammi più utili?

Modifica: La mia esperienza è limitata a piccoli, meno di 10 progetti di sviluppo.

Modifica: Molte buone risposte, e anche se non il più dettagliato, credo che quello selezionato sia il più equilibrato.

+3

I risultati di un sondaggio del 2013 rivelano che non è utilizzato tanto quanto i professori dell'ingegneria del software si aspettano (!) E rivelano alcuni motivi per cui: http://oro.open.ac.uk/35805/8/UML%20in%20practice% 208.pdf 11 giu. 152015-06-11 23:21:25

39

In un sistema sufficientemente complesso ci sono alcuni posti in cui alcuni UML sono considerati utili.

Gli schemi utili per un sistema variano in base all'applicabilità. Ma quelli più usati sono Diagrammi di stato, Diagrammi di attività e Diagramma di sequenza.

Ci sono molte aziende che giurano su di loro e molti che li rifiutano completamente come un totale spreco di tempo e fatica.

È meglio non esagerare e pensare qual è il modo migliore per il progetto in cui si opera e scegliere ciò che è applicabile e sensato.


17

Il flusso di lavoro generico e i DFD possono essere molto utili per processi complessi. Tutti gli altri diagrammi (SPECIALMENTE UML) hanno, nella mia esperienza, senza eccezioni, uno spreco doloroso di tempo e fatica.


1

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

  0

O almeno i problemi chiave di progettazione. 06 nov. 082008-11-06 08:20:57


-3

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


16

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

Ora se viene utilizzato il pozzetto è un'altra questione.

Come detto da Stu, trovo che entrambi i casi d'uso (insieme alle descrizioni dei casi d'uso) e gli schemi di attività sono i più utili dal punto di vista degli sviluppatori.

Il diagramma di classe può essere molto utile quando si tenta di mostrare le relazioni, nonché gli attributi dell'oggetto, come la persistenza. Quando si tratta di aggiungere sempre un singolo attributo o proprietà, di solito sono eccessivi, specialmente perché spesso diventano obsoleti rapidamente una volta che il codice è stato scritto.

Uno dei maggiori problemi con UML è la quantità di lavoro necessaria per tenerlo aggiornato una volta che il codice viene generato, in quanto vi sono pochi strumenti che possono re-ingegnerizzare UML dal codice, e pochi ancora lo fanno bene .

  0

hai letto la mia mente;) 25 set. 082008-09-25 04:58:03


2

Vedo diagrammi di sequenza e diagrammi di attività utilizzati abbastanza spesso. Lavoro molto con i 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 fare diagrammi del caso d'uso, ma non ho incontrato troppe persone che pensano che siano preziose.

Mi sono chiesto spesso se Rational Rose è un buon esempio del tipo di applicazioni ottenute dal design basato su modello UML. È gonfio, buggy, lento, brutto, ...


13

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

Il modo in cui ho vista UML e il Rational Unified Process è che è più TALKING su ciò che si sta andando a fare che in realtà FARE quello che stai andando a fare.

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

+8

Non ti voterò perché penso che sia una buona risposta, ma non potrei essere più in disaccordo. Ogni volta che diagramma qualcosa, mi risparmio ore o mesi di tempo di sviluppo, e quasi sempre mi sviluppo da solo (di recente). 22 ott. 082008-10-22 06:09:40

+1

Parlare e scrivere su quello che vuoi fare aiuta te e gli altri a capire e cogliere i possibili problemi prima. 16 giu. 152015-06-16 17:34:32


10

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

Il tempo di lezione era limitato, così come lo era il mio tempo fuori dalla classe. Come tale, abbiamo dovuto eseguire revisioni del codice ad 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. I diagrammi di ERD e di classe erano fatti solo in Visual Studio, quindi il tempo necessario per crearli era banale per gli studenti.

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

Senza utilizzare diagrammi, avremmo dovuto prendere il tempo di andare uno dopo l'altro attraverso i file di codice degli studenti in cerca di problemi.

  0

+1 Una buona visualizzazione dei dati aiuta ad esporre problemi e tendenze altrimenti oscurati con dettagli non pertinenti. 14 gen. 102010-01-14 11:43:09


2

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

In sostanza, in realtà non importa quello che si utilizza, basta tenere a mente due cose:

  • Volete qualche tipo di pianificazione dell'architettura
  • Volete essere sicuri che tutti nel il team sta attualmente utilizzando la stessa tecnologia per la pianificazione del progetto

Quindi UML è proprio questo: uno standard su come pianificare i progetti. Se assumi nuove persone, è più probabile che tu conosca uno standard esistente - che si tratti di UML, Flowchard, Nassi-Schneiderman, qualunque cosa - piuttosto che delle tue attuali cose in casa.

L'utilizzo di UML per un singolo sviluppatore e/o un semplice progetto software mi sembra eccessivo, ma quando si lavora in un team più ampio, vorrei sicuramente uno standard per la pianificazione del software.


30

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

L'eccezione è perché ti ritrovi nei boschi di notte senza torcia e inizia a piovere - quindi devi guardare i tuoi piedi per evitare di cadere. Ci sono momenti in cui l'attività che hai intrapreso è più complicata di quanto il tuo intuito possa gestire, e devi rallentare e indicare esplicitamente la struttura del tuo programma. Quindi UML è uno dei tanti strumenti che puoi usare. Altri includono pseudocodici, diagrammi di architettura di alto livello e strane metafore.

+3

Cosa strana di questo sito, non c'è modo di dire che stai citando qualcuno nel primo paragrafo e poi non sono d'accordo con loro .. ma sì, vero: lo pseudocodice è anche una grande tecnica di diagrammi e molto comunemente usata. Anche strane metafore che coinvolgono boschi, torce, ecc. 22 ott. 082008-10-22 06:13:28


2

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

  • Brainstorming sui modi in cui un software dovrebbe funzionare. Rende facile comunicare ciò che stai pensando.
  • Documentare l'architettura di un sistema, i suoi modelli e le relazioni principali delle sue classi. Aiuta quando qualcuno entra nella tua squadra, quando parti e vuoi assicurarti che il tuo successore lo capisca, e quando alla fine dimentichi che diavolo era destinato a quella piccola classe.
  • documentazione di eventuali pattern architetturale si utilizza su tutti i sistemi, per le stesse ragioni del puntino sopra

Non sono d'accordo soltanto con Michael quando dice che utilizzando UML per un unico committente e/o di un semplice software il progetto sembra eccessivo a. L'ho usato nei miei piccoli progetti personali, e averli documentati usando UML mi ha fatto risparmiare un sacco di tempo quando sono tornato da loro sette mesi dopo e avevo completamente dimenticato come avevo costruito e messo insieme tutte quelle lezioni.


1

UML sembra essere adatto per grandi progetti con grandi gruppi di persone. Tuttavia ho lavorato in piccoli team in cui la comunicazione è migliore.

L'utilizzo di diagrammi UML è buono, soprattutto in fase di pianificazione. Tendo a pensare in codice, quindi trovo difficile scrivere le specifiche più dettagliate. Preferisco scrivere gli input e le uscite e lasciare che gli sviluppatori progettino il bit nel mezzo.

+1

Anche nei progetti più piccoli è frustrante lavorare comunicando secondo me. Se devi chiedere e dire tutto un sacco di cose, interrompe il lavoro e non viene prodotto alcun documento. Invece i principi chiave di progettazione dovrebbero essere documentati e modellati. 06 nov. 082008-11-06 08:24:53


0

Nella mia esperienza:

La possibilità di creare e comunicare gli schemi del codice di significato è una competenza necessaria per qualsiasi ingegnere del software che sta sviluppando il nuovo codice, o il tentativo di capire il codice esistente.

Conoscere le specifiche di UML - quando utilizzare una linea tratteggiata o un punto finale del cerchio - non è altrettanto necessario, ma è comunque buono da avere.


0

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

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


74

Utilizzare UML è come guardare i piedi mentre si cammina. Sta facendo qualcosa di cosciente ed esplicito che di solito puoi fare inconsciamente. I principianti devono riflettere attentamente su quello che stanno facendo, ma un programmatore professionista sa già cosa stanno facendo. La maggior parte delle volte, scrivere il codice stesso è più veloce e più efficace della scrittura del codice, perché la loro intuizione di programmazione è sintonizzata sull'attività.

Non si tratta solo di quello che stai facendo. Che mi dici del nuovo noleggio che arriverà fra sei mesi e che deve venire a conoscenza del codice? Che dire circa cinque anni da quando tutti quelli che stanno lavorando al progetto sono finiti?

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

Ho trovato che la chiave per la documentazione è la moderazione. Nessuno leggerà 50 pagine di diagrammi UML in piena regola con la documentazione di progettazione senza addormentarsi di alcune pagine. D'altra parte, molte persone vorrebbero avere 5-10 pagine di semplici diagrammi di classe con alcune descrizioni di base di come 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 passa il progetto a uno sviluppatore junior per implementarlo.

+1

+1 quindi colpisci il 10k 11 gen. 112011-01-11 09:31:59

+25

"Che ne pensi del nuovo noleggio che arriverà fra sei mesi e che deve arrivare a velocità sul codice?" Errr .. che ne dici di guardare il codice? Questo è l'unico modo accurato e completo per aggiornarsi sul codice. Anche il modo più naturale, considerando che siamo programmatori. Considero l'idea che dobbiamo guardare un diagramma per capire il codice completamente ridicolo e anche deprimente che questa spazzatura sia diventata in qualche modo diffusa. 03 giu. 112011-06-03 08:31:25

+4

D'accordo con BobTurbo, non ho mai avuto alcun uso per UML, specialmente per l'UML di qualcun altro. Preferisco sempre andare direttamente al codice. 20 feb. 132013-02-20 19:38:41

+7

Ho trovato il disegno di un diagramma di classe UML prima di imbarcarmi nella codifica mi ha fatto risparmiare tempo. Mi ha permesso di visualizzare difetti di progettazione e difetti e discuterne con i miei colleghi. Meglio ancora se sono disegnati usando gli strumenti CASE, genereranno il codice strutturale di base della tua app. Quindi il rimborso è tre volte. 28 gen. 142014-01-28 07:09:10

+1

@James Adam, nessun diagramma dovrebbe sostituire il codice ma in enormi basi di codice (provare milioni di righe di codice) avere una panoramica più elevata del sistema può far risparmiare tempo e nervosismo. 24 gen. 152015-01-24 01:14:30

+6

Un'immagine vale ancora migliaia di parole, anche quando si tratta di codice, @BobTurbo. Non vedo alcuna argomentazione razionale contro questo - e questo include argomenti che iniziano con "Ben _ programmatori_realisti ..." Se avrò una conversazione sull'architettura con la mia squadra, non ho intenzione di scotch tape 10 pagine di codice sorgente su una lavagna. 19 giu. 152015-06-19 21:51:56

  0

@DavidS Se necessario, i diagrammi possono essere post-produzione molto più velocemente del contrario. Non è necessario forzare un intero progetto in una metodologia superflessiva, nel caso in cui qualcuno volesse dare una rapida occhiata in futuro. 02 giu. 162016-06-02 03:30:24

+1

@BobTurbo Ma è sempre facile leggere il codice di un'altra persona? Quanto sei sicuro di leggere il codice sorgente di Microsoft .NET e di capirlo tutto in 1 mese? Anche se capisci, ti rimane sempre la domanda: "Perché l'ha fatto in questo modo? Perché non in quel modo?" I diagrammi consentono inoltre una corretta pianificazione e distribuzione delle attività di codifica in modo da non sovrapporre le attività. Aiuta anche a determinare la fattibilità, i costi e le prove per giustificare la decisione del cliente/superiore/non-codificatore. In sostanza, UML è consigliato a meno che non si stia sviluppando un'app ciao mondo. 05 dic. 162016-12-05 04:06:08


12

Gettare via solo secondo me. UML è un ottimo strumento per comunicare idee, l'unico problema è quando lo memorizzi e lo mantieni perché in sostanza stai creando due copie delle stesse informazioni e questo è dove solitamente si soffia. Dopo il primo round di implementazione, la maggior parte di UML dovrebbe essere generata dal codice sorgente, altrimenti andrà fuori data molto velocemente o richiederà molto tempo (con errori manuali) per tenersi aggiornato.

  0

Wow. Che dire di uno strumento che mantiene il diagramma in sincronia con il codice e viceversa, come Together? 22 ott. 082008-10-22 06:08:21

+1

Il fatto che UML possa essere generato dalla sorgente significa, per me, che non c'è alcun vantaggio nel leggere l'UML semplicemente leggendo la fonte. In altre parole è uno spreco. 25 set. 112011-09-25 23:42:31

+1

@MarcusDowning No, aiuta i nuovi assunti in modo massiccio. È più rapido guardare UML rispetto al codice. 16 giu. 152015-06-16 17:37:41


4

UML ha lavorato per me per anni. Quando ho iniziato ho letto Fowler's UML Distilled dove dice "do enough modeling/architecture/etc.". Basta usare quello che hai necessario!


2

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

Così ho fatto un esperimento e qui c'è un post con il tag "UML" o "FOWLER". E 'stata un'idea semplice per C#. Trova un modo per incorporare i casi di uso di Cockburn negli spazi dei nomi dei costrutti di programmazione (come gli spazi dei nomi delle classi e delle classi interne 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 bisogno di altri per verificarlo. Potrebbe essere utile per programmi semplici che necessitano di una sorta di linguaggio specifico pseudo-dominio che può esistere proprio nel mezzo del codice C# senza alcuna estensione di lingua.

Si prega di controllare il post se siete interessati. Vai a here.


2

Uno dei problemi che ho con UML è la comprensibilità delle specifiche. Quando cerco di comprendere 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, falliscono nell'obiettivo.

Inoltre, ho provato a porre domande specifiche sul documento di super-struttura in diversi forum UML e ai membri dell'OMG stesso, con risultati minimi o nulli. Non penso che la comunità UML sia ancora abbastanza matura per supportarsi.


3

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

Imparare a usare l'UML 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 di lavagna digitale" che sia riuscito a catturare l'utilità di una lavagna reale.

Detto questo mi piace i seguenti strumenti UML:

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

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

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

  4. Poseidon - troppo dignitoso l con buona bang per il dollaro

  5. StarUML - Miglior strumento di modellazione open source

8

io vengo a questo tema un po 'in ritardo e sarà solo provare un chiarire un paio di punti minori. Chiedere se UML è troppo utile. La maggior parte delle persone sembrava rispondere alla domanda dal tipico/popolare UML come prospettiva di strumento di disegno/comunicazione. Nota: Martin Fowler e altri autori di libri UML ritengono che UML sia utilizzato al meglio solo per le comunicazioni. Tuttavia, ci sono molti altri usi per UML. Soprattutto, UML è un linguaggio di modellazione che ha notazione e diagrammi mappati ai concetti logici. Qui ci sono alcuni usi per UML:

  • Comunicazione
  • standardizzato documentazione di progettazione/Soluzione
  • DSL (Domain Specific Language) Definizione
  • Modello Definizione (UML Profiles)
  • Pattern/Asset Uso
  • Generazione codice
  • Trasformazioni da modello a modello

Dato che 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 dei fattori sopra elencati è un fattore critico di successo o è un'area problematica che necessita di una soluzione standardizzata.

La discussione dovrebbe estendersi dal modo in cui UML può essere superato o applicato a piccoli progetti per discutere quando UML ha un senso o effettivamente migliorerà il prodotto/soluzione come quando UML deve essere utilizzato. Ci sono situazioni in cui UML per uno sviluppatore potrebbe percepire anche, come Pattern Application o Code Generation.


3

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


0

UML è utile in due modi:

  • lato tecnico: un sacco di gente (manager e qualche analista funzionale) pensare che UML è una caratteristica di lusso perché Il codice è la documentazione: si avvia la codifica, dopo aver eseguito il debug e risolto. La sincronizzazione dei diagrammi UML con codice e analisi ti costringe a comprendere bene le richieste del cliente;

  • Lato gestione: i diagrammi UMl sono uno specchio delle esigenze del cliente che è impreciso: se si codifica senza UML, forse è possibile trovare un bug in richiede dopo un sacco di 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.

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

se si è nel gruppo linkedin INGEGNERI DEL SISTEMA, vedere my old discussion.


2

Provenendo da uno studente, trovo che UML abbia pochissimo uso. Trovo paradossale che PROGAMERS non abbia ancora sviluppato un programma che genererà automaticamente le cose che hai detto siano necessarie. Sarebbe estremamente semplice progettare una funzionalità in Visual Studio in grado di estrarre pezzi di dati, cercare definizioni e risposte di prodotto sufficienti in modo che chiunque possa guardarli, grandi o piccoli, e capire il programma. Ciò manterrebbe anche aggiornato perché prenderebbe le informazioni direttamente dal codice per produrre le informazioni.

  0

Non è così facile! Se si utilizza il reverse engineering per estrarre un modello UML dal codice reale, si tende a finire con così tanti dettagli nel modello UML che è inutile. Senza dubbio questo viene perseguito dai ricercatori, ma non è un problema facile da risolvere. 04 feb. 162016-02-04 17:20:37


-2

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


-1

Alla fine UML esiste solo a causa di RUP. Abbiamo bisogno di UML o di qualsiasi sua roba correlata per usare Java/.Net? La risposta pratica è che hanno la loro documentazione (javadoc, ecc.) Che è sufficiente e ci permette di fare il nostro lavoro!

UML no grazie.

  0

RUP riguarda Gestione processo, UML riguarda la lingua. UML è utile quando si ha a che fare con molte persone e si ha bisogno di un linguaggio comune. 09 ago. 092009-08-09 10:20:43

+1

Mai sentito parlare di whispiers cinesi - più uno traslativo si fa da una forma all'altra, si insinua differenza ed errore Se UML è così buono perché non Microsoft, Sun, Google include UML nei dettagli del prodotto? Avrai difficoltà a trovarne. Qualunque cosa sia successo agli utensili? Avanti/indietro strumenti a due vie? Non esistono perché quella moda è morta a causa della mancanza di merito. 11 ago. 092009-08-11 11:55:27


2

UML viene utilizzato non appena si rappresenta una classe con i relativi 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 è proprio un metodo.

Per quanto mi riguarda, trovo davvero fastidioso la mancanza di schemi UML per i progetti Opensource. Prendi qualcosa come Wordpress, hai solo uno schema di database, nient'altro. Devi aggirare l'api del codice per cercare di ottenere il quadro generale.


3

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.

dal tema: utilizzo di modelli all'interno del processo di sviluppo a http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

un modello può aiutare a visualizzare il mondo in cui funziona il sistema, chiarire le esigenze degli utenti, definire l' architettura del sistema , analizza il codice e assicurati che il tuo codice soddisfi i requisiti.

Si potrebbe anche voler leggere la mia risposta alla seguente post:

come imparare “buon software di progettazione/architettura”? a https://stackoverflow.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489


-1

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


3

Anche se questa discussione è stata a lungo inattiva, ho un paio di punti a mio avviso importanti da aggiungere.

Il codice bacato è una cosa. Lasciato andare alla deriva a valle, gli errori di progettazione possono ottenere molto molto gonfio e brutto davvero. UML, tuttavia, è auto-validante. Con ciò intendo che permettendoti di esplorare i tuoi modelli in più dimensioni matematicamente chiuse e reciprocamente controllabili, genera un design robusto.

UML ha un altro aspetto importante: "parla" direttamente alla nostra capacità più forte, quella di visualizzazione. Se, ad esempio, ITIL V3 (abbastanza facilmente) fosse stato comunicato sotto forma di diagrammi UML, avrebbe potuto essere pubblicato su alcune dozzine di fogli A3. Invece, è venuto fuori in diversi tomi di proporzioni veramente bibliche, generando un intero settore, costi mozzafiato e shock catatonico diffuso.

+1

Hai letto lo standard UML?non ha alcun background matematico e ha persino inconsistenze interne. È anche molto difficile da capire: per esempio, i rettangoli arrotondati sono usati per due cose completamente diverse (stati nelle macchine a stati e azioni e attività nei diagrammi di attività). È terribile. 27 giu. 122012-06-27 20:48:40


-3

No, non lo è. Il codice è la migliore forma di comunicazione. Tutto il resto è per le persone che sono entrate nell'industria sbagliata e hanno deciso di cambiarle per adattarle al loro cervello.

Le interfacce sono di gran lunga superiori ai diagrammi delle classi. I diagrammi dei casi d'uso utilizzano i requisiti utente in un modulo che li distrugge e ti spiega come progettare il prodotto. Diagrammi di flusso dei dati e diagrammi ER complicano il processo di creazione di un database. A volte potresti voler disegnare diagrammi per comunicare il tuo punto, ma non c'è ragione per cui debbano essere diagrammi UML o essere conformi a qualsiasi standard diverso da quello che l'altra persona può capirli.

Alla fine, queste sono tutte forme di documentazione per grandi, inutili, burocratiche società "software" che realizzano prodotti terribili con XML. Cioè, se mai finiscono di documentare. In realtà, la maggior parte dei dipendenti non si preoccupa del proprio lavoro e sta solo aspettando che la persona sopra di loro muoia in modo tale da ottenere una promozione.

+4

Si prega di provare a progettare un'applicazione software mission-critical di grandi dimensioni che deve interfacciarsi con diversi sistemi hardware con requisiti di realtime vicini o completi e affidarsi esclusivamente al codice per fornire la documentazione. Ora prova a gestire un team che mantiene quell'applicazione con 0% di downtime/failure rate. Dì ... sistemi di controllo avionico, software di imaging medicale, ecc. 05 gen. 122012-01-05 15:31:21