程序員眼中的UML

UML自1997年誕生以來，受到無數廠商、組織、專家學者的追捧和擁護，短短幾年時間，便有一統天下之勢。提起建模語言，舍UML其誰？

UML相關標準

OMG組織作為影響力最大的面向對象技術的機構，早早便將UML收入囊中，力捧其為標準建模語言。OMG在CORBA取得成功之后，最大的著力點便是MDA架構，而MDA架構的四大標準UML、MOF、XMI和CWM中，圍繞著UML的技術便有三種：UML本身自不必說，版本已經到了2.0；MOF作為“建模語言的語言”，似乎就是為UML量身定做的，雖說MOF有能力創建出與UML并駕齊驅的建模語言，但是似乎沒有看到誰這么干，大家只是在努力的發展UML的“方言”，例如UML Profile for CORBA，UML Profile for EJB等等；XMI是“模型的標準存儲交換格式”，為了解決不同的建模工具創建的模型不能互用的問題，OMG創建了XMI作為模型的存儲交換標準。這樣一來，UML工具更加可以大行其道，使用不同的建模工具創建的UML模型可以互相交流，只要它們都基于XMI。

UML相關工具

工具的多寡與優劣可以看出某個技術的受歡迎程度，在建模工具中，不說100％，大概也有90％支持了UML語言。最出名的UML工具Rational Rose，被IBM收購了；Eclipse下面的UML工具EclipseUML讓開發它的小公司Omondo也出名了；國內也有一個UML工具，聽說效果也不錯，就是楚凡科技的Trufun Plato 2005。至于其他國際上有點名氣的UML工具，更是不勝枚舉，幾乎有點軟件實力的國家，都有自己的UML工具。

當然，UML不僅僅出現在專用的UML工具中，它也頻繁出現在最新的各種開發環境中。例如編程開發環境JBuilder，具有將代碼轉換為UML類圖的功能；Together就更進一步，直接實現了代碼和類圖的同步轉換；Eclipse作為最優秀的開放式開發平臺，擁有眾多的UML相關插件，除了前面提到的EclipseUML，比較有名的還有EMF和UML2。

UML在MDA出現之后，在OMG的概念中，成為了MDA的一個子集（雖然UML的名氣遠遠大于MDA）。因此眾多的MDA工具中，幾乎都少不了UML功能。我認為很多MDA工具就是從UML工具直接改過來的。

UML使用現狀

照理說來，如火如荼的標準和工具應該催生出如火如荼的應用才對，可是UML的使用狀況實在不盡如人意。無論是身邊的還是網絡上的朋友，在項目中使用UML的都是鳳毛麟角，即便使用了UML，也是在很小的范圍內，完全沒有發揮出1％的功效。現在總結一下目前我所知道的UML使用現狀：

l         讀代碼時，用UML工具進行逆向工程，可以清晰的觀察代碼結構，方便理解代碼。

l         寫代碼時，由于開發平臺可以自動生成UML類圖，因此有時觀察UML類圖得到比較清晰的代碼結構。例如Together或者JBuilder等工具。當然，如果沒有自動生成的UML圖，大部分人也不會尋找其他工具去生成UML類圖的。

l         撰寫科技論文時，使用UML來表達系統架構或者系統流程等。

l         部分對UML非常熟悉的程序員，在開始寫代碼時，先畫UML類圖，然后利用工具生成代碼，最后對代碼進行擴展。

從上面的使用現狀可以看出，很多人把UML當成一種可有可無的技術。即使使用了UML，也只是圍繞著UML中的類圖，其他的UML圖都拋到一邊去了。造成這種狀況的原因，一方面固然是因為國內的正規大型軟件項目比較少，軟件工程技術起步很晚；另一方面是由于國內不管是架構師、系統分析員、軟件工程師、程序員、測試人員等等實質上都是程序員而已，很多人是趕著鴨子上架成了架構師或者系統分析員的。這種狀況下，軟件工程的概念難以深入人心，UML更加成了一個國內項目的雞肋。

看看國外的架構師、UML專家們，往往都是滿臉大胡子，在計算機領域中浸淫了3，40年；而中國最古老的程序員，也只有十幾年經驗，除去在黑暗中摸索的幾年，有十年以上開發經驗的程序員少之又少。不經歷幾個大型項目，要使用軟件工程技術是不可能的，也是不能起到什么效果的。因此，有人堂而皇之的撰文“UML的三大硬傷”，將UML駁斥得一無是處。高喊口號打倒某東西是很容易的，關鍵是打倒了UML何以取而代之？

程序員眼中的UML

既然國內90％以上的軟件開發人員都是程序員，那么程序員眼中的UML到底應該是什么樣子的呢？我很期望有一本好書能夠讓程序員們快速的掌握自己所需的UML知識，遺憾的是目前還沒有看到這樣的一本書。無論是“三友”的UML經典教材還是國內的一些“xx天精通UML”都不符合這樣的要求。沒有一本是“有中國特色的UML教材――一本寫給程序員的UML入門書”。

作為一個程序員，我很了解其他同僚的心理，如果拿到一本書，翻了一個小時還沒有找到可以run的HelloWorld，90％的人會大叫一聲“去nmd”，然后把書扔進廢紙堆。不能怪我們急功近利，在這個技術術語滿天飛，連底層平臺都動蕩不安的年代，誰還有時間和興趣看一些與自己無關的東西呢？

我很能想象一個程序員，好不容易空出時間來看看最近很熱的UML技術，當他拿到一本UML入門以后，開始尋找對自己有用的東西。在開始的一個小時，滿篇都是需求分析，use case，甚至書的作者還在饒有興趣的介紹use case有六種譯法：用例、用況、用案……對不起，老子一百年都沒做過需求分析了，也不想知道這個狗屁的use case到底叫什么。于是開始后悔在china-pub上又白花了這么多銀子。

還有些書上信誓旦旦的說“學好UML，走遍天下都不怕”，如果你做需求分析，你可以用UML和客戶交流；如果你做系統分析員，你可以用UML設計系統；如果你做程序員，你可以用UML生成程序；如果你做測試員，你可以基于UML設計測試用例。而實際情況是什么呢？國內的客戶有幾個懂UML？懂UML的人差不多自己都可以把軟件寫出來了，還需要請你做需求分析么？別說客戶了，上次聽同學說和北京某大科研所的工程師們交流，無意中說起了UML，在場的竟然只有一個稍微了解，而且堅持認為那是一種畫圖工具（那位仁兄其實也沒錯，Visio不就是一個畫圖工具么）。

雖然狀況如此不堪，但是UML確實是一個很優秀的“交流語言”、“代碼生成工具”和“系統設計工具”。讓我們擦干身上的獻血，掩埋戰友的尸體，睜大迷蒙的雙眼來看清UML對程序員的作用。UML有九種圖，作用各自不同，基本上涵蓋了軟件工程的各個方面，很多人就是不堪于忍受知識不足的困惑與“侮辱”（很多程序員認為一種技術自己看不懂就是對自己的侮辱），從而放棄了整片UML森林。他們怕的不是在UML這棵樹上吊死，而是怕在UML森林里面迷路。但是我想說，知識學習的過程就是去蕪存精，找出對自己有用的東西，然后掌握之。對于程序員來說，UML的價值就體現在三個方面：

一、UML是最好的交流語言，無論是與其他程序員交流，還是與領域專家、測試員或者用戶交流。原因只有一點，UML是標準的，就像英語一樣，無論多么該死，大家還是忙著把自己的論文改成英文的。當然，在小的領域可能有更好的交流方言，但是在大而長遠的交流中，使用標準的交流語言是穩妥的。

二、UML是很好的代碼生成工具，其實代碼生成功能并不是由UML語言和規范提供的，而是由UML工具提供的，而且不同的UML工具提供的代碼生成功能還不盡相同。例如Rose提供簡單的代碼框架生成，而Eclipse插件EMF可以生成功能豐富，提供了各種設計模式的代碼包。無論如何，如果程序員可以從UML入手來寫程序，比直接敲代碼要高級那么一點點。從文檔、版本控制、維護、測試等各方面來說，畫UML類圖比直接寫代碼都要高那么一點點。

三、UML是很好的系統設計工具。對于程序員來說，很少用到“設計”這個詞，大部分時候我們都是在“編寫”或者“實現”。但是勿庸置疑，程序員的許多工作中還是需要“設計”的。包和組件之間的依賴關系、復雜操作的流程、對象之間的關聯和狀態、程序的部署等等，都經常是程序員的工作。那么上面的四種情況可以用UML的組件圖、序列圖、對象圖和部署圖來設計。雖然，不同的程序員有不同的設計方法或者設計圖例，不過，UML是標準的。不要忽視標準的力量，標準的東西意味著在全世界范圍內都有可能會被看懂，不標準的東西可能出了你的辦公室就沒人能夠清晰、準確的理解了。

后記

Blog好久沒有更新，因為最近一直忙于一些俗物，于是想寫點清高的東西。但是寫完之后再看，好像也不怎么清高，反而更俗了。

前段時間寫論文時，需要用到UML2.0的類圖元模型，在UML2.0的規范中尋覓了好久，發現類圖元模型已經被拆分到三個包里面了，因為UML2.0的規范實在是太大太繁瑣了。于是有感于UML之博大精深，說好聽是博大精深，難聽點就是亂七八糟。不過OMG歷來如此，當初的CORBA如果更簡約一點，也許J2EE根本就沒有立足之地。

感慨之后就是想把UML中對自己有用的部分整理出來，在整理之前免不了到處翻資料，這篇文檔就是翻資料的一些感觸了。希望能夠將UML的有用部分都整理出來，形成一個系列的文檔。