潘加宇

本文刪節(jié)版發(fā)表于《程序員》2013年11期

UML（統(tǒng)一建模語言）是軟件建模的表示法標(biāo)準(zhǔn)。我從2002年開始專門從事研究和推廣UML的工作，在為軟件組織提供UML相關(guān)需求和設(shè)計技能服務(wù)時，經(jīng)常會發(fā)現(xiàn)軟件開發(fā)人員對UML建模存在種種誤解。本文歸納了最典型的八個誤解加以剖析。

誤解一：UML是開發(fā)團(tuán)隊(duì)用來和客戶溝通的

UML模型是開發(fā)團(tuán)隊(duì)內(nèi)部高效溝通的手段，但不是用來和涉眾溝通的。拿音樂中的五線譜類比，五線譜是音樂專業(yè)人士交流的工具，作曲要懂、編曲要懂、樂手要懂、指揮要懂、歌手要懂（注意：是懂五線譜，不是人人都要用五線譜作曲），但聽音樂的人不需要懂。UML只是在“軟件開發(fā)人員”圈子里面的統(tǒng)一表示法，強(qiáng)迫開發(fā)人員思考，改善開發(fā)人員的交流，表達(dá)軟件開發(fā)的模型。

另外，“和客戶溝通”的說法本身就有問題，因?yàn)椤翱蛻簟辈皇且粋€人，而是一個組織，里面有不同角色和崗位的“涉眾”。他們的學(xué)歷職位有高有低，年齡有大有小，關(guān)注的利益更是各自不同，所以，和涉眾交流的介質(zhì)不是模型本身，而是模型的各種視圖。面對大領(lǐng)導(dǎo)，我們可以給他放幻燈片交流愿景；中層干部喜歡看文檔，我們可以按照他喜歡的格式給他炮制文檔；一線操作工只關(guān)心他那一小塊工作，我們可以制作界面原型和他交流；有時候甚至有的涉眾根本不喜歡看任何東西，我們還可以通過“談話”這種視圖和他交流。涉眾連談話都不樂意，我們也可以通過觀察來獲取素材。許多偉大的創(chuàng)新需求正是有心人在涉眾不作聲的情況下，觀察涉眾的行為得到的。

涉眾能提供的只是需求的素材，沒有資格也沒有責(zé)任直接提供需求。軟件需求不是由涉眾直接提供的，而是由需求工程師綜合不同涉眾的利益決定。就像電影劇本一樣，劇本不是由觀眾直接提供的，而是由編劇根據(jù)不同觀眾的口味編出來的。

如果不了解這個區(qū)分，直接拿UML模型去和涉眾交流，很容易導(dǎo)致“四不像”。不少開發(fā)團(tuán)隊(duì)十年如一日沒有進(jìn)步和積累，“交流影響開發(fā)”是原因之一。為了遷就不同涉眾的知識水平，開發(fā)團(tuán)隊(duì)只好損害模型的嚴(yán)謹(jǐn)性，即使是這樣，涉眾也不一定接受，交流效果還是不好，而且還會因?yàn)樯姹姷慕涣餍问蕉嘧兌绊戦_發(fā)團(tuán)隊(duì)核心工作流的穩(wěn)定─——雙方都受害。客戶的領(lǐng)導(dǎo)說，我不習(xí)慣看UML模型，就知道以前看的是××標(biāo)準(zhǔn)格式的文檔，我只在這個格式的文檔上簽字，難道我們就不用UML建模了？下一個項(xiàng)目的客戶領(lǐng)導(dǎo)喜歡另一種格式怎么辦？下下個項(xiàng)目根本不需要簽字怎么辦？互聯(lián)網(wǎng)網(wǎng)站沒有“客戶領(lǐng)導(dǎo)”簽字確認(rèn)需求怎么辦？建模的目的是幫開發(fā)團(tuán)隊(duì)思考，它可以指引開發(fā)團(tuán)隊(duì)發(fā)現(xiàn)到底需要向涉眾了解什么，但不是直接拿著模型和涉眾交流。

開發(fā)人員有意無意把建模的目的理解成和涉眾交流，有時背后的思想還是“懶”字，因?yàn)檫@樣想，就有了推卸責(zé)任的機(jī)會：不是我不想建模，就算我建模了，客戶不想看啊。

誤解二：UML是Rational公司的，Rose是最好的UML工具

說到UML，很多人會想到最開始推動UML誕生的“三友”：Grady Booch、James Rumbaugh和Ivar Jacobson。在早期，“三友”的貢獻(xiàn)是最大的。接下來，UML標(biāo)準(zhǔn)的管理和推動主要由OMG（對象管理組織）負(fù)責(zé)，OMG的成員是各大軟件企業(yè)，包括IBM、Microsoft、Oracle、Lockheed Martin等。

在OMG的推動下，UML被越來越多的標(biāo)準(zhǔn)組織采納。2005年開始，UML被ISO接納為標(biāo)準(zhǔn)。和UML 2.4.1對應(yīng)的標(biāo)準(zhǔn)是ISO/IEC 19505-1:2012和ISO/IEC 19505-2:2012。2011年，中華人民共和國發(fā)布了統(tǒng)一建模語言國家標(biāo)準(zhǔn)GB/T28174。行業(yè)標(biāo)準(zhǔn)組織如醫(yī)療衛(wèi)生信息化的標(biāo)準(zhǔn)組織HL7、IT管理標(biāo)準(zhǔn)化組織DMTF、美國國防部等，也使用UML來描述它們的標(biāo)準(zhǔn)。

UML誕生初期，最流行工具確實(shí)是Rational Rose，甚至有些人會把Rose和UML混為一談。2002年Rational被IBM收購以后，名稱變?yōu)镽ational Software Architect（簡稱RSA），這意味著如果現(xiàn)在您還使用Rose，那是在用十多年前的工具。

因?yàn)閁ML標(biāo)準(zhǔn)是開放的，所以各廠商可以根據(jù)標(biāo)準(zhǔn)開發(fā)自己的UML工具，工具之間還可以通過XML交換模型。根據(jù)UMLChina的統(tǒng)計，UML相關(guān)工具最多時達(dá)168種，經(jīng)過市場的洗禮，現(xiàn)在還在更新的還有近百種。

論功能的強(qiáng)大，RSA仍然是第一位的，不過個頭很大、價格昂貴。近年來，Enterprise Architect（簡稱EA）逐漸成為大多數(shù)開發(fā)人員學(xué)習(xí)建模的首選工具。EA的使用風(fēng)格和以前的Rose接近，個頭又不大，很方便開發(fā)人員自行安裝學(xué)習(xí)，價格也適中，堪稱性價比最好的工具。

實(shí)時系統(tǒng)開發(fā)方面，Rational Rhapsody是目前最好的工具，可以在類圖、狀態(tài)圖層面上做設(shè)計級調(diào)試，生成各RTOS下可直接運(yùn)行的代碼。

如果不想花錢購買工具，還有大量的免費(fèi)、開源或在線工具可以選擇，可以參見UMLChina網(wǎng)站上的“UML工具大全”頁面，鏈接是www.umlchina.com/Tools/Newindex1.htm。

誤解三：許多開源軟件沒有用UML建模

許多流行起來的開源項(xiàng)目（Linux、Apache、MySQL...）確實(shí)沒有使用UML建模，但是這些項(xiàng)目的核心領(lǐng)域多為基礎(chǔ)設(shè)施領(lǐng)域。基礎(chǔ)設(shè)施領(lǐng)域的"負(fù)載"（需要依賴的領(lǐng)域的數(shù)量）比較低，只需關(guān)注計算機(jī)的資源，不需關(guān)注醫(yī)院、稅務(wù)、物流....。因?yàn)樨?fù)載低，基礎(chǔ)設(shè)施級別的分解和復(fù)用相對容易，而且基礎(chǔ)設(shè)施領(lǐng)域有大量的教材和先行例子，程序員在學(xué)校里已經(jīng)受過這方面的教育，大腦比較容易把握基礎(chǔ)設(shè)施領(lǐng)域問題的復(fù)雜性，所以對顯式建模的要求沒有那么高。

很多能夠帶來利潤的系統(tǒng)"負(fù)載"比較高，除了核心領(lǐng)域（如醫(yī)院）的知識，還要依賴于其他非核心域的知識，而且，核心域并沒有那么多人去研究。很少有類似這樣的書，把一家醫(yī)院的流程，各種業(yè)務(wù)對象之間的關(guān)系，用某種方法（彩色UML建模也好，以前的數(shù)據(jù)流圖＋ER圖也好）研究得透透的。要在市場上獲得競爭優(yōu)勢，有必要把復(fù)用的級別提升到核心域的復(fù)用（因?yàn)槠渌暮锰?#xff0c;競爭對手也能獲得），這確實(shí)很難，但再難也要做。這時，建模技能就必不可少了。

在這方面，不少媒體有誤導(dǎo)。媒體會訪問某些“知名程序員”對建模的看法，得到的回答可能是“對我來說不重要”。這里面的原因是：基礎(chǔ)設(shè)施領(lǐng)域的程序員更容易得到媒體青睞成為“知名程序員”，因?yàn)椤靶酒薄ⅰ安僮飨到y(tǒng)”等詞匯上的光環(huán)會把媒體晃暈。更不客氣地說，其中一些“知名程序員”實(shí)際上僅僅是“玩家”，不了解開發(fā)帶來利潤的軟件需要付出的辛勞。

和我們生活工作密切相關(guān)的軟件，媒體關(guān)注得太少。一名白領(lǐng)，早上起來用微波爐熱牛奶，開電視看新聞，坐電梯下樓，刷卡坐地鐵，手機(jī)看微博，打卡進(jìn)公司，用公司的業(yè)務(wù)系統(tǒng)工作。上面這句話中涉及到至少七個系統(tǒng)，其中估計只有微博的開發(fā)人員能登上媒體的版面。你知道微波爐的軟件是誰寫的嗎？大多數(shù)開發(fā)人員做的軟件和“知名程序員”不一樣，讓“知名程序員”來做這些軟件，也未必做得來。Linus能做好一個醫(yī)院信息系統(tǒng)嗎？

誤解四：UML模型是源代碼的概要表現(xiàn)形式

持這樣看法的開發(fā)人員，應(yīng)該對軟件開發(fā)的工作流沒有概念，軟件開發(fā)工作流以及推薦使用的UML元素如下圖：

工作流	思考焦點(diǎn)	可選UML元素	推薦UML元素
業(yè)務(wù)建模	組織內(nèi)系統(tǒng)之間	用例圖、類圖、序列圖、活動圖	用例圖、類圖、序列圖
需求	系統(tǒng)邊界	用例圖、序列圖、狀態(tài)機(jī)圖、活動圖、文本	用例圖、文本
分析	系統(tǒng)內(nèi)核心域	類圖、序列圖、狀態(tài)機(jī)圖、活動圖、通信圖、包圖	類圖、序列圖、（狀態(tài)機(jī)圖）
設(shè)計	系統(tǒng)內(nèi)各域之間	類圖、序列圖、狀態(tài)機(jī)圖、活動圖、通信圖、組件圖、部署圖、時間圖、組合結(jié)構(gòu)圖、包圖	不畫，代碼即設(shè)計

圖1?各工作流以及推薦的UML元素

源代碼（開發(fā)人員最終需要編輯的介質(zhì)）能夠表達(dá)的只是"設(shè)計"工作流的內(nèi)容，所謂“代碼就是設(shè)計”。UML模型的重點(diǎn)是表達(dá)前面三個工作流的內(nèi)容。雖然最后目的是要得到代碼，但沒有前面幾個工作流的正確的推導(dǎo)，正確的代碼不會從天上掉下來。

一些書籍、文章、博客大談“編碼的藝術(shù)”，很多也屬于概念不清，文中探討的根本不是編碼的技能，而是分析技能甚至是業(yè)務(wù)建模技能。編碼確實(shí)有編碼的技能，但到了編碼時還在思考訂單和商品、發(fā)票的關(guān)系是什么，相當(dāng)于護(hù)士已經(jīng)把注射器拿在手里了，還在思考病人可能是什么病，開什么藥。

這種認(rèn)為“UML模型是代碼的概要形式”的誤解不止“普通”的開發(fā)人員會有，一些著名的UML書籍作者也有。Martin Fowler所著的UML暢銷書《UML精粹》，認(rèn)為UML有三種用法：草稿、藍(lán)圖和編程語言，也是僅從編碼的角度來說的。從Fowler寫作的其他書籍《重構(gòu)》、《企業(yè)應(yīng)用架構(gòu)模式》、《分析模式》等可以知道，他的研究工作集中在分析設(shè)計工作流，特別是設(shè)計工作流，不了解他在業(yè)務(wù)建模和需求方面有多少研究。

誤解五：UML建模和迭代開發(fā)沖突

有的開發(fā)團(tuán)隊(duì)以“敏捷”為名，放棄了建模技能的學(xué)習(xí)，借口是“反正一開始不可能把所有東西都想明白，先做做看吧！”。“先做做看”和建模并不矛盾，不能把“敏捷”、“迭代”當(dāng)作偷懶的庇護(hù)所。

一名從護(hù)士成長起來的醫(yī)生，只掌握了打針的技能，卻缺少檢查、診斷、擬治療方案等技能，索性說：“唉，反正再高明的大夫，也不能一個療程把病人治好，干脆我也別花那么多心思了，先隨便給病人打一針看看吧，不好再來！“迭代”只是一個底線，確實(shí)，再高明的大夫也沒有把握一個療程就治好病人，但是檢查、診斷等技能越精湛，所需要的療程就越少。

光喊口號“先做最重要的需求”是沒用的，你知道哪些需求最重要嗎？掌握業(yè)務(wù)建模技能，能幫助你準(zhǔn)確定位最重要的需求。光喊口號“分離變化”是沒用的，你知道哪些容易變，哪些不容易變嗎？掌握分析設(shè)計技能，能讓你看到變和不變的部分。

唱曲的名家，唱到極快之處，吐字依然干凈利落；快節(jié)奏的現(xiàn)代足球，職業(yè)球員的一招一式依然清清楚楚；即時戰(zhàn)略游戲高手要在極短時間內(nèi)完成多次操作，動作依然井然有序。在激烈競爭的年代需要快速應(yīng)變，掌握技能才能真敏捷。世上無易事，偷懶要不得。

剛?cè)胄械拈_發(fā)人員體會不到建模的重要性，是正常的。就像下象棋，初學(xué)者面對單車對馬雙士、單馬對單士等已經(jīng)有共識的局面還需要思考良久，最終還拿不下來甚至輸?shù)簟＿@時中局和布局的書在他看來多半是枯燥無味的，還不如把一本實(shí)用殘局匯編看熟了，學(xué)到一些奇技淫巧，也能在菜市場贏幾盤棋。不過，要邁向職業(yè)棋手的境界，參加更殘酷的競爭，就體會到中局和布局的重要了。

誤解六：能否給我一個完整的UML案例？

經(jīng)常有這樣的問題“能不能給一個案例，完完整整地實(shí)施了整套UML？”這是一種誤解，這樣的案例不應(yīng)該有。可以把UML看作一個完備的工具箱，里面各種工具都有。您只需要從這個工具箱中選擇適合您的項(xiàng)目類型的工具用上就可以，并不需要“完整地”使用UML。不只是UML，對編程語言也一樣的。很多人說“我用Java”，其實(shí)只是用Java的一小部分，而且很長時間內(nèi)只用這一小部分就夠了。

即使針對你的項(xiàng)目類型，挑選出了一些適用的UML元素，也不提倡一次性都用到下一個項(xiàng)目中，而應(yīng)該找出最值得改進(jìn)的工作流，一點(diǎn)點(diǎn)引進(jìn)。

例如，一個工期比較緊迫的管理信息系統(tǒng)，業(yè)務(wù)建模和需求工作流就很重要，畢竟這個項(xiàng)目不滿足客戶的要求，后面的生意也就沒了，而分析設(shè)計就沒那么重要，因?yàn)橄炔挥每紤]復(fù)用和擴(kuò)展的問題，那么，可以只在關(guān)鍵的業(yè)務(wù)流程做業(yè)務(wù)建模，在關(guān)鍵的用例認(rèn)真定義需求，然后按照熟悉的套路開發(fā)。需要引進(jìn)的UML元素可能有：業(yè)務(wù)序列圖、系統(tǒng)用例圖、系統(tǒng)用例規(guī)約。

反之，如果做一個醫(yī)療設(shè)備，需求可能容易獲得，但是對系統(tǒng)的質(zhì)量要求非常高，不允許出任何錯誤，這時，前面的業(yè)務(wù)建模、需求工作流可以不改進(jìn)，把分析設(shè)計工作流作為改進(jìn)重點(diǎn)。需要引進(jìn)的UML元素可能有：類圖、狀態(tài)機(jī)圖、序列圖。

如果開發(fā)團(tuán)隊(duì)能夠最終改進(jìn)到覆蓋所有工作流，自然是件好事，但是大多數(shù)項(xiàng)目來說，點(diǎn)狀的逐步改進(jìn)更符合實(shí)際情況。UML如何完整應(yīng)用在業(yè)務(wù)建模、需求、分析、設(shè)計工作流，這些年以來已經(jīng)有不少圍繞案例講解的書籍。閱讀之后也不要一次性照搬，還是要慢慢來。一些工具廠商出于展示其工具建模能力的目的，在建模工具自帶的案例模型中，把所有的UML圖都給用上了，這也要注意辨別，不可當(dāng)真。

誤解七：大師們不寫UML書了

最開始一批UML書籍，基本上是方法學(xué)家所寫。最近幾年，以“UML”為題的新書大多為高校教材或普及性教材。這并不是說UML已經(jīng)不重要，而是沒有必要再去強(qiáng)調(diào)，焦點(diǎn)不再是“要不要UML”，而是如何把UML建模高效應(yīng)用到軟件開發(fā)各工作流中。

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

?

圖2?國內(nèi)最近幾個月出版的帶“UML”書名的書籍（摘自amazon.cn搜索結(jié)果）

更深入討論需求和設(shè)計技能的書，雖然里面使用的表示法也是UML，但作者更喜歡起不帶UML的書名。

UML也已經(jīng)走入國內(nèi)各高校甚至高職校園，當(dāng)然，課程名稱不一定叫“UML”，而是冠以“面向?qū)ο蠓治鲈O(shè)計”之類的名字。下圖是我從各學(xué)校官網(wǎng)上摘錄的信息

學(xué)校	院系	課程名稱
北京大學(xué) ?	信息科學(xué)技術(shù)學(xué)院	軟件建模理論與UML
	軟件與微電子學(xué)院	面向?qū)ο蠹夹g(shù) 軟件需求工程
清華大學(xué)	信息科學(xué)技術(shù)學(xué)院	面向?qū)ο蠹夹g(shù)與應(yīng)用
	軟件學(xué)院	軟件體系結(jié)構(gòu) 軟件需求工程
?	經(jīng)管學(xué)院	面向?qū)ο蟮姆治鲈O(shè)計方法
復(fù)旦大學(xué)	信息學(xué)院	UML和面向?qū)ο笤O(shè)計模式
……	……	……
天津大學(xué)	計算機(jī)科學(xué)與技術(shù)學(xué)院	統(tǒng)一建模語言
……	……	……
湖南科技學(xué)院	?	UML與軟件建模
……	……	……

圖3?國內(nèi)各高校開設(shè)UML相關(guān)課程情況

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

一些批評UML的文章中，會有類似的說法。其實(shí)UML建模的研究者大多比較嚴(yán)謹(jǐn)，有哪一篇UML論文把UML說得"天花亂墜"？“大師說得天花亂墜”是無知之人編造出來的謠言，先編造謠言，再攻擊謠言。

被宣傳得“天花亂墜”反倒是一些偽敏捷宣傳，因?yàn)樾枰媸牢瓷畹哪贻p人和媒體人士，讓他們認(rèn)為世界上有容易做的事情，有免費(fèi)的午餐，所以用語比較激情澎湃，例如“無敵”、“硝煙”、“武士”、“顛覆”、“勇敢”等。相比之下，建模顯得太過嚴(yán)肅了。

?

一些參考：

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

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

?

轉(zhuǎn)載于:https://www.cnblogs.com/wangshide/p/3961643.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。