Quanto spesso usi UML formale?

Mai.

Diamine, sono anni che non ho creato alcun UML. I diagrammi delle linee su lavagne bianche e pezzi di carta non contano.

In realtà, abbiamo rimosso la sola domanda UML dalla guida che usiamo durante le interviste, perché a nessuno di noi importava davvero delle risposte.

Uso UML appena sufficiente (in termini sia dei tipi di diagrammi che del 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 il sottosistema. E l'unica ragione per cui uso UML è perché è un insieme 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 pedante nel farlo in modo corretto one . Si tratta di comunicare e documentare efficacemente un sistema / processo / idea.

Per rispondere alla tua domanda, sono con gli altri. Non ho mai utilizzato pienamente 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.

However, I've had a professor or two that harped on the use of strict, formal UML, as close to the spec as possible.

Chiedi al tuo professore quando è stata l'ultima volta che ha usato quell'approccio su un sistema reale. Scherzi a parte.

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 cowboys ai formalisti stremati) non riescono a capirlo.

Esistono 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, dove i requisiti sono piccoli e non completamente definiti; il gruppo responsabile è efficiente ed efficace; è più importante tirarlo fuori che farlo diventare perfetto. È fatto in modo iterativo e alcune deficienze sono accettabili.

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

In altri casi, è necessario un approccio UML formale rigido. Ad esempio, potresti essere vincolato contrattualmente; si dispone di un numero molto elevato di sviluppatori in più team (eventualmente distribuiti); la portata del progetto potrebbe essere in anni; è un sistema molto grande (inclusi componenti software e hardware); il costo del fallimento è alto, ecc.

Altre volte , devi usare qualcos'altro invece / oltre a UML (veri modelli matematici formali come reti di Petri, CSP o logica temporale). Esempio di questo sono i sistemi in tempo reale, sistemi in cui i guasti sono catastrofici (dispositivi medici) o in cui si è vincolati contrattualmente (come in Europa nello sviluppo di sistemi di trasporto).

Tutto dipende dalle circostanze e da ciò che ci aspettiamo di ottenere da ciascun approccio. Un professore che cerca di attenersi alla formalità è semplicemente essere un cieco zelante. Il mondo dell'ingegneria non è una dicotomia black-n-white, giusto / sbagliato. È un mondo di compromessi intelligenti.

Se sei abbastanza intelligente da usare un modello casuale e informale in modo efficace e appropriato per svolgere il lavoro, allora così sia. Per lo stesso motivo, ci si aspetta che tu riconosca quando NON utilizzare un approccio informale e / o quando NON per usarne uno formale.

Detto questo, devi giocare con le orecchie con i professori. Dai loro un osso in modo che ti diano un voto, e se questo significa finalmente inchinarsi al loro mantra di zeloti, 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, ho studiato il modo in cui i designer esperti utilizzano UML nelle collaborazioni di progettazione (anche se in ambienti artificiali).

I miei risultati sono che le metafore e le annotazioni UML sono prese in prestito, ma c'è poca aderenza alla rigidità degli strumenti.

In seguito, alcuni modelli potrebbero essere trasformati iterativamente in UML più rigidi, spesso quando uno strumento CASE impegnativo è coinvolto allo scopo di generare codice.

Si applicano le solite precauzioni della ricerca accademica:)

Un link alla abstract cartaceo e la carta stessa (se non si dispone dell'accesso ACM) .

A parte questo, consiglio vivamente la "Modellazione Agile" di Ambler.

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

Dipende dall'industria in cui ti trovi. Se lavori per clienti che richiedono frequenti revisioni tecniche (ad esempio PDR, CDR ecc.) preferiscono una sorta di standardizzazione piuttosto che sistemi notazionali ad-hoc. In particolare lavori governativi. Previene i problemi di comunicazione e la spiegazione iniziale di 15 minuti della notazione che hai inventato.

Inoltre, solo perché stai usando UML non significa che devi puntare ogni i e incrociare ogni t secondo lo standard. Questo è solo se si vuole fare una sorta di generazione / esecuzione di codice auto. Non conosco nessuno che lo abbia fatto per più di un progetto.

D'altra parte, se lavori solo per la tua azienda con un team di tuoi sviluppatori, allora a chi importa quale notazione utilizzi. Anche se, se scegli lo strumento giusto, può essere un risparmio in tempo reale.

Con tutto ciò che è stato detto, in alcune industrie sarà difficile cavarsela senza poter progettare usando UML. In altri settori, non lo vedrai mai.

Inoltre, penso che troverai anche una correlazione tra quei settori che richiedono che il design sia giusto perché i costi di correzione sono corrispondentemente alti come utenti pesanti di UML; contro le industrie che i costi delle correzioni di progettazione sono poco più che modifiche di documenti / codice come luoghi che probabilmente UML non è mai stato utilizzato.

Riguardo alla domanda originale. La maggior parte delle università tende ad orientare la formazione dei loro studenti per le aziende che reclutano i loro studenti più spesso. Se il professore ritiene che UML sia importante, non mi sorprende che molte delle aziende che reclutano dalla tua scuola utilizzino UML. Quindi, dovresti imparare a usarlo.

Quando ho letto su UML ho provato questo su tutti i problemi che dovevo 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, insieme a un buon processo di modellazione, UML è utile. Solo perché è uno standard migliore o peggiore.
Mi piacerebbe vedere un linguaggio descrittivo della meta programmazione dei modelli. Penso che sarebbe di grande aiuto per 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 base ai livelli richiesti, quindi passare immediatamente ai diagrammi delle classi. Aggiungo la tracciabilità dei requisiti tra i diagrammi Usecase e Class. Il mio diagramma di classe crea anche codice perché è sincronizzato dal vivo. Nessun tag nel codice, tutti i modelli vengono salvati nel modello UML che è mappato sul progetto Java.

Creo lo scheletro della mia applicazione con pochi diagrammi di classe, quindi passa al codice. Una volta completato il codice, lo unisco al modello. È una sorta di iterazione tra codice e modello in cui il codice esegue il modello. Quindi i miei diagrammi di classe mi forniscono un livello più alto di astrazione e il mio codice mentre il mio codice mi dà la mia implementazione della logica di business (ad es. Metodi).

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

UML è fantastico, fantastico e davvero utile, ma lo sviluppo guidato dal modello è inutile !!

Se sto documentando un sistema che abbiamo implementato, allora provo a deporlo con UML completamente formale. Ma per il resto del tempo, uso solo il necessario per far passare l'idea. Inoltre, mi trovo a utilizzare più DFD di UML, in quanto sembrano più appropriati per i sistemi che stiamo progettando ultimamente.

Ho appena abbandonato il mio presunto college di alto livello (almeno temporaneamente) a causa della loro rigida insistenza su attività di modellizzazione visiva eccessivamente dispendiose in termini di tempo, lavori da forum, roba di competenze soft eccessivamente ridondanti che chiunque sia cresciuto intorno ai computer o abbia mai guardato pensieroso verso un'interfaccia utente sarebbe andata abbastanza bene che il pensiero di indebitarsi profondamente avrebbe fatto venir voglia di rompere le cose in completa frustrazione.

Dovevo scegliere tra l'apprendimento di ciò che vedevo impegnativo per i lavori di livello base e junior e quali sono i CES impostati per l'accreditamento ABET dell'università, il che fa sì che i responsabili delle decisioni giochino quando ci sono problemi evidenti con vincoli di tempo e aspettative irrealistiche che una valutazione PERT rivelerebbe. L'università non pratica ciò che insegna.

Secondo me, il processo unificato ha molto valore, ma l'intera pratica di coniare artefatti visivi, che mai il linguaggio di modellazione è un po 'ridicolo. Un documento elaborato in modo iterativo che contiene un elenco seriated, come potrebbe essere prodotto con Word, Workflowy, Evernote, OpenOffice o un word processor è perfettamente in grado di documentare ciò che è richiesto dal processo unificato. Qualcosa di semplice jane può essere facilmente lavorato da più utenti, controllati dalla versione, e se uno ha scelto lo strumento giusto per farlo, una squadra potrebbe persino lavorarci allo stesso tempo. Questo è molto più facile da fare rispetto a quando UML sembrava una modalità necessaria per unire le orde.