So che molti luoghi usano UML e il processo unificato come loro modello di sviluppo ... ma poi ce ne sono molti che non lo fanno. Sarebbe importante avere più di una comprensione di base e funzionale di questi argomenti o sarebbe meglio focalizzarsi sullo sviluppo delle capacità di programmazione in altri settori (ad esempio sviluppo del linguaggio, IDE, ecc.)?
A meno che tu pensi che guardare la vernice asciutta mentre il collo nelle profondità delle acque reflue è un buon momento, ignorare il processo unificato. Aspetta, ignorarlo non è abbastanza. Paura. Per quanto ne so, è usato solo in questi giorni da posti enormi che sono oltre ogni speranza di efficienza, qualità o sanità mentale.
UML, d'altra parte, può essere una notazione utile per importanti concetti di programmazione. Scarica il Distillato UML di Martin Fowler , dagli un tocco e esercitati a disegnare diagrammi mentre pensi al design. È un'abilità che uso regolarmente e sono felice di averlo.
Tieni presente che le persone cercano di sovra-utilizzare UML. La lavagna UML mentre si discute delle cose è fantastica. Un diagramma occasionale nella documentazione pubblicata può essere carino. Ma la ricerca per documentare l'intero codice in UML è inutile e dispendiosa. E il desiderio di "programmare in UML" è idiota. Se incontri persone simili, fuggi. Ma prima, marca le loro fronti con un diagramma di sequenza, così il resto di noi viene opportunamente avvertito.
Non spendere troppo tempo su UML. Nella mia squadra sono l'unico a conoscere molto bene UML e quindi creare casi d'uso, componenti, stati, spiegazioni e altri diagrammi. Gli altri membri del team sono migliori di me per la codifica, ma non per il diagramma UML.
Il trucco che usiamo è di concentrarsi sul diagramma di classe a livello di modellazione per definire la struttura dell'applicazione e anche lasciare che lo sviluppatore / architetto codifichi come vogliono. Quindi uniamo il modello con il nuovo codice e aggiorniamo il modello ad ogni iterazione. Davvero facile e molto efficiente. Sviluppiamo in Java con Omondo EclipseUML.
Raccomando di non usare alcun MDD che è per me una vera schifezza !! Modeler proverà a prendere più energia all'interno del processo di sviluppo, ma questo non creerà alcun valore se provano a generare tutto il codice dal modello. Il codice appartiene allo sviluppatore / architetto ma non al modellatore. UML deve essere solo una vista dei requisiti del progetto (ad es. Usecase, sequenza, ecc ....) del processo (ad esempio stato o diagramma di attivazione), distribuzione (distribuzione, diagrammi dei componenti). Il diagramma delle classi dovrebbe avere una vista del codice e del diagramma delle classi UML solo come visualizzatore del codice. La codifica Java dovrebbe rispettare l'approccio agli oggetti e UML, che è anche una lingua oggetto, è davvero utile per evitare cazzate e codifiche stupide.
Il più importante è l'iterazione del diagramma di classe tra il modello in codice e il codice in modello. Non intendo realmente sincronizzazione live, ma per poter unire codice e modello ad ogni iterazione. Uso Omondo EclipseUML e penso che siano l'unico ad aver unito java, entità database e ID modello. L'unione di ID è davvero un concetto potente ed è perfetto per i nostri progetti agili.
La mia raccomandazione è di non comprare alcun libro. Dovresti avere un approccio ad oggetti e usare il linguaggio del diagramma di classe per visualizzare i tuoi oggetti al fine di creare architetture migliori. Se uno dei membri del team conosce UML, usa gli altri diagrammi, altrimenti il diagramma delle classi sarebbe sufficiente.
Il processo unificato e UML sono un insieme di strumenti strutturati di pensiero e comunicazione. Questi strumenti aiutano in alcuni modi; sia definendo un modo di parlare dei progetti, sia aiutandoci a lavorare attraverso i dettagli e le sfaccettature dei nostri progetti.
Migliorare il tuo modo di pensare è fondamentale per completare i dettagli di un progetto e per trovare il tuo percorso verso un prodotto sano e coerente. Le discipline personali ti aiutano a concentrarti, a tenere traccia dei dettagli, a pensare oltre i bordi e a ricordare che cosa pensi dopo mesi.
Migliorare il modo in cui il design viene discusso e migliorato è fondamentale per far sì che un gruppo di designer si spinga oltre, più velocemente. Le discipline di gruppo aiutano a ottenere di più dal gruppo.
Ma ricorda che UML e il processo unificato sono solo uno dei tanti strumenti per pensare. Sono ragionevoli, ma possono o meno adattarsi a te o al tuo gruppo (che è importante quanto qualsiasi altro fattore).
Nella mia mente ora c'è modo di aggirare UML. Ricevi un libro e imparalo. Ne hai bisogno per:
Il processo unificato credo sia una storia diversa, dipende dal datore di lavoro in cui ti trovi. Vorrei leggere un libro almeno per sapere cosa lo è e quando arriverà il momento in cui ne avrai davvero bisogno, studialo.
Spero che questo aiuti.
Non penso che tu abbia bisogno di una conoscenza estremamente approfondita di UML, ma dovresti sicuramente essere in grado di guardare un diagramma ed essere in grado di dire cosa sta succedendo. Quello che dovresti cercare di ottenere una conoscenza approfondita sono i diversi modelli di design (acquista un libro). Quando trovi i tuoi disegni, ti aiuterà a conoscere sia il modello di progettazione che il pattern UML anche se non lo realizzi. Ti aiuta anche a capire un diagramma UML quando lo vedi, perché potresti capire un po 'meglio perché l'UML sia così.
Sono stato in questo mondo dal 1987 e le uniche volte in cui ho avuto a che fare con UML e il processo unificato sono state alcune occasioni in cui qualche insolito consulente è stato pagato un sacco di soldi per forzare il personale con tutte le minuzie di queste metodologie overhyped, overblown e tendenzioso. All'indomani di ogni tentativo di applicare questa merda non adulterata, abbiamo finito per generare una documentazione quasi immediatamente obsoleta per riempire la Biblioteca del Congresso fino a traboccare e oltre, rallentando allo stesso tempo la progettazione e lo sviluppo dei nostri progetti inconsciamente.
Se il tuo prodotto aziendale deve essere misurato in libbre di carta e / o la dimensione della documentazione, non verrà mai letto più di una volta (se così tante), e per sempre sarà obsoleto, e questa sarà la base su cui sei pagato, quindi con tutti i mezzi, vai intero con questa merda.
Se no, corri urlando per le colline alla prima menzione di UML e UP. O meglio, picchia la prima persona che la pronuncia in poltiglia.
Potresti menzionare che potresti utilizzare U.M.L. SENZA il processo unificato. Io uso molti U.M.L. allo stesso tempo della programmazione, ma per me è importante essere in un modo pratico, non solo usarlo perché "è uno strumento nuovo e shinny".
Diagrammi di classe, casi d'uso e diagrammi sequenziali sono i miei preferiti. Non ho bisogno di usare altri tipi di diagrammi come spesso, come questi.
Molte aziende non utilizzano il processo unificato / razionale.
Leggi altre domande sui tag education uml rational-unified-process