建站
咨詢
售后
建站咨詢
新聞中心
本節(jié)和大家一起學習一下UML應用的三種境界，UML有很多值得學習的地方，這里和大家分享一下UML應用的三種境界，希望通過本節(jié)的學習你一定會對UML應用有一定的了解。
UML應用的三重境界
古今之成大事業(yè)、大學問者，必經(jīng)過三種之境界，今之UML應用的三重境界能給你帶來什么呢？
先從幾年前的一次爭論談起吧。2002年5月某IT雜志刊登了一篇知名學者高展先生的文章:《UML三大“硬傷”》，文章說UML“上不著天、下不著地、一盤散沙”，后即引來業(yè)界關(guān)于UML的一場大討論。
在細述這場論戰(zhàn)之前，且讓我們先往返答兩個問題，第一個問題是為什么軟件開發(fā)過程需要建模，第二個問題是建模為什么要使用UML語言。
想搭一個狗窩，備好木料、釘子和一些基本工具之后，就可以開始工作了，在沒有別人幫忙的情況下，幾個小時也可以完工;假如想為家庭建造一所房子，備好木料、釘子和一些基本工具之后，也能開始工作，但這將需要較長的時間，并且，除非曾經(jīng)多次建造過房子，否則就需要事先制定出一些具體的計劃，再開始動工，才能夠成功;而假如要建設高樓時，仍然是先備好木料、釘子和一些基本工具就開始工作，那將是非常愚蠢的。
那么在軟件開發(fā)中，假如我們不事先建立模型，做好計劃，就開始倉促去實現(xiàn)，那就好比在使用建造狗窩的工具來建造一座大廈。而建模是一項經(jīng)過檢驗并被廣為接受的工程技術(shù)，模型提供了系統(tǒng)的藍圖。模型可以是結(jié)構(gòu)性的，強調(diào)系統(tǒng)的組織。它也可以是行為性的，強調(diào)系統(tǒng)的動態(tài)方面。
通過建模，可以達到4個目的:模型有助于按照實際情況或按照所需要的樣式對系統(tǒng)進行可視化;模型能夠規(guī)約系統(tǒng)的結(jié)構(gòu)或行為;模型給出了指導構(gòu)造系統(tǒng)的模板;模型對做出的決策進行文檔化。
下面讓我們來到文章開頭提到的那場論戰(zhàn)。論戰(zhàn)的發(fā)起者高先生也許當初也沒有想到文章發(fā)表之后引來的激烈反應。綜合高先生那篇文章的主旨，可以概括為UML“上不著天，下不著地，一盤散沙”，他認為:UML上不著天，也就是說用UML建立的模型無法與用戶溝通;下不著地，采用UML設計的模型不能為程序員所用;一盤散沙，UML建立的各種模型之間關(guān)系凌亂，無法實際應用。
我的看法是，高先生此三點意見卻恰恰就是UML的三大優(yōu)點，關(guān)鍵在于應用。假如使用不好，則在應用過程中是會發(fā)生這樣的錯覺，認為使用了UML反而會給項目帶來額外的負擔;但是假如能有效地根據(jù)實際項目和人員情況對UML進行裁減，制定出適合的UML應用方法，并通過項目來逐步積累和推進，那么UML這個神兵寶器則會大放異彩，體現(xiàn)它應有的價值。就譬如金箍棒，倘若等閑之輩得之，不過是廢鐵一塊;如若在悟空手中，則大如倚天之柱，小則化為繡花針，降妖除魔，變?yōu)橹翆殹?/p>
那么如何能有效利用UML呢？就如王國維所談詞作的三重境界，UML的利用也可以分為三種境界。
王國維在《人間詞話》里談到:“古今之成大事業(yè)、大學問者，必經(jīng)過三種之境界:‘昨夜西風凋碧樹。獨上高樓，望盡天邊路’。此第一境也?！聨u寬終不悔，為伊消得人憔悴?！说诙骋??！娎飳にО俣龋嚾换厥啄侨藚s在，燈火闌珊處’。此第三境也?！?/p>
第一重境界:霧里看花
屬于UML的初級應用，對UML有了初步的一點了解，知道了用例圖，類圖，能畫出簡單的時序圖、協(xié)作圖等。初入UML的世界，各種圖型的特性、適用范圍、圖形元素的功用都還一知半解，而UML龐大的體系足以讓初入者無從著手，就好比駕一扁舟，漂游于大海之上，“望盡天邊路”而不知所歸。在第一重境界的應用所要完成的目標是達到與客戶的需求溝通，即解決前文所說的“上不著天”的問題。在初級階段，假如能擁有扎實的面向?qū)ο笤O計基礎(chǔ)，同時配合以良好的UML工具，那么可以很快度過這個階段，來到下一重境界。
第二重境界:小樓一夜聽春雨
從第一重境界的迷茫中走過來了，當然這是一個痛苦的過程，不然為何“衣帶漸寬”呢。假如說在第一個階段的UML應用是屬于局部范圍的應用，那么到第二重境界，則是全局的利用UML了。在這個階段，開始初窺UML的奧妙，不僅可以借助于UML的用例圖、時序圖等完成與用戶的需求溝通，而且在此基礎(chǔ)上，可以使用UML的類圖、交互圖、部署圖、組件圖等指導程序員進行開發(fā)。在第二重境界下，解決了前文所說的“下不著地”的問題。
第三重境界:如魚得水
隨著UML的項目實踐增加，軟件組織也在不斷的成長。明白了UML只是一種方法，而獨立于過程，在實踐中，UML是貫徹整個軟件開發(fā)過程，解決了“一盤散沙”的問題。通過在前期需求分析階段形成的業(yè)務用例模型，通過細化，進一步描述業(yè)務的細節(jié)，并且通過UML的類圖、交互圖等可以建立目標系統(tǒng)的邏輯模型。而UML應用的最高層次則是將UML作為一種“高高級”語言，實現(xiàn)從目標系統(tǒng)邏輯模型向物理模型的直接轉(zhuǎn)換。
通過在現(xiàn)有的高級語言基礎(chǔ)上描述業(yè)務過程，而UML編程語言的編譯器則可以實現(xiàn)UML語言的編譯執(zhí)行，這也是當前MDA（ModelDrivenArchitecture，模型驅(qū)動架構(gòu)）所追求的目標。
可以說，UML應用對系統(tǒng)模型的表達能力超出了以往任何一種面向?qū)ο蟮姆治龊驮O計方法。隨之出現(xiàn)的問題是，它的復雜性也超出了以往任何一種方法。由于UML的復雜性，對它的把握和使用確實不是一件輕松的事。因此，從初入“霧里看花”的第一重境界，并逐步進入到“如魚得水”是一個循序漸進的過程，是一個逐步學習，逐步應用與提高的過程。
首先，UML是一個復雜的體系，而且為了能夠靈活的適應各種項目的需要，增加了很多符號，而并不是每一個項目都需要使用到這些符號。為了成功使用UML，在使用的過程中必須流程化使用，針對不同的項目實際情況，對UML符號進行裁剪。當然，這也意味著幾乎任何項目都可以使用UML來建模。
第二，需要保持項目組對UML的統(tǒng)一一致的理解，這是建模成功的保障。究竟，現(xiàn)在大型項目都是幾十個甚至成百上千的人員牽涉其中，要確保負責設計與開發(fā)人員對UML的各種符號有統(tǒng)一的理解，不然，UML應用不但不能起到溝通橋梁的作用，反而會導致傳遞的失真?？梢酝ㄟ^項目組的培訓等方式來實現(xiàn)。
第三，簡單有效才是最重要的。一般說來，項目組成員的設計分析能力、以及對UML的理解使用能力是層次不一的，即使通過培訓能提高部分程序員的水平，但是，經(jīng)驗、閱歷這是不能通過培訓來解決的。因此，只有保持最簡單有效的過程，使用最簡單的UML圖形，才能使得UML的應用達到最佳的效果。而假如我們?yōu)榱嗽敱M的描述一個用例，使用了一系列完整的時序圖、協(xié)作圖、狀態(tài)圖、部署圖、用例圖和類圖，這樣，可能導致一個團隊完全脫離面向?qū)ο蠓治龊驮O計。
第四，抉擇畫圖。畫UML圖是一種非常有用的活動，它也可能成為一種浪費時間的、可怕的活動。不需要制定什么都必須畫圖的規(guī)則，因為這樣的規(guī)則將比不用更糟糕。項目的大量時間和精力將會被浪費在追逐那個根本沒有人去讀的圖上。下面列舉了需要畫圖的情況:
當許多人一起需要同時進行開發(fā)時，這些人需要都理解一個系統(tǒng)的特定部分的設計結(jié)構(gòu)時，開始畫圖。當所有的人都已經(jīng)聲明理解了的時候，結(jié)束畫圖。
當兩個人或更多人不同意一個特定的元素如何設計的時候，需要團隊意見一致的時候，要找一個時間進行討論做出決定，比如投票，或一個公正的宣告的方式進行，這時需要畫圖。當決定做出來后，擦掉這些圖。
當需要探討一個設計的想法時，畫圖能夠幫我們更好地思考。當?shù)玫搅四軌驇椭覀兺瓿伤伎嫉拇a的要點的時候，扔掉這些圖。
當需要向其他人或自己解釋一部分代碼的結(jié)構(gòu)的時候，可以畫圖。當覺得其實最好看代碼來進行解釋的時候，停止畫圖。
當項目快要結(jié)束，顧客需要我們將圖與其他文檔一起提供的時候，開始畫圖。
在項目中使用UML，需要時刻記住的是保持簡單，并且結(jié)合軟件工程文檔，同時讓項目組對過程有統(tǒng)一的熟悉。很多成功的項目都采用用例驅(qū)動，迭代，遞增方法的。假如能把過程細化并且讓項目組把握技巧，那么UML項目已經(jīng)離成功不遠了。本節(jié)關(guān)于UML應用的三種境界介紹到這里。
網(wǎng)站標題：UML應用的三種境界中你屬于哪一種
網(wǎng)頁路徑：http://www.fisionsoft.com.cn/article/dpeoopp.html
