UML 在業界的使用情況如何？

01-16

歡迎大家說說各自的廠里的使用情況（希望點出名字）~ 具體的有說服力的數據！
注意此題僅僅是問在業界的使用情況，在此題宣傳UML有多好是完全離題的。（比如下面某個答案被認為是對本題沒有價值的：認真看就會發現都是「道理論證」，連比喻都用上了，但沒有任何具體的有說服力的數據和實際的例子，大量所謂的「有的人」，「很多人」，「我們的客戶」，最後丟出了一篇為UML傳教的文章順便還做了個廣告; 而另外一個回答里舉出 Microsoft 和 Adobe、Nortel 的情況則是真的是在說明UML在業界的使用情況，然後對Understanding the Linux Kernel的圖的肯定和UML的批評具有一定的啟發性，這樣的回答是符合題意的）
同時本題沒有詢問「建模」在業界的情況，而是「UML」這種工具在業界的使用情況。（不要在回答里論述建模有多重要之類的）

騰訊沒有統一、從上而下的軟體工程方法論，畢竟業務差異很大。但在各種文檔及簡報中也經常以 UML 圖來呈現一些信息，算是一種輔助溝通的方法。

例如某些子模塊的架構以類圖表示，有時候會用於重構工作的前後對比。另外常見的是用順序圖展示一些比較複雜的分散式系統協議。

我在面試時會讓候選人做一些簡單設計，用 UML 最好，不會的也可用他熟悉的編程語言表示。

UML 在業界沒有用處。我接觸過 Microsoft 和 Adobe 的工作環境，在 Nortel 用過 UML（但是不代表它有用處）。至於最近，經常和 Google 與 Facebook 的接觸，也基本不用 UML。如果有人覺得 UML 有用，可能他的「業界」跟我的不一樣。

拿《 Understanding the Linux Kernel 》這本書來說，裡面一個 UML 都沒有用到，但是裡面的圖對任何人設計軟體都會很有啟發。

另外，UML 的 class diagram 和 sequence diagram 和大多數人討論軟體設計的時候隨手畫的草圖很接近。但是標準化這樣的草圖付出的資源完全不值得。而後來走火入魔的標準化什麼 deploy diagram 就完全是脫離實踐的東西了。

建模很重要，diagram 很重要。但是，用來交流的 diagram 應該是：1. 不能完全脫離文字；2. 在附帶少量文字的基礎上做到 self-evident。UML 定義標準圖形完全是自己製造問題。

至於某些張口閉口「扯淡」的人，他的業界和 Microsoft, Google, Facebook, Adobe 都不一樣，也不用強求。拿 Nortel 破產說事有什麼用呢？根本沒搞清楚邏輯。我是在說只有 Nortel 多多少少還用一些 UML，其它過的滋潤的公司都懶得用。至於是不是因為用 UML 用到破產就不知道了。至於貼的幾個新聞，都是 Microsoft 所謂「擁抱」UML，只能說 Microsoft 這些年走的是上坡還是下坡大家都在看。至於利益相關，我和我接觸的人都是為了做軟體，某些人似乎像個神棍公司賣 UML。

對於對 UML 還抱有感情的各位，我必須坦白，我腦海里冒出來的就是「shit work」這個概念：

Don"t Give Your Users Shit Work

本來用自然的描述和靈活的圖表就能解決的問題，非要向著一個過時的標準去靠攏。然後說：

Boy, I spent an hour doing this. I really accomplished a lot today!
—— You didn"t.You did shit work。

UML在軟體設計中至關重要

圖型的表達能力遠勝於文字 ;

統一的圖示法更有助交流；

如果建築、機械等領域沒有工程三視圖，我想像不出將是怎樣的結果。而uml 正在軟體領域起到相同的作用。UML的使用成效與軟體系統的規模、參與者多少、周期和質量成正比。

看下我自己畫幾張圖：

用活動圖來表示流程：

使用組件圖表達邏輯架構

使用時序圖表達調用關係

如果沒有UML,我不知道有什麼更好的方法，可以使用讓我團隊的小夥伴，快速、一致的理解上述的信息

我曾經在雅虎中國、數字公司及現在的創業公司都在推薦使用UML

UML 與 RUP 沒有什麼關係。

UML 與繪圖的工具沒有什麼關係。

我推薦學習使用UML。

----------------------------------------------------------------------

如何有效討論問題 - 左撰 - 知乎專欄

即使狂奔，也要優雅 - 左撰 - 知乎專欄

如何提高團隊管理能力？ - 左文建的回答

從大公司離職去小公司當 CTO 是一種怎樣的體驗？ - 左文建的回答

答題前先對幾位知友的回答作點評論。

非常贊同阿姨幫 CTO @左文建的回答！我們的觀點不謀而合：

UML在軟體設計中至關重要
圖型的表達能力遠勝於文字 ;
統一的圖示法更有助交流；
如果建築、機械等領域沒有工程三視圖，我想像不出將是怎樣的結果。而uml 正在軟體領域起到相同的作用。UML的使用成效與軟體系統的規模、參與者多少、周期和質量成正比。
...
如果沒有UML,我不知道有什麼更好的方法，可以使用讓我團隊的小夥伴，快速、一致的理解上述的信息

我曾經在雅虎中國、數字公司及現在的創業公司都在推薦使用UML

關於圖形優於文字的表達力還有一個俗語叫：一圖勝千言（A picture is worth a thousand words），對此人們在日常的生活工作中應該都有體會。當然，用圖形符號進行有效溝通，有一個前提就是：看圖的人都能準確、一致地理解這些圖形符號的具體涵義，對此大家事先必須有約定，這樣對這些由圖形符號組成的建模語言進行標準化的需求就自然而生了。

這些簡單的道理，我本來覺得理工科畢業、有點大中型系統研發和 OO 軟體編程經歷的軟體工程師只要簡單地學過一點 UML ，正確理解了 UML 建模的價值和意義後，大多會得出與 @左文建和我觀點類似的結論，但事實好像並非如此。贊成 UML 與反對 UML 兩派的觀點可謂大相徑庭，截然相反。這是一個非常有意思的現象，值得繼續研究。

我是在 1997 年見到 Rose 和 UML 的，1998 年正式學的 UML（當時 Rational 公司還未正式進入中國）。自從見到、用上 UML 就愛不釋手，覺得這東西省事、管用。作為專業的 OOP，學習基於國際通行標準 UML 的 OOAD 不是很自然的一件事嗎？於是 18 年來我一直在用 UML 圖形符號思考各種 OO 軟體的設計，從 C++、Java 到 http://VB.NET、C#、JavaScript 等等。

多年來我的觀點一直是：

基於 OOAD 和 UML 建模的系統分析與設計非常重要，也非常有價值，尤其對於複雜的 OO 軟體開發。

迄今我確實沒看到有其他能取代 UML 價值和用途、更先進的 OO 建模語言標準。

看到樓里有大 V 說：

UML 在業界沒有用處。

好大的口氣，扯談！是的，他說的「業界」和我們的不是一個「業界」。

著名的 UML 開源軟體 StarUML（http://staruml.io）擁有幾百萬的下載量，以下是它官網上客戶名單的截圖。好吧，這是另一個「業界」：

拿《 Understanding the Linux Kernel 》這本書來說，裡面一個 UML 都沒有用到，但是裡面的圖對任何人設計軟體都會很有啟發。

居然有人會拿 Linux 內核開發來論證 UML 的無用，這是兩個截然不同的軟體開發領域好么！一個是底層操作系統開發，適用傳統的結構化編程或者其他套路，而另一個是上層的應用軟體開發，而 OOP、OOAD/UML 的主要適用領域是後者，自然不會出現在前者的書里了，「一個 UML 都沒有用到」，這有什麼好奇怪的。你的意思是 UML 圖不如 Linux 內核的設計圖？這不是扯么。你拿兩者做比較，這叫牛頭不對馬嘴，關公戰秦瓊，明顯是 OO 技術的外行。

建模很重要，diagram 很重要。但是，用來交流的 diagram 應該是：1. 不能完全脫離文字；2. 在附帶少量文字的基礎上做到 self-evident。UML 定義標準圖形完全是自己製造問題。

說這種話是不懂 UML 的外行吧。1，UML 完全脫離了文字？你沒見過 UML 圖裡的 notes、OCL 等等 text 表示？2，UML 不能在附帶少量文字的基礎上做到 self-evident？你見過幾張 UML 圖啊？其實 UML diagrams 完全符合這兩點要求，因而是日常開發交流的有效工具。

不錯，他贊成建模與 diagrams，這是我們的共同點，可是奇怪，他為什麼要反對 UML 進行的標準化呢？UML 標準化是因為 1995 年之前世界上有幾十種五花八門的 OO 建模語言，在建模的實踐中造成了許多問題和障礙。顯然 UML 標準化不是為了製造問題，而是為了通過更加精準的定義和規範來減少問題，消除以往各種流派圖形、符號的歧義、繁複與不一致性，所以 UML 標準的出現是軟體科學、軟體工程發展到一定階段後水到渠成、必然的結果，而這也正是統一建模語言的價值所在。

無法理解 UML 標準化意義的人，也談不上什麼軟體建模專家吧，估計也是 OOAD、OOM 的外行。

UML 有用還是無用，不便在這裡展開了，有興趣的同學可以前往：

如何反駁 UML 無用論？ - 面向對象分析與設計

以下轉入正題，談談幾個公司的 UML 應用情況。

題主：
而另外一個回答里舉出 Microsoft 和 Adobe、Nortel 的情況則是真的是在說明UML在業界的使用情況

Nortel

Nortel 早就破產清算了，有 P 說服力。

Wikipedia: Nortel
In June 2009, the company announced it would cease operations and sell off all of its business unit. The period of bankruptcy protection was extended to February 2, 2013.

Microsoft

過去，微軟一直是 UML 江湖上的二線選手（second-class player）吧，一貫秉持的所謂「跟隨跑」戰略，not a leading role，因此說服力也有限。不過 Visio、VS 的 UML 模塊這十多年來在國內外也一直有不少的擁護者，對 Visio 的評價尤其不錯。

2008 年微軟正式加入（重回）OMG 可以說是一個轉折點。這幾年 VS 對 UML 的支持也在明顯加強中，這些都是正面積極的信號。從這個專欄可以看出 MS 的努力與決心，MS 正在趕上來：

MSDN: Analyze and model your architecture

幾條新聞：

ZDNet: OMG, Microsoft joins OMG
In the words of Bob Muglia, senior vice president, Server and Tools Business at Microsoft:
"We"re building modeling in as a core part of the platform. This
enables IT pros to specify their business needs and build applications
that work directly from those specifications. It also brings together
the different stages of the IT life cycle -- connecting business
analysts, who specify requirements, with system architects, who design
the solution, with developers, who build the applications, and with
operations experts, who deploy and maintain the applications.
Ultimately, this means IT pros can innovate and respond faster to the
needs of their business."

eWeek 的這篇報道更深入，值得一讀：

eWeek: Microsoft Sets Modeling Strategy, Joins OMG
Microsoft established its modeling strategy and joined the Object
Management Group (OMG). With this move the company also is more
explicitly supporting the Unified Modeling Language (UML).
Thus, to make model-driven development a reality, Microsoft is focused
on providing a model-driven platform and visual modeling tools that make
it easy for all "mainstream" users, including information workers,
developers, database architects, software architects, business analysts
and IT professionals, to collaborate throughout the application
development life cycle. By putting model-driven innovation directly into
the Microsoft .NET platform, organizations will gain visibility and
control over applications from end to end, Microsoft officials said.

這段暴料很有趣：

Microsoft"s participation in OMG helps not only with the company"s plans
to garner support for modeling, but also to extend one of Bill Gates"
legacy issues. Modeling was one of Gates" pet projects. The company has
even courted the attentions of leaders in the UML space, including Ivar Jacobson and Grady Booch,
two of the co-authors of UML. Jacobsen lent his support to the
Microsoft Solutions Framework and sources said Microsoft has twice tried
to hire Booch, once when Gates personally attempted to woo the IBM
Fellow, and again since Gates" departure at the end of June.

最後一段很精彩：

Microsoft eschewed UML at one point in favor of a modeling strategy
around domain-specific languages (DSLs). And although with this move
Microsoft is not abandoning DSLs in favor of UML, there is sufficient
demand for UML that Microsoft cannot afford to ignore it. Brad Lovering,
a Microsoft technical fellow in the CSD unit, said Oslo would support
UML because of significant customer demand. Research firm Forrester
estimates that 71 percent of the development shops that do software
modeling use UML.

Microsoft Boosts Modeling Strategy and Rejoins OMG -- Redmondmag.com

涉及到多個端開發，協議交互十分複雜的繁多的情況，需要在im上討論闡述各自分工，用uml時序圖非常合適，我在公司引入後大家都開始用這個

我在東軟集團，東軟會用到UML。

項目立項會用：為客戶輸出設計文檔時會有業務序列圖、部署圖、核心組件類圖
開發大需求任務會用：尤其做多系統聯動的需求時，需求分析文檔會有業務序列圖。
平時的小任務就不用了：因為帶著新人做，告訴改造思路和代碼大體位置就能幹活。
使用UML大多是職級高的：大約4級左右（高級工程師），因為這個級別的工程師會分析大需求，設計複雜業務功能，此時用UML整理思路。
UML很有用：就像是設計模式很有用一樣，設計模式就是靠UML類圖來傳承的。
東軟也是個大圈子：低水平的人有說設計模式沒用的（他們不知道有UML這東西...），因為他們天天寫簡單業務代碼。可實際上，複雜業務是不能靠堆砌代碼完成的，這時要使用UML整理思路、做做設計。

在日本很流行的uml工具astah，這裡是其英文的用戶說明link（http://www.astah.net/friends-of-astah/friends#friends-open）。貌似還是有很多從事敏捷開發的大牛也都在用。不知道這個對題主有無幫助？

援引日本著名的it人士萩本順三的話說，木了就是用來幫助研究開發對象的問題領域用的工具。它能讓開發者去粗取精，看清問題的本質。（原文：モデリングとは「対象問題について深い理解を得るために、その対象をある目的または観點から眺め、細かくて余計な部分を取り除くことで、本質的な部分だけを浮かび上がらせる方法」なのです。）

當然，一旦uml生成了之後作為分析、設計階段的資產需要維護，會多少帶來負擔，但是對於複雜的系統的開發成功，及以後的整體的開發成功都是大有裨益的。

具體有人提到的大家在開會時對一些uml細節進行爭論使得核心問題無法解決，我認為那是參與者不在同一個認識層次上討論問題產生的問題，跟uml本身好壞沒有直接關係。就像一個英語8級跟一個英語4級都不及格的人聊天，大家雖然都在說英語，但是很難溝通。

「……要記住，表示法只是記錄系統行為和架構分析的工具，表示法本身並不是目的。因此，應該只是用那些表達意思所必需的表示法元素，而不是其他的東西。正如過度定義需求很危險一樣，過度定義問題的解決方案也是很危險的。……因此，如果一個較小的軟體系統的分析師、設計師和實現者技術很好，而且已經建立起了密切的工作關係，較粗的草圖就夠了（雖然仍有必要為系統的維護者留下一份架構視圖）。在實踐中，很少會是這種情況。另一方面，如果系統很大，軟體的部分很多，或者實現者的技術不是那麼好，或者開發者被地理位置、時間或者合約所分隔，在開發的過程中就需要更多地細節。
——Grady Booch等 ·《面向對象分析與設計》

葛來迪·布區（Grady Booch ），生於美國，計算機科學家與軟體工程師，與伊瓦爾·雅各布森、詹姆士·蘭寶共同開發了統一建模語言。他曾為Ada語言寫作了重要的教科書，在軟體架構、軟體工程及Collaborative development environment的貢獻，獲得國際性的聲望。
——維基百科

不知名小廠，老程序員來回答。

先說觀點：像RUP那樣繁文縟節的UML已經死了；但UML作為一種優秀的建模語言，仍然是程序員們溝通思考的利器。

UML的各種圖當時被設計用於RUP的各個階段。而RUP因為太重被業界拋棄，被敏捷過程所代替了。敏捷過程中的很多階段不強調文檔，注重的是代碼、溝通、快速迭代；所以圖也不那麼正規，以草圖居多。

但這不意味著UML也被完全拋棄了。

軟體設計就是建模的過程。這個過程中使用一種建模語言來描述一種模型是常見的事。更別提UML是最完善的建模語言了。拿它一個子集來描述軟體設計的模型並不是不恰當的。

就算是敏捷過程里，程序員之間用簡化的UML交流可以降低溝通成本。

表現對象關係時，用UML類圖來畫（主要突出類的層級關係，公共成員。比如討論設計模式時）。

多對象協作，非同步調用，多方通訊等複雜的設計，用順序圖和協作圖比較好。（比如，OAuth的文檔）

多個系統之間有通訊，描述系統邊界和介面，用組件圖是很好的選擇。（比如表述RESTful的web構架）

RUP需求分析階段，用UML的用例圖來分析需求。儘管敏捷時代不再要求這樣，但我一般在初期分析時，仍然經常拿用例圖來幫助自己想清楚很多問題。（用戶角色，系統邊界，輸入輸出和副作用，核心業務的數據等。往往這些是比較穩定，在迭代中並不常常變化。）

最後，推薦兩個極其輕便的UML工具：

http://www.ckwnc.com/ 順序圖DSL工具

http://yuml.me/ 用例圖/類圖/活動圖DSL工具

敏捷講究「活的文檔」，我廠用wiki管理文檔版本，而上面兩個DSL工具正好是純文本，適合帖到wiki裡面。

針對樓主的補充，特地加上說明

（1）業界真的不是微軟、Adobe這些外企，這些外企在中國的開發人員只屬於下游的「喝湯」水平，上游的，核心的開發人員不在中國。不過，微軟的MCS顧問團隊曾是我們的客戶。

（2）關於Linux為什麼不用UML建模也行，我下面給的鏈接《UML八大誤解》的「誤解三：許多開源軟體沒有用UML建模」就可以回答。

（3）如果你看了我下面的鏈接，裡面也有提到：我們從不在網站上宣傳客戶的名字。要了解哪個重量級的軟體組織，你可以私下聯繫我。

（4）你問到：本題沒有詢問「建模」在業界的情況，而是「UML」這種工具在業界的使用情況。說明你對UML、建模這些概念還是比較模糊，類似於《UML八大誤解》中的「誤解六」，而這些不是幾句話能說完的，建議還是抽空看一眼下面我給的《軟體方法》鏈接，看第一章的前面10頁就可以，這不是什麼廣告。

====================

對於各領域的冠軍和想成為冠軍的組織和開發人員，建模是帶來競爭優勢的重要武器，這些組織和開發人員也是我們UMLChina的主要客戶來源。我們的客戶覆蓋了國內各個領域的冠軍組織，包括通信、企業管理、電子商務、房地產、網路遊戲、地理信息、物流、數碼設備、醫療設備、工業控制.....等領域。

如果不上升到「開發有利潤的軟體」的高度，很多人會覺得「沒有必要」建模。

建模是更抽象的思維，確實是有門檻的。大家可以抽空看看下面的資料：

我在《程序員》雜誌發表的文章：UML八大誤解

http://www.umlchina.com/book/uml8.htm

我寫的《軟體方法》書：http://www.umlchina.com/book/softmeth.htm

我的UML建模答疑記錄：http://www.umlchina.com/qa/Index1.htm

希望以上資料能幫您更加了解建模。

工作中，我自己寫技術方案的時候用過順序圖，用例圖，流程圖。自己寫小項目的時候，uml也是挺有用的，整理自己得思路。比如資料庫關係圖什麼的，簡直不可或缺。但是你談標準化。。。我好不容易學會了，其他人沒學會，不也白扯么。

ワークフローシステム ExchangeUSE | TOP | 富士電機株式會社

前公司的產品ExchangeUSE，是一個基於自研工作流的OA系統，

當時我是工作流引擎的TEAM LEADER，負責團隊管理，架構設計兼主程序。

當時新版開發時的狀況：

系統有十來年的歷史，需要大升級提升架構
已有幾千家客戶使用，需要保證原有系統無縫升級
與業界某一ERP公司合作，提供兼容性API並能二次開發
完全按照工作流標準模式進行實現

基於以上原因，軟工流程選擇為：

充分調研客戶需求
原型迭代開發
充分設計

UML在裡面起到的作用

需求分析與共通化整理
系統模塊化分析工具
架構設計的交流工具
實現合理性的分析工具

可以看出，UML主要使用在前期需求分析和架構設計階段

作為通用語言進行high level 的高效率交流。

當時使用的UML工具： Enterprise Architect

寫業務程序員並沒有使用UML，也看不懂。

除開了這次大升級，其他一般性常規項目基本上都不系統的使用UML。

一般設計書根據客戶或者自己公司的習慣，使用EXCEL的線框圖就能滿足。

應該裁剪使用吧，我們用的比較多的是交互圖，這樣就可以對業務和系統的關係分析比較清晰。

通信設備軟體開發，&>10年工作經歷，信息源於ALCATEL ,LUCENT，還有ERICSSON。前兩者是自己服務的公司，ERICSSON的信息源於認識其中的員工。

以上公司，UML曾經用得很廣泛，現在還在繼續使用，序列圖和狀態圖用得比較多，use case這個概念也經常使用。通信行業的一大特點是實現各種協議，用序列圖和狀態圖表達起來比較自然。這些實踐發源於通信行業可能也跟我們經常工作在協議領域有關係。

個人興趣的原因，也關注UML在其他軟體行業的使用。感覺世紀之交的那幾年UML比較活躍，比如前面的答主潘加宇先生，當時是UML在國內的主要推廣者，他創辦的UMLChina質量很好，除了推廣UML，也推廣面向對象設計，其聲譽和關注度絕對超過現在的infoQ，我們這一代工程師，很多人都欠他一句感謝。但是最近8年，隨著互聯網行業的發展和agile概念的興起，UML在很多行業沉寂了。

試著分析一下原因：

軟體內涵發生了變化。軟體的內容沒法確定下來，找不到大規模建模的對象。
15年前軟體的主題之一是各行各業的信息化改造，比較有名的是政府推行的三金工程。雖然信息化改造的過程會改變組織的流程，但大體上是軟體去配合組織現有流程。從需求的角度，有大規模的需求要去挖掘，核對；反應到設計階段，有大量的需求作為輸入。

15年前的另一個軟體主題是電信設備軟體（我猜的，因為當時大學的計算機專業畢業生大部分都去了各大通信設備供應商）。電信行業因為有互聯互通的硬需求，各種行業規範在動手之前一定會準備好。

互聯網時代一切都變了。
首先，軟體和它所服務的業務是相互作用的關係，創業者們根據想像中的業務需求1.0做了一個軟體1.0，這個軟體一旦成功，就會催生現實世界發生改變，據此產生了更多需要用軟體來支撐的業務2.0，接著推出了軟體2.0....。

其次，即便天才的創業者穿越到未來，他也不敢按照未來的需求設計軟體。一是沒法解決今天到未來的過渡，二是虎視眈眈的競爭者讓他必須先搞定今天。

開發模型發生了很大變化。從瀑布：設計-&>評審-&>建造-&>部署變成了迭代：實現-&>試錯-&>拋棄或採用。

快速迭代成為硬需求。

首先移動互聯網時代競爭激烈，微信發布了發紅包的功能，支付寶必須馬上跟進；其次，很多有價值的需求來自於用戶的反饋，與其讓產品經理隔山打牛的閉門造車不如快速獲取用戶反饋。對應到開發上就是迭代周期縮短到1到2周。從設計來說，一周的工作本身也不會產生什麼驚天動地的設計改變，與其精益求精的對設計評審，不如在市場證明能夠大賣後再迅速重構。

快速迭代成為可能。
15年前的傳統軟體業，軟體是分別裝在各個電腦上的，修改和部署的成本非常高。需求和設計階段犯錯誤的成本也就非常高。客觀上有需要在正式開發之前仔細評審需求和設計，那麼也就需要相應的建模語言來較為準確的呈現需求和設計，UML相比它的前輩，比較好的滿足了這個需求。互聯網時代的軟體更新成本相對低（當然實際上也不容易，但是至少不用出差更新軟體，不用終端依賴軟體的業務），服務端完全是集中控制，自己說了算；即便是客戶端，如果某個手機軟體一周不提醒更新，簡直就要懷疑後面的公司是不是要倒閉了。

開發活動發生了變化。大部分軟體開發體現為對現成框架的配置，傳統意義上的建模需求消失了。
15年前招聘軟體工程師，大部分要求熟悉編程語言，熟悉數據結構和演算法，熟悉操作系統。今天仍然需要這種工程師，但是需求佔比小。今天軟體工程師的必備技能，除了編程語言，通常是掌握至少一個NoSQL，一個ORM，一個應用伺服器，或者再專門一點，hadoop,hive,storm...。

框架通常規定了某個特定類別應用的最佳設計實踐，集成了大部分支撐部件，甚至資料庫的schema都規定好了。

這種情況下，軟體工程師做的更多的是具體需求到通用框架的映射。UML自然也不大用得上了。

結束語

軟體開發本質上是回報驅動，風險驅動的。在基礎設施領域，以及人命攸關的行業，相信建模的需求仍舊存在，甚至UML也不能滿足。

要看軟體的規模和團隊大小，如果是業務不複雜的軟體，用UML太麻煩；規模幾個人也麻煩。項目主管還是需要，用來分析業務過程和開發管理。個人認為熟悉比較好，起碼開發習慣了這套方式，業務就清楚多。

最重要的是將這套理念用於開發，工作有理有據，維護也方便。即使沒畫UML，自己做東西時心裡也有個類似的大概。

UML是和客戶、上級、同事溝通的一種溝通方式。對方想要知道你的想法，如果照著UML的相關圖講給對方聽，聽者感覺靠譜（即使明白一點或者一些）和有計劃性。這也是一種很NB交流彙報方式，另外一種就是PPT大法。

不要把UML看成毒蛇猛獸，這是一套工具和理念，像使用其他編程工具，多使用會對整個工作環節有較多幫助。

軟體架構師（高級）層次就需要對UML比較熟悉，這樣可以提高工作效率，當然也有架構師不學UML，但這畢竟是現成的一套方式，總比自己獨創容易多。

總結，UML是工程的設計草圖，也是交流的PPT，還是一種設計思想。如果認為UML沒用，那是沒到一個層次。程序員可以是泥水匠，泥水師傅，工頭，設計師，設計大師。如果想成為設計大師，還是多用用UML。

說UML反人類的原因，主要是圖多和難記，比如關係，虛線，直線，箭頭好，方箭頭，方塊箭頭組合起來就容易搞混，還有各種圖，有些圖類似區別小。再者UML的教材多，一些人定義也不一樣。甚至一些書籍作者本身畫的圖就有問題。硬背沒用，要多使用，這個和編程一樣。

古語：工欲善其事必先利其器，大系統開發前期準備、分析工作肯定要仔細的設計一番的。UML確實很容易理解，學起來也很簡單，用一部分設計理清大家思路，能起到事半功倍的效果。畫草圖交流不假，多次修改草圖的成本不見得比UML耗時少。

如果定義UML圖能直接生成框架代碼，我覺得一定程度上能提高編寫效率的

畢竟自己在設計上更直觀了

不畫設計圖直接擼代碼容易遺失東西

UML有部分的應用，用來表示資料庫中數據表的結構和相互之間的關係。還用來表示系統的部署情況。

說說自身的感受，

首先，UML的定位問題：

UML本身只是一種語言，語言就是有些語義和語法，但要用好一種語言，需要好的方法，所以使用UML關鍵是方法問題，針對方法有大量的書可以參考，但只是參考，可以找到符合自己的一套方法（到底該用哪幾種圖？軟體每個階段如何使用？模型的目錄結構如何組織？模型的粒度有多細？）。

其次，UML的用途定位問題：

UML叫做統一建模語言，越通用的東西，抽象層次越高，對描述細節就越難，所以想通過UML建模後直接生成可執行代碼（注意是可執行代碼，不是框架代碼）難上加難，需要定義大量的Profile，工具需要做擴展，很複雜，需要搞清楚元模型、元元模型之類的概念。所以UML的定位在分析、設計層面，我實際使用過程中只應用到架構設計這一層，詳細設計還是代碼吧（UML模型跟代碼的一致性無法保證，如果誰有好的解決方案可以討論，逆向工程向來不好做）。需要了解MDA的話，可以找我聊聊，有些個心得體會。

最後，UML的認知程度問題：

現在隨便一本軟體分析設計（注意是軟體分析設計，例如XX設計模式）的書使用的圖形大部分都是UML，它已經成為了軟體分析設計的業界標準（系統工程領域還是用SysML吧，UML不合適了）。這也是歷史洗禮的結果，剛開始的諸侯混戰，最後UML一統江山，UML成為了軟體行業的行話，方便交流嘛。

不知道這個回答滿意不？好久沒在社區類的網站敲這麼多字了。

uml已經死了。

從來沒用過，從來沒見身邊人用過。