|
陶剛編譯 |
為了成功地開發(fā)一個(gè)項(xiàng)目,你需要正確的過程、工具和符號(hào)(注釋)。在本文中作者解釋了UML是如何為你提供符號(hào)、Rational統(tǒng)一流程(Unified Process)是如何為你提供正確的流程,以及Rational Rose是如何為你提供使項(xiàng)目成功的工具的。 什么是可視化建模? 可視化建模(VISUAL MODELING)是利用圍繞現(xiàn)實(shí)想法組織模型的一種思考問題的方法。模型對(duì)于了解問題、與項(xiàng)目相關(guān)的每個(gè)人(客戶、行業(yè)專家、分析師、設(shè)計(jì)者等)溝通、模仿企業(yè)流程、準(zhǔn)備文檔、設(shè)計(jì)程序和數(shù)據(jù)庫來說都是有用的。建模促進(jìn)了對(duì)需求的更好的理解、更清晰的設(shè)計(jì)、更加容易維護(hù)的系統(tǒng)。 模型通過過慮非本質(zhì)的細(xì)節(jié)信息,成為描述復(fù)雜的問題或結(jié)構(gòu)的本質(zhì)的抽象(abstraction),她使問題更容易理解了。抽象是一種允許我們處理復(fù)雜問題的基本能力。千百年以來,工程師、藝術(shù)家和工匠一直在實(shí)施某項(xiàng)工程之前,先建立模型提煉出它的設(shè)計(jì)方案。軟件系統(tǒng)的開發(fā)也并不例外。為了建立復(fù)雜的系統(tǒng),開發(fā)者必須抽象出系統(tǒng)的不同的視圖,使用精確的符號(hào)建立模型,驗(yàn)證這些模型是否滿足系統(tǒng)的需求,并逐漸添加細(xì)節(jié)信息把這些模型轉(zhuǎn)變?yōu)閷?shí)現(xiàn)(implementation)。 我們建立復(fù)雜系統(tǒng)的模型是因?yàn)槲覀儧]法理解整個(gè)系統(tǒng)。人類理解復(fù)雜性的能力是有限的。這個(gè)觀念可以在世界上的建筑中看到。如果你希望在后院中建立小屋,你可以立即開始建造;如果你希望建立新房子,你就可能需要一張藍(lán)圖了;如果你要建立摩天大樓,你就絕對(duì)需要一張藍(lán)圖。在軟件的世界中這也是一樣的。由源代碼行或Visual Basic中設(shè)計(jì)的窗體擔(dān)任主角為程序員提供的開發(fā)項(xiàng)目的全局視圖是很微不足道的。構(gòu)造模型允許設(shè)計(jì)師集中考慮項(xiàng)目中的組成部分如何交互的全局情況,而不會(huì)陷入每個(gè)組成部分的具體細(xì)節(jié)信息的泥沼中。 高度競爭的和不斷改變的業(yè)務(wù)環(huán)境導(dǎo)致了復(fù)雜性不斷增加,這為系統(tǒng)開發(fā)者帶來了獨(dú)特的挑戰(zhàn)。模型幫助我們組織、形象化、理解和建立復(fù)雜的事物。它們?cè)谀壳昂臀磥矶紩?huì)幫助我們解決開發(fā)軟件遭遇的各種挑戰(zhàn)。 成功三角形 我經(jīng)常使用圖1所示的成功三角形來解釋成功的項(xiàng)目所需要的組成部分。你需要所有的三個(gè)方面——符號(hào)、過程和工具。你可以學(xué)習(xí)一種符號(hào),但是如果不知道如何利用它(過程),你可能會(huì)失敗。你可能擁有強(qiáng)大的過程,但是如果不能溝通這些過程(符號(hào)),你也可能失敗。最后,如果你不能記載自己的工作文檔(工具),你也可能失敗。
符號(hào)的角色 符號(hào)在任何模型中都扮演著重要的部分——它是把過程連接在一起的“粘合劑”。符號(hào)有三種角色: · 它作為傳達(dá)決定的語言服務(wù)的,它不能明顯地或者不能從代碼自身中推理得到。 · 它提供的語義學(xué)對(duì)于捕捉所有重要的戰(zhàn)略和戰(zhàn)術(shù)決定都是足夠豐富的。 · 它提供了一種具體的形式,足以供人們來思考和工具來操作。 統(tǒng)一的建模語言(UML)提供了非常健全的符號(hào),它從分析的范圍發(fā)展到了設(shè)計(jì)的范圍了。一定的符號(hào)元素(例如類、聯(lián)系、集合體、繼承)都是在分析中引入的。其它的符號(hào)元素(例如保留實(shí)現(xiàn)的標(biāo)識(shí)和屬性)都是在設(shè)計(jì)中引入的。 UML的歷史 在九十年代很多不同的方法學(xué)和它們的符號(hào)集都被引入市場中。其中最流行的三個(gè)是OMT(Rumbaugh)、Booch和OOSE (Jacobson)。每種方法都有自己的價(jià)值和重點(diǎn)。OMT在分析方面強(qiáng)大,但是在設(shè)計(jì)方面比較弱。Booch 1991在設(shè)計(jì)方面強(qiáng)大但是在分析方面比較弱。Jacobson在行為分析方面強(qiáng)大,但是在其它方面比較弱。 隨著時(shí)間的推移,Booch寫了他的第二本書,除了別的內(nèi)容以外,他還采用了大量的Rumbaugh和 Jacobson提倡的好的分析技術(shù)。Rumbaugh出版了一系列文章,形成了我們所知道的OMT-2,它采用了Booch的大量的好的設(shè)計(jì)技術(shù)。這三種技術(shù)開始聚合在一起,但是各自仍然有自己獨(dú)特的符號(hào)。由于符號(hào)對(duì)不同的人的意味著不同的事物,所以不同的符號(hào)的使用給市場帶來了混亂。例如滿圓形(filled circle)在OMT中是多樣性標(biāo)志,在Booch中卻是集合標(biāo)志。你可能聽到過用術(shù)語“方法的戰(zhàn)爭”來描述這段時(shí)間——類到底是云形還是長方形的?哪個(gè)更好? 當(dāng)符號(hào)都采用了統(tǒng)一的建模語言(UML)的時(shí)候“方法的戰(zhàn)爭”才結(jié)束了。“UML是一種用于具體說明、形象化、并記載開發(fā)中的面向?qū)ο笙到y(tǒng)的工作的語言。它表現(xiàn)了Booch、OMT和對(duì)象符號(hào),以及大量的其它方法學(xué)(圖2)的最佳觀念的統(tǒng)一。通過統(tǒng)一這些面向?qū)ο蠓椒ㄊ褂玫姆?hào),統(tǒng)一的建模語言為基于廣泛的用戶經(jīng)驗(yàn)基礎(chǔ)形成的面向?qū)ο蠓治龊驮O(shè)計(jì)領(lǐng)域中的事實(shí)上的標(biāo)準(zhǔn)提供了基礎(chǔ)。” 圖2. UML的組成 UML試圖標(biāo)準(zhǔn)化分析和設(shè)計(jì)的工作:語義模型(semantic models)、語法符號(hào)(syntactic notation)和圖表(diagrams)。它的第一份公共草案(0.8版本)是在1995年10月引入的。公眾和Ivar Jacobson的反饋都在后面的兩個(gè)版本(1996年7月的0.9版本和1996年10月的0.91版本)中包括了。在1997年7月1.0版本被提供給對(duì)象管理工作組(OMG)以供標(biāo)準(zhǔn)化。額外的一些增強(qiáng)被集成到UML 1.1版本中,它在1997年9月被提交給OMG。在1997年11月,UML被OMG采用作為標(biāo)準(zhǔn)的建模語言。UML目前的版本是UML 1.4,并且正在朝UML 2.0的方向進(jìn)展。你可以查看OMG的Web站點(diǎn)www.omg.org找到更多關(guān)于UML的信息。 過程的角色 成功地開發(fā)的項(xiàng)目滿足或超過了客戶的期望,它是用及時(shí)并節(jié)約的方式開發(fā)的,并且對(duì)于改變和適應(yīng)是有彈性的。開發(fā)的生命周期必須促進(jìn)創(chuàng)造和革新,同時(shí)開發(fā)過程必須被控制和衡量,以確保項(xiàng)目真正地完成了。“創(chuàng)造性對(duì)于所有良好構(gòu)建的面向?qū)ο蠹軜?gòu)的技巧是基本的,但是允許開發(fā)者完全無限制地創(chuàng)造會(huì)使項(xiàng)目趨向于永遠(yuǎn)不會(huì)結(jié)束。同樣地,當(dāng)組織開發(fā)小組共同工作的時(shí)候紀(jì)律是必要的,但是太多的紀(jì)律將產(chǎn)生官僚作風(fēng),這會(huì)毀掉各種創(chuàng)新的嘗試”。良好地組織的迭代和增加的生命周期在不影響創(chuàng)造性的情況下提供了必要的控制。 什么是迭代和增加的開發(fā) 在迭代和增加的生命周期中(圖3),開發(fā)的進(jìn)行就是一系列迭代,它們形成最終的系統(tǒng)。每種迭代包括下面的過程組成部分中的一個(gè)或多個(gè):業(yè)務(wù)建模、需求、分析、設(shè)計(jì)、實(shí)現(xiàn)、測試和部署。在生命周期的開始,開發(fā)者不能假設(shè)所有的需求都是已知的;在所有的階段中必然的改變都是預(yù)料中的。 這種類型的生命周期是一種減輕風(fēng)險(xiǎn)的過程。在生命周期的早期評(píng)估并區(qū)分了技術(shù)風(fēng)險(xiǎn)的優(yōu)先次序,在每個(gè)階段的開發(fā)中都會(huì)調(diào)整技術(shù)風(fēng)險(xiǎn)。風(fēng)險(xiǎn)被附加到每個(gè)階段上,這樣每個(gè)階段的成功完成都會(huì)減輕附加到它上面的風(fēng)險(xiǎn)。其版本是按計(jì)劃預(yù)定的,以確保最高的風(fēng)險(xiǎn)被最先處理。采用這種方式建立系統(tǒng)在生命周期的早期就暴露并減輕了系統(tǒng)的風(fēng)險(xiǎn)。這種生命周期方法的結(jié)果是風(fēng)險(xiǎn)更少,相關(guān)的投資更小。
通過使用Rational Unified Process可以支持對(duì)迭代和增加的生命周期的控制。它是解決那些集中于需求分析和設(shè)計(jì)的軟件開發(fā)的技術(shù)方面和組織方面的問題的指導(dǎo)方針的擴(kuò)展集合。 Rational Unified Process是沿著這兩個(gè)方向構(gòu)建的: · 時(shí)間——把生命周期分割為階段和迭代 · 過程組成部分——良好地定義的活動(dòng)的特定工作集合的產(chǎn)品。 一個(gè)項(xiàng)目要獲得成功的話,這兩個(gè)方面都必須重視。 沿著時(shí)間維度構(gòu)建項(xiàng)目包含了采用下面的基于時(shí)間的階段: · 初始——指定項(xiàng)目的版本 · 詳盡細(xì)節(jié)——計(jì)劃必要的活動(dòng)和需要的資源;指明特征和設(shè)計(jì)架構(gòu) · 構(gòu)建——用一系列增加的迭代建立產(chǎn)品 · 轉(zhuǎn)換——為用戶團(tuán)體提供產(chǎn)品(制造、交付和訓(xùn)練) 沿著過程組成部分維度構(gòu)建項(xiàng)目包含下面的活動(dòng): · 業(yè)務(wù)建模——希望得到的系統(tǒng)能力和用戶需求的認(rèn)識(shí) · 需求——擁有一組功能或非功能的需求的系統(tǒng)景象的敘述 · 分析和設(shè)計(jì)——在實(shí)現(xiàn)階段系統(tǒng)如何被了解的描述 · 實(shí)現(xiàn)——結(jié)果將是可執(zhí)行的系統(tǒng)的代碼產(chǎn)品 · 測試——整個(gè)系統(tǒng)的驗(yàn)證 · 部署——系統(tǒng)的交付和對(duì)客戶的用戶訓(xùn)練
開發(fā)過程 典型情況下,過程組成部分維度中的每個(gè)活動(dòng)都應(yīng)用于基于時(shí)間的維度中的每個(gè)階段。但是,特定的過程組成部分被應(yīng)用的程度依賴于開發(fā)的階段。例如,你可能決定在初始階段做一次概念原型的校對(duì),因此你做的事情比僅僅捕獲需求要多一些(為了完善原型,你可能要執(zhí)行分析、設(shè)計(jì)、實(shí)現(xiàn)和測試的事務(wù))。分析過程的組成部分大部分在詳盡細(xì)節(jié)階段發(fā)生。但是,在這個(gè)階段完善系統(tǒng)最初的少量迭代也是明智的。典型情況下,這些最初的少量迭代被用于驗(yàn)證為系統(tǒng)架構(gòu)所作出的分析決定。 因此,你做的事情不僅僅是分析問題。在開發(fā)的構(gòu)造階段,系統(tǒng)由一組迭代完成。在任何類型的開發(fā)結(jié)構(gòu)中,隨著系統(tǒng)的構(gòu)建,通常會(huì)出現(xiàn)一些事態(tài),因此你仍然需要做一些分析。 圖表應(yīng)該是項(xiàng)目的生命周期的指導(dǎo)。其要點(diǎn)是在編寫代碼的時(shí)候,如果你仍然試圖找出要建立什么樣的系統(tǒng),你可能就遇到麻煩了。你應(yīng)該注意,測試應(yīng)用于整個(gè)迭代過程中——你不能等待所有的代碼完成后才檢查它們是否能一起工作。 本文使用了Rational Unified Process的簡化版本,它集中于使用UML來捕獲和記載開發(fā)的初始階段和詳盡細(xì)節(jié)階段中作出的決定。 Rational Rose工具 任何軟件開發(fā)的方法都被某種工具最好地支持著。當(dāng)我最初開始OO建模的時(shí)候,我的工具是紙張和鉛筆,我想要更多的工具,F(xiàn)在市場中有了很多工具——從最簡單的繪圖工具到成熟的對(duì)象建模工具。本文使用的是Rational Rose。 Rational Rose產(chǎn)品家族被設(shè)計(jì)為為軟件開發(fā)者提供完整的用于開發(fā)客戶端/服務(wù)器、分布式企業(yè)和實(shí)時(shí)系統(tǒng)環(huán)境中滿足實(shí)際業(yè)務(wù)需求的牢固的、高效率的解決方案的可視化建模工具集合。Rational Rose產(chǎn)品共享全體通用的標(biāo)準(zhǔn),使得希望建立業(yè)務(wù)流程模型的非程序員和建立應(yīng)用程序邏輯模型的程序員可以相互理解。Rational Rose工具的評(píng)估版可以通過Rational軟件公司W(wǎng)eb站點(diǎn)www.rational.com獲取。 總結(jié) 可視化建模是利用圍繞現(xiàn)實(shí)想法組織模型思考問題的一種方法。模型對(duì)于理解問題、溝通、建立企業(yè)模型、準(zhǔn)備文檔和設(shè)計(jì)程序和數(shù)據(jù)庫都是有用的。建模促進(jìn)了對(duì)需求的更好的理解、更好的設(shè)計(jì)和更容易維護(hù)的系統(tǒng)。符號(hào)在任何模型中都扮演著重要的部分——它是把過程粘合在一起的“粘合劑”。統(tǒng)一的建模語言提供了豐富的符號(hào),它從分析中發(fā)展到設(shè)計(jì)中。 成功地開發(fā)的項(xiàng)目滿足或超越客戶的期望,它是用及時(shí)并節(jié)約的方式開發(fā)的,并且對(duì)改變和適應(yīng)是有彈性的。開發(fā)生命周期必須促進(jìn)創(chuàng)造和革新。良好的管理的迭代和增加生命周期提供了必要的控制,同時(shí)不會(huì)影響創(chuàng)造性。在迭代和增加的開發(fā)生命周期中,開發(fā)由一系列的迭代組成,它們將發(fā)展成最終的系統(tǒng)。每個(gè)迭代包含下面的過程組成部分中的一個(gè)或多個(gè):業(yè)務(wù)建模、需求、分析、設(shè)計(jì)、實(shí)現(xiàn)、測試和部署。 通過使用Rational Unified Process可以支持對(duì)迭代和增加的生命周期的控制。它是解決那些集中于需求分析和設(shè)計(jì)的軟件開發(fā)的技術(shù)方面和組織方面的問題的指導(dǎo)方針的擴(kuò)充集合。 Rational Rose產(chǎn)品家族被設(shè)計(jì)為為軟件開發(fā)者提供完整的用于開發(fā)客戶端/服務(wù)器、分布式企業(yè)和實(shí)時(shí)系統(tǒng)環(huán)境中滿足實(shí)際業(yè)務(wù)需求的牢固的、高效率的解決方案的可視化建模工具集合。 |
煤炭網(wǎng)版權(quán)與免責(zé)聲明:
凡本網(wǎng)注明"來源:煤炭網(wǎng)www.jingweixianlan.com "的所有文字、圖片和音視頻稿件,版權(quán)均為"煤炭網(wǎng)www.jingweixianlan.com "獨(dú)家所有,任何媒體、網(wǎng)站或個(gè)人在轉(zhuǎn)載使用時(shí)必須注明"來源:煤炭網(wǎng)www.jingweixianlan.com ",違反者本網(wǎng)將依法追究責(zé)任。
本網(wǎng)轉(zhuǎn)載并注明其他來源的稿件,是本著為讀者傳遞更多信息的目的,并不意味著本網(wǎng)贊同其觀點(diǎn)或證實(shí)其內(nèi)容的真實(shí)性。其他媒體、網(wǎng)站或個(gè)人從本網(wǎng)轉(zhuǎn)載使用時(shí),必須保留本網(wǎng)注明的稿件來源,禁止擅自篡改稿件來源,并自負(fù)版權(quán)等法律責(zé)任。違反者本網(wǎng)也將依法追究責(zé)任。 如本網(wǎng)轉(zhuǎn)載稿件涉及版權(quán)等問題,請(qǐng)作者在兩周內(nèi)盡快來電或來函聯(lián)系。
網(wǎng)站技術(shù)運(yùn)營:北京真石數(shù)字科技股份有限公司、喀什中煤遠(yuǎn)大供應(yīng)鏈管理有限公司、喀什煤網(wǎng)數(shù)字科技有限公司
總部地址:北京市豐臺(tái)區(qū)總部基地航豐路中航榮豐1層
京ICP備18023690號(hào)-1 京公網(wǎng)安備 11010602010109號(hào)