Con quale frequenza usi UML formale?

Ho usato MUML ad hoc (linguaggio di modellazione inventato) per progettare e spiegare il sistema abbastanza frequentemente. Sembra simile a UML e tende ad essere abbastanza ben compreso.

Tuttavia, ho avuto un professore o due che si sono scontrati con l'uso di UML rigoroso e formale, il più vicino possibile alle specifiche. Ho sempre sospettato che UML rigoroso non fosse così comune come hanno affermato. Quindi, che ne dici di quanto spesso elabori diagrammi completi che usano tutti i finali di riga, la molteplicità, i simboli del tipo di membro, ecc.?

Mai.

Cavolo, sono passati anni dall'ultima volta che ho creato qualsiasi UML. Gli schemi lineari su lavagne e pezzi di carta non contano.

In effetti, abbiamo appena rimosso l'unica domanda UML dalla guida che usiamo durante le interviste, perché nessuno di noi si preoccupava davvero delle risposte.

Uso abbastanza UML (in termini sia di tipi di diagrammi sia di contenuto delle informazioni nel diagramma) per ottenere il mio punto di vista per consentire a me stesso o a qualcun altro di implementare il sistema o sottosistema. E l'unica ragione per cui utilizzo UML è perché è un set di simboli ampiamente noto che ognuno significa qualcosa di molto specifico, quindi non c'è ambiguità: qualsiasi ingegnere del software dovrebbe essere in grado di guardare il diagramma e capire cosa sto cercando di dire sul sistema.

Ironia della sorte, UML dovrebbe essere flessibile.

Nel mondo reale, non dovrebbe essere un esercizio di pedanteria nel farlo un modo giusto. Si tratta di comunicare e documentare efficacemente un sistema / processo / idea.

Per rispondere alla tua domanda, sono con gli altri. Non ho mai utilizzato UML completo e formale.

Ho usato UML molto regolarmente per circa quattro anni per un prodotto che ha generato tutti (la maggior parte) dei suoi scheletri di codice da Rational Rose.

Negli ultimi cinque anni ci sono state più "scatole e frecce" per lo più inventate sul posto e di solito abbastanza per far passare l'idea generale. UML formalmente corretto solo poche volte durante questo periodo.

Tuttavia, ho avuto un professore o due che si sono scontrati con l'uso di UML rigoroso e formale, il più vicino possibile alle specifiche.

Chiedi al tuo professore quando è stata l'ultima volta che ha usato questo approccio su un sistema reale. Sul serio.

Cerco di essere il più formale possibile quando si tratta di UML, ma solo se / quando ha senso. Gli zeloti su entrambi i lati dello spettro (dai cowboy ai formalisti tesi) non riescono a capirlo.

Ci sono contesti in cui un approccio meno rigido (come quello che usi personalmente) è l'approccio migliore da seguire. Un buon esempio è per piccoli sistemi o modifiche, in cui i requisiti sono piccoli e non completamente definiti; il gruppo responsabile è efficiente ed efficace; è più importante tirarlo fuori che renderlo perfetto. Viene eseguito in modo iterativo e alcune carenze sono accettabili.

O forse ti trovi in ​​una fase in cui stai facendo guestimation e sketch invece di una fase di modellazione formale completa. Questi sono esempi che verrebbero in mente.

Altre volte, è necessario un rigido approccio UML formale. Ad esempio, potresti essere vincolato contrattualmente; hai un numero molto elevato di sviluppatori in più team (possibilmente distribuito); la portata del progetto potrebbe essere tra anni; è un sistema molto grande (compresi componenti software e hardware); il costo del fallimento è elevato, ecc.

Altre volte , è necessario utilizzare qualcos'altro invece / oltre a UML (modelli formali matematici reali come reti di Petri, CSP o logica temporale). Esempio di questo sono sistemi in tempo reale, sistemi in cui i guasti sono catastrofici (dispositivi medici) o dove sei contrattualmente vincolato (.ie. come in Europa durante lo sviluppo di sistemi di trasporto.)

Tutto dipende dalle circostanze e da cosa ci aspettiamo di ottenere da ciascun approccio. Un professore che si attiene al rispetto della formalità è semplicemente essere un fanatico cieco. Il mondo dell'ingegneria non è una dicotomia nero-n-bianco, giusto / sbagliato. È un mondo di compromessi intelligenti.

Se sei abbastanza intelligente da utilizzare un modello informale e informale in un modo efficace e appropriato per svolgere il lavoro, allora così sia. Allo stesso modo, dovresti riconoscere quando NON usare un approccio informale e / o quando NON usare un approccio formale.

Detto questo, devi giocare a orecchi con i professori. Dai loro un osso in modo che ti dia un voto, e se ciò significa infine inchinarsi al loro mantra zelante, va bene. Sai cosa funziona per te e, si spera, saprai quando usare cosa e come nel mondo reale.

Come parte della mia ricerca di dottorato di ricerca, ho studiato il modo in cui i designer esperti utilizzano UML nelle collaborazioni di progettazione (sebbene in contesti artificiali).

Le mie scoperte sono state che le metafore e le notazioni UML sono prese in prestito, ma c'è poca aderenza alla rigidità degli strumenti.

Successivamente, alcuni modelli possono essere trasformati in modo iterativo in UML più rigoroso, spesso quando è coinvolto uno strumento CASE impegnativo ai fini della generazione del codice.

Le solite avvertenze della ricerca accademica si applicano, ovviamente :)

Un collegamento al riassunto della carta e alla stessa carta (se non si dispone dell'accesso ACM) .

A parte questo, consiglio vivamente la "modellazione agile" di Ambler.

Usiamo UML formale per la generazione di codice di un ORM ibernato. La maggior parte delle altre cose sono informali o lavagna bianca. È importante solo per noi con la generazione di codice perché la mancanza di formalità lo spezzerebbe.

Dipende dal settore in cui ti trovi. Se lavori per clienti che richiedono frequenti revisioni tecniche (es. PDR, CDR ecc.) Preferiscono una sorta di standardizzazione piuttosto che sistemi notazionali ad hoc. In particolare il lavoro del governo. Previene errori di comunicazione e la spiegazione iniziale di 15 minuti della notazione che hai inventato.

Inoltre, solo perché stai usando UML non significa che devi dot ogni punto e attraversare ogni t secondo lo standard. Questo è solo se vuoi fare una sorta di generazione / esecuzione del codice automatico. Non conosco nessuno che lo abbia fatto per più di 1 progetto.

D'altra parte, se lavori solo per la tua azienda con un team di sviluppatori, a chi importa quale notazione usi. Tuttavia, se si sceglie lo strumento giusto, può essere un vero risparmio di tempo.

Detto questo, sarà difficile cavarsela in alcuni settori senza essere in grado di progettare utilizzando UML. In altri settori, non lo vedrai mai.

Inoltre, penso che troverai anche una correlazione tra quei settori che richiedono che il progetto sia corretto perché i costi di correzione sono corrispondentemente elevati in quanto utenti pesanti di UML; rispetto alle industrie che i costi delle correzioni del progetto sono poco più che cambiamenti di documentazione / codice in quanto luoghi che UML probabilmente non verrà mai utilizzato.

Per quanto riguarda la domanda originale. La maggior parte delle università tende a orientare la formazione dei propri studenti per le aziende che reclutano i propri studenti più spesso. Se il tuo professore ritiene che UML sia importante, non mi sorprenderebbe che molte delle aziende che reclutano nella tua scuola utilizzino UML. Quindi, dovresti imparare ad usarlo.

Quando ho letto di UML ho provato questo su tutti i problemi che avrei dovuto risolvere nel mio corso C ++. Fortunatamente uno dei primi esempi che ho provato è stato quello di descrivere un elenco collegato.
Non ha funzionato
Detto questo, in combinazione con un buon processo di modellazione UML è utile. Solo perché è nel bene o nel male uno standard.
Mi piacerebbe vedere un linguaggio descrittivo della meta programmazione dei template. Penso che aiuterebbe molto a capire cosa sta succedendo in <<<>>> -land

UML è doloroso se provi anche lo sviluppo Model Driven. Voglio dire che UML è solo una notazione grafica molto utile e tutto il resto è inutile. Non spendo per la modellazione ma uso UML ogni giorno per creare la struttura dei miei progetti. Quello che faccio è disegnare rapidamente un diagramma di base di utilizzo a livelli di requisito, quindi passare immediatamente ai diagrammi di classe. Aggiungo la tracciabilità dei requisiti tra casi d'uso e diagrammi di classe. Il mio diagramma di classe crea anche codice perché è sincronizzato dal vivo. Nessun tag nel codice tutto il modello viene salvato nel modello UML che è mappato al progetto Java.

Creo lo scheletro della mia applicazione con alcuni diagrammi di classe, quindi passo al codice. Una volta terminato il codice, lo unisco al modello. È una specie di iterazione tra codice e modello in cui il codice esegue il modello. Quindi i miei diagrammi di classe mi danno un livello più alto di astrazione e il mio codice mentre il mio codice mi dà l'implementazione della mia logica di business (ad esempio metodi).

La modellazione UML richiede meno di 10 minuti al giorno, il che avviene quando ho bisogno di tempo per pensare a cosa devo sviluppare e come.

UML è fantastico, fantastico e davvero utile, ma lo sviluppo guidato da modelli è inutile !!

Se sto documentando un sistema che abbiamo implementato, allora provo a definirlo con UML formale completo. Ma per il resto del tempo, uso solo quanto è necessario per far passare l'idea. Mi ritrovo anche a utilizzare più DFD rispetto a UML, in quanto sembrano essere più appropriati per i sistemi che stiamo progettando di recente.

Ho appena lasciato il mio college presumibilmente di alto livello (almeno temporaneamente) a causa della loro rigida insistenza su attività di modellazione visiva eccessivamente dispendiose in termini di tempo, faccende di forum, roba di abilità morbide eccessivamente ridondanti che chiunque sia cresciuto attorno ai computer o abbia mai tenuto le mani pensieroso verso un'interfaccia utente andrebbe abbastanza bene che il pensiero di andare in fondo al debito perché indurrebbe a voler rompere le cose in totale frustrazione.

Ho dovuto scegliere tra l'apprendimento di ciò che ho visto richiedere lavori entry-level e di livello junior e quali cerchi CES stabilisce per l'accreditamento ABET dell'università, il che fa sì che i decisori diventino stupidi quando ci sono problemi evidenti con vincoli di tempo e aspettative non realistiche che una valutazione PERT rivelerebbe. L'università non pratica ciò che insegna.

A mio avviso, il processo unificato ha molti meriti, ma l'intera pratica di coniare artefatti visivi, qualunque sia il linguaggio di modellazione è un po 'ridicola. Un documento raffinato in modo iterativo che contiene un elenco di serie, come potrebbe essere prodotto con Word, Workflowy, Evernote, OpenOffice o un elaboratore di testi, è perfettamente in grado di documentare ciò che è richiesto dal processo unificato. Qualcosa su cui questa semplice jane può essere facilmente lavorata da più utenti, controllata dalla versione, e se si scegliesse lo strumento giusto per farlo, un team potrebbe persino lavorarci allo stesso tempo. Questo è molto più semplice di quando UML sembrava una modalità necessaria per unire le orde.