UML發展現狀與實際應用——希賽嘉賓聊天實錄

        本文是我在2007年1月作為希賽(CSAI)嘉賓的聊天實錄，希望對大家能夠有所幫助，來自www.csai.cn。

聊天記錄：

【希賽主持人】各位希賽的網友大家上午好，歡迎大家再次光臨希賽嘉賓聊天室，讓您們久等了，今天我們有幸請到的是希賽顧問團顧問劉偉作客希賽嘉賓聊天室。
先請劉顧問與我們打個招呼吧！

【希賽嘉賓】大家好！我是劉偉，很高興在希賽聊天室和大家交流一下UML的現狀和應用方面的問題！

【希賽主持人】今天我們要聊的是“UML發展現狀與實際應用”，首先我們還是請劉顧問介紹一下UML吧，UML這些年來在不少地方都得到了應用，UML做為一種建模語言，它現在在我們國家的使用狀況如何呢，UML在實踐應用的多嗎？

【希賽嘉賓】UML這幾年在我國發展還是比較迅速的，但是與美國、印度等國家相比還是有差距，越來越多的公司開展了UML系列的培訓與學習，也購置了一些UML的CASE工具，但是在我們國家的使用情況效果並不是太好，我認為UML的發展與應用還需要一個過程。

【希賽主持人】UML現在使用得廣嗎？它主要應用在哪些地方呢？

【希賽嘉賓】它的應用領域很廣泛，實際上除了軟體界可以使用之外，其他行業也可以使用，我甚至看到有用UML的方法繪製的軍事戰略部署圖，當然最主要的還是應用於計算機領域；它可以用於各種型別的軟體的開發，無論是製造業、遊戲開發、醫療衛生系統、還是OA，EAI，DSS，ERP...都可以使用到UML。

【希賽主持人】 網友[miskitter]: UML建模語言是不是對所有應用系統都實用呢？

【希賽嘉賓】這樣看具體的情況，對於使用物件導向技術開發的系統更加合適，當然在需求分析等階段對所有的應用系統都實用。像一些流程化很強的系統，或者小型的專案有時候沒有必要一定使用UML。像敏捷開發中就提到系統的開發人員應該從技術和工具靈活的選擇，找到最合適的工具，像做一個小軟體，如一個小的網站就不需要用到UML來進行建模。

【希賽主持人】UML為什麼會受到這麼廣泛的使用呢？

【希賽嘉賓】這與UML的特點有關，它綜合了軟體工程領域的一些主流的軟體思想，並在20世紀90年代進行了綜合，是公認的目前最流行的軟體分析與設計方法，同時它推出了一套標準，使專案開發人員可以不考慮技術細節對系統達成共識，這套標準與應用系統無關，與採用的程式語言無關，開發工具無關。UML是程式設計師之間的交流語言，RUP之類的工具也保證了軟體開發過程的規範性，嚴格保證了先設計後開發，設計階段有規範詳細的規範化的文件等不是唯一的，它不能完全取代傳統的軟體工程方法，實際上在現在的XP理念中對於建模方法的選擇不是唯一的，需要根據實際的業務來選擇合適的建模方式，像傳統的業務流程建模，資料建模也有它們的優勢，我們可以取長補短。

【希賽主持人】網友[meisong]說: 在現實軟體工程應用中，物件導向UML建模方法是否是唯一的，是否取代了傳統的軟工方法？

【希賽嘉賓】不是唯一的，它不能完全取代傳統的軟體工程方法，實際上在現在的XP理念中對於建模方法的選擇不是唯一的，需要根據實際的業務來選擇合適的建模方式，像傳統的業務流程建模，資料建模也有它們的優勢，我們可以取長補短。

【希賽主持人】那UML在專案開發過程中是一個什麼樣的地位？

【希賽嘉賓】UML主要用於系統的分析和設計階段，現在大部分的UML case工具都能自動生成一些程式程式碼，實際上也可以用於一些基本的系統實施階段，同時從UML分析中可以得到一些測試用例，另外UML對系統的維護與設計也有所幫助，好的UML模型讓維護人員在發現問題後可以很快找到問題的根源，在專案開發的全過程中就可以見到UML，但是主要還是分析和設計。

【希賽主持人】那在我國是否存著對UML只是一種形式主義，是一種盲目的炒作與跟風？

【希賽嘉賓】確實對於某些公司和個人來說存在這個現象，但是隨著物件建模技術的發展和應用，越來越多的人會理解怎樣正確使用UML來分析與設計系統的。

       這裡說一個題外話：有時我到長沙的一些高校附近的書店去逛，看到計算機類圖書問老闆有沒有UML的書，很多書店老闆說不好賣，現在的學生很少買這方面的書。

       大學教材一般還是用資料流圖來描述系統，系統設計也主要就是對資料流的分解，我覺得應該讓計算機專業的學生在高校就有對UML的知識一個系統學習更好。

　　實際上，採用UML作的建模語言是完全必要的:首先，各種各樣的物件導向的建模語言都是相互獨立的，而UML可以消除一些潛在的不必要的差異，以免使用者混淆；
　　第二，通過統一語義和符號表示，能夠穩定我國的物件導向技術市場，使專案根植於一個成熟的標準建模語言，從而可以大大拓寬所研製與開發的軟體系統的適用範圍，並大大提高其靈活程度。

【希賽主持人】在現在來講。現在常用的UML建模工具有哪些呢？

【希賽嘉賓】UML建模工具有很多，常用的有：Rational Rose、ArgoUML、Visio、Power Designer、Jude、Enterprise Architect、Together等等，我用的比較多的是Rational Rose，Visio，Power Designer和Jude。現在好象出現了一箇中國自己的UML建模工具，叫在Trufun Plato，有興趣的網友也可以去了解下，畢竟據說是第一款中國的UML建模工具。

【希賽主持人】這些工具有什麼區別呢？我們該如何選擇？

【希賽嘉賓】我個人認為選擇的標準如下：價格、是不是符合UML最新的標準(如:UML2.0)，能不能和資料建模整合，雙向工程，HTML 文件化，程式碼的自動生成，表圖操作的容易性，自動化程度；像正版的Rose 很貴，IBM Rational的這個工具很龐大，適合企業級的一些應用，但是如果只是為了學習沒有必要；Jude是個免費的小工具，可以自動生成Java程式碼，還不錯，推薦大家用做學習；Visio有些圖不太標準，和UML標準有點衝突，但是因為符合office軟體的風格，上手很快；Power Designer在資料建模領域是世界第一，它對UML標準的支援也比較全面，遺憾的是有些圖，如活動圖、狀態圖等提供的功能不完善 ；當然還有其他工具 像EA，Together也是很不錯的UML工具。
　　學哪個工具並不是最重要的，關鍵是UML建模中的思想。

【希賽主持人】劉顧問向我們介紹了UML的一些現狀問題和UML建模工具，現在我們聊一下UML在實際上的東西吧。
　　劉顧問，您有過多年的專案開始與管理經驗，在你的專案中都會用到UML嗎？

【希賽嘉賓】不是所有的專案都用到，想用非面嚮物件語言設計的一些系統或者專案比較小，需求很清晰的系統就可以不需要用到UML，畢竟UML本身也是個比較複雜的建模方式，要均衡一下成本和時間。

【希賽主持人】那使用UML的應用是怎樣的一個流程呢？在專案當中的什麼地方會用到UML？

【希賽嘉賓】這個問題比較複雜，呵……
　　從專案的最開始進行需求分析時需要進行需求建模，要使用到UML中的用例圖，撰寫相應的用例描述文件之後可以從用例描述文件和SRS中尋找名詞和關鍵詞，開始進行靜態建模和動態建模，現從這些名詞得到一些類，對類進行整理和抽象，確定類之間的關係，繪製類圖，有時候需要繪製物件圖，注意的是對於大的專案類圖實際上也有一些模組化的思想在裡面，不可能把一個系統所有的類都畫出來，像一些介面類，控制元件類在類圖中有時候並不需要表示，因為分析設計和開發人員都明白是怎麼回事。
　　我一般對一些複雜的部分，才繪製詳細的類圖，有時候在識別類之間關係時，需要時序圖和協作圖，實際上靜態建模和動態建模是結合使用的，不需要一定要等一個圖全部畫完了再考慮繪製另一類圖。
對於一些複雜的需求用例，可以繪製活動圖，我個人把活動圖理解為物件建模和流程建模的一個交叉點，對於一些複雜的流程，我們用活動圖來表示，但是又加入一些物件的思想，以便清晰知道哪個流程中會與哪些類或物件有關聯。
　　對於一個狀態比較多的類，可以考慮畫狀態圖，以便了解在系統執行中，狀態之間是怎麼轉換的，什麼時候轉換，然後把一些類組織起來，形成包，或者是元件建立元件圖，在java 裡面有個包圖，實際上也是類的集合之間的關係，這些都是更加巨集觀的檢視。
　　最後考慮到系統的真實執行環境，畫部署圖，後面這兩個有時候也叫做構架建模，實際上把UML建模分成四個子建模，可以為：需求建模（第一步）、靜態建模和動態建模（第二步）、構架建模（第三步）。

【希賽主持人】劉顧問，還能談談UML在這些專案上的經驗或者一些心得嗎？

【希賽嘉賓】使用UML來對應用系統進行建模，要注意不能為繪圖而繪圖，就象傳統軟體工程中的文件一樣，不能為寫文件而寫文件。
　　還有幾點是：圖一定要準確反映系統的真實情況，並不是每個系統所有的圖都要，不同的圖表示系統的不同側面，不要幻想用幾個UML圖就能描述整個系統的所有細節，採用最新的標準技術，因為UML1.1和後面的1.3以及2.0還是有點區別的，需要在使用的時候瞭解一下。
　　實際上在UML建模中也有一個簡明規則，就是儘量讓圖畫簡單一些，要是畫到客戶也能夠看懂，但是又能夠表示系統的真實面貌是最好不過的了。

【希賽主持人】那有沒有發現UML不足的地方？

【希賽嘉賓】世界上沒有完美的東西，記得在2002年吧，在《程式設計師》雜誌上看到一篇文章好象叫《UML的三大硬傷》，網友們可以去看看，說到了UML存在的一些缺陷，雖然UML不斷在發展，但是有些問題是一直存在的，那篇文章講到UML在獲取需求，對程式設計工作的指導，建模圖形之間的關係方面都存在不足，所有對於一些複雜的業務流程，我們還是需要用到一些傳統的建模方式來輔助。還有一個就是UML本身也比較複雜，UML工具不統一，大家用過這些工具就知道，不同的工具繪製出來的圖形有時候並不一致，首先對於需求的捕獲，因為UML太專業了，不象一些流程圖，客戶一看就懂，你想畫個類圖給客戶看他能看懂嗎？

【希賽主持人】 網友[cjp106] 說: 能大體說下三大硬傷是那幾個嗎？

【希賽嘉賓】首先對於需求的捕獲困難，因為UML太專業了，不象一些流程圖，客戶一看就懂，你想畫個類圖給客戶看他能看懂嗎？
　　第二，UML建模不像軟體工程中的詳細設計文件，程式碼規範什麼都有了，程式設計師看到這些圖還是要花很多時間去研究怎麼實現這些功能
　　第三、圖太多了，圖與圖之間的關係不明確，很容易造成衝突，建議你去網上找這篇文章看看。
UML的書確實很多，首先大家現在購買的話儘量選擇採用2.0標準的，UML使用者指南，UML參考手冊，UML精髓，UML與模式應用都是不錯的經典。
　　對於需求的描述可以使用UML用例，這與物件導向無關。
       如果是物件導向技術來實現系統，要了解的是要不要濫用UML，這樣反而會導致系統看上去很複雜。例如狀態圖，沒有必要任何一個類都畫一個。
　　有時候初學者喜歡賣弄，例如一個公交反饋系統，像這個系統中一個很關鍵的名詞是反饋，在程式碼中會被設計為一個類，被例項化成一個物件後就存在多個狀態，例如剛被提交的反饋，通過調查確定其真實性的反饋，對真實反饋進行跟蹤最後採取了糾正行動的反饋，所有操作都完成的歷史反饋，這些狀態在系統分析時有時候把人搞暈了，如果畫個狀態圖那就清晰很多了。但是並不是所有的類都有這麼多狀態的。

　　初學者首先下載個免費的工具，像Jude，拿一個小專案出來，一邊分析一邊學，理解每個圖的含義和作用，重點是三個圖先理解：用例圖、類圖、時序圖，其他圖再慢慢理解，是否使用UML的關鍵決定因素是需求的穩定性，系統的規模，是否採用物件導向的開發方式，系統的可維護性與團隊的協作能力等。

【希賽主持人】最後，劉顧問對要即將涉足UML的企業或要學習UML個人有什麼建議？

【希賽嘉賓】首先要有一個完整的學習，特別是對於軟體企業，美國UML使用相對成功的原因之一是他們的企業對客戶都進行了UML培訓，另外還是那句話——UML圖形要保持簡潔，不要太過複雜，不需要的圖儘量不畫。

　　理解物件建模的一些原則，選擇合適的CASE工具，對於小型專案可以不使用UML的不要濫用，有意識培養程式設計師的分析設計能力。
　　從一開始學就養成一些好的繪圖習慣，一定要對圖中的一些關鍵字進行註釋。

【希賽主持人】由於時間的關係，今天聊天就到這裡，可能些有網友還有問題，可以在希賽社群中發貼與大家交流，我們的嘉賓也會給您解答的。

　　謝謝劉顧問的參與，也謝謝各位網友的參與，我們下次嘉賓聊天再見！

【希賽嘉賓】如果大家在UML方面還有一些想法，我們可以進一步交流。我的郵箱地址是weiliu_china@hotmail.com再見！

【作者：劉偉 http://blog.csdn.net/lovelion】