?

古今之成大事業、大學問者，必經過三種之境界，今之UML應用的三重境界能給你帶來什么呢？本文主要討論了兩個問題：一是為什么軟件開發過程需要建模，二是建模為什么要使用UML語言。

先從幾年前的一次爭論談起吧。2002年5月某IT雜志刊登了一篇知名學者高展先生的文章：《UML三大“硬傷”》，文章說UML“上不著天、下不著地、一盤散沙”，后即引來業界關于UML的一場大討論。

在細述這場論戰之前，且讓我們先來回答兩個問題，第一個問題是為什么軟件開發過程需要建模，第二個問題是建模為什么要使用UML語言。

想搭一個狗窩，備好木料、釘子和一些基本工具之后，就可以開始工作了，在沒有別人幫忙的情況下，幾個小時也可以完工；如果想為家庭建造一所房子，備好木料、釘子和一些基本工具之后，也能開始工作，但這將需要較長的時間，并且，除非曾經多次建造過房子，否則就需要事先制定出一些詳細的計劃，再開始動工，才能夠成功；而如果要建設高樓時，仍然是先備好木料、釘子和一些基本工具就開始工作，那將是非常愚蠢的。

那么在軟件開發中，如果我們不事先建立模型，做好計劃，就開始倉促去實現，那就好比在使用建造狗窩的工具來建造一座大廈。而建模是一項經過檢驗并被廣為接受的工程技術，模型提供了系統的藍圖。模型可以是結構性的，強調系統的組織。它也可以是行為性的，強調系統的動態方面。

通過建模，可以達到4個目的：模型有助于按照實際情況或按照所需要的樣式對系統進行可視化；模型能夠規約系統的結構或行為；模型給出了指導構造系統的模板；模型對做出的決策進行文檔化。

下面讓我們來到文章開頭提到的那場論戰。論戰的發起者高先生也許當初也沒有想到文章發表之后引來的激烈反應。綜合高先生那篇文章的主旨，可以概括為UML“上不著天，下不著地，一盤散沙”，他認為：UML上不著天，也就是說用UML建立的模型無法與用戶溝通；下不著地，采用UML設計的模型不能為程序員所用；一盤散沙，UML建立的各種模型之間關系凌亂，無法實際應用。

我的看法是，高先生此三點意見卻恰恰就是UML的三大優點，關鍵在于應用。如果使用不好，則在應用過程中是會發生這樣的錯覺，認為使用了UML反而會給項目帶來額外的負擔；但是如果能有效地根據實際項目和人員情況對UML進行裁減，制定出適合的UML應用方法，并通過項目來逐步積累和推進，那么UML這個神兵寶器則會大放異彩，體現它應有的價值。就譬如金箍棒，倘若等閑之輩得之，不過是廢鐵一塊；如若在悟空手中，則大如倚天之柱，小則化為繡花針，降妖除魔，變為至寶。

那么如何能有效利用UML呢？就如王國維所談詞作的三重境界，UML的利用也可以分為三種境界。

王國維在《人間詞話》里談到：“古今之成大事業、大學問者，必經過三種之境界：‘昨夜西風凋碧樹。獨上高樓，望盡天涯路’。此第一境也。‘衣帶漸寬終不悔，為伊消得人憔悴。’此第二境也。‘眾里尋他千百度，驀然回首那人卻在，燈火闌珊處’。此第三境也。”

第一重境界：霧里看花

屬于UML的初級應用，對UML有了初步的一點了解，知道了用例圖，類圖，能畫出簡單的時序圖、協作圖等。初入UML的世界，各種圖型的特性、適用范圍、圖形元素的功用都還一知半解，而UML龐大的體系足以讓初入者無從著手，就好比駕一扁舟，漂游于大海之上，“望盡天涯路”而不知所歸。在第一重境界的應用所要完成的目標是達到與客戶的需求溝通，即解決前文所說的“上不著天”的問題。在初級階段，如果能擁有扎實的面向對象設計基礎，同時配合以良好的UML工具，那么可以很快度過這個階段，來到下一重境界。

第二重境界：小樓一夜聽春雨

從第一重境界的迷茫中走過來了，當然這是一個痛苦的過程，不然為何“衣帶漸寬”呢。如果說在第一個階段的UML應用是屬于局部范圍的應用，那么到第二重境界，則是全局的利用UML了。在這個階段，開始初窺UML的奧妙，不僅可以借助于UML的用例圖、時序圖等完成與用戶的需求溝通，而且在此基礎上，可以使用UML的類圖、交互圖、部署圖、組件圖等指導程序員進行開發。在第二重境界下，解決了前文所說的“下不著地”的問題 。

第三重境界：如魚得水

隨著UML的項目實踐增加，軟件組織也在不斷的成長。明白了UML只是一種方法，而獨立于過程，在實踐中，UML是貫徹整個軟件開發過程，解決了“一盤散沙”的問題。通過在前期需求分析階段形成的業務用例模型，通過細化，進一步描述業務的細節，并且通過UML的類圖、交互圖等可以建立目標系統的邏輯模型。而UML應用的最高層次則是將UML作為一種“高高級”語言，實現從目標系統邏輯模型向物理模型的直接轉換。

通過在現有的高級語言基礎上描述業務過程，而UML編程語言的編譯器則可以實現UML語言的編譯執行，這也是當前MDA（Model Driven Architecture, 模型驅動架構）所追求的目標。

可以說，UML對系統模型的表達能力超出了以往任何一種面向對象的分析和設計方法。隨之出現的問題是，它的復雜性也超出了以往任何一種方法。由于UML的復雜性，對它的掌握和使用確實不是一件輕松的事。因此，從初入“霧里看花”的第一重境界，并逐步進入到“如魚得水”是一個循序漸進的過程，是一個逐步學習，逐步應用與提高的過程。

首先，UML是一個復雜的體系，而且為了能夠靈活的適應各種項目的需要，增加了很多符號，而并不是每一個項目都需要使用到這些符號。為了成功使用UML，在使用的過程中必須流程化使用，針對不同的項目實際情況，對UML符號進行裁剪。當然，這也意味著幾乎任何項目都可以使用UML來建模。

第二，需要保持項目組對UML的統一一致的理解，這是建模成功的保障。畢竟，現在大型項目都是幾十個甚至成百上千的人員牽涉其中，要確保負責設計與開發人員對UML的各種符號有統一的理解，不然，UML不但不能起到溝通橋梁的作用，反而會導致信息傳遞的失真。可以通過項目組的培訓等方式來實現。

第三，簡單有效才是最重要的。一般說來，項目組成員的設計分析能力、以及對UML的理解使用能力是層次不一的，即使通過培訓能提高部分程序員的水平，但是，經驗、閱歷這是不能通過培訓來解決的。因此，只有保持最簡單有效的過程，使用最簡單的UML圖形，才能使得UML的應用達到最佳的效果。而如果我們為了詳盡的描述一個用例，使用了一系列完整的時序圖、協作圖、狀態圖、部署圖、用例圖和類圖，這樣，可能導致一個團隊完全脫離面向對象分析和設計。

第四，抉擇畫圖。畫UML圖是一種非常有用的活動，它也可能成為一種浪費時間的、可怕的活動。不需要制定什么都必須畫圖的規則，因為這樣的規則將比不用更糟糕。項目的大量時間和精力將會被浪費在追逐那個根本沒有人去讀的圖上。下面列舉了需要畫圖的情況：

當許多人一起需要同時進行開發時，這些人需要都理解一個系統的特定部分的設計結構時，開始畫圖。當所有的人都已經聲明理解了的時候，結束畫圖。

當兩個人或更多人不同意一個特定的元素如何設計的時候，需要團隊意見一致的時候，要找一個時間進行討論做出決定，比如投票，或一個公正的宣告的方式進行，這時需要畫圖。當決定做出來后，擦掉這些圖。

當需要探討一個設計的想法時，畫圖能夠幫我們更好地思考。當得到了能夠幫助我們完成思考的代碼的要點的時候，扔掉這些圖。

當需要向其他人或自己解釋一部分代碼的結構的時候，可以畫圖。當覺得其實最好看代碼來進行解釋的時候，停止畫圖。

當項目快要結束，顧客需要我們將圖與其他文檔一起提供的時候，開始畫圖。

在項目中使用UML，需要時刻記住的是保持簡單，并且結合軟件工程文檔，同時讓項目組對過程有統一的認識。很多成功的項目都采用用例驅動，迭代，遞增方法的。如果能把過程細化并且讓項目組掌握技巧，那么UML項目已經離成功不遠了。

系統開發過程

UML簡介

UML起源于面向對象的分析與設計方法。

在80年代末至90年代中，對面向對象分析與設計方法的研究發展到一個高潮。但是，諸多流派在思想和術語上有很多不同的提法，在術語、概念上的運用也各不相同，需要一種統一的符號來描述面向對象的分析和設計活動。UML應運而生。它不僅統一了Booch、Rumbaugh和Jacobson的表示方法，而且有進一步的發展，最終成為大眾所共同接受的標準建模語言。

UML是一種定義良好、易于表達、功能強大且普遍適用的建模語言。它融入了軟件工程領域的新思想、新方法和新技術。不僅支持面向對象的分析與設計，還支持從需求分析開始的軟件開發全過程。