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。行業標準組織如醫療衛生信息化的標準組織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工具大全”頁面，鏈接是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

?

總結

以上是生活随笔為你收集整理的UML八大误解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。