[轉]UML八大誤解

潘加宇

本文刪節版發表於《程序員》2013年11期

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。行業標準組織如醫療衛生信息化的標準組織HL七、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工具大全」頁面，連接是www.umlchina.com/Tools/Newindex1.htm。

誤解三：許多開源軟件沒有用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建模高效應用到軟件開發各工做流中。

下圖是amazon.cn上搜索的最近三個月出版的UML書籍結果。

 

圖2 國內最近幾個月出版的帶「UML」書名的書籍（摘自amazon.cn搜索結果）

更深刻討論需求和設計技能的書，雖然裏面使用的表示法也是UML，但做者更喜歡起不帶UML的書名。

UML也已經走入國內各高校甚至高職校園，固然，課程名稱不必定叫「UML」，而是冠以「面向對象分析設計」之類的名字。下圖是我從各學校官網上摘錄的信息

學校	院系	課程名稱
北京大學	信息科學技術學院	軟件建模理論與UML
	軟件與微電子學院	面向對象技術 軟件需求工程
清華大學	信息科學技術學院	面向對象技術與應用
	軟件學院	軟件體系結構 軟件需求工程
	經管學院	面向對象的分析設計方法
復旦大學	信息學院	UML和麪向對象設計模式
……	……	……
天津大學	計算機科學與技術學院	統一建模語言
……	……	……
湖南科技學院		UML與軟件建模
……	……	……

圖3 國內各高校開設UML相關課程狀況

誤解八：UML以前被宣傳得天花亂墜

一些批評UML的文章中，會有相似的說法。其實UML建模的研究者大多比較嚴謹，有哪一篇UML論文把UML說得"天花亂墜"？「大師說得天花亂墜」是無知之人編造出來的謠言，先編造謠言，再攻擊謠言。

被宣傳得「天花亂墜」反卻是一些僞敏捷宣傳，由於須要吸引涉世未深的年輕人和媒體人士，讓他們認爲世界上有容易作的事情，有免費的午飯，因此用語比較激情澎湃，例如「無敵」、「硝煙」、「武士」、「顛覆」、「勇敢」等。相比之下，建模顯得太過嚴肅了。

 

一些參考：

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

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