UML 還有用嗎？
在敏捷開發時代，uml還有沒有必要去學習？
據說uml的最高境界是用uml圖直接生成可執行軟體！這個設想實在是太牛了，可能是未來智能語言的方向。其實像ruby on rails已經有點類似的趨勢，如在model里直接一個has_many就解決了一系列問題。圍觀大神回答！
有用的，主要用在設計和分析階段，但是 UML 不適合用來做代碼生成。
從這個問題里，也正好發現了一個有意思的事兒：圖形化的方式傳達信息的能力很強，但是通過圖形化語言去做編程反而很困難。代碼生成或者說技術效率的提升，一直以來靠得其實是 DSL。
UML 有幾種圖
UML 有幾種圖？第一反應是不是類圖？其實，還有用例圖、順序圖、活動圖、狀態圖、組件圖等。這裡提到的每一種圖，都代表著工程的一個特定維度，它們的專註點是正交的，都有其獨特的用處。使用 UML 來分析和設計，可以讓大家對整個系統有個更全面的認知。
用例圖
拿用例圖來說，它衡量的是 1) 系統內部的功能結構 2) 外部系統和用戶的對接關係。
「和外部系統對接」，這是整個工程中最薄弱的環節，就好比汽車各系統零部件之間的結合處，非常脆弱而且容易磨損老化。外部系統對接的複雜程度是衡量工程風險和工作量的一項重要指標，如果沒有用例圖這樣的工具和針對外部系統對接關係進行分析的意識，那後期會有很多坑。
你是不是只熟悉類圖
UML 初學者最容易犯的錯誤就是太在意類圖，卻忽略其他。類圖是一種「靜態」設計，像順序圖、協作圖、活動圖則是對系統的一種「動態」設計，體現的是二進位世界中的實際場景。我們經常使用順序圖來設計、分析關鍵流程，有哪些模塊參與，分別承擔什麼責任，彼此之間如何調用。活動圖通常被人拿來描述複雜的業務流程。
狀態圖，狀態圖的用處就廣泛了，常用來分析組件的生命周期，而且用途不僅僅局限在敲代碼：PM 可以拿它來設計頁面跳轉邏輯，Growth Hacker 可以拿它設計和分析用戶轉化模型，工程師可以用它來吊打邏輯不清晰的產品經理。
最後，附上一張 Android MediaPlayer 的狀態圖，相信很多 Android 工程師都比較眼熟吧 
厘米腳印-小而美的互聯網諮詢公司，致力於用技術創新提升效率的 geek 團隊，提供互聯網產品諮詢和研發服務，訪問 http://limijiaoyin.com了解更多。
UML應該落在建模，不管是最本質的業務建模還是系統建模。
非要糾結於它是不是一種可以自動生成的代碼語言。
本末倒置了吧。
當然沒有用。UML是一門反人類的建模語言。妄圖把OOD過程中建模的圖形進行標準化。然而設計者設計出的圖形和規範文檔晦澀複雜，充滿二義性，無法作為有效交流的圖形（這個比較有意思，所謂一圖勝千言的圖表達的意思要用一大段「規範」才能隱式地描述得「不清不楚」，注意是「不清不楚」，不是「清楚」。這種圖怎麼能保證書寫方和閱讀方的理解一致？）。不同版本的UML還相互打臉（規範的晦澀，不清不楚，打臉的實際例子：UML association class）。UML中的部分圖形經過適當簡化變形可以在設計階段使用（例如狀態圖，順序圖等）。但是其實然並卵，我們自己拍腦袋上手就畫的圖跟這些圖差不多，用於溝通的話，標準化這些圖完全沒有任何意義。作為一個建模階段有效交流（或者理清思路）的圖片，看第一眼就不怎麼看得懂的都是耍流氓。用於自動生成代碼的話，UML沒有定義圖形內容的存儲格式(後來開始定義了但是沒被廣泛接受DD 1.1)，完全做不到統一，更不用說生成代碼的可讀性和可靠性。
鼓吹UML的就是給你戴緊箍咒的唐僧。而你跟孫悟空的區別是他戴了緊箍咒能去西天取經而你戴了後能去西天。
更多參考：如何反駁 UML 無用論？ - 陳吉的回答小產品一枚，正好這兩天被領導逼著畫了次狀態圖，拿了本UML書，看狀態圖規範，修改了5次，達到了領導滿意的效果。
用這玩意畫完後，第一次覺得，整個產品流程，狀態邏輯在我腦子裡是異樣的清晰，有種發現新大陸的感覺。
so我的結論是，用UML幹嘛很重要，於我可以用它來完善產品邏輯，數據邏輯。對於UML其它高大上的功能和用途，我暫時並用不著，用到在學。
畫圖理清思路， 怎麼就沒用了 ？
利用 Open-source tool that uses simple textual descriptions to draw UML diagrams. + Markdown +markdown preview enhance ( @Yiyi Wang ) + Vscode | atom 做做代碼閱讀筆記之類的 還是蠻好用的 反正比平常寫文檔用 Viso 是好用很多。
至於語法等的學習成本 幾乎為0 ， 要用的時候打開個網頁 看下就成。
10年前UML這玩意很火，那時候真是裝B利器啊，IBM Rapsody那叫一個貴，界面極其複雜，但機子裡面不裝一個你都不敢出去裝架構師。那些個懷裡揣著IBM證書的「架構師」，胡扯起來一套一套的，特別「企業級」。。。
現在大家都知道了，在IT界，騙人的東西是活不長的。說不客氣點，那些專門搞UML的（出書的，搞教育的，等等），全TM是一群江湖騙子。
UML十年前我也學過。這根本就是一門忽悠的技術。一般的技術吧，學起來用起來都是腳踏實地，寫一個hello world，例子程序跑起來，代碼一點點寫起來，然後是框架、應用，複雜度一點點往上加。UML可不是那麼回事。各種各樣複雜花哨的圖給你一大堆，但實踐是沒有的，也實踐不了。那些搞UML的「大牛」，你看他論壇上發的帖子，好傢夥，談起UML洋洋洒洒一大套，說完跟沒說一樣。
我問你，UML, rhapsody, 這套玩意現在在主流領域誰用了？前端？後段？中間件？移動開發？遊戲開發？移動遊戲開發？UML在哪裡？最多就是敏捷開發的時候在白板上畫幾個方塊做交流用吧？那些號稱用UML就能生成代碼的軟體在哪個領域普及了？你別告訴我哪個角落裡哪個狗都不知道的破單片機上有人用UML成功建模寫軟體了。拜託。
UML說不懂也不行，看兩下，知道類圖和流程圖怎麼畫，能做到在團隊中白版交流，就可以了。至於那些細節，不了解無所謂，沒有哪個做正事的程序員會鳥這些。代碼才是最重要的。顯而易見的事實，無需說三遍。為什麼寫這篇？
我想設計一個安卓，iOS或者Web應用的時候，開始做軟體的步驟是什麼，有個想法，做個需求分析，然後開始設計軟體。這篇講的是設計軟體這一步。我想好了要做個什麼，然後開始幹了，不能擼起袖子開始一個介面一個介面寫，一個界面一個界面開工。該怎麼做一個整個項目的設計圖呢？這篇主要想解決的是蓋樓如何有個基本圖紙。
為什麼建築師要畫圖紙？
UML是當時上大三的時候的一門課，印象比較深，這是一門選修，沒幾個人交作業，讓花一打UML圖，沒幾個人交作業。為什麼沒幾個人交作業呢？大部分人對於為什麼要花UML圖沒什麼概念，如同讓不蓋樓的人去畫一份圖紙。為什麼建築師要畫圖紙是一個好問題，因為人人可以摞起石頭卻不能蓋起摩天大樓。UML圖是成千上萬的工程師積累蓋樓的經驗總結的圖紙。首先我需要蓋一座大樓，所以我需要畫一份圖紙。大部分人停留在摞石頭的狀態所以自然畫不好幾張UML圖。當自己需要設計一個自己的軟體的時候，自然需要這麼一份圖紙。
有其形無其實，有其實無其形
當時印象比較深，時常很糾結UML該用那個箭頭，用圓的還是用方塊。其實這個東西感覺也不用那麼糾結，能背下來那麼一套複雜的標準自然好，在幾百人合作的項目中可能確實需要這種規範，但是小項目可能並不用那麼精細，能符合固然好，不能那麼細緻也是可以接受的，不要太拘泥於此細節。就和倚天屠龍記裡面，張三丰問張無忌忘了嗎，很多事情在於有其實無其形，如果生搬硬套全把精力花費在用那個三角方塊上可能反而背離了初衷有其形而無其實。下面寫的是一個思路，其實需要了就花畫不需要也可以不畫。UML其實從另一個方面告訴我們如何開始設計自己的軟體。
五個大部分
用例圖
用例圖是核心，為什麼用例圖最重要，用例圖是用戶的使用過程，哪怕你懶到一定地步後面的圖都不花也應該花一張這個。你一定要用這張圖描述明白，誰幹了什麼，第一步是什麼，第二步是什麼。你做這個東西要解決一個什麼問題。Use case View:對系統用例進行描述，典型的視圖為用例視圖(use case diagram)。
靜態圖
這部分主要描述靜態的關係，對象圖，類圖，這個講的是開發過程中的抽象。Logic View:對系統各個組成部分進行抽象描述，其焦點在於系統是如何構成的以及構成系統的各個部分之間是如何互動的。我們常用的類視圖(class digram)，對象圖(object diagram)，順序圖(sequence diagram)/通信圖(communication diagram)都屬於Logic View。
動態圖
描述的是各種狀態。Process View:描述系統中的各種活動，典型的視圖為活動圖(activity diagram)。個人認為活動圖和流程圖非常類似，且目的都是為了將系統中的活動描述清楚。
部署圖
這個有利於自己部署好這個系統，從0.1到1.0到2.0如果進行部署。這塊可以寫清楚如何部署，是直接部署，部署在幾個機器上部署，用虛擬機，還是docker，如何理清楚部署過程進行自動構建。Development View:從開發者的角度描述系統的構成，典型的視圖為構件視圖(component diagram)。
物理圖
Physical View:該視圖關注軟體構件在硬體上的top結構，以及構件之間的通信。典型的視圖為部署視圖(deployment diagram)
UML不過是一種方法論而已，簡單說跟特么勵志書一樣道理人人都懂，但是IBM的目的其實是賣Rose，然後再賣db2，然後再賣web死菲兒，然後再賣AIX，然後再賣機器，然後都賣給聯想了......
單純的分「有用」還是「沒用」，很容易陷入二元論的爭論，UML既不可能包打天下，也不可能是一無是處，我的看法是「有用，但不是很有用」。UML全稱是Unified Modeling Language，注意這裡的重點是「Language」，也就是說和英語漢語是一樣的，只是一個表達的語言，UML是表達模型的語言而已。你會說中文，但並不意味你就會寫小說，UML也是類似，你掌握了UML的各種圖和細節，並不代表你就會建模了。所以，使用UML的關鍵其實還是「建模能力」，一個蹩腳和不合理的模型，UML一樣可以表示。
通過UML生成代碼早在十年前Rose就可以做了......，UML有用，需要足夠的面向對象的經驗才能用得順手。
謝邀。
在大公司做過SE，SA，對這個問題應該應該比較有發言權。
先說結論:
UML圖及其相關的整體開發流程已經過時了。現在是敏捷開發的時代，重型的開發方法已經不流行。
但是有些UML圖在設計時還是會用，比如我會使用use case和時序圖，單純只是用來理清思路用的。UML當然有用。
在項目介紹的時候ppt里放上UML圖，人家一看你這就是個靠譜的項目。如果畫的圖不好看，老闆們就會說：「你看看你一點都不專業，畫個圖都只會用方框。」"uml的最高境界是用uml圖直接生成可執行軟體"這個已經實現了，例如用帶有設計級調試和強大代碼生成能力的Rational Rhapsody開發實時嵌入系統。軟體開發的歷史就是源代碼（也就是人腦需要編輯的介質）的形式一直在升級的歷史，從最初的機器語言到彙編語言、過程式高級語言到現在流行的面向對象語言。「模型就是源代碼」不是可不可能的問題，而是合不合算的問題。真實世界中，涉眾對許多系統的質量要求並不高，電商網站、銀行系統出個故障，人們習以為常，能夠接受，反正出了故障再恢復唄。這樣的系統，充分的建模沒有必要性。同時，也沒有可能性，因為類太多，工期不允許為每個類畫狀態機。這類系統，只需要對關鍵的類充分建模。如果做一個心臟起搏器，對質量要求非常高，通過充分的建模儘可能減少人工編碼導致的偶發錯誤是必要的，而且也是可能的，因為類的個數少。但是，UML的最重要的意義不在於生成代碼，而在於前面的工作流！
我從2002年開始專門從事研究和推廣UML的工作，在為軟體組織提供UML相關需求和設計技能服務時，經常會發現軟體開發人員對UML建模存在種種誤解。我歸納了最典型的八個誤解加以剖析。
誤解一：UML是開發團隊用來和客戶溝通的UML模型是開發團隊內部高效溝通的手段，但不是用來和涉眾溝通的。拿音樂中的五線譜類比，五線譜是音樂專業人士交流的工具，作曲要懂、編曲要懂、樂手要懂、指揮要懂、歌手要懂（注意：是懂五線譜，不是人人都要用五線譜作曲），但聽音樂的人不需要懂。UML只是在「軟體開發人員」圈子裡面的統一表示法，強迫開發人員思考，改善開發人員的交流，表達軟體開發的模型。
另外，「和客戶溝通」的說法本身就有問題，因為「客戶」不是一個人，而是一個組織，裡面有不同角色和崗位的「涉眾」。他們的學歷職位有高有低，年齡有大有小，關注的利益更是各自不同，所以，和涉眾交流的介質不是模型本身，而是模型的各種視圖。面對大領導，我們可以給他放幻燈片交流願景；中層幹部喜歡看文檔，我們可以按照他喜歡的格式給他炮製文檔；一線操作工只關心他那一小塊工作，我們可以製作界面原型和他交流；有時候甚至有的涉眾根本不喜歡看任何東西，我們還可以通過「談話」這種視圖和他交流。涉眾連談話都不樂意，我們也可以通過觀察來獲取素材。許多偉大的創新需求正是有心人在涉眾不作聲的情況下，觀察涉眾的行為得到的。
涉眾能提供的只是需求的素材，沒有資格也沒有責任直接提供需求。軟體需求不是由涉眾直接提供的，而是由需求工程師綜合不同涉眾的利益決定。就像電影劇本一樣，劇本不是由觀眾直接提供的，而是由編劇根據不同觀眾的口味編出來的。
如果不了解這個區分，直接拿UML模型去和涉眾交流，很容易導致「四不像」。不少開發團隊十年如一日沒有進步和積累，「交流影響開發」是原因之一。為了遷就不同涉眾的知識水平，開發團隊只好損害模型的嚴謹性，即使是這樣，涉眾也不一定接受，交流效果還是不好，而且還會因為涉眾的交流形式多變而影響開發團隊核心工作流的穩定─——雙方都受害。客戶的領導說，我不習慣看UML模型，就知道以前看的是××標準格式的文檔，我只在這個格式的文檔上簽字，難道我們就不用UML建模了？下一個項目的客戶領導喜歡另一種格式怎麼辦？下下個項目根本不需要簽字怎麼辦？互聯網網站沒有「客戶領導」簽字確認需求怎麼辦？建模的目的是幫開發團隊思考，它可以指引開發團隊發現到底需要向涉眾了解什麼，但不是直接拿著模型和涉眾交流。
開發人員有意無意把建模的目的理解成和涉眾交流，有時背後的思想還是「懶」字，因為這樣想，就有了推卸責任的機會：不是我不想建模，就算我建模了，客戶不想看啊。
誤解二：UML是Rational公司的，Rose是最好的UML工具說到UML，很多人會想到最開始推動UML誕生的「三友」：Grady Booch、James Rumbaugh和Ivar Jacobson。在早期，「三友」的貢獻是最大的。接下來，UML標準的管理和推動主要由OMG（對象管理組織）負責，OMG的成員是各大軟體企業，包括IBM、Microsoft、Oracle、Lockheed Martin等。
在OMG的推動下，UML被越來越多的標準組織採納。2005年開始，UML被ISO接納為標準。和UML 2.4.1對應的標準是ISO/IEC 19505-1:2012和ISO/IEC 19505-2:2012。2011年，中華人民共和國發布了統一建模語言國家標準GB/T28174。行業標準組織如醫療衛生信息化的標準組織HL7、IT管理標準化組織DMTF、美國國防部等，也使用UML來描述它們的標準。
UML誕生初期，最流行工具確實是Rational Rose，甚至有些人會把Rose和UML混為一談。2002年Rational被IBM收購以後，名稱變為Rational Software Architect（簡稱RSA），這意味著如果現在您還使用Rose，那是在用十多年前的工具。
因為UML標準是開放的，所以各廠商可以根據標準開發自己的UML工具，工具之間還可以通過XML交換模型。根據UMLChina的統計，UML相關工具最多時達168種，經過市場的洗禮，現在還在更新的還有近百種。
論功能的強大，RSA仍然是第一位的，不過個頭很大、價格昂貴。近年來，Enterprise Architect（簡稱EA）逐漸成為大多數開發人員學習建模的首選工具。EA的使用風格和以前的Rose接近，個頭又不大，很方便開發人員自行安裝學習，價格也適中，堪稱性價比最好的工具。
實時系統開發方面，Rational Rhapsody是目前最好的工具，可以在類圖、狀態圖層面上做設計級調試，生成各RTOS下可直接運行的代碼。
如果不想花錢購買工具，還有大量的免費、開源或在線工具可以選擇，可以參見UMLChina網站上的「UML工具大全」頁面，鏈接是UML相關工具一覽（截止2014年8月）。
誤解三：許多開源軟體沒有用UML建模許多流行起來的開源項目（Linux、Apache、MySQL...）確實沒有使用UML建模，但是這些項目的核心領域多為基礎設施領域。基礎設施領域的"負載"（需要依賴的領域的數量）比較低，只需關注計算機的資源，不需關注醫院、稅務、物流....。因為負載低，基礎設施級別的分解和復用相對容易，而且基礎設施領域有大量的教材和先行例子，程序員在學校里已經受過這方面的教育，大腦比較容易把握基礎設施領域問題的複雜性，所以對顯式建模的要求沒有那麼高。
很多能夠帶來利潤的系統"負載"比較高，除了核心領域（如醫院）的知識，還要依賴於其他非核心域的知識，而且，核心域並沒有那麼多人去研究。很少有類似這樣的書，把一家醫院的流程，各種業務對象之間的關係，用某種方法（彩色UML建模也好，以前的數據流圖＋ER圖也好）研究得透透的。要在市場上獲得競爭優勢，有必要把復用的級別提升到核心域的復用（因為其他的好處，競爭對手也能獲得），這確實很難，但再難也要做。這時，建模技能就必不可少了。
在這方面，不少媒體有誤導。媒體會訪問某些「知名程序員」對建模的看法，得到的回答可能是「對我來說不重要」。這裡面的原因是：基礎設施領域的程序員更容易得到媒體青睞成為「知名程序員」，因為「晶元」、「操作系統」等辭彙上的光環會把媒體晃暈。更不客氣地說，其中一些「知名程序員」實際上僅僅是「玩家」，不了解開發帶來利潤的軟體需要付出的辛勞。
和我們生活工作密切相關的軟體，媒體關注得太少。一名白領，早上起來用微波爐熱牛奶，開電視看新聞，坐電梯下樓，刷卡坐地鐵，手機看微博，打卡進公司，用公司的業務系統工作。上面這句話中涉及到至少七個系統，其中估計只有微博的開發人員能登上媒體的版面。你知道微波爐的軟體是誰寫的嗎？大多數開發人員做的軟體和「知名程序員」不一樣，讓「知名程序員」來做這些軟體，也未必做得來。Linus能做好一個醫院信息系統嗎？
誤解四：UML模型是源代碼的概要表現形式持這樣看法的開發人員，應該對軟體開發的工作流沒有概念，軟體開發工作流以及推薦使用的UML元素如下圖：
工作流
思考焦點
可選UML元素
推薦UML元素
業務建模
組織內系統之間
用例圖、類圖、序列圖、活動圖
用例圖、類圖、序列圖
需求
系統邊界
用例圖、序列圖、狀態機圖、活動圖、文本
用例圖、文本
分析
系統內核心域
類圖、序列圖、狀態機圖、活動圖、通信圖、包圖
類圖、序列圖、（狀態機圖）
設計
系統內各域之間
類圖、序列圖、狀態機圖、活動圖、通信圖、組件圖、部署圖、時間圖、組合結構圖、包圖
不畫，代碼即設計
圖1 各工作流以及推薦的UML元素
源代碼（開發人員最終需要編輯的介質）能夠表達的只是"設計"工作流的內容，所謂「代碼就是設計」。UML模型的重點是表達前面三個工作流的內容。雖然最後目的是要得到代碼，但沒有前面幾個工作流的正確的推導，正確的代碼不會從天上掉下來。
一些書籍、文章、博客大談「編碼的藝術」，很多也屬於概念不清，文中探討的根本不是編碼的技能，而是分析技能甚至是業務建模技能。編碼確實有編碼的技能，但到了編碼時還在思考訂單和商品、發票的關係是什麼，相當於護士已經把注射器拿在手裡了，還在思考病人可能是什麼病，開什麼葯。
這種認為「UML模型是代碼的概要形式」的誤解不止「普通」的開發人員會有，一些著名的UML書籍作者也有。Martin Fowler所著的UML暢銷書《UML精粹》，認為UML有三種用法：草稿、藍圖和編程語言，也是僅從編碼的角度來說的。從Fowler寫作的其他書籍《重構》、《企業應用架構模式》、《分析模式》等可以知道，他的研究工作集中在分析設計工作流，特別是設計工作流，不了解他在業務建模和需求方面有多少研究。
誤解五：UML建模和迭代開發衝突有的開發團隊以「敏捷」為名，放棄了建模技能的學習，借口是「反正一開始不可能把所有東西都想明白，先做做看吧！」。「先做做看」和建模並不矛盾，不能把「敏捷」、「迭代」當作偷懶的庇護所。
一名從護士成長起來的醫生，只掌握了打針的技能，卻缺少檢查、診斷、擬治療方案等技能，索性說：「唉，反正再高明的大夫，也不能一個療程把病人治好，乾脆我也別花那麼多心思了，先隨便給病人打一針看看吧，不好再來！「迭代」只是一個底線，確實，再高明的大夫也沒有把握一個療程就治好病人，但是檢查、診斷等技能越精湛，所需要的療程就越少。
光喊口號「先做最重要的需求」是沒用的，你知道哪些需求最重要嗎？掌握業務建模技能，能幫助你準確定位最重要的需求。光喊口號「分離變化」是沒用的，你知道哪些容易變，哪些不容易變嗎？掌握分析設計技能，能讓你看到變和不變的部分。
唱曲的名家，唱到極快之處，吐字依然乾淨利落；快節奏的現代足球，職業球員的一招一式依然清清楚楚；即時戰略遊戲高手要在極短時間內完成多次操作，動作依然井然有序。在激烈競爭的年代需要快速應變，掌握技能才能真敏捷。世上無易事，偷懶要不得。
剛入行的開發人員體會不到建模的重要性，是正常的。就像下象棋，初學者面對單車對馬雙士、單馬對單士等已經有共識的局面還需要思考良久，最終還拿不下來甚至輸掉。這時中局和布局的書在他看來多半是枯燥無味的，還不如把一本實用殘局彙編看熟了，學到一些奇技淫巧，也能在菜市場贏幾盤棋。不過，要邁向職業棋手的境界，參加更殘酷的競爭，就體會到中局和布局的重要了。
誤解六：能否給我一個完整的UML案例？經常有這樣的問題「能不能給一個案例，完完整整地實施了整套UML？」這是一種誤解，這樣的案例不應該有。可以把UML看作一個完備的工具箱，裡面各種工具都有。您只需要從這個工具箱中選擇適合您的項目類型的工具用上就可以，並不需要「完整地」使用UML。不只是UML，對編程語言也一樣的。很多人說「我用Java」，其實只是用Java的一小部分，而且很長時間內只用這一小部分就夠了。
即使針對你的項目類型，挑選出了一些適用的UML元素，也不提倡一次性都用到下一個項目中，而應該找出最值得改進的工作流，一點點引進。
例如，一個工期比較緊迫的管理信息系統，業務建模和需求工作流就很重要，畢竟這個項目不滿足客戶的要求，後面的生意也就沒了，而分析設計就沒那麼重要，因為先不用考慮復用和擴展的問題，那麼，可以只在關鍵的業務流程做業務建模，在關鍵的用例認真定義需求，然後按照熟悉的套路開發。需要引進的UML元素可能有：業務序列圖、系統用例圖、系統用例規約。
反之，如果做一個醫療設備，需求可能容易獲得，但是對系統的質量要求非常高，不允許出任何錯誤，這時，前面的業務建模、需求工作流可以不改進，把分析設計工作流作為改進重點。需要引進的UML元素可能有：類圖、狀態機圖、序列圖。
如果開發團隊能夠最終改進到覆蓋所有工作流，自然是件好事，但是大多數項目來說，點狀的逐步改進更符合實際情況。UML如何完整應用在業務建模、需求、分析、設計工作流，這些年以來已經有不少圍繞案例講解的書籍。閱讀之後也不要一次性照搬，還是要慢慢來。一些工具廠商出於展示其工具建模能力的目的，在建模工具自帶的案例模型中，把所有的UML圖都給用上了，這也要注意辨別，不可當真。
誤解七：大師們不寫UML書了最開始一批UML書籍，基本上是方法學家所寫。最近幾年，以「UML」為題的新書大多為高校教材或普及性教材。這並不是說UML已經不重要，而是沒有必要再去強調，焦點不再是「要不要UML」，而是如何把UML建模高效應用到軟體開發各工作流中。
下圖是http://amazon.cn上搜索的最近三個月出版的UML書籍結果。
圖2 國內最近幾個月出版的帶「UML」書名的書籍（摘自http://amazon.cn搜索結果）
更深入討論需求和設計技能的書，雖然裡面使用的表示法也是UML，但作者更喜歡起不帶UML的書名。
UML也已經走入國內各高校甚至高職校園，當然，課程名稱不一定叫「UML」，而是冠以「面向對象分析設計」之類的名字。下圖是我從各學校官網上摘錄的信息
學校
院系
課程名稱
北京大學
信息科學技術學院
軟體建模理論與UML
軟體與微電子學院
面向對象技術
軟體需求工程
清華大學
信息科學技術學院
面向對象技術與應用
軟體學院
軟體體系結構
軟體需求工程
經管學院
面向對象的分析設計方法
復旦大學
信息學院
UML和面向對象設計模式
……
……
……
天津大學
計算機科學與技術學院
統一建模語言
……
……
……
湖南科技學院
UML與軟體建模
……
……
……
圖3 國內各高校開設UML相關課程情況
誤解八：UML之前被宣傳得天花亂墜一些批評UML的文章中，會有類似的說法。其實UML建模的研究者大多比較嚴謹，有哪一篇UML論文把UML說得"天花亂墜"？「大師說得天花亂墜」是無知之人編造出來的謠言，先編造謠言，再攻擊謠言。
被宣傳得「天花亂墜」反倒是一些偽敏捷宣傳，因為需要吸引涉世未深的年輕人和媒體人士，讓他們認為世界上有容易做的事情，有免費的午餐，所以用語比較激情澎湃，例如「無敵」、「硝煙」、「武士」、「顛覆」、「勇敢」等。相比之下，建模顯得太過嚴肅了。
一些參考：
我寫的《軟體方法》書：《軟體方法》
我的UML建模答疑記錄：軟體需求和設計答疑
UML is cheap , show me your code
另外，悄悄告訴大家一個秘密吧。
那些不寫代碼的管理層碼農，如果沒有uml圖或者類似uml的東西，
你讓他們怎麼推進項目……
UML 還有用嗎？
UML 的主要作用和價值是用於 OOAD（面向對象分析與設計）中的圖形建模。如果 OOA、OOD 沒用了，自然 UML 就沒用了。可問題是 OOAD 會變得沒用嗎？
OOAD 在中國有真正的火熱過嗎？好像還沒有。
所以，UML 今後會越來越有用，至少看好到 2030 年。
在敏捷開發時代，uml還有沒有必要去學習？
答案是肯定的。在敏捷 2.0（Agile 2）時代，非常有必要學習 UML。UML 建模的本質其實是非常敏捷的，是敏捷軟體設計、敏捷建模的核心技術之一。
敏捷 1.0 時代，為什麼大家會覺得 UML 沒用？主要是受到了極限派和部分媒體、社區的影響，極限編程具有反 UML、反 Use Case 的傾向。但這是不對的，例如極限派領袖（極限派中的溫和派）Martin Fowler 大師就是支持 UML 建模的，另外支持 UML 敏捷建模的還有 Scott Ambler、Craig Larman 等敏捷大師。
。。。反正我不怎麼用了。。。
uml是用來治需求，設計，開發人員張嘴胡說的良藥
目前看來斃大於利
UML作為任何OO圖書的必講內容, 極大的增加了學習OO的負擔, 當你在學習設計模式時, 會發現自己經常糾結箭頭方向, 代表含義等內容, 當你查手冊終於搞清楚時, 你會發現自己處於兩個狀態:
- 終於把圖看懂了, 今天就到這裡吧, 明天再看---&> 無限循環
- 終於把圖看懂了, 這個設計模式我已經學會了---&> 其實你還沒有開始呢.
UML 作為一個更高層次的抽象, 並沒有給初學者帶來任何益處.
ProcessOn - 免費在線作圖，實時協作我一般都用這個在線工具來做架構圖，流程圖等等...挺方便的..但是只是圖， 如果要生成語音或者更複雜的功能， 還的用專業的工具。ProcessOn一般圖形都夠用了.
推薦閱讀：
※關於內存地址和顯存地址？
※C 語言是學編程的基礎嗎？
※在編程過程中boolean變數一般怎麼命名？
※計算機系的學生應該考什麼證？
※如何從學術原型代碼拓展成工業級別代碼？