暢談UML建模技術(shù)的四大誤區(qū)和十大原則
本節(jié)和大家學(xué)習(xí)一下UML建模的幾個(gè)誤區(qū)和建模原則,希望通過本節(jié)的學(xué)習(xí)你對UML建模技術(shù)有深入的認(rèn)識(shí),以便在以后的學(xué)習(xí)和使用過程中少走彎路。
UML建模誤區(qū)
通過理解和避開建模的誤區(qū),你能夠是得你自己、你的項(xiàng)目組和你的組織更加有效地進(jìn)行軟件開發(fā)。在揭示這些普遍存在誤區(qū)的過程中,我已經(jīng)表述了AgileModeling(AM)的許多原則。AgileModeling以前叫做ExtremeModeling(XM)。我希望我所給于你的是精神上的食糧。
--------------------------------------------------------------------------------
無論你遵從的是重量級的方法,比如EnterpriseUnifiedProcess(EUP),還是輕量級的開發(fā)過程,如ExtremeProgramming(XP),建模在軟件開發(fā)中都是不可或缺的。但不幸的是其中充斥著各種謬誤與迷思。這來自于各個(gè)方面,有從理論家錯(cuò)誤的研究、數(shù)十年來信息技術(shù)領(lǐng)域內(nèi)的文化沉積、軟件工具開發(fā)商天花亂墜半的市場宣傳以及象ObjectManagementGroup(OMG)和IEEE這類組織的標(biāo)準(zhǔn)。這個(gè)月,我要揭示建模中的誤區(qū),指出其相應(yīng)的事實(shí)真相。
UML建模誤區(qū)一:建模就等于是寫文檔
這很可能是其中***破壞力的一條,因?yàn)殚_發(fā)人員可以此為借口而完全放棄建模。許多優(yōu)秀的軟件開發(fā)人員會(huì)說他們不想把時(shí)間浪費(fèi)在這些“無用的“文檔上。他們沉溺于編碼之中,制造著一些脆弱而劣質(zhì)的系統(tǒng)。另外,甚至于許多盡責(zé)的開發(fā)人員現(xiàn)在也認(rèn)為建模是一件討厭的事,而不愿去學(xué)習(xí)相應(yīng)的建模技術(shù)。
事實(shí)分析:“模型”與“文檔”這二者在概念上是風(fēng)馬牛不相及的—你可以擁有一個(gè)不是文檔的模型和不是模型的文檔。一幅設(shè)計(jì)圖就是一個(gè)模型,而不論是被畫在餐巾紙的背面,或?qū)懺谝粔K白板上,或在ClassResponsibilityCollaboration(CRC)卡片中,還是根據(jù)記錄在報(bào)紙和便簽紙上的流程圖而生成的一個(gè)粗略的用戶界面原型。雖然這些都不能說是文檔,但他們卻都是有價(jià)值的模型。
建模很象是作計(jì)劃:作計(jì)劃的價(jià)值在于計(jì)劃編制的過程中,而非計(jì)劃本身;價(jià)值體現(xiàn)在建模的活動(dòng)中,而非模型本身。實(shí)際上,模型不是你系統(tǒng)中的一部分正式的文檔,而且在完成它們的使命后可以被丟掉。你會(huì)發(fā)現(xiàn)值得保留的只有很少的模型,而且它一定是非常***。
UML建模誤區(qū)二:從開始階段你可以考慮到所有的一切
這種說法流行于二十世紀(jì)七十年代到八十年代早期,現(xiàn)今的許多經(jīng)理都是在那個(gè)時(shí)候?qū)W習(xí)的軟件開發(fā)。對這一點(diǎn)的迷信會(huì)導(dǎo)致在前期投入可觀的時(shí)間去對所有的一切建模以期把所有一切都弄正確,試圖在編碼開始前就“凍結(jié)”所有的需求(見誤區(qū)四),以致于患上“分析期麻痹癥”–要等到模型非常***之后才敢向前進(jìn)?;谶@個(gè)觀點(diǎn),項(xiàng)目組開發(fā)了大量的文檔,而不是他們真正想要得到的—開發(fā)滿足需要的軟件。
事實(shí)分析:怎么才能走出這個(gè)誤區(qū)呢?首先,你必須認(rèn)識(shí)到你不能考慮到所有的細(xì)枝末節(jié)。第二,認(rèn)識(shí)到編碼員可能會(huì)對建模者的工作不以為然(這是可能的,事實(shí)上建模者所作的工作在實(shí)際價(jià)值中只占很少的部分),他們或許會(huì)說模型沒有反應(yīng)出真實(shí)的情況。第三,認(rèn)識(shí)到不管你的最初所作的規(guī)格說明書有多好,但注定代碼會(huì)很快地與之失去同步,即便是你自己建模自己編碼。一個(gè)基本的道理就是代碼永遠(yuǎn)只會(huì)和代碼保持一致。第四,認(rèn)識(shí)到迭代法(小規(guī)模地建模,編一些代碼,做一些測試,可能還會(huì)做一個(gè)小的工作版本)是軟件開發(fā)的準(zhǔn)則。它是現(xiàn)代重量級的軟件開發(fā)過程(如EUP),以及輕量級(如XP)的基本原理。
UML建模誤區(qū)三:建模意味著需要一個(gè)重量級的軟件開發(fā)過程
走入這個(gè)誤區(qū)(經(jīng)常與誤區(qū)一有聯(lián)系)的項(xiàng)目組常常是連建模都徹底地放棄了,應(yīng)為這樣的軟件開發(fā)過程對他們來說太復(fù)雜太沉重了。這不亞于一場天災(zāi)。
事實(shí)分析:你可以用一種敏捷的方式取而代之。關(guān)于用簡單的工具進(jìn)行簡單地建模的詳細(xì)內(nèi)容可參看AgileModeling(AM)。而且,你可以丟棄你的模型當(dāng)使命完之后,同樣也可以很基本的方式進(jìn)行建模(比如,從辦公桌起來,來到白板前就開始構(gòu)略草圖)。只要你愿意,你就可以輕松地建模。
UML建模誤區(qū)四:必須“凍結(jié)”需求
這個(gè)要求常常來自高級經(jīng)理,他們確切地想知道他們從這個(gè)項(xiàng)目組能得到什么東西。這樣的好處就是在開發(fā)周期的早期確定下需求,就可以確切地知道所要的是一個(gè)什么樣的東西;缺點(diǎn)就是他們可能沒有得到實(shí)際上所需要的(不全或錯(cuò)誤的需求,譯者)。
事實(shí)分析:變化總會(huì)發(fā)生的。由于優(yōu)先級的變化和逐漸對系統(tǒng)有了更進(jìn)一步的理解,都會(huì)引起需求的變化。與凍結(jié)需求相反,估計(jì)項(xiàng)目成功的風(fēng)險(xiǎn),盡量去接受變化而且相應(yīng)地采取行動(dòng),就象XP所建議的一樣。
UML建模十條原則
僅有數(shù)據(jù)模型對于現(xiàn)代軟件是不夠的。
接收變化,并且允許你的模型能夠隨著時(shí)間進(jìn)行改進(jìn)。你不能凍結(jié)它們,然后就期待著成功。
模型并不一定就是文檔,文檔也不一定就是模型。
大多數(shù)的模型可能也應(yīng)該被丟棄。
只有代碼才能與代碼保持真正的同步。
一些簡單的工具,比如白板,就完全足以應(yīng)付大多數(shù)得建模工作。
思考,然后再編碼。
你總能從別人身上學(xué)到東西。
建??梢杂靡环N輕盈的方式。
設(shè)計(jì)直到代碼發(fā)布以后才算完成。
【編輯推薦】
- 實(shí)例講解UML建模分析與設(shè)計(jì)
- UML建模技術(shù)要點(diǎn)總結(jié)
- 專家指導(dǎo) UML建模分析步驟
- UML建模時(shí)需要注意的四大問題
- UML建模技術(shù)的三大組成部分