UML還有用嗎？

作者：潘加宇
鏈接：https://www.zhihu.com/question/23569835/answer/30235970

引言

"uml的最高境界是用uml圖直接生成可執(zhí)行軟件"這個已經(jīng)實現(xiàn)了，例如用帶有設(shè)計級調(diào)試和強大代碼生成能力的Rational Rhapsody開發(fā)實時嵌入系統(tǒng)。

現(xiàn)狀

• 軟件開發(fā)的歷史就是源代碼（也就是人腦需要編輯的介質(zhì)）的形式一直在升級的歷史，從最初的機器語言到匯編語言、過程式高級語言到現(xiàn)在流行的面向?qū)ο笳Z言。
• “模型就是源代碼”不是可不可能的問題，而是合不合算的問題。真實世界中，涉眾對許多系統(tǒng)的質(zhì)量要求并不高，電商網(wǎng)站、銀行系統(tǒng)出個故障，人們習(xí)以為常，能夠接受，反正出了故障再恢復(fù)唄。這樣的系統(tǒng)，充分的建模沒有必要性。同時，也沒有可能性，因為類太多，工期不允許為每個類畫狀態(tài)機。這類系統(tǒng)，只需要對關(guān)鍵的類充分建模。如果做一個心臟起搏器，對質(zhì)量要求非常高，通過充分的建模盡可能減少人工編碼導(dǎo)致的偶發(fā)錯誤是必要的，而且也是可能的，因為類的個數(shù)少。但是，UML的最重要的意義不在于生成代碼，而在于前面的工作流！
• 我從2002年開始專門從事研究和推廣UML的工作，在為軟件組織提供UML相關(guān)需求和設(shè)計技能服務(wù)時，經(jīng)常會發(fā)現(xiàn)軟件開發(fā)人員對UML建模存在種種誤解。我歸納了最典型的八個誤解加以剖析。

UML誤解與回答

誤解一

• UML是開發(fā)團隊用來和客戶溝通的UML模型是開發(fā)團隊內(nèi)部高效溝通的手段，但不是用來和涉眾溝通的。
• 拿音樂中的五線譜類比，五線譜是音樂專業(yè)人士交流的工具，作曲要懂、編曲要懂、樂手要懂、指揮要懂、歌手要懂（注意：是懂五線譜，不是人人都要用五線譜作曲），但聽音樂的人不需要懂。
• UML只是在“軟件開發(fā)人員”圈子里面的統(tǒng)一表示法，強迫開發(fā)人員思考，改善開發(fā)人員的交流，表達軟件開發(fā)的模型。
• 另外，“和客戶溝通”的說法本身就有問題，因為“客戶”不是一個人，而是一個組織，里面有不同角色和崗位的“涉眾”。他們的學(xué)歷職位有高有低，年齡有大有小，關(guān)注的利益更是各自不同，所以，和涉眾交流的介質(zhì)不是模型本身，而是模型的各種視圖。
• 面對大領(lǐng)導(dǎo)，我們可以給他放幻燈片交流愿景；中層干部喜歡看文檔，我們可以按照他喜歡的格式給他炮制文檔；一線操作工只關(guān)心他那一小塊工作，我們可以制作界面原型和他交流；有時候甚至有的涉眾根本不喜歡看任何東西，我們還可以通過“談話”這種視圖和他交流。涉眾連談話都不樂意，我們也可以通過觀察來獲取素材。
• 許多偉大的創(chuàng)新需求正是有心人在涉眾不作聲的情況下，觀察涉眾的行為得到的。
• 涉眾能提供的只是需求的素材，沒有資格也沒有責(zé)任直接提供需求。軟件需求不是由涉眾直接提供的，而是由需求工程師綜合不同涉眾的利益決定。就像電影劇本一樣，劇本不是由觀眾直接提供的，而是由編劇根據(jù)不同觀眾的口味編出來的。
• 如果不了解這個區(qū)分，直接拿UML模型去和涉眾交流，很容易導(dǎo)致“四不像”。不少開發(fā)團隊十年如一日沒有進步和積累，“交流影響開發(fā)”是原因之一。為了遷就不同涉眾的知識水平，開發(fā)團隊只好損害模型的嚴謹性，即使是這樣，涉眾也不一定接受，交流效果還是不好，而且還會因為涉眾的交流形式多變而影響開發(fā)團隊核心工作流的穩(wěn)定─——雙方都受害?？蛻舻念I(lǐng)導(dǎo)說，我不習(xí)慣看UML模型，就知道以前看的是××標準格式的文檔，我只在這個格式的文檔上簽字，難道我們就不用UML建模了？下一個項目的客戶領(lǐng)導(dǎo)喜歡另一種格式怎么辦？下下個項目根本不需要簽字怎么辦？互聯(lián)網(wǎng)網(wǎng)站沒有“客戶領(lǐng)導(dǎo)”簽字確認需求怎么辦？建模的目的是幫開發(fā)團隊思考，它可以指引開發(fā)團隊發(fā)現(xiàn)到底需要向涉眾了解什么，但不是直接拿著模型和涉眾交流。開發(fā)人員有意無意把建模的目的理解成和涉眾交流，有時背后的思想還是“懶”字，因為這樣想，就有了推卸責(zé)任的機會：不是我不想建模，就算我建模了，客戶不想看啊。

誤解二

• UML是Rational公司的，Rose是最好的UML工具說到UML，很多人會想到最開始推動UML誕生的“三友”：Grady Booch、James Rumbaugh和Ivar Jacobson。在早期，“三友”的貢獻是最大的。接下來，UML標準的管理和推動主要由OMG（對象管理組織）負責(zé)，OMG的成員是各大軟件企業(yè)，包括IBM、Microsoft、Oracle、Lockheed Martin等。
• 在OMG的推動下，UML被越來越多的標準組織采納。2005年開始，UML被ISO接納為標準。和UML 2.4.1對應(yīng)的標準是ISO/IEC 19505-1:2012和ISO/IEC 19505-2:2012。2011年，中華人民共和國發(fā)布了統(tǒng)一建模語言國家標準GB/T28174。行業(yè)標準組織如醫(yī)療衛(wèi)生信息化的標準組織HL7、IT管理標準化組織DMTF、美國國防部等，也使用UML來描述它們的標準。
• UML誕生初期，最流行工具確實是Rational Rose，甚至有些人會把Rose和UML混為一談。2002年Rational被IBM收購以后，名稱變?yōu)镽ational Software Architect（簡稱RSA），這意味著如果現(xiàn)在您還使用Rose，那是在用十多年前的工具。因為UML標準是開放的，所以各廠商可以根據(jù)標準開發(fā)自己的UML工具，工具之間還可以通過XML交換模型。根據(jù)UMLChina的統(tǒng)計，UML相關(guān)工具最多時達168種，經(jīng)過市場的洗禮，現(xiàn)在還在更新的還有近百種。論功能的強大，RSA仍然是第一位的，不過個頭很大、價格昂貴。
• 近年來，Enterprise Architect（簡稱EA）逐漸成為大多數(shù)開發(fā)人員學(xué)習(xí)建模的首選工具。EA的使用風(fēng)格和以前的Rose接近，個頭又不大，很方便開發(fā)人員自行安裝學(xué)習(xí)，價格也適中，堪稱性價比最好的工具。實時系統(tǒng)開發(fā)方面，Rational Rhapsody是目前最好的工具，可以在類圖、狀態(tài)圖層面上做設(shè)計級調(diào)試，生成各RTOS下可直接運行的代碼。如果不想花錢購買工具，還有大量的免費、開源或在線工具可以選擇，可以參見UMLChina網(wǎng)站上的“UML工具大全”頁面，鏈接是UML相關(guān)工具一覽（截止2014年8月）。

誤解三

• 許多開源軟件沒有用UML建模許多流行起來的開源項目（Linux、Apache、MySQL...）確實沒有使用UML建模，但是這些項目的核心領(lǐng)域多為基礎(chǔ)設(shè)施領(lǐng)域。
• 基礎(chǔ)設(shè)施領(lǐng)域的"負載"（需要依賴的領(lǐng)域的數(shù)量）比較低，只需關(guān)注計算機的資源，不需關(guān)注醫(yī)院、稅務(wù)、物流....。因為負載低，基礎(chǔ)設(shè)施級別的分解和復(fù)用相對容易，而且基礎(chǔ)設(shè)施領(lǐng)域有大量的教材和先行例子，程序員在學(xué)校里已經(jīng)受過這方面的教育，大腦比較容易把握基礎(chǔ)設(shè)施領(lǐng)域問題的復(fù)雜性，所以對顯式建模的要求沒有那么高。
• 很多能夠帶來利潤的系統(tǒng)"負載"比較高，除了核心領(lǐng)域（如醫(yī)院）的知識，還要依賴于其他非核心域的知識，而且，核心域并沒有那么多人去研究。很少有類似這樣的書，把一家醫(yī)院的流程，各種業(yè)務(wù)對象之間的關(guān)系，用某種方法（彩色UML建模也好，以前的數(shù)據(jù)流圖＋ER圖也好）研究得透透的。要在市場上獲得競爭優(yōu)勢，有必要把復(fù)用的級別提升到核心域的復(fù)用（因為其他的好處，競爭對手也能獲得），這確實很難，但再難也要做。這時，建模技能就必不可少了。在這方面，不少媒體有誤導(dǎo)。媒體會訪問某些“知名程序員”對建模的看法，得到的回答可能是“對我來說不重要”。這里面的原因是：基礎(chǔ)設(shè)施領(lǐng)域的程序員更容易得到媒體青睞成為“知名程序員”，因為“芯片”、“操作系統(tǒng)”等詞匯上的光環(huán)會把媒體晃暈。
• 更不客氣地說，其中一些“知名程序員”實際上僅僅是“玩家”，不了解開發(fā)帶來利潤的軟件需要付出的辛勞。和我們生活工作密切相關(guān)的軟件，媒體關(guān)注得太少。一名白領(lǐng)，早上起來用微波爐熱牛奶，開電視看新聞，坐電梯下樓，刷卡坐地鐵，手機看微博，打卡進公司，用公司的業(yè)務(wù)系統(tǒng)工作。上面這句話中涉及到至少七個系統(tǒng)，其中估計只有微博的開發(fā)人員能登上媒體的版面。你知道微波爐的軟件是誰寫的嗎？大多數(shù)開發(fā)人員做的軟件和“知名程序員”不一樣，讓“知名程序員”來做這些軟件，也未必做得來。Linus能做好一個醫(yī)院信息系統(tǒng)嗎？

軟件工作流以及推薦的UML

工作流>>>思考焦點>>>可選UML元素>>>推薦UML元素
=======================================================================
業(yè)務(wù)建模>>>組織內(nèi)系統(tǒng)之間>>>用例圖、類圖、序列圖、活動圖>>>用例圖、類圖、序列圖
=======================================================================
需求>>>系統(tǒng)邊界>>>用例圖、序列圖、狀態(tài)機圖、活動圖、文本>>>用例圖、文本
=======================================================================
系統(tǒng)內(nèi)核心域>>>類圖、序列圖、狀態(tài)機圖、活動圖、通信圖、包圖>>>類圖、序列圖、（狀態(tài)機圖）>>>設(shè)計
=======================================================================
設(shè)計>>>系統(tǒng)內(nèi)各域之間>>>全部都可選>>>不畫，代碼即設(shè)計

誤解四

• UML模型是源代碼的概要表現(xiàn)形式持這樣看法的開發(fā)人員，應(yīng)該對軟件開發(fā)的工作流沒有概念
• 各工作流以及推薦的UML元素源代碼（開發(fā)人員最終需要編輯的介質(zhì)）能夠表達的只是"設(shè)計"工作流的內(nèi)容，所謂“代碼就是設(shè)計”。
• UML模型的重點是表達前面三個工作流的內(nèi)容。雖然最后目的是要得到代碼，但沒有前面幾個工作流的正確的推導(dǎo)，正確的代碼不會從天上掉下來。
• 一些書籍、文章、博客大談“編碼的藝術(shù)”，很多也屬于概念不清，文中探討的根本不是編碼的技能，而是分析技能甚至是業(yè)務(wù)建模技能。編碼確實有編碼的技能，但到了編碼時還在思考訂單和商品、發(fā)票的關(guān)系是什么，相當(dāng)于護士已經(jīng)把注射器拿在手里了，還在思考病人可能是什么病，開什么藥。這種認為“UML模型是代碼的概要形式”的誤解不止“普通”的開發(fā)人員會有，一些著名的UML書籍作者也有。
• Martin Fowler所著的UML暢銷書《UML精粹》，認為UML有三種用法：草稿、藍圖和編程語言，也是僅從編碼的角度來說的。從Fowler寫作的其他書籍《重構(gòu)》、《企業(yè)應(yīng)用架構(gòu)模式》、《分析模式》等可以知道，他的研究工作集中在分析設(shè)計工作流，特別是設(shè)計工作流，不了解他在業(yè)務(wù)建模和需求方面有多少研究。

誤解五

• UML建模和迭代開發(fā)沖突有的開發(fā)團隊以“敏捷”為名，放棄了建模技能的學(xué)習(xí)，借口是“反正一開始不可能把所有東西都想明白，先做做看吧！”。
• “先做做看”和建模并不矛盾，不能把“敏捷”、“迭代”當(dāng)作偷懶的庇護所。一名從護士成長起來的醫(yī)生，只掌握了打針的技能，卻缺少檢查、診斷、擬治療方案等技能，索性說：“唉，反正再高明的大夫，也不能一個療程把病人治好，干脆我也別花那么多心思了，先隨便給病人打一針看看吧，不好再來！
• “迭代”只是一個底線，確實，再高明的大夫也沒有把握一個療程就治好病人，但是檢查、診斷等技能越精湛，所需要的療程就越少。光喊口號“先做最重要的需求”是沒用的，你知道哪些需求最重要嗎？
• 掌握業(yè)務(wù)建模技能，能幫助你準確定位最重要的需求。光喊口號“分離變化”是沒用的，你知道哪些容易變，哪些不容易變嗎？
• 掌握分析設(shè)計技能，能讓你看到變和不變的部分。唱曲的名家，唱到極快之處，吐字依然干凈利落；快節(jié)奏的現(xiàn)代足球，職業(yè)球員的一招一式依然清清楚楚；即時戰(zhàn)略游戲高手要在極短時間內(nèi)完成多次操作，動作依然井然有序。在激烈競爭的年代需要快速應(yīng)變，掌握技能才能真敏捷。世上無易事，偷懶要不得。
• 剛?cè)胄械拈_發(fā)人員體會不到建模的重要性，是正常的。就像下象棋，初學(xué)者面對單車對馬雙士、單馬對單士等已經(jīng)有共識的局面還需要思考良久，最終還拿不下來甚至輸?shù)?。這時中局和布局的書在他看來多半是枯燥無味的，還不如把一本實用殘局匯編看熟了，學(xué)到一些奇技淫巧，也能在菜市場贏幾盤棋。不過，要邁向職業(yè)棋手的境界，參加更殘酷的競爭，就體會到中局和布局的重要了。

誤解六

• 能否給我一個完整的UML案例？經(jīng)常有這樣的問題“能不能給一個案例，完完整整地實施了整套UML？”這是一種誤解，這樣的案例不應(yīng)該有。
• 可以把UML看作一個完備的工具箱，里面各種工具都有。您只需要從這個工具箱中選擇適合您的項目類型的工具用上就可以，并不需要“完整地”使用UML。不只是UML，對編程語言也一樣的。
• 很多人說“我用Java”，其實只是用Java的一小部分，而且很長時間內(nèi)只用這一小部分就夠了。
• 即使針對你的項目類型，挑選出了一些適用的UML元素，也不提倡一次性都用到下一個項目中，而應(yīng)該找出最值得改進的工作流，一點點引進。
• 例如，一個工期比較緊迫的管理信息系統(tǒng)，業(yè)務(wù)建模和需求工作流就很重要，畢竟這個項目不滿足客戶的要求，后面的生意也就沒了，而分析設(shè)計就沒那么重要，因為先不用考慮復(fù)用和擴展的問題，那么，可以只在關(guān)鍵的業(yè)務(wù)流程做業(yè)務(wù)建模，在關(guān)鍵的用例認真定義需求，然后按照熟悉的套路開發(fā)。
• 需要引進的UML元素可能有：業(yè)務(wù)序列圖、系統(tǒng)用例圖、系統(tǒng)用例規(guī)約。
• 反之，如果做一個醫(yī)療設(shè)備，需求可能容易獲得，但是對系統(tǒng)的質(zhì)量要求非常高，不允許出任何錯誤，這時，前面的業(yè)務(wù)建模、需求工作流可以不改進，把分析設(shè)計工作流作為改進重點。需要引進的UML元素可能有：類圖、狀態(tài)機圖、序列圖。
• 如果開發(fā)團隊能夠最終改進到覆蓋所有工作流，自然是件好事，但是大多數(shù)項目來說，點狀的逐步改進更符合實際情況。UML如何完整應(yīng)用在業(yè)務(wù)建模、需求、分析、設(shè)計工作流，這些年以來已經(jīng)有不少圍繞案例講解的書籍。閱讀之后也不要一次性照搬，還是要慢慢來。一些工具廠商出于展示其工具建模能力的目的，在建模工具自帶的案例模型中，把所有的UML圖都給用上了，這也要注意辨別，不可當(dāng)真。