本節(jié)和大家一起學(xué)習(xí)一下UML應(yīng)用的三種境界，UML有很多值得學(xué)習(xí)的地方，這里和大家分享一下UML應(yīng)用的三種境界，希望通過本節(jié)的學(xué)習(xí)你一定會(huì)對(duì)UML應(yīng)用有一定的了解。

UML應(yīng)用的三重境界

古今之成大事業(yè)、大學(xué)問者，必經(jīng)過三種之境界，今之UML應(yīng)用的三重境界能給你帶來什么呢？
先從幾年前的一次爭論談起吧。2002年5月某IT雜志刊登了一篇知名學(xué)者高展先生的文章:《UML三大“硬傷”》，文章說UML“上不著天、下不著地、一盤散沙”，后即引來業(yè)界關(guān)于UML的一場大討論。

在細(xì)述這場論戰(zhàn)之前，且讓我們先往返答兩個(gè)問題，第一個(gè)問題是為什么軟件開發(fā)過程需要建模，第二個(gè)問題是建模為什么要使用UML語言。

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

那么在軟件開發(fā)中，假如我們不事先建立模型，做好計(jì)劃，就開始倉促去實(shí)現(xiàn)，那就好比在使用建造狗窩的工具來建造一座大廈。而建模是一項(xiàng)經(jīng)過檢驗(yàn)并被廣為接受的工程技術(shù)，模型提供了系統(tǒng)的藍(lán)圖。模型可以是結(jié)構(gòu)性的，強(qiáng)調(diào)系統(tǒng)的組織。它也可以是行為性的，強(qiáng)調(diào)系統(tǒng)的動(dòng)態(tài)方面。
通過建模，可以達(dá)到4個(gè)目的:模型有助于按照實(shí)際情況或按照所需要的樣式對(duì)系統(tǒng)進(jìn)行可視化;模型能夠規(guī)約系統(tǒng)的結(jié)構(gòu)或行為;模型給出了指導(dǎo)構(gòu)造系統(tǒng)的模板;模型對(duì)做出的決策進(jìn)行文檔化。

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

我的看法是，高先生此三點(diǎn)意見卻恰恰就是UML的三大優(yōu)點(diǎn)，關(guān)鍵在于應(yīng)用。假如使用不好，則在應(yīng)用過程中是會(huì)發(fā)生這樣的錯(cuò)覺，認(rèn)為使用了UML反而會(huì)給項(xiàng)目帶來額外的負(fù)擔(dān);但是假如能有效地根據(jù)實(shí)際項(xiàng)目和人員情況對(duì)UML進(jìn)行裁減，制定出適合的UML應(yīng)用方法，并通過項(xiàng)目來逐步積累和推進(jìn)，那么UML這個(gè)神兵寶器則會(huì)大放異彩，體現(xiàn)它應(yīng)有的價(jià)值。就譬如金箍棒，倘若等閑之輩得之，不過是廢鐵一塊;如若在悟空手中，則大如倚天之柱，小則化為繡花針，降妖除魔，變?yōu)橹翆殹?/p>

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

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

第一重境界:霧里看花

屬于UML的初級(jí)應(yīng)用，對(duì)UML有了初步的一點(diǎn)了解，知道了用例圖，類圖，能畫出簡單的時(shí)序圖、協(xié)作圖等。初入U(xiǎn)ML的世界，各種圖型的特性、適用范圍、圖形元素的功用都還一知半解，而UML龐大的體系足以讓初入者無從著手，就好比駕一扁舟，漂游于大海之上，“望盡天邊路”而不知所歸。在第一重境界的應(yīng)用所要完成的目標(biāo)是達(dá)到與客戶的需求溝通，即解決前文所說的“上不著天”的問題。在初級(jí)階段，假如能擁有扎實(shí)的面向?qū)ο笤O(shè)計(jì)基礎(chǔ)，同時(shí)配合以良好的UML工具，那么可以很快度過這個(gè)階段，來到下一重境界。

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

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

第三重境界:如魚得水

隨著UML的項(xiàng)目實(shí)踐增加，軟件組織也在不斷的成長。明白了UML只是一種方法，而獨(dú)立于過程，在實(shí)踐中，UML是貫徹整個(gè)軟件開發(fā)過程，解決了“一盤散沙”的問題。通過在前期需求分析階段形成的業(yè)務(wù)用例模型，通過細(xì)化，進(jìn)一步描述業(yè)務(wù)的細(xì)節(jié)，并且通過UML的類圖、交互圖等可以建立目標(biāo)系統(tǒng)的邏輯模型。而UML應(yīng)用的最高層次則是將UML作為一種“高高級(jí)”語言，實(shí)現(xiàn)從目標(biāo)系統(tǒng)邏輯模型向物理模型的直接轉(zhuǎn)換。

通過在現(xiàn)有的高級(jí)語言基礎(chǔ)上描述業(yè)務(wù)過程，而UML編程語言的編譯器則可以實(shí)現(xiàn)UML語言的編譯執(zhí)行，這也是當(dāng)前MDA（ModelDrivenArchitecture，模型驅(qū)動(dòng)架構(gòu)）所追求的目標(biāo)。

可以說，UML應(yīng)用對(duì)系統(tǒng)模型的表達(dá)能力超出了以往任何一種面向?qū)ο蟮姆治龊驮O(shè)計(jì)方法。隨之出現(xiàn)的問題是，它的復(fù)雜性也超出了以往任何一種方法。由于UML的復(fù)雜性，對(duì)它的把握和使用確實(shí)不是一件輕松的事。因此，從初入“霧里看花”的第一重境界，并逐步進(jìn)入到“如魚得水”是一個(gè)循序漸進(jìn)的過程，是一個(gè)逐步學(xué)習(xí)，逐步應(yīng)用與提高的過程。

首先，UML是一個(gè)復(fù)雜的體系，而且為了能夠靈活的適應(yīng)各種項(xiàng)目的需要，增加了很多符號(hào)，而并不是每一個(gè)項(xiàng)目都需要使用到這些符號(hào)。為了成功使用UML，在使用的過程中必須流程化使用，針對(duì)不同的項(xiàng)目實(shí)際情況，對(duì)UML符號(hào)進(jìn)行裁剪。當(dāng)然，這也意味著幾乎任何項(xiàng)目都可以使用UML來建模。

第二，需要保持項(xiàng)目組對(duì)UML的統(tǒng)一一致的理解，這是建模成功的保障。究竟，現(xiàn)在大型項(xiàng)目都是幾十個(gè)甚至成百上千的人員牽涉其中，要確保負(fù)責(zé)設(shè)計(jì)與開發(fā)人員對(duì)UML的各種符號(hào)有統(tǒng)一的理解，不然，UML應(yīng)用不但不能起到溝通橋梁的作用，反而會(huì)導(dǎo)致傳遞的失真?？梢酝ㄟ^項(xiàng)目組的培訓(xùn)等方式來實(shí)現(xiàn)。

第三，簡單有效才是最重要的。一般說來，項(xiàng)目組成員的設(shè)計(jì)分析能力、以及對(duì)UML的理解使用能力是層次不一的，即使通過培訓(xùn)能提高部分程序員的水平，但是，經(jīng)驗(yàn)、閱歷這是不能通過培訓(xùn)來解決的。因此，只有保持最簡單有效的過程，使用最簡單的UML圖形，才能使得UML的應(yīng)用達(dá)到最佳的效果。而假如我們?yōu)榱嗽敱M的描述一個(gè)用例，使用了一系列完整的時(shí)序圖、協(xié)作圖、狀態(tài)圖、部署圖、用例圖和類圖，這樣，可能導(dǎo)致一個(gè)團(tuán)隊(duì)完全脫離面向?qū)ο蠓治龊驮O(shè)計(jì)。

第四，抉擇畫圖。畫UML圖是一種非常有用的活動(dòng)，它也可能成為一種浪費(fèi)時(shí)間的、可怕的活動(dòng)。不需要制定什么都必須畫圖的規(guī)則，因?yàn)檫@樣的規(guī)則將比不用更糟糕。項(xiàng)目的大量時(shí)間和精力將會(huì)被浪費(fèi)在追逐那個(gè)根本沒有人去讀的圖上。下面列舉了需要畫圖的情況:

當(dāng)許多人一起需要同時(shí)進(jìn)行開發(fā)時(shí)，這些人需要都理解一個(gè)系統(tǒng)的特定部分的設(shè)計(jì)結(jié)構(gòu)時(shí)，開始畫圖。當(dāng)所有的人都已經(jīng)聲明理解了的時(shí)候，結(jié)束畫圖。

當(dāng)兩個(gè)人或更多人不同意一個(gè)特定的元素如何設(shè)計(jì)的時(shí)候，需要團(tuán)隊(duì)意見一致的時(shí)候，要找一個(gè)時(shí)間進(jìn)行討論做出決定，比如投票，或一個(gè)公正的宣告的方式進(jìn)行，這時(shí)需要畫圖。當(dāng)決定做出來后，擦掉這些圖。

當(dāng)需要探討一個(gè)設(shè)計(jì)的想法時(shí)，畫圖能夠幫我們更好地思考。當(dāng)?shù)玫搅四軌驇椭覀兺瓿伤伎嫉拇a的要點(diǎn)的時(shí)候，扔掉這些圖。

當(dāng)需要向其他人或自己解釋一部分代碼的結(jié)構(gòu)的時(shí)候，可以畫圖。當(dāng)覺得其實(shí)最好看代碼來進(jìn)行解釋的時(shí)候，停止畫圖。

當(dāng)項(xiàng)目快要結(jié)束，顧客需要我們將圖與其他文檔一起提供的時(shí)候，開始畫圖。

在項(xiàng)目中使用UML，需要時(shí)刻記住的是保持簡單，并且結(jié)合軟件工程文檔，同時(shí)讓項(xiàng)目組對(duì)過程有統(tǒng)一的熟悉。很多成功的項(xiàng)目都采用用例驅(qū)動(dòng)，迭代，遞增方法的。假如能把過程細(xì)化并且讓項(xiàng)目組把握技巧，那么UML項(xiàng)目已經(jīng)離成功不遠(yuǎn)了。本節(jié)關(guān)于UML應(yīng)用的三種境界介紹到這里。
 

【編輯推薦】

1. UML應(yīng)用的三重境界
2. 專家解析 圖書館管理系統(tǒng)中UML應(yīng)用
3. 實(shí)例講解UML對(duì)象圖使用
4. 軟件設(shè)計(jì)過程中面向?qū)ο骍ML技術(shù)如何使用
5. UML建?；A(chǔ)教程