軟件過程和模型_第1頁
軟件過程和模型_第2頁
軟件過程和模型_第3頁
軟件過程和模型_第4頁
軟件過程和模型_第5頁
已閱讀5頁,還剩110頁未讀 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)

文檔簡介

教學(xué)內(nèi)容:

軟件過程與軟件生存周期典型軟件過程模型面向?qū)ο蟮能浖^程模型統(tǒng)一建模語言UML基本要求:掌握軟件過程與軟件生存周期的概念熟悉典型軟件過程模型熟悉統(tǒng)一建模語言UML教學(xué)重點(diǎn):軟件過程模型和UML第2章軟件過程和模型軟件過程軟件過程(SoftwareProcedure)就是按照軟件項目的進(jìn)度、成本和質(zhì)量要求,開發(fā)和維護(hù)軟件所必需的一系列有序活動的集合。過程是活動的集合;活動是任務(wù)的集合;任務(wù)要起著把輸入進(jìn)行加工然后輸出的作用?;顒拥膱?zhí)行可以是順序的、重復(fù)的、并行的、嵌套的或者是有條件地引發(fā)的。軟件過程可概括為三類:基本過程類、支持過程類和組織過程類?;具^程類包括需求獲取、開發(fā)、維護(hù)等基本活動及與基本活動相關(guān)的里程碑事件和質(zhì)量保證點(diǎn)。支持過程類包括文檔、配置管理、質(zhì)量保證、確認(rèn)和評審等活動。組織過程類包括基礎(chǔ)設(shè)施、人員管理和培訓(xùn)等活動(見圖2-1)。軟件過程組織過程(基礎(chǔ)設(shè)施、管理、改進(jìn)、培訓(xùn))支持過程(文檔、配置管理、質(zhì)量保證、評審確認(rèn))基本過程基本活動里程碑事件(提交物)質(zhì)量保證點(diǎn)圖2-1軟件過程軟件生存周期軟件生存周期就是從提出軟件產(chǎn)品開始,直到該軟件產(chǎn)品被淘汰的全過程。研究軟件生存周期是為了更科學(xué)地、有效地組織和管理軟件的生產(chǎn),從而使軟件產(chǎn)品更可靠、更經(jīng)濟(jì)。采用軟件生存周期來劃分軟件的工程化開發(fā)方法,就是將軟件開發(fā)分階段地依次進(jìn)行一種的方法。前一個階段任務(wù)的完成是后一個階段的開始和基礎(chǔ),而后一個階段通常是將前一個階段提出的方案進(jìn)一步具體化。軟件生存周期一般可分為三個主要階段:定義階段、開發(fā)階段和維護(hù)階段。而這三個階段往往又可以細(xì)分為一些子階段。1、定義階段

還可根據(jù)實際情況分為兩個子階段:軟件計劃和需求分析。軟件計劃:主要任務(wù)是從待開發(fā)的目標(biāo)系統(tǒng)出發(fā),定義軟件的性質(zhì)與規(guī)模,確定軟件總的目標(biāo);研究在現(xiàn)有資源與技術(shù)的條件下能否實現(xiàn)目標(biāo)這個問題;推薦目標(biāo)系統(tǒng)的設(shè)計方案,對目標(biāo)系統(tǒng)的成本與效益做出估算,最后還要提出軟件開發(fā)的進(jìn)度安排,提交軟件計劃文檔。需求分析:在待開發(fā)軟件的可行性研究和項目開發(fā)計劃獲得評審?fù)ㄟ^以后,進(jìn)一步準(zhǔn)確地理解用戶的要求,分析系統(tǒng)必須“做什么”,并將其轉(zhuǎn)換成需求定義,提交軟件的需求分析文檔。

2、開發(fā)階段開發(fā)階段也可分為三個子階段:設(shè)計、編碼和測試。設(shè)計階段:主要根據(jù)需求分析文檔對軟件進(jìn)行體系結(jié)構(gòu)設(shè)計、定義接口、建立數(shù)據(jù)結(jié)構(gòu)、規(guī)定標(biāo)記、進(jìn)行模塊過程設(shè)計,提交設(shè)計說明書文檔和測試計劃。編碼階段:按照設(shè)計說明書選擇程序語言工具進(jìn)行編碼和單元測試,提交程序代碼和相應(yīng)文件。測試階段:根據(jù)測試計劃對軟件項目進(jìn)行各種測試,對每一個測試用例和結(jié)果都要進(jìn)行評審,提交軟件項目測試報告。3、維護(hù)階段軟件經(jīng)過評審確認(rèn)后提交用戶使用,就進(jìn)入了維護(hù)階段。在這個階段首先要做的工作就是配置評審,通過檢查軟件文檔和代碼是否齊全、一致,分析系統(tǒng)運(yùn)行與維護(hù)環(huán)境的現(xiàn)實狀況,確認(rèn)系統(tǒng)的可維護(hù)性;為了實施維護(hù),還必須建立維護(hù)的組織、明確維護(hù)人員的職責(zé);當(dāng)用戶提出維護(hù)要求時,根據(jù)維護(hù)的性質(zhì)和類型開展有效的維護(hù)活動,以保持軟件系統(tǒng)正常的運(yùn)行以及持久地滿足用戶的需求。軟件維護(hù)的過程漫長、維護(hù)內(nèi)容廣泛,從軟件維護(hù)活動的特征以及維護(hù)工作的復(fù)雜性來看,我們甚至可以認(rèn)為軟件維護(hù)是系統(tǒng)的第二次開發(fā)。軟件生存期的階段劃分(1)可行性研究與計劃(2)需求分析(3)總體設(shè)計(4)詳細(xì)設(shè)計(5)實現(xiàn)(6)集成測試(7)確認(rèn)測試(8)使用和維護(hù)(根據(jù)國標(biāo)《計算機(jī)軟件開發(fā)規(guī)范》)上游下游2.2典型軟件過程模型所謂模型就是一種策略,這種策略針對軟件工程的各個階段提供了一套范形,也就是一個跨越整個軟件生存周期的系統(tǒng)開發(fā)、運(yùn)行、維護(hù)所實施的全部工作和任務(wù)的結(jié)構(gòu)框架,這個框架給出了軟件開發(fā)活動各階段之間的關(guān)系,以及軟件開發(fā)方法和步驟的高度抽象,從而保證整個工程有條不紊的進(jìn)展達(dá)到預(yù)期的目的。一個錯誤模型的選擇,會使開發(fā)者迷失方向,并可能導(dǎo)致軟件項目開發(fā)的失敗。一般使用過程模型區(qū)分或解釋不同的軟件開發(fā)方法。在實際的軟件開發(fā)中,很少單獨(dú)使用單一的過程模型,軟件過程模型也常稱為: 軟件生命周期模型

軟件開發(fā)模型 軟件工程范型在軟件工程實踐中,有許多模型,如:線性順序過程(模型瀑布模型)、演化過程模型(原型模型、螺旋模型、協(xié)同開發(fā)模型、增量模型、RAD模型)、專用過程模型(基于構(gòu)件的開發(fā)模型、統(tǒng)一過程模型、形式化方法模型、面向方面的軟件開發(fā)模型),以下根據(jù)流行情況,介紹其中幾種典型的模型。2.2.1瀑布模型WaterfallModel(線形順序模型)瀑布模型規(guī)定了各項軟件工程活動,包括:制定開發(fā)計劃,進(jìn)行需求分析和說明,軟件設(shè)計,程序編碼,測試及運(yùn)行維護(hù)。并且規(guī)定了軟件生存周期的各個階段如同瀑布流水,逐級下落,自上而下、相互銜接的固定次序。特點(diǎn):1)從上一項活動接收該項活動的工作對象,作為輸入;

2)利用這一輸入實施該項活動應(yīng)完成的內(nèi)容;

3)給出該項活動的工作結(jié)果,作為輸出傳給下一項活動;

4)對該項活動實施的工作進(jìn)行評審。若其工作得到確認(rèn),則繼續(xù)進(jìn)行下一項活動,否則返回前項,甚至更前項的活動進(jìn)行返工。缺點(diǎn):1)嚴(yán)格分級導(dǎo)致缺乏靈活性,特別是無法解決軟件需求不明確或不準(zhǔn)確的問題。凡前一階段出現(xiàn)的問題需要通過后一階段的重新確認(rèn)來解決,所以這一點(diǎn)在開發(fā)過程完成后才有所察覺,因此,有時其代價十分高昂。2)人員之間的通訊和軟件工具之間的聯(lián)系以及開發(fā)工作之間的并行和串行等都是必要的,但瀑布模型中并沒有體現(xiàn)出這一點(diǎn)。3)需要人員比較多;4)瀑布式方法在需求不明并且在項目進(jìn)行過程中可能變化的情況下基本是不可行的。2.2.2快速原型模型從需求分析開始,軟件開發(fā)者和用戶在一起定義軟件的總目標(biāo),說明需求,并規(guī)劃出定義的區(qū)域。然后快速設(shè)計軟件中對用戶/客戶可見部分的表示。快速設(shè)計導(dǎo)致了原型的建造,原型是一個可以實際運(yùn)行的模型,在功能上可看作是最終產(chǎn)品的子集。原型由用戶/客戶評估,并進(jìn)一步求精待開發(fā)軟件的需求。逐步調(diào)整原型使之滿足用戶需求,這個過程是迭代的。建造/修改原型用戶測試運(yùn)行原型聽取用戶意見特點(diǎn):1)開發(fā)者和用戶可充分通信,明確用戶的需求;2)可以給用戶以機(jī)會更改心中原先設(shè)想的、不盡合理的最終系統(tǒng);3)可以低風(fēng)險開發(fā)柔性較大的計算機(jī)系統(tǒng);4)使系統(tǒng)更易維護(hù)、對用戶更友好的機(jī)會;5)使總的開發(fā)費(fèi)用降低,時間縮短。缺點(diǎn):1)“模型效應(yīng)”或“管中窺豹”。對于開發(fā)者不熟悉的領(lǐng)域把次要部分當(dāng)作主要框架,做出不切題的原型。2)原型迭代不收斂于開發(fā)者預(yù)先的目標(biāo)。為了消除錯誤,每次更改,次要部分越來越大,“淹沒”了主要部分。3)原型過快收斂于需求集合,而忽略了一些基本點(diǎn)。4)資源規(guī)劃和管理較為困難,隨時更新文檔也帶來麻煩。2.2.3螺旋模型螺旋模型將瀑布模型和快速原型模型結(jié)合,剛開始規(guī)模很小,當(dāng)項目被定義得更好、更穩(wěn)定時,逐漸展開,沿著螺線旋轉(zhuǎn),如圖所示,在笛卡爾坐標(biāo)的四個象限上分別表達(dá)了四個方面的活動,即:

1)制定計劃:確定軟件目標(biāo),選定實施方案,弄清項目開發(fā)的限制條件;

2)風(fēng)險分析:分析所選方案,考慮如何識別和消除風(fēng)險;3)實施工程:實施軟件開發(fā);4)客戶評估:評價開發(fā)工作,提出修正建議。沿螺線自內(nèi)向外每旋轉(zhuǎn)一圈便開發(fā)出更為完善的一個新的軟件版本。特點(diǎn):螺旋模型加入了風(fēng)險分析,是一種風(fēng)險驅(qū)動的方法體系;“螺旋模型”的核心就在于不需要在剛開始的時候就把所有事情都定義的清清楚楚??梢韵榷x最重要的功能,實現(xiàn)它,然后聽取客戶的意見,之后再進(jìn)入到下一個階段。如此不斷輪回重復(fù),直到得到滿意的最終產(chǎn)品。因此,迭代過程這種模式使適應(yīng)需求的變化會更容易些;加快了整個開發(fā)工作的進(jìn)度。因為開發(fā)人員清楚問題的焦點(diǎn)所在,他們的工作會更有效率;使用面向?qū)ο蟮恼Z言或統(tǒng)一建模語言(UnifiedModelingLanguage,UML)。缺點(diǎn):這個模型的使用需要具有相當(dāng)豐富的風(fēng)險評估經(jīng)驗和專門知識,具有高素質(zhì)的項目管理者和軟件研發(fā)團(tuán)隊。2.2.4增量模型增量模型采用隨著日程時間的進(jìn)展而交錯的線性序列。每一個線性序列產(chǎn)生軟件的一個可發(fā)布的“增量”。當(dāng)使用增量模型時,第一個增量往往是核心的產(chǎn)品,也就是說第一個增量實現(xiàn)了基本的需求,但很多補(bǔ)充的特征還沒有發(fā)布??蛻魧γ恳粋€增量的使用和評估,都作為下一個增量發(fā)布的新特征和功能。這個過程在每一個增量發(fā)布后不斷從復(fù),直到產(chǎn)生了最終的完善產(chǎn)品。增量模型強(qiáng)調(diào)每一個增量均發(fā)布一個可操作的產(chǎn)品。特點(diǎn):1)這種模型融合了線性順序模型的基本成份和原型實現(xiàn)模型的迭代特征。2)人員分配靈活,剛開始不用投入大量人力資源,當(dāng)核心產(chǎn)品很受歡迎時,可增加人力實現(xiàn)下一個增量。3)當(dāng)配備的人員不能在設(shè)定的期限內(nèi)完成產(chǎn)品時,它提供了一種先推出核心產(chǎn)品的途徑,這樣就可以先發(fā)布部分功能給客戶,對客戶起到鎮(zhèn)靜劑的作用。缺點(diǎn): 始至終開發(fā)者和客戶糾纏在一起,直到完全版本出來。2.2.5敏捷模型(SCRUM)是一種從1990年代開始逐漸引起廣泛關(guān)注的一些新型軟件開發(fā)方法,是一種應(yīng)對快速變化的需求的一種軟件開發(fā)能力。1、從產(chǎn)品角度看,敏捷方法適用于需求萌動并且快速改變的情況,如系統(tǒng)有比較高的關(guān)鍵性、可靠性、安全性方面的要求,則可能不完全適合;2、從組織結(jié)構(gòu)的角度看,組織結(jié)構(gòu)的文化、人員、溝通則決定了敏捷方法是否適用。3、瀑布模型式是最典型的預(yù)見性的方法,嚴(yán)格遵循預(yù)先計劃的需求、分析、設(shè)計、編碼、測試的步驟順序進(jìn)行。敏捷方法強(qiáng)調(diào)適應(yīng)性而非預(yù)見性,相比迭代式開發(fā)兩者都強(qiáng)調(diào)在較短的開發(fā)周期提交軟件,敏捷開發(fā)的周期可能更短,并且更加強(qiáng)調(diào)隊伍中的高度協(xié)作。特點(diǎn):2.3面向?qū)ο蟮能浖^程模型傳統(tǒng)的軟件開發(fā)過程大都建立在軟件生存周期概念基礎(chǔ)上的,螺旋模型、原型模型、增量模型、螺旋模型等實際上都是從瀑布模型拓展或演變而來的,通常把它們稱為傳統(tǒng)的軟件過程模型。面向?qū)ο蟮能浖_發(fā)過程的重點(diǎn)放在軟件生存周期的定義階段。這是因為面向?qū)ο蠓椒ㄔ陂_發(fā)早期就定義了一系列面向問題域的對象,即建立了對象模型。整個開發(fā)過程統(tǒng)一使用這些對象,并不斷地充實和擴(kuò)展對象模型。定義階段得到的對象模型也適用于設(shè)計階段和實現(xiàn)階段,并在各個階段都使用統(tǒng)一的概念和描述符號。

面向?qū)ο蟮能浖_發(fā)過程的特點(diǎn)是:開發(fā)階段界限模糊,開發(fā)過程逐步求精,開發(fā)活動反復(fù)迭代。每次迭代都會增加或明確一些目標(biāo)系統(tǒng)的性質(zhì),但不是對前期工作結(jié)構(gòu)本質(zhì)性改動,這樣就減少了不一致性,降低了出錯的可能性。2.3.1構(gòu)件復(fù)用模型軟件構(gòu)件是軟件系統(tǒng)中有價值的、幾乎獨(dú)立的并可替換的一個部分,它在良好定義的體系結(jié)構(gòu)語境內(nèi)滿足某清晰的服務(wù)功能,可以通過其接口訪問它的服務(wù)。經(jīng)過適當(dāng)?shù)脑O(shè)計和實現(xiàn)的類也可成為構(gòu)件,在基于構(gòu)件的軟件開發(fā)中,軟件可以由這種構(gòu)件裝配而成。構(gòu)件組裝模型如圖所示,它融合了螺旋模型的特征、它利用預(yù)先包裝好的軟件構(gòu)件來構(gòu)造應(yīng)用程序,如果這類不存在,就采用面向?qū)ο蟮姆椒ㄩ_發(fā)它,以后就可以使用從庫中提取的類及為了滿足應(yīng)用程序的特定要求而建造的新類。進(jìn)而完成待開發(fā)應(yīng)用程序的第一次迭代。過程流程后又回到螺旋,最后進(jìn)入構(gòu)件組裝迭代。軟件生產(chǎn)線應(yīng)用構(gòu)件提取車間應(yīng)用構(gòu)件庫構(gòu)件生產(chǎn)車間構(gòu)件庫組裝車間領(lǐng)域

1領(lǐng)域

2應(yīng)用系統(tǒng)

...12341基礎(chǔ)構(gòu)件,2功能構(gòu)件3接口構(gòu)件,4用戶界面構(gòu)件統(tǒng)一過程(RationalUnifiedProcess,簡稱RUP)具有較高認(rèn)知度的原因之一恐怕是因為其提出者Rational軟件公司聚集了面向?qū)ο箢I(lǐng)域三位杰出專家Booch、Rumbaugh和Jacobson,同時它又是面向?qū)ο箝_發(fā)的行業(yè)標(biāo)準(zhǔn)語言——標(biāo)準(zhǔn)建模語言(UML)的創(chuàng)立者。是目前最有效的軟件開發(fā)過程模型。2.3.2統(tǒng)一過程模型統(tǒng)一過程首先建立了整個項目的不同階段,包括初始階段、細(xì)化階段、構(gòu)造階段、交付階段。同時每個階段中又保留了瀑布模型的活動,這里稱之為工作流,即從需求、分析到設(shè)計和實現(xiàn)、測試等活動。所以,可以將其理解為一個二維坐標(biāo),工作流是一個豎坐標(biāo),階段構(gòu)成了橫坐標(biāo)。但是,二維坐標(biāo)并不是統(tǒng)一過程的主要思想,它的主要思想是每個豎坐標(biāo)制定的活動可能會產(chǎn)生多次迭代,每個迭代會隨著橫坐標(biāo)(階段)的進(jìn)展而產(chǎn)生變更,最終逐漸減少直至消失。如圖2-7所示。(1)初始階段目標(biāo)是為系統(tǒng)建立商業(yè)(業(yè)務(wù))案例并確定項目的邊界。為了達(dá)到該目的必須識別所有與系統(tǒng)交互的外部實體,在較高層次上定義交互的特性。初始階段結(jié)束時是第一個重要的里程碑:生命周期目標(biāo)里程碑。初始階段的成果主要有:項目藍(lán)圖文檔(系統(tǒng)的核心需求、關(guān)鍵特性與主要約束)、初始的用例模型(完成10%~20%)、初始的項目術(shù)語表、業(yè)務(wù)用例模型,包括商業(yè)環(huán)境、驗收標(biāo)準(zhǔn)和財政預(yù)測、初始的風(fēng)險評估、一個可以顯示階段和迭代的項目計劃、一個或多個原型、初始的架構(gòu)文檔。(2)細(xì)化階段目標(biāo)是分析問題領(lǐng)域,建立健全的體系結(jié)構(gòu)基礎(chǔ),編制項目計劃,淘汰項目中最高風(fēng)險的元素。為了達(dá)到該目的,必須在理解整個系統(tǒng)的基礎(chǔ)上,對體系結(jié)構(gòu)作出決策,包括其范圍、主要功能和諸如性能等非功能需求。同時為項目建立支持環(huán)境,包括創(chuàng)建開發(fā)案例,創(chuàng)建模板、準(zhǔn)則并準(zhǔn)備工具。細(xì)化階段的成果主要有:系統(tǒng)架構(gòu)基線、UML靜態(tài)模型、UML動態(tài)模型、UML用例模型、修訂的風(fēng)險評估、修訂的用例、修訂的項目計劃、可執(zhí)行的原型。構(gòu)造階段目標(biāo)是所有剩余的構(gòu)件和應(yīng)用程序功能被開發(fā)并集成為產(chǎn)品,所有的功能被詳細(xì)測試。從某種意義上說,構(gòu)建階段是一個制造過程,其重點(diǎn)放在管理資源及控制運(yùn)作以優(yōu)化成本、進(jìn)度和質(zhì)量。構(gòu)建階段結(jié)束時是第三個重要的里程碑:初始功能里程碑。構(gòu)造階段的成果主要有:可運(yùn)行的軟件系統(tǒng)、UML模型、測試用例、用戶手冊、發(fā)布描述。交付階段的目標(biāo)是確保軟件對最終用戶是可用的。交付階段可以跨越幾次迭代,包括為發(fā)布做準(zhǔn)備的產(chǎn)品測試,基于用戶反饋的少量的調(diào)整。如用戶反饋的產(chǎn)品調(diào)整,設(shè)置、安裝和可用性等問題。在交付階段的終點(diǎn)是第四個里程碑:產(chǎn)品發(fā)布里程碑。交付階段的成果主要有:可運(yùn)行的軟件產(chǎn)品、用戶手冊、用戶支持計劃。RUP中有9個核心工作流,分為6個核心過程工作流和3個核心支持工作流。9個核心工作流在項目中輪流被使用,每一次迭代都有相應(yīng)的重點(diǎn)和強(qiáng)度。(1)商業(yè)建模工作流描述了如何為新的目標(biāo)組織開發(fā)一個構(gòu)想,并基于這個構(gòu)想在商業(yè)(業(yè)務(wù))用例模型和商業(yè)對象模型中定義組織的過程,角色和責(zé)任。(2)需求工作流描述系統(tǒng)應(yīng)該做什么,并使開發(fā)人員和用戶就這一描述達(dá)成共識。理解系統(tǒng)所解決問題的定義和范圍。(3)分析和設(shè)計工作流將需求轉(zhuǎn)化成未來系統(tǒng)的設(shè)計,為系統(tǒng)開發(fā)一個健壯的結(jié)構(gòu)并調(diào)整設(shè)計使其與實現(xiàn)環(huán)境相匹配,優(yōu)化其性能。分析和設(shè)計的結(jié)果是一個設(shè)計模型和一個可選的分析模型。設(shè)計模型是源代碼的抽象,由設(shè)計類和一些描述組成。設(shè)計類被組織成具有良好接口的設(shè)計包和設(shè)計子系統(tǒng),而描述則體現(xiàn)了類的對象如何協(xié)同工作實現(xiàn)用例的功能。(4)實現(xiàn)工作流包括以層次化的子系統(tǒng)形式定義代碼的組織結(jié)構(gòu)。以組件的形式(源文件、二進(jìn)制文件、可執(zhí)行文件)實現(xiàn)類和對象,將開發(fā)出的組件作為單元進(jìn)行測試以及集成由單個開發(fā)者(或小組)所產(chǎn)生的結(jié)果,使其成為可執(zhí)行的系統(tǒng)。(5)測試工作流驗證對象間的交互,驗證軟件中所有組件的集成是否合理,檢驗所有的需求是否已被正確的實現(xiàn)。識別并確認(rèn)缺陷在軟件部署之前是否已被提出并處理。RUP提出了迭代的方法,意味著在整個項目中進(jìn)行測試,從而盡可能早地發(fā)現(xiàn)缺陷,從根本上降低了修改缺陷的成本。(6)部署工作流其目的是成功的生成版本并將軟件分發(fā)給最終用戶。部署工作流描述了那些與確保軟件產(chǎn)品對最終用戶具有可用性相關(guān)的活動,包括:軟件打包、生成軟件本身以外的產(chǎn)品、安裝軟件、為用戶提供幫助。(7)配置和變更管理工作流主要描繪了如何在多個成員組成的項目中控制大量的各種產(chǎn)品。配置和變更管理工作流提供了準(zhǔn)則來管理演化系統(tǒng)中的多個變體,跟蹤軟件創(chuàng)建過程中的版本。(8)項目管理平衡各種可能產(chǎn)生沖突的目標(biāo),管理風(fēng)險,克服各種約束并成功交付使用戶滿意的產(chǎn)品。其目標(biāo)包括:為項目的管理提供框架,為計劃、人員配備、執(zhí)行和監(jiān)控項目提供實用的準(zhǔn)則,為管理風(fēng)險提供框架等。(9)環(huán)境工作流的目的是向軟件開發(fā)組織提供軟件開發(fā)環(huán)境,包括過程和工具。RUP中的每個階段可以進(jìn)一步分解為迭代。一個迭代是一個完整的開發(fā)循環(huán),產(chǎn)生一個可執(zhí)行的產(chǎn)品版本,是最終產(chǎn)品的一個子集,它增量式地發(fā)展,從一個迭代過程到另一個迭代過程到成為最終的系統(tǒng)。在工作流中的每一次順序的通過稱為一次迭代。軟件生命周期是迭代的連續(xù),它可以使軟件開發(fā)是增量開發(fā),這就形成了RUP的迭代模型。如圖2-8所示。RUP的迭代開發(fā)模式:2.4統(tǒng)一建模語言UML統(tǒng)一建模語言UML(UnifiedModelingLanguage)是一種用于描述、構(gòu)造可視化和文檔軟件系統(tǒng)的圖形語言?;诿嫦?qū)ο蟆⒍x良好、易于表達(dá)、功能強(qiáng)大且普遍實用的建模語言,它獨(dú)立于過程,從需求分析、軟件規(guī)范、結(jié)構(gòu)設(shè)計、測試、到配置管理都提供了模型化和可視化的支持。UML作為一種模型語言,為不同領(lǐng)域的用戶提供了統(tǒng)一的交流標(biāo)準(zhǔn)--UML圖,最適于數(shù)據(jù)建模,業(yè)務(wù)建模,對象建模,組件建模,它使開發(fā)人員專注于建立產(chǎn)品的模型和結(jié)構(gòu),而不是選用什么程序語言和算法實現(xiàn)。當(dāng)模型建立之后,模型可以被UML工具轉(zhuǎn)化成指定的程序語言代碼。2.4.1UML的結(jié)構(gòu)UML由三個關(guān)鍵要素構(gòu)成:面向?qū)ο蟮幕尽皹?gòu)造塊”、支配這些構(gòu)造塊的建模“規(guī)則”和運(yùn)用于整個UML的“公共機(jī)制”。1、UML中的基本構(gòu)造塊構(gòu)成UML模型的基本構(gòu)造塊有“事物”、“關(guān)系”、“圖”三種積木元素或積木組合體。事物:是UML模型中的靜態(tài)元素,UML中共有11種不同的事物,結(jié)構(gòu)事物(類、接口、協(xié)作、用例、主動類、構(gòu)件、節(jié)點(diǎn))、行為事物(交互、狀態(tài)機(jī))、分組事物(包)和注釋事務(wù)(注釋)如表2-1和圖2-10所示。用例構(gòu)件類屬性操作對象屬性操作接口節(jié)點(diǎn)包注釋狀態(tài)機(jī)圖2-10UML中的模型元素關(guān)系:也是UML模型的構(gòu)造塊,它們反應(yīng)的是類與類之間聯(lián)系的方法與性質(zhì),關(guān)系有依賴、關(guān)聯(lián)、泛化、實現(xiàn)和聚合等5種(見表2-2)關(guān)聯(lián)

關(guān)聯(lián)是描述兩個或多個類之間的聯(lián)系,鏈則是關(guān)聯(lián)的實例,它們之間的關(guān)系與類和對象之間的關(guān)系類似。在程序設(shè)計中,關(guān)聯(lián)常用一個對象到另一對象的指針實現(xiàn)。②依賴所謂依賴關(guān)系是一種使用關(guān)系,它說明一個類的變化可能影響到使用它的另一個類。比如一個類使用另一個類的對象作為操作參數(shù),綁定(bind)、友元(friend)等。課題組增加(學(xué)生:x)刪除(學(xué)生:x)……….學(xué)生姓名專業(yè)……….如果獨(dú)立類學(xué)生的專業(yè)屬性發(fā)生變化,將影響到課題組類的操作。在UML的類圖中,用帶箭頭的虛線連接有依賴關(guān)系的兩個類,箭頭指向獨(dú)立的類。在虛線上可以帶一個版類標(biāo)簽,具體說明依賴的種類。模板類Stack<T>定義了棧相關(guān)的操作;IntStack將參數(shù)T與實際類型int綁定,使得所有操作都針對int類型的數(shù)據(jù)類Memento和類Originator建立了友元依賴關(guān)系,以便Originator使用Memento的私有變量state泛化UML中的泛化關(guān)系就是就是通常所說的繼承關(guān)系,是具體元素和通用元素之間的一種分類關(guān)系。UML對定義泛化關(guān)系有下述三條要求?!?/p>

具體元素應(yīng)與通用元素完全一致,通用元素具有的屬性、操作和關(guān)聯(lián),具體元素也都隱含地具有?!?/p>

具體元素還應(yīng)包含通用元素所沒有的額外信息。·

允許使用通用元素實例的地方,也應(yīng)能夠使用具體元素的實例。泛化關(guān)系指出在類與類之間存在“一般——特殊”關(guān)系。基類子類B子類A雇員年收入計算月工資臨時工小時工資計算月工資固定工月工資計算月工資

在UML中,用一端為空心三角形的連線表示泛化關(guān)系,三角形的頂角緊挨著通用元素(基類)。則表示一種繼承關(guān)系。基類子類B子類Aor人員-姓名-年齡…….研究生-學(xué)號-年級…….教工-職稱-工齡…….在職研究生-在職單位-年級…….④實現(xiàn)(細(xì)化)關(guān)系

同一個事物在不同抽象層次上進(jìn)行描述時,之間具有細(xì)化(實現(xiàn))關(guān)系。細(xì)化的圖示符號由空心的三角形加虛線表示。對應(yīng)于類和接口之間的關(guān)系,如圖:類CreditCardPayment和類CashPayment實現(xiàn)了接口Payment的操作caleAmount

聚集是關(guān)聯(lián)的特例,它表示類與類之間的關(guān)系是整體與部分的關(guān)系。在陳述需求時使用的“包含”、“組成”、“分為……部分”等字句,往往意味著存在聚集關(guān)系。把作為“整體”的類稱為聚集,作為“部分”的類稱為成分。聚合的目的是為了保持對象的完整性。聚集之外,還有兩種特殊的聚集關(guān)系,分別是共享聚集和組合聚集。⑤聚合/聚集共享聚集

如果在聚集關(guān)系中處于部分方的對象可同時參與多個處于整體方對象的構(gòu)成,則該聚集稱為共享聚集,即聚集對象由部分對象組成。一般聚集和共享聚集的圖示符號,都是在表示關(guān)聯(lián)關(guān)系的直線末端緊挨著整體類的地方畫一個空心菱形。在共享聚集中,部分可能屬于多個整體。即一個人可以屬于多個課題組。組合/組成聚集

如果部分的類完全隸屬于整體類,部分與整體共存,整體不存在了部分也會隨之消失(或失去存在價值了),則該聚集稱為組合聚集(簡稱為組成)。組成關(guān)系用實心菱形表示。Person………..……….Head………..……….Hand………..……….1.2人員-姓名-年齡-電話號碼+撥電話學(xué)生-學(xué)號-年級+考試教師-職稱-工齡+授課課題組-名稱-活動時間+科研大學(xué)-名稱-位置+招生+招聘1,*11,*0,*組合關(guān)系共享關(guān)系單繼承關(guān)系圖:是一組元素的表示,包含了事物及其關(guān)系的組合。UML主要用圖來表達(dá)模型的內(nèi)容,用代表模型元素(例如,用例、類、對象、消息和關(guān)系)的圖形符號組成。學(xué)會使用UML的圖,是學(xué)習(xí)、使用統(tǒng)一建模語言UML的關(guān)鍵。UML中有9種圖,如表2-3所示。1、類和類圖類是對一組具有相同屬性、相同操作、相同關(guān)系和相同語義的對象的描述。類實現(xiàn)一個或多個接口。在圖形上,把類畫成一個矩形,用兩條橫線把長方形分成上、中、下三個區(qū)域(后兩個區(qū)域可省),三個區(qū)域分別用來存放類名、屬性和服務(wù)(操作)。可見性-代表private+代表public#代表protected也可以使用圖形表示返回值類型操作名稱斜體為抽象操作缺省值類名斜體為抽象類屬性名稱參數(shù)列表類圖-類圖描述系統(tǒng)中類的靜態(tài)結(jié)構(gòu)。不僅定義系統(tǒng)中的類,表示類之間的聯(lián)系如關(guān)聯(lián)、依賴、聚合等,也包括類的內(nèi)部結(jié)構(gòu)(類的屬性和操作)

Graphics:基本圖形和組合圖形的父類,聲明了所有圖形共同的操作,如Draw;也聲明了專用于組合圖形管理子圖形的操作,如Add、RemoveLine、Rectangle:基本圖形類GroupGraphics:組合圖形類,與父類有組合關(guān)系,從而可以組合所有圖形對象(基本圖形和組合圖形)2、對象圖

對象是類的實例,對象之間的連接是類之間關(guān)聯(lián)的實例,因此,對象圖可以看作是類圖的實例,能幫助人理解一個比較復(fù)雜的類圖。在UML中,對象圖與類圖具有幾乎完全相同的表示形式,主要差別是對象的名字下面要加一條下劃線。對象名有下列三種表示格式:第一種格式對象名在前,類名在后,中間用冒號連接。形如:對象名:類名

第二種格式省略類名,但冒號不能省略。形如::類名

第三種格式只有對象名(即省略類名)。形如:對象名

用例模型描述的是外部參與者(actor)所理解的系統(tǒng)功能。用例模型用于需求分析階段,它的建立是系統(tǒng)開發(fā)者和用戶反復(fù)討論的結(jié)果,描述了開發(fā)者和用戶對需求規(guī)格達(dá)成的共識。首先,它描述了待開發(fā)系統(tǒng)的功能需求;其次,它把系統(tǒng)看作黑盒子,從外部參與者的角度來理解系統(tǒng);第三,它驅(qū)動了需求分析之后各階段的開發(fā)工作,不僅在開發(fā)過程中保證了系統(tǒng)所有功能的實現(xiàn),而且被用于驗證和檢測所開發(fā)的系統(tǒng),從而影響到開發(fā)工作的各個階段和UML的各個模型。3、用例圖事物名稱解釋UML表示參與者(Actor)在系統(tǒng)外部與系統(tǒng)直接交互的人或事物(如另一個計算機(jī)系統(tǒng)或一些可運(yùn)行的進(jìn)程)。我們需要注意的是:1.參與者是角色(role)而不是具體的人,它代表了參與者在與系統(tǒng)打交道的過程中所扮演的角色。所以在系統(tǒng)的實際運(yùn)作中,一個實際用戶可能對應(yīng)系統(tǒng)的多個參與者。不同的用戶也可以只對應(yīng)于一個參與者,從而代表同一參與者的不同實例。2.參與者作為外部用戶(而不是內(nèi)部)與系統(tǒng)發(fā)生交互作用,是它的主要特征。3.在后面的順序圖等中出現(xiàn)的“參與者”,與此概念相同,但具體指代的含義,視具體情況而定。用例(UseCase)系統(tǒng)外部可見的一個系統(tǒng)功能單元。系統(tǒng)的功能由系統(tǒng)單元所提供,并通過一系列系統(tǒng)單元與一個或多個參與者之間交換的消息所表達(dá)。關(guān)系解釋圖參與者與用例之間的關(guān)系關(guān)聯(lián)表示參與者與用例之間的交互,通信途徑。(關(guān)聯(lián)有時候也用帶箭頭的實線來表示,這樣的表示能夠顯示地表明發(fā)起用例的是參與者。)用例之間的關(guān)系包含箭頭指向的用例為被包含的用例,稱為包含用例;箭頭出發(fā)的用例為基用例。包含用例是必選的,如果缺少包含用例,基用例就不完整;包含用例必須被執(zhí)行,不需要滿足某種條件;其執(zhí)行并不會改變基用例的行為。

《include》擴(kuò)展箭頭指向的用例為被擴(kuò)展的用例,稱為擴(kuò)展用例;箭頭出發(fā)的用例為基用例。擴(kuò)展用例是可選的,如果缺少擴(kuò)展用例,不會影響到基用例的完整性;擴(kuò)展用例在一定條件下才會執(zhí)行,并且其執(zhí)行會改變基用例的行為。參與者之間的關(guān)系泛化發(fā)出箭頭的事物“isa”箭頭指向的事物。泛化關(guān)系是一般和特殊關(guān)系,發(fā)出箭頭的一方代表特殊的一方,箭頭指向的一方代表一般一方。特殊一方繼承了一般方的特性并增加了新的特性?!秂xtend》實例1參與者之間的泛化關(guān)系參與者:經(jīng)理,安全主管,保安用例:管理人事,批準(zhǔn)預(yù)算,批準(zhǔn)安全證書,監(jiān)視周邊在參與者之間不存在泛化關(guān)系的情況下,各個參與者參與用例的情況分別是:經(jīng)理參與用例管理人事和批準(zhǔn)預(yù)算;安全主管參與用例批準(zhǔn)安全證書;保安參與用例監(jiān)視周邊。由于安全主管與經(jīng)理,安全主管與保安之間泛化關(guān)系的存在,意味著安全主管可以擔(dān)任經(jīng)理和保安的角色,就能夠參與經(jīng)理和保安參與的用例。這樣,安全主管就可以參與全部4個用例。但經(jīng)理或者保安卻不能擔(dān)任安全主管的角色,也就不能參與用例批準(zhǔn)安全證書。實例2用例之間擴(kuò)展和包含關(guān)系用例的上下文是:短途旅行但汽車的油不足以應(yīng)付全部路程。那么為汽車加油的動作在旅行的每個場景(事件流)中都會出現(xiàn),不加油就不會完成旅行。吃飯則可以由司機(jī)決定是否進(jìn)行,不吃飯不會影響旅行的完成。4、狀態(tài)圖(StatechartDiagram)

狀態(tài)圖描述一個特定對象的所有可能的狀態(tài)以及引起狀態(tài)轉(zhuǎn)換的事件。大多數(shù)面向?qū)ο蠹夹g(shù)都用狀態(tài)圖表示單個對象在其生命期中的行為。一個狀態(tài)圖包括一系列狀態(tài)、事件以及狀態(tài)之間的轉(zhuǎn)移。第6章面向?qū)ο蠓椒?)狀態(tài),是對象執(zhí)行了一系列活動的結(jié)果。當(dāng)某個事件發(fā)生后,對象的狀態(tài)將發(fā)生變化。在狀態(tài)圖中定義的狀態(tài)可能有:初態(tài)(初始狀態(tài))、終態(tài)(最終狀態(tài))、中間狀態(tài)和復(fù)合狀態(tài)。是對象所具有的屬性值的抽象,具有時間性和持續(xù)性。中間狀態(tài)用圓角矩形表示,其可能包含三個部分,如圖第一部分為狀態(tài)的名稱;第二部分為狀態(tài)變量的名字和值,這部分是可選的;第三部分是行為表,這部分也是可選的。結(jié)束狀態(tài)初始狀態(tài)中間狀態(tài)

狀態(tài)名狀態(tài)變量行為表第6章面向?qū)ο蠓椒?)事件是指對象狀態(tài)變化的觸發(fā)活動,是引起狀態(tài)轉(zhuǎn)換的控制信息,是從一個狀態(tài)到另一個狀態(tài)的信息的單向傳遞。3)活動是指對象觸發(fā)狀態(tài)變化的一系列操作。4)行為是指對象在所處狀態(tài)內(nèi)進(jìn)行的一系列操作。包括三個標(biāo)準(zhǔn)行為:entry(進(jìn)入)、exit(退出)和do(做)。entry事件指定進(jìn)入該狀態(tài)的動作,exit事件指定退出該狀態(tài)的動作,而do事件則指定在該狀態(tài)下的動作。5)內(nèi)部轉(zhuǎn)移:在不使?fàn)顟B(tài)發(fā)生變更的情況下進(jìn)行的轉(zhuǎn)移。第6章面向?qū)ο蠓椒?/p>

狀態(tài)用圓角框表示,框內(nèi)標(biāo)注狀態(tài)名,用箭頭連線表示狀態(tài)的轉(zhuǎn)換,上面標(biāo)記事件名及相關(guān)活動,箭頭方向表示轉(zhuǎn)換的方向,初始狀態(tài)用圓點(diǎn)表示,終止?fàn)顟B(tài)用圓圈內(nèi)一個圓點(diǎn)表示。

狀態(tài)名狀態(tài)變量行為表事件1[活動1]初始事件結(jié)束事件

狀態(tài)名狀態(tài)變量行為表第6章面向?qū)ο蠓椒ń顟B(tài)圖的步驟(1)確定對象的初始狀態(tài)和終止?fàn)顟B(tài)。如果初始和終止?fàn)顟B(tài)具有前提條件和后續(xù)條件,也應(yīng)將這些條件定義出來。

(2)確定對象要響應(yīng)的事件。這些事件可以在對象的接口或協(xié)議中找到。(3)按照從初始狀態(tài)到終止?fàn)顟B(tài)的順序,列出對象可能處于的頂層狀態(tài)。將這些狀態(tài)與相應(yīng)事件所觸發(fā)的轉(zhuǎn)移連接起來。然后添加這些轉(zhuǎn)移。

(4)確定所有進(jìn)入操作或退出操作。

(5)檢查狀態(tài)圖中的所有事件觸發(fā)轉(zhuǎn)移是否與該對象實現(xiàn)的接口或協(xié)議所期望的事件相符。(6)檢查狀態(tài)機(jī)中的所有操作是否都得到了包含對象的關(guān)系、方法和操作的支持。第6章面向?qū)ο蠓椒ɡ?第6章面向?qū)ο蠓椒ɡ?電梯的狀態(tài)圖第6章面向?qū)ο蠓椒ɡ?:研討班注冊的一個UML狀態(tài)圖5、順序圖順序圖用來表示用例中的行為順序。當(dāng)執(zhí)行一個用例行為時,順序圖中的每條消息對應(yīng)了一個類操作或狀態(tài)機(jī)中引起轉(zhuǎn)換的事件。順序圖展示對象之間的交互,這些交互是指在場景或用例的事件流中發(fā)生的。順序圖屬于動態(tài)建模。順序圖的重點(diǎn)在消息序列上,也就是說,描述消息是如何在對象間發(fā)送和接收的。表示了對象之間傳送消息的時間順序。瀏覽順序圖的方法是:從上到下查看對象間交換的消息。。事物名稱解釋圖參與者與系統(tǒng)、子系統(tǒng)或類發(fā)生交互作用的外部用戶(參見用例圖定義)。對象順序圖的橫軸上是與序列有關(guān)的對象。對象的表示方法是:矩形框中寫有對象或類名,且名字下面有下劃線。生命線坐標(biāo)軸縱向的虛線表示對象在序列中的執(zhí)行情況(即發(fā)送和接收的消息,對象的活動)這條虛線稱為對象的“生命線”,矩形符號表示激活,激活的生存期在生命線上。消息符號消息用從一個對象的生命線到另一個對象生命線的箭頭表示。箭頭以時間順序在圖中從上到下排列。第6章面向?qū)ο蠓椒樞驁D示例從參與者到對象和從對象到參與者之間發(fā)送的消息從對象傳遞給另一個對象的消息在類圖中的類的對象使用系統(tǒng)的參與者,這個系統(tǒng)是為某個用例的某個場景設(shè)計的對象生命線表示從上到下的時間順序,消息1在消息2之前發(fā)生,消息2在消息3之前發(fā)生窄長方框用以強(qiáng)調(diào)這個部分處于活動狀態(tài)消息格式:

operation(parameterlist)向哪個對象發(fā)消息實際上就是調(diào)用它的類中的操作,就是調(diào)用箭頭指向的對象所在類的一個operation。例:訂單類發(fā)消息給客戶類調(diào)用客戶類中的“驗證客戶”操作順序圖與用例圖和類圖的關(guān)系此圖是描述購票這個用例的順序圖。顧客在信息亭與售票中心通話觸發(fā)了這個用例的執(zhí)行。順序圖中付款這個用例包括售票中心與信息亭和信用卡服務(wù)處使用消息進(jìn)行通信過程。從這個例子中可以看出:Kjosk類中的操作有ShowAvailable(seat-list)DemandPayment(cost)printtickets(performance,seats)ejectcardBoxOffice中的操作有Request(count,performance)SelectSeatsInsertCard(CardNumber)authorizedCreditCardService類中的操作有charge(cardnumber,cost)第6章面向?qū)ο蠓椒?、協(xié)作圖協(xié)作圖是一種交互圖,強(qiáng)調(diào)的是發(fā)送和接收消息的對象之間的組織結(jié)構(gòu),使用協(xié)作圖來說明系統(tǒng)的動態(tài)情況。協(xié)作圖主要描述協(xié)作對象間的交互和鏈接,顯示對象、對象間的鏈接以及對象間如何發(fā)送消息。協(xié)作圖可以表示類操作的實現(xiàn)。協(xié)作圖與順序圖不同的是,協(xié)作圖側(cè)重點(diǎn)在事件。通過對消息進(jìn)行編號表述協(xié)作圖中事件發(fā)生的次序,并顯示方法調(diào)用的細(xì)節(jié)。事物名稱解釋圖參與者發(fā)出主動操作的對象,負(fù)責(zé)發(fā)送初始消息,啟動一個操作。對象對象是類的實例,負(fù)責(zé)發(fā)送和接收消息,與順序圖中的符號相同,冒號前為對象名,冒號后為類名。消息流(由箭頭和標(biāo)簽組成)箭頭指示消息的流向,從消息的發(fā)出者指向接收者。標(biāo)簽對消息作說明,其中,順序號指出消息的發(fā)生順序,并且指明了消息的嵌套關(guān)系;冒號后面是消息的名字。標(biāo)簽第6章面向?qū)ο蠓椒ǎ篊lassE:ClassE:ClassE:ClassE:ClassEMsg()1a[test1]:Msg1()1b.1:Msg4()1b:[nottest1]:Msg3()1a.1:Msg2()2*[i=1..N]:Msg5()消息2要重復(fù)發(fā)送N次消息1根據(jù)判定條件的不同結(jié)果發(fā)送第6章面向?qū)ο蠓椒ɡ?例2:訂票交互過程的協(xié)作圖7、活動圖

活動圖是另一種描述交互的方式,它描述采取何種動作,動作的結(jié)果是什么(動作狀態(tài)改變),何時發(fā)生(動作序列),以及在何處發(fā)生(泳道)。活動圖可看作是一種流程圖。它顯示活動序列、判定點(diǎn)和分支。通常情況下,活動圖可以處理并行進(jìn)程。在一個活動圖中只有一個起始狀態(tài)。終止?fàn)顟B(tài)表示了一個活動圖的最后和終結(jié)狀態(tài),一個活動圖中可以有0個或多個終止?fàn)顟B(tài)。打開收音機(jī)吃早餐聽音樂去教室軟件工程網(wǎng)絡(luò)基礎(chǔ)回寢室[雙周][單周]條件并發(fā)第6章面向?qū)ο蠓椒ɑ顒訄D示例制訂教學(xué)計劃預(yù)習(xí)備課選課上課考試評成績學(xué)生教師帶泳道的活動圖第6章面向?qū)ο蠓椒ɡ菏燮敝行牡幕顒訄D第6章面向?qū)ο蠓椒?/p>

物理視圖有兩種:組件圖和部署圖。將組件圖和部署圖合二為一成為實現(xiàn)圖。

用小圓圈代表接口,即服務(wù)的連貫集。從組件到接口的實線表明該組件提供的列在接口旁的服務(wù)。從組件到接口的虛線箭頭說明這個組件要求接口提供的服務(wù)。8、組件圖和部署圖第6章面向?qū)ο蠓椒?)組件

組件是構(gòu)造應(yīng)用的軟件單元,它將類和接口等邏輯元素打包而形成的物理模塊,如執(zhí)行文件和庫。包內(nèi)的組件名應(yīng)唯一,用包名區(qū)分組件屬于不同的包。

包名::組件名tool::dialog.dll表示法組件示例第6章面向?qū)ο蠓椒ǎ?)組件與類

組件與類很相似,都能實現(xiàn)一組接口,都有依賴、關(guān)聯(lián)、繼承和聚合關(guān)系,都可以有實例和參與交互。但他們之間有明顯的不同。a)類表示邏輯抽象是邏輯模塊,而組件表示以比特表示的物理抽象,是物理模塊。b)類具有屬性和操作,構(gòu)件通常僅擁有通過其接口向外提供或請求的操作。tool::dialog.dllClassAClassB1*tool::dialog.dllClassAClassB1*第6章面向?qū)ο蠓椒?2)組件與接口

接口描述類或組件所提供操作的集合,用小圓圈代表接口,即服務(wù)的連貫集。從組件到接口的實線表明該組件提供的列在接口旁的服務(wù)。從組件到接口的虛線箭頭說明這個組件要求接口提供的服務(wù)。Image.javacomp.javaImageObserver<<interface>>ImageObserverimageUpdate():Boolean…comp.javaImage.java接口的實現(xiàn)Comp提供接口第6章面向?qū)ο蠓椒ǎ?)組件圖/構(gòu)件圖組件圖用于表示一組組件及其它們之間的關(guān)系tool.exeedit.dlldialog.dlltool.cppedit.htool.h源代碼組件之間的關(guān)系可執(zhí)行組件和二進(jìn)制組件的關(guān)系第6章面向?qū)ο蠓椒?/p>

(3)部署圖

部署圖用于系統(tǒng)的硬件拓?fù)浣Y(jié)構(gòu)建模。它包含節(jié)點(diǎn)、節(jié)點(diǎn)之間的關(guān)系、組件及組件與節(jié)點(diǎn)之間的關(guān)系。節(jié)點(diǎn)是運(yùn)行時存在并代表一項計算資源的物理元素,一般至少擁有內(nèi)存和計算處理能力,通常表示一個可以在其上部署組件的處理器或設(shè)備。comp1.execomp2.exe節(jié)點(diǎn)名稱第6章面向?qū)ο蠓椒ɡ菏燮毕到y(tǒng)的部署圖2、UML中的規(guī)則——UML建模的“粘合劑”UML中的規(guī)則是為了將UML中的構(gòu)造塊有機(jī)地組裝在一起,形成一個結(jié)構(gòu)良好的模型而對事物進(jìn)行描述的語義規(guī)則。共有5種規(guī)則:命名規(guī)則:為事物、關(guān)系和圖命名范圍規(guī)則:給一個名字以特定含義的語境可見性規(guī)則:描述名字可見或如何使用(見表2-4)。完整性規(guī)則:描述事物正確、一致地相互聯(lián)系。執(zhí)行規(guī)則:描述運(yùn)行或模擬動態(tài)模型的含義。3、應(yīng)用于UML的公共機(jī)制——UML模型的圖紙說明規(guī)格說明:UML圖形的每一部分背后都有一個詳細(xì)的說明,提供了對UML構(gòu)造塊的語法和語義的文字描述。修飾:UML表示法中的每一個元素都有一個基本符號,這些符號對元素的最重要的方面進(jìn)行了可視化的表示,還包含了對元素其他細(xì)節(jié)的描述,例如不同可視性的符號、用斜體字表示抽象類。通用劃分:UML中的構(gòu)造塊存在兩種通用的劃分方法:類和對象、接口與實現(xiàn)。類是一個抽象,對象是該抽象的一個實例,可同時對類和對象建模;接口聲明一個契約,實現(xiàn)表示對該契約的具體實施,可同時對接口和實現(xiàn)建模。擴(kuò)展機(jī)制:擴(kuò)展機(jī)制進(jìn)一步提高了UML的語言表達(dá)能力,它包含構(gòu)造型、標(biāo)記值和約束等3種類型。構(gòu)造型:擴(kuò)展UML的詞匯,允許創(chuàng)造新的構(gòu)造塊,該構(gòu)造塊既可從現(xiàn)有構(gòu)造塊派生,也可針對要解決的問題另建。標(biāo)記值:擴(kuò)展UML構(gòu)造塊的特性,允許創(chuàng)建元素的新信息。約束:擴(kuò)展UML構(gòu)造塊的語義,允許增加新的規(guī)則或修改現(xiàn)有的規(guī)則。2.4.2UML建模機(jī)制UML為了適應(yīng)不同的情況,提供了不同的模型,這表現(xiàn)在它的“9個模型、9種圖和5張視圖”上。1、9個模型業(yè)務(wù)模型:業(yè)務(wù)操作流程,建立組織的一個抽象。領(lǐng)域模型:業(yè)務(wù)操作規(guī)程,建立系統(tǒng)的語境。用例模型:用戶功能需求列表,建立系統(tǒng)的功能需求。分析模型:系統(tǒng)的邏輯設(shè)計,建立概念設(shè)計。設(shè)計模型:物理設(shè)計(含字典設(shè)計),建立問題的詞匯以及解決方案。過程模型:系統(tǒng)的進(jìn)程設(shè)計,建立系統(tǒng)的并發(fā)和同步機(jī)制。部署模型:系統(tǒng)的網(wǎng)絡(luò)節(jié)點(diǎn)設(shè)計,建立系統(tǒng)的硬件拓?fù)渚W(wǎng)絡(luò)結(jié)構(gòu)。實現(xiàn)模型:系統(tǒng)的軟硬件配置設(shè)計,建立用于實施和發(fā)布物理系統(tǒng)的各部件。測試模型:系統(tǒng)的測試計劃設(shè)計,建立驗證和校驗系統(tǒng)的路徑。2、9個圖可以將這9種圖分為兩類,一類用于結(jié)構(gòu)建模,稱為結(jié)構(gòu)圖;一類用于行為建模,稱為行為圖,圖的定義如表2-3所示。3、5張視圖統(tǒng)一建模語言UML是用來描述模型的,它用模型來描述系統(tǒng)的結(jié)構(gòu)、靜態(tài)特征及動態(tài)特征,它從不同

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論