九大UML建模誤區(qū)不得不防
本文和大家重點(diǎn)討論一下UML建模的幾個(gè)誤區(qū)，通過(guò)對(duì)這些誤區(qū)的了解，你會(huì)在UML建模過(guò)程中少走不少?gòu)澛?，希望本文的學(xué)習(xí)對(duì)你有所幫助。
UML建模誤區(qū)
通過(guò)理解和避開(kāi)UML建模的誤區(qū)，你能夠是得你自己、你的項(xiàng)目組和你的組織更加有效地進(jìn)行軟件開(kāi)發(fā)。在揭示這些普遍存在誤區(qū)的過(guò)程中，我已經(jīng)表述了AgileModeling(AM)的許多原則。AgileModeling以前叫做ExtremeModeling(XM)。我希望我所給于你的是精神上的食糧。
--------------------------------------------------------------------------------
無(wú)論你遵從的是重量級(jí)的方法,比如EnterpriseUnifiedProcess(EUP)，還是輕量級(jí)的開(kāi)發(fā)過(guò)程，如ExtremeProgramming(XP)，UML建模在軟件開(kāi)發(fā)中都是不可或缺的。但不幸的是其中充斥著各種謬誤與迷思。這來(lái)自于各個(gè)方面，有從理論家錯(cuò)誤的研究、數(shù)十年來(lái)信息技術(shù)領(lǐng)域內(nèi)的文化沉積、軟件工具開(kāi)發(fā)商天花亂墜半的市場(chǎng)宣傳以及象ObjectManagementGroup(OMG)和IEEE這類組織的標(biāo)準(zhǔn)。這個(gè)月，我要揭示UML建模中的誤區(qū)，指出其相應(yīng)的事實(shí)真相。
UML建模誤區(qū)一：UML建模就等于是寫(xiě)文檔
這很可能是其中***破壞力的一條，因?yàn)殚_(kāi)發(fā)人員可以此為借口而完全放棄UML建模。許多優(yōu)秀的軟件開(kāi)發(fā)人員會(huì)說(shuō)他們不想把時(shí)間浪費(fèi)在這些“無(wú)用的“文檔上。他們沉溺于編碼之中，制造著一些脆弱而劣質(zhì)的系統(tǒng)。另外，甚至于許多盡責(zé)的開(kāi)發(fā)人員現(xiàn)在也認(rèn)為UML建模是一件討厭的事，而不愿去學(xué)習(xí)相應(yīng)的UML建模技術(shù)。
事實(shí)分析：“模型”與“文檔”這二者在概念上是風(fēng)馬牛不相及的—你可以擁有一個(gè)不是文檔的模型和不是模型的文檔。一幅設(shè)計(jì)圖就是一個(gè)模型，而不論是被畫(huà)在餐巾紙的背面，或?qū)懺谝粔K白板上，或在ClassResponsibilityCollaboration(CRC)卡片中，還是根據(jù)記錄在報(bào)紙和便簽紙上的流程圖而生成的一個(gè)粗略的用戶界面原型。雖然這些都不能說(shuō)是文檔，但他們卻都是有價(jià)值的模型。
UML建模很象是作計(jì)劃：作計(jì)劃的價(jià)值在于計(jì)劃編制的過(guò)程中，而非計(jì)劃本身；價(jià)值體現(xiàn)在UML建模的活動(dòng)中，而非模型本身。實(shí)際上，模型不是你系統(tǒng)中的一部分正式的文檔，而且在完成它們的使命后可以被丟掉。你會(huì)發(fā)現(xiàn)值得保留的只有很少的模型，而且它一定是非常***。
UML建模誤區(qū)二：從開(kāi)始階段你可以考慮到所有的一切
這種說(shuō)法流行于二十世紀(jì)七十年代到八十年代早期，現(xiàn)今的許多經(jīng)理都是在那個(gè)時(shí)候?qū)W習(xí)的軟件開(kāi)發(fā)。對(duì)這一點(diǎn)的迷信會(huì)導(dǎo)致在前期投入可觀的時(shí)間去對(duì)所有的一切UML建模以期把所有一切都弄正確，試圖在編碼開(kāi)始前就“凍結(jié)”所有的需求（見(jiàn)誤區(qū)四），以致于患上“分析期麻痹癥”–要等到模型非常***之后才敢向前進(jìn)?；谶@個(gè)觀點(diǎn)，項(xiàng)目組開(kāi)發(fā)了大量的文檔，而不是他們真正想要得到的—開(kāi)發(fā)滿足需要的軟件。
事實(shí)分析：怎么才能走出這個(gè)誤區(qū)呢？首先，你必須認(rèn)識(shí)到你不能考慮到所有的細(xì)枝末節(jié)。第二，認(rèn)識(shí)到編碼員可能會(huì)對(duì)UML建模者的工作不以為然（這是可能的，事實(shí)上UML建模者所作的工作在實(shí)際價(jià)值中只占很少的部分），他們或許會(huì)說(shuō)模型沒(méi)有反應(yīng)出真實(shí)的情況。第三，認(rèn)識(shí)到不管你的最初所作的規(guī)格說(shuō)明書(shū)有多好，但注定代碼會(huì)很快地與之失去同步，即便是你自己UML建模自己編碼。一個(gè)基本的道理就是代碼永遠(yuǎn)只會(huì)和代碼保持一致。第四，認(rèn)識(shí)到迭代法（小規(guī)模地UML建模，編一些代碼，做一些測(cè)試，可能還會(huì)做一個(gè)小的工作版本）是軟件開(kāi)發(fā)的準(zhǔn)則。它是現(xiàn)代重量級(jí)的軟件開(kāi)發(fā)過(guò)程（如EUP），以及輕量級(jí)（如XP)的基本原理。
UML建模誤區(qū)三：UML建模意味著需要一個(gè)重量級(jí)的軟件開(kāi)發(fā)過(guò)程
走入這個(gè)誤區(qū)（經(jīng)常與誤區(qū)一有聯(lián)系）的項(xiàng)目組常常是連UML建模都徹底地放棄了，應(yīng)為這樣的軟件開(kāi)發(fā)過(guò)程對(duì)他們來(lái)說(shuō)太復(fù)雜太沉重了。這不亞于一場(chǎng)天災(zāi)。
事實(shí)分析：你可以用一種敏捷的方式取而代之。關(guān)于用簡(jiǎn)單的工具進(jìn)行簡(jiǎn)單地UML建模的詳細(xì)內(nèi)容可參看AgileModeling(AM)。而且，你可以丟棄你的模型當(dāng)使命完之后，同樣也可以很基本的方式進(jìn)行UML建模（比如，從辦公桌起來(lái)，來(lái)到白板前就開(kāi)始構(gòu)略草圖）。只要你愿意，你就可以輕松地UML建模。
UML建模誤區(qū)四：必須“凍結(jié)”需求
這個(gè)要求常常來(lái)自高級(jí)經(jīng)理，他們確切地想知道他們從這個(gè)項(xiàng)目組能得到什么東西。這樣的好處就是在開(kāi)發(fā)周期的早期確定下需求，就可以確切地知道所要的是一個(gè)什么樣的東西；缺點(diǎn)就是他們可能沒(méi)有得到實(shí)際上所需要的（不全或錯(cuò)誤的需求，譯者）。
事實(shí)分析：變化總會(huì)發(fā)生的。由于優(yōu)先級(jí)的變化和逐漸對(duì)系統(tǒng)有了更進(jìn)一步的理解，都會(huì)引起需求的變化。與凍結(jié)需求相反，估計(jì)項(xiàng)目成功的風(fēng)險(xiǎn)，盡量去接受變化而且相應(yīng)地采取行動(dòng)，就象XP所建議的一樣。
UML建模誤區(qū)五：設(shè)計(jì)是不可更改的
如同誤區(qū)四，要求每一個(gè)開(kāi)發(fā)人員必須嚴(yán)格遵從“設(shè)計(jì)“，導(dǎo)致開(kāi)發(fā)人員為了符合“設(shè)計(jì)“而作了錯(cuò)誤的事情或以錯(cuò)誤的方式作正確的事情?；蛘呤呛?jiǎn)單地忽略了設(shè)計(jì)，否定了所有設(shè)計(jì)可能帶來(lái)的好處。凍結(jié)了設(shè)計(jì)，你就不能從在項(xiàng)目進(jìn)程中所學(xué)到知識(shí)進(jìn)一步獲益。另外一個(gè)很大的趨勢(shì)就是開(kāi)發(fā)出大量的文檔而不是實(shí)際的軟件，使用面向文檔的CASE工具而不是能給項(xiàng)目帶來(lái)實(shí)際價(jià)值的面向應(yīng)用的工具。
事實(shí)分析：事實(shí)上，設(shè)計(jì)會(huì)經(jīng)常根據(jù)開(kāi)發(fā)人員和數(shù)據(jù)庫(kù)管理員的反饋進(jìn)行修改，因?yàn)樗麄兪亲罱咏鼘?shí)際應(yīng)用的人，通常他們對(duì)技術(shù)環(huán)境的理解要好于UML建模者。我們必須的面對(duì)這樣一個(gè)事實(shí)：人無(wú)完人，他們所作的工作也不可能盡善盡美。難道您真的想將一個(gè)并不完善的設(shè)計(jì)固定下來(lái)而不再去修改其中的錯(cuò)誤嗎？另外，如果需求并沒(méi)有被凍結(jié)，其實(shí)就意味著你不能凍結(jié)你的設(shè)計(jì)，因?yàn)槿魏涡枨蟮男薷膭?shì)必影響設(shè)計(jì)。對(duì)之，正確的態(tài)度是：只要你的代碼還在改動(dòng)，涉及就沒(méi)完。
UML建模誤區(qū)六：必須使用CASE工具
UML建模常常被認(rèn)為是一項(xiàng)復(fù)雜的工作，因此需要大量地使用CASE工具輔助進(jìn)行。
事實(shí)分析：是的，UML建?？梢允呛軓?fù)雜的。但你完全可以建立一個(gè)有效而簡(jiǎn)單的模型表述其中關(guān)鍵的信息，而不是將一些無(wú)關(guān)緊要的細(xì)節(jié)包括進(jìn)來(lái)。
比如，我經(jīng)常使用UML建立模型來(lái)表示類、它們的屬性及一些關(guān)鍵的業(yè)務(wù)操作，但并不畫(huà)出屬性的存取操作(get和set)，以及維護(hù)與其它類關(guān)系的框架代碼，或者其他一些瑣碎的實(shí)現(xiàn)細(xì)節(jié)。我通過(guò)UML建模尋找解決問(wèn)題的方法，讓我和我的同事能繼續(xù)前進(jìn)去實(shí)現(xiàn)這個(gè)模型。以這樣靈活的方式，大多數(shù)情況下我并不需要一個(gè)CASE工具來(lái)支持UML建模工作，一塊白板，或者一臺(tái)數(shù)字相機(jī)足以。這樣，我就不用花時(shí)間去評(píng)估CASE工具，不用去和工具供應(yīng)商討論許可證的問(wèn)題，也免去了人員培訓(xùn)開(kāi)銷(xiāo)。CASE工具只有當(dāng)它能體現(xiàn)***性價(jià)比時(shí)（相對(duì)你自己的情況而言），才值得購(gòu)買(mǎi)。大多數(shù)情況下，我都能不用它而達(dá)到目的（完成UML建模）。我經(jīng)常使用的工具有Together/J(http://www.togethersoft.com/)–因?yàn)樗墚a(chǎn)生數(shù)目可觀的Java框架代碼；還有ERWin（http://www.cai.com/）--因?yàn)樗芤?guī)劃數(shù)據(jù)庫(kù)。這兩個(gè)工具真正地幫助我實(shí)現(xiàn)了軟件開(kāi)發(fā)的目的–制造滿足用戶要求的軟件。但我絕大多數(shù)得UML建模工作仍然使用的是簡(jiǎn)單的工具，而不是CASE工具。
UML建模誤區(qū)七：UML建模是在浪費(fèi)時(shí)間
許多新手都這樣認(rèn)為，這主要是因?yàn)樗麄兯邮艿慕逃齼H僅局限于如何編寫(xiě)代碼，對(duì)于完整的開(kāi)發(fā)流程鮮有接觸。而且他們的經(jīng)驗(yàn)也僅限于如何實(shí)現(xiàn)代碼，就如初級(jí)程序員。他們放棄了提高效率和學(xué)習(xí)技能的機(jī)會(huì)，這些技能能夠使他們很容易地適應(yīng)不同的項(xiàng)目或組織。他們應(yīng)該為此感到羞愧。
事實(shí)分析：在大多數(shù)情況下，在開(kāi)始編碼之前畫(huà)一個(gè)草圖、開(kāi)發(fā)一個(gè)粗率的原型或者制作一些索引卡片都能提高你的生產(chǎn)效率。高效的開(kāi)發(fā)者在編碼之前都要進(jìn)行UML建模工作。另外，UML建模是一種很好的在項(xiàng)目組成員與項(xiàng)目負(fù)責(zé)人之間溝通途徑。你們?cè)谶@個(gè)過(guò)程中探討問(wèn)題，從而對(duì)所要的是一個(gè)什么樣的東西可以得到更好的理解，涉及到該項(xiàng)目中的每個(gè)成員也可得到對(duì)該項(xiàng)目有一個(gè)從分的了解。
UML建模誤區(qū)八：數(shù)據(jù)模型(DataModel)就是一切
許多組織基于數(shù)據(jù)模型就蹣跚啟動(dòng)新的開(kāi)發(fā)工作，也許正如你所在的組織：IT部門(mén)對(duì)于數(shù)據(jù)有非常嚴(yán)格的規(guī)定，控制著你的開(kāi)發(fā)項(xiàng)目；或者你以前的數(shù)據(jù)庫(kù)是一團(tuán)糟，別無(wú)選擇。
事實(shí)分析：數(shù)據(jù)模型是一個(gè)重要的但不是最重要的UML建模，它***是建立在另外的模型之上。（參見(jiàn)“ExtremeModeling”，ThinkingObjectively，Nov.2000）。這即使在象數(shù)據(jù)倉(cāng)庫(kù)這類面向數(shù)據(jù)的項(xiàng)目中也如此。如果沒(méi)有很好的理解用戶是如何使用該數(shù)據(jù)倉(cāng)庫(kù)的（在數(shù)據(jù)模型中沒(méi)有表示出來(lái)），這些項(xiàng)目經(jīng)常是以可悲的失敗而告終。你可以使用的模型有很多–使用案例（usecases），業(yè)務(wù)規(guī)則（businessrules），activitydiagrams，類圖（classdiagrams），componentdiagrams，用戶界面流程圖（userinterfaceflowdiagrams）和CRC，等等。數(shù)據(jù)模型僅僅是其中的一種。每種模型都有其長(zhǎng)處和短處，應(yīng)該正確地使用。
UML建模誤區(qū)九：所有的開(kāi)發(fā)人員都知道如何UML建模
我們現(xiàn)在面臨照這樣一個(gè)嚴(yán)重的問(wèn)題：許多不是開(kāi)發(fā)人員的人，包括高級(jí)經(jīng)理和用戶，不知道軟件是如何建成的。其結(jié)果，他們不能夠區(qū)分開(kāi)熟練的開(kāi)發(fā)者和一般的程序員（當(dāng)然也分不清高級(jí)程序員和一般程序員），他們想當(dāng)然地認(rèn)為所有的開(kāi)發(fā)人員都具備從頭到尾開(kāi)發(fā)整個(gè)系統(tǒng)的技能。
事實(shí)分析：這肯定是不正確的。UML建模的技能，是只有當(dāng)一個(gè)開(kāi)發(fā)者通過(guò)學(xué)習(xí)它，并經(jīng)過(guò)長(zhǎng)期的實(shí)踐才能夠掌握。一些非常聰明的程序員常常相信自己無(wú)所不能，畢竟他們終究只是程序員。正因?yàn)檫@樣的狂妄自大，他們承當(dāng)?shù)囊恍┤蝿?wù)是他們根本就沒(méi)有相應(yīng)的技能去完成的。軟件開(kāi)發(fā)是如此的復(fù)雜，單單一個(gè)人是很難具備所有的技能去成功地進(jìn)行開(kāi)發(fā)，甚至也不可能去配置有一定復(fù)雜程度的系統(tǒng)。開(kāi)發(fā)這應(yīng)該有自知之明，明白他們自己的弱點(diǎn)，學(xué)無(wú)止境。通過(guò)互相取長(zhǎng)補(bǔ)短，UML建模者可從程序員身上學(xué)到一項(xiàng)技術(shù)的具體細(xì)節(jié)，程序員也可從UML建模者那里學(xué)到有價(jià)值的設(shè)計(jì)和體系結(jié)構(gòu)的技術(shù)。我個(gè)人認(rèn)為所有的人，包括我自己，都是新手。
AgileModeling
通過(guò)理解和避開(kāi)UML建模的誤區(qū)，你能夠是得你自己、你的項(xiàng)目組和你的組織更加有效地進(jìn)行軟件開(kāi)發(fā)。在揭示這些普遍存在誤區(qū)的過(guò)程中，我已經(jīng)表述了AgileModeling(AM)的許多原則。AgileModeling以前叫做ExtremeModeling(XM)。我希望我所給于你的是精神上的食糧。
【編輯推薦】
