軟件系統(tǒng)發(fā)方法

1、2021年11月7日星期日第1頁第3章 軟件系統(tǒng)開發(fā)方法v3.1 軟件開發(fā)生命周期v3.2 軟件開發(fā)模型v3.3 傳統(tǒng)軟件開發(fā)方法v3.4 面向?qū)ο筌浖_發(fā)方法v3.5 rup統(tǒng)一軟件開發(fā)過程v3.6 敏捷軟件開發(fā)技術(shù)2021年11月7日星期日第2頁v在軟件開發(fā)的早期，人們常用的軟件開發(fā)方法是邊寫邊改法。這種開發(fā)方法在應(yīng)用開發(fā)中最為快捷，但由于其開發(fā)的隨意性，因而也最為低效。同時，使用該方法的項(xiàng)目常常因?yàn)楣芾硎Э囟K結(jié)?；谶@種情況，業(yè)界人士借鑒其它工程領(lǐng)域的方法，提出了許多有規(guī)則可言的軟件系統(tǒng)開發(fā)方法。最著名的當(dāng)數(shù)“瀑布式”方法了，即把軟件開發(fā)過程分解成這樣一些階段：制定開發(fā)計劃、需求分析和

2、定義、系統(tǒng)設(shè)計、編碼實(shí)現(xiàn)、測試驗(yàn)證。然而，在軟件開發(fā)實(shí)踐中完全遵循這種過程取得成功的案例并不多。其原因主要在于這種方法有一個前提條件，那就是系統(tǒng)需求必須明確、不變。但在現(xiàn)實(shí)應(yīng)用中，這幾乎是不可能的。需求通常模糊不清，并且在系統(tǒng)開發(fā)期間隨時都有可能發(fā)生變化。因此軟件開發(fā)要求采用的方法過程也必須能適應(yīng)這種變化，這就出現(xiàn)了其它一些軟件開發(fā)方法，如原型法、敏捷方法等。2021年11月7日星期日第3頁3.1 軟件開發(fā)生命周期v正如任何事物一樣，軟件也有其孕育、誕生、成長、成熟以及衰亡的生命過程，一般稱其為“軟件生命周期”。 2021年11月7日星期日第4頁3.1 軟件開發(fā)生命周期v根據(jù)這一思想，可以得到

3、軟件生命周期的六個階段：制定計劃需求分析和定義設(shè)計編碼測試運(yùn)行及維護(hù)。2021年11月7日星期日第5頁3.1 軟件開發(fā)生命周期v(1) 制定計劃（planning）團(tuán)隊人員：分析人員、領(lǐng)域?qū)＜壹坝脩舻?。這個階段的任務(wù)是確定待開發(fā)軟件系統(tǒng)的總體目標(biāo)，給出軟件系統(tǒng)的功能、性能及接口等方面的要求。由團(tuán)隊人員協(xié)作，共同研究完成該項(xiàng)軟件開發(fā)任務(wù)的技術(shù)、經(jīng)濟(jì)、社會可行性，探討解決問題的各種可能方案，并對現(xiàn)有可利用資源、成本、可取得的效益、開發(fā)進(jìn)度等做出估計，制定出完成該項(xiàng)開發(fā)任務(wù)的實(shí)施計劃，并編寫可行性研究報告。 2021年11月7日星期日第6頁3.1 軟件開發(fā)生命周期v(2) 需求分析和定義（requi

4、rement analysis and definition）團(tuán)隊人員：分析人員、測試人員、領(lǐng)域?qū)＜壹坝脩舻?。該階段對于待開發(fā)軟件項(xiàng)目獲取的用戶需求進(jìn)行分析，并給出詳細(xì)定義。這個階段團(tuán)隊人員必須協(xié)同工作，讓軟件開發(fā)人員充分理解用戶的各項(xiàng)需求，并確定哪些需求是可以滿足的，哪些需求在現(xiàn)有技術(shù)下是不能滿足的，對能滿足的需求加以確切的描述。然后，編寫出軟件需求規(guī)格說明書（srs）或系統(tǒng)功能說明書，以及初步的系統(tǒng)用戶手冊、測試用例等。為了團(tuán)隊人員之間能很好地溝通，從這個階段開始通常會采用一些標(biāo)準(zhǔn)的建模語言（如：統(tǒng)一建模語言，unified modeling language，簡稱uml）對系統(tǒng)建模。 2

5、021年11月7日星期日第7頁3.1 軟件開發(fā)生命周期v(3) 軟件設(shè)計（software design）團(tuán)隊人員：架構(gòu)設(shè)計人員、軟件設(shè)計人員、數(shù)據(jù)庫設(shè)計員、用戶界面設(shè)計員、封裝體設(shè)計員和集成人員、測試人員等。這個階段通常分為兩部分：概要設(shè)計和詳細(xì)設(shè)計。在軟件設(shè)計階段，軟件開發(fā)人員把已經(jīng)經(jīng)過用戶和領(lǐng)域?qū)＜掖_認(rèn)的各項(xiàng)需求轉(zhuǎn)換成相應(yīng)的軟件體系結(jié)構(gòu)。結(jié)構(gòu)中的每一成份都是意義明確的子系統(tǒng)、模塊或用例，每個部分都和某些需求相對應(yīng)，進(jìn)行所謂的概要設(shè)計。然后對每個模塊或用例要完成的工作采用合適的技術(shù)進(jìn)行具體的描述，如畫出模塊的程序流程圖或描述類的屬性、操作等，為源程序的編寫工作打下基礎(chǔ)，即所謂的詳細(xì)設(shè)計。

6、2021年11月7日星期日第8頁3.1 軟件開發(fā)生命周期v(4) 編碼（coding）團(tuán)隊人員：編程人員、測試人員等。將詳細(xì)設(shè)計階段所描述的模塊程序流程圖或類的設(shè)計轉(zhuǎn)換為計算機(jī)能處理的程序代碼，即使用特定的程序設(shè)計語言表示的源程序。目前，通常使用高級程序設(shè)計語言編寫程序，如c語言、java語言等。2021年11月7日星期日第9頁3.1 軟件開發(fā)生命周期v(5) 軟件測試（software testing）團(tuán)隊人員：測試人員、開發(fā)人員、用戶等。測試是保證軟件質(zhì)量的重要手段，其主要目的是通過軟件測試暴露出軟件中隱藏的錯誤和缺陷。軟件測試的主要方式是在設(shè)計測試用例的基礎(chǔ)上檢驗(yàn)軟件的各個組成部分。軟件

7、測試一般包括單元測試、集成測試、系統(tǒng)測試、驗(yàn)收測試等幾個階段。首先進(jìn)行單元測試，查找各模塊或類在功能和結(jié)構(gòu)上存在的問題并加以修改，這個過程會反復(fù)進(jìn)行；其次進(jìn)行集成測試，驗(yàn)證各軟件單元集成后形成的模塊能否達(dá)到概要設(shè)計規(guī)格說明中各模塊的設(shè)計目標(biāo)；然后進(jìn)行系統(tǒng)測試，目的是對最終軟件系統(tǒng)進(jìn)行全面的測試，確保最終軟件系統(tǒng)滿足產(chǎn)品需求并且遵循系統(tǒng)設(shè)計；最后進(jìn)行確認(rèn)測試，以檢查已實(shí)現(xiàn)的軟件是否滿足了需求規(guī)格說明書中確定的各種需求，包括功能需求和性能需求，決定已開發(fā)的軟件能否交付用戶使用。 2021年11月7日星期日第10頁3.1 軟件開發(fā)生命周期v(6) 運(yùn)行/維護(hù)（running/maintenance）

8、團(tuán)隊人員：系統(tǒng)支持人員等。已交付的軟件投入正式使用，軟件便進(jìn)入運(yùn)行階段。軟件在運(yùn)行過程中可能會因?yàn)榘l(fā)現(xiàn)了軟件中存在的錯誤需要修改；或?yàn)榱诉m應(yīng)變化了的軟件工作環(huán)境，需做一些變更；或?yàn)榱嗽鰪?qiáng)軟件的功能需做變更等。這就稱為軟件維護(hù)。 2021年11月7日星期日第11頁3.2 軟件開發(fā)模型v從上節(jié)的內(nèi)容中我們知道，一個軟件的生命周期包含了若干個活動，那么，這些活動應(yīng)該如何組織呢？不同的組織方式可能會產(chǎn)生很大差別的結(jié)果。v實(shí)際上，與其它工程項(xiàng)目中安排各道工序類似，為了反應(yīng)軟件開發(fā)生命周期內(nèi)的各種活動應(yīng)如何組織，各活動之間應(yīng)如何銜接，需要用軟件開發(fā)模型做出直觀的圖示來表達(dá)。2021年11月7日星期日第12

9、頁3.2 軟件開發(fā)模型v軟件開發(fā)模型是從軟件項(xiàng)目需求定義到軟件經(jīng)使用后被廢棄為止，跨越整個軟件生命周期的系統(tǒng)開發(fā)、運(yùn)作和維護(hù)的全部過程、活動和任務(wù)的結(jié)構(gòu)框架，它給出了軟件開發(fā)活動各個階段之間的關(guān)系。每種軟件生命周期模型代表一種軟件開發(fā)與管理的組織過程。 2021年11月7日星期日第13頁3.2 軟件開發(fā)模型v迄今為止，出現(xiàn)了多種軟件開發(fā)模型。如：迄今為止，出現(xiàn)了多種軟件開發(fā)模型。如：瀑布模型螺旋模型演化模型噴泉模型智能模型增量模型原型化模型 2021年11月7日星期日第14頁3.2.1 瀑布模型v瀑布模型將軟件生命周期劃分為制定開發(fā)計劃、需求分析和定義、軟件設(shè)計、程序編寫、軟件測試和運(yùn)行維護(hù)等

10、六個基本活動，并且規(guī)定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。 2021年11月7日星期日第15頁3.2.1 瀑布模型v瀑布模型是最早出現(xiàn)的軟件開發(fā)模型，在軟件工程中占有十分重要的地位，它提供了軟件開發(fā)的基本框架。瀑布模型規(guī)定了各項(xiàng)軟件工程活動，其核心思想是按工序?qū)栴}化簡，將功能的實(shí)現(xiàn)與設(shè)計分開，便于分工協(xié)作，即采用結(jié)構(gòu)化的分析與設(shè)計方法將邏輯實(shí)現(xiàn)與物理實(shí)現(xiàn)分開。 軟件計劃 需求分析和定義 軟件設(shè)計 實(shí)現(xiàn) 測試 運(yùn)行維護(hù) 2021年11月7日星期日第16頁3.2.1 瀑布模型v瀑布模型每項(xiàng)開發(fā)活動均應(yīng)具有下述特征：(1) 從上一項(xiàng)活動接收本項(xiàng)活動的工作對象，作為本項(xiàng)活動的

11、輸入；(2) 利用這一輸入實(shí)施本項(xiàng)活動應(yīng)完成的任務(wù)；(3) 給出本項(xiàng)活動的工作成果，作為輸出傳遞給下一項(xiàng)活動；(4) 對本項(xiàng)活動實(shí)施的工作進(jìn)行評審。若得到確認(rèn)，則繼續(xù)下一項(xiàng)活動；否則，返回到前項(xiàng)活動，或更前一項(xiàng)活動進(jìn)行返工。 2021年11月7日星期日第17頁3.2.1 瀑布模型v瀑布模型中軟件維護(hù)的特點(diǎn)：瀑布模型中軟件維護(hù)的特點(diǎn)：(1) 維護(hù)的具體要求是在軟件投入使用以后提出來的，經(jīng)過評價，確定需求變更的必要性，才進(jìn)行維護(hù)工作。(2) 維護(hù)中對軟件的變更仍然要經(jīng)歷軟件生命周期在開發(fā)中已經(jīng)歷過的各項(xiàng)活動。2021年11月7日星期日第18頁3.2.1 瀑布模型v瀑布模型的優(yōu)點(diǎn)：瀑布模型的優(yōu)點(diǎn)：(

12、1) 為軟件項(xiàng)目提供了按階段劃分的檢查點(diǎn)，強(qiáng)調(diào)開發(fā)的階段性。(2) 強(qiáng)調(diào)早期計劃及需求調(diào)查。(3) 強(qiáng)調(diào)產(chǎn)品測試和階段評審。(4) 強(qiáng)調(diào)文檔的重要性。 2021年11月7日星期日第19頁3.2.1 瀑布模型v瀑布模型的缺點(diǎn)：瀑布模型的缺點(diǎn)：(1) 在項(xiàng)目各個階段之間極少有反饋，往往會將早期的錯誤引入到后期各個階段。(2) 依賴于早期進(jìn)行的唯一一次需求調(diào)查，用戶參與較少，不能適應(yīng)需求的變化。(3) 只有在項(xiàng)目生命周期的后期才能看到結(jié)果，可能與用戶的需求出現(xiàn)很大的偏差，使風(fēng)險推遲到項(xiàng)目開發(fā)的后期階段才顯露出來，因而失去及早糾正的機(jī)會。(4) 通過過多的強(qiáng)制完成日期和里程碑來跟蹤各個項(xiàng)目階段，靈活性

13、較差。 2021年11月7日星期日第20頁3.2.1 瀑布模型v瀑布模型缺乏靈活性，無法通過開發(fā)活動來理清本來不夠明確的需求，這將可能導(dǎo)致直到軟件開發(fā)完成時才發(fā)現(xiàn)所開發(fā)的軟件并非用戶所需要的，此時必將付出高額的代價才能糾正出現(xiàn)的偏差。v瀑布模型一般適用于功能、性能明確、完整、無重大變化的軟件系統(tǒng)的開發(fā)。如操作系統(tǒng)、編譯系統(tǒng)等系統(tǒng)軟件的開發(fā)。v當(dāng)用戶需求不明確或經(jīng)常變更時，不宜采用瀑布模型，可以考慮其它的架構(gòu)來進(jìn)行項(xiàng)目管理，如：演化模型等。 2021年11月7日星期日第21頁3.2.2 演化模型v演化模型主要針對事先不能完整定義需求的軟件開發(fā)。用戶可以給出待開發(fā)系統(tǒng)的核心需求，并且當(dāng)看到核心需求

14、實(shí)現(xiàn)后，能夠有效地提出反饋，以支持系統(tǒng)的最終設(shè)計和實(shí)現(xiàn)。2021年11月7日星期日第22頁3.2.2 演化模型v該模型可以表示為：第一次迭代（需求設(shè)計編碼測試集成）反饋第二次迭代（需求設(shè)計編碼測試集成）反饋. 2021年11月7日星期日第23頁3.2.2 演化模型 問 題 定 義 需求分析 設(shè)計 編碼 測試 集成 交付用戶 迭代 1 迭代 2 迭代 3 迭代 n 反饋 反饋 反饋 需求分析 設(shè)計 編碼 測試 集成 交付用戶 需求分析 設(shè)計 編碼 測試 集成 交付用戶 需求分析 設(shè)計 編碼 測試 集成 交付用戶 2021年11月7日星期日第24頁3.2.2 演化模型v演化模型的主要優(yōu)點(diǎn)：演化模型

15、的主要優(yōu)點(diǎn)：(1) 用戶能在開發(fā)過程中而不是開發(fā)接近尾聲時看到自己所需要的軟件產(chǎn)品。對發(fā)現(xiàn)的問題能夠提早解決。(2) 在一定程度上減少了軟件開發(fā)活動的盲目性。如果在某次迭代中，其需求沒有滿足用戶的要求，軟件開發(fā)人員可根據(jù)用戶的反饋信息在下一次迭代中予以修正。(3) 將系統(tǒng)中難度較大、風(fēng)險較高的部分安排在早期的迭代中，可增加項(xiàng)目的成功率。 2021年11月7日星期日第25頁3.2.2 演化模型v演化模型的缺點(diǎn)演化模型的缺點(diǎn)(1) 由于項(xiàng)目需求在開發(fā)初期不可能完全弄清楚，這樣會給系統(tǒng)總體設(shè)計帶來很大的困難，并影響系統(tǒng)設(shè)計的完整性。(2) 如果在開發(fā)過程中缺乏嚴(yán)格的過程管理，演化模型很可能退化為邊寫

16、邊改模式。(3) 如果沒有一定的約束條件，可能永遠(yuǎn)無法得到一個最終的軟件產(chǎn)品。 2021年11月7日星期日第26頁3.2.2 演化模型v采用演化模型的軟件開發(fā)過程，實(shí)際上是從最初的原型逐步演化成最終軟件產(chǎn)品的過程。在整個演化過程中，不斷修正缺陷，以開發(fā)出最終滿足用戶需要的軟件產(chǎn)品。v演化模型特別適用于用戶需求不夠明確的軟件開發(fā)項(xiàng)目，但不適宜用于大而復(fù)雜的系統(tǒng)。 2021年11月7日星期日第27頁3.2.3 螺旋模型v對于復(fù)雜的大型軟件系統(tǒng)，開發(fā)一個原型往往很難達(dá)到要求，顯然用單一的演化模型很難開發(fā)出這樣的軟件系統(tǒng)。那么，究竟要使用什么樣的模型才適合用來開發(fā)大型而復(fù)雜的軟件系統(tǒng)呢？答案就是螺旋模

17、型。 2021年11月7日星期日第28頁3.2.3 螺旋模型v螺旋模型沿著螺線旋轉(zhuǎn)，在笛卡爾坐標(biāo)的四個象限上分別表達(dá)了每個迭代周期的四個階段，從左象限按順時針方向依次為： 風(fēng)險 分析 可運(yùn)行原型 原型 1 原型 2 原型 3 風(fēng)險分析 風(fēng)險分析 風(fēng)險分析 操作概念 需求計劃、生命周期計劃 開發(fā)計劃 集成與測試計劃 軟件需求 需求確認(rèn) 軟件產(chǎn)品設(shè)計 設(shè)計確認(rèn)與驗(yàn)證 詳細(xì)設(shè)計 編碼 單元測試 集成測試 驗(yàn)收測試 實(shí)施 累計費(fèi)用 各步驟的進(jìn)度 評估方案 識別并排除風(fēng)險 制定目標(biāo) 選擇方案 設(shè)定約束條件 計劃下一階段 開發(fā)并驗(yàn)證下一級產(chǎn)品 模擬模型基準(zhǔn) 2021年11月7日星期日第29頁3.2.3 螺

18、旋模型v(1) 制定計劃確定該階段的軟件目標(biāo)，選定為完成這些目標(biāo)的實(shí)施方案，設(shè)定這些方案的約束條件。v(2) 風(fēng)險分析分析所選方案，識別并努力消除各種潛在的風(fēng)險，通常用構(gòu)建原型的方法來消除風(fēng)險。如果不能消除風(fēng)險，則停止開發(fā)工作或降低軟件項(xiàng)目規(guī)模。如果成功地消除了所有風(fēng)險，則轉(zhuǎn)向下一個階段。v(3) 實(shí)施工程實(shí)施軟件開發(fā)。這個階段相當(dāng)于一個純粹的瀑布模型。v(4) 用戶評估由用戶評價開發(fā)工作，提出修改建議。 2021年11月7日星期日第30頁3.2.3 螺旋模型v螺旋模型將瀑布模型和演化模型結(jié)合起來，吸取了兩者的優(yōu)點(diǎn)，并加入了兩種模型都忽略了的風(fēng)險分析，彌補(bǔ)了兩種模型的不足。 2021年11月7

19、日星期日第31頁3.2.3 螺旋模型v軟件風(fēng)險是任何軟件開發(fā)項(xiàng)目中普遍存在的實(shí)際問題，項(xiàng)目規(guī)模越大，問題越復(fù)雜，資源、成本、進(jìn)度等因素的不確定性就越大，承擔(dān)該項(xiàng)目所冒的風(fēng)險也就越大。軟件風(fēng)險可能在不同程度上損害軟件的開發(fā)過程和軟件產(chǎn)品的質(zhì)量。因此，在軟件開發(fā)過程中必須及時對風(fēng)險進(jìn)行識別、分析，采取應(yīng)有的措施，以消除或較少風(fēng)險的損害。 2021年11月7日星期日第32頁3.2.3 螺旋模型v在螺旋模型中，沿著螺線由內(nèi)向外每旋轉(zhuǎn)一圈，也就是每完成一次迭代過程，軟件開發(fā)就前進(jìn)一個層次，開發(fā)出一個更加完善的軟件版本。在每一圈螺線上，風(fēng)險分析作為開發(fā)是否能夠繼續(xù)下去的判斷點(diǎn)。假如風(fēng)險太大，開發(fā)人員和用戶

20、無法承受，開發(fā)項(xiàng)目有可能被終止。但多數(shù)情況下沿螺線的活動會繼續(xù)下去，并由內(nèi)向外逐步延伸，最終得到用戶所期望的系統(tǒng)。 2021年11月7日星期日第33頁3.2.3 螺旋模型v螺旋模型的優(yōu)點(diǎn)：螺旋模型的優(yōu)點(diǎn)：(1) 設(shè)計上的靈活性，可以保證在項(xiàng)目的各個階段進(jìn)行變更。(2) 以小的分段來構(gòu)建大型系統(tǒng)，使資源、成本和進(jìn)度的估計變得更加簡單容易。(3) 用戶始終參與到每個階段的開發(fā)中，保證了項(xiàng)目的正確性與可控性。2021年11月7日星期日第34頁3.2.3 螺旋模型v螺旋模型的缺點(diǎn)：螺旋模型的缺點(diǎn)：(1) 采用螺旋模型需要具有豐富的風(fēng)險評估經(jīng)驗(yàn)和專門知識，在風(fēng)險較大的項(xiàng)目開發(fā)中，如果未能及時識別出潛在的

21、風(fēng)險，或者消除風(fēng)險的能力不足，都會造成極其重大的損失。(2) 過多的迭代次數(shù)會增加軟件開發(fā)成本，延遲交付使用的時間。 2021年11月7日星期日第35頁3.2.3 螺旋模型v螺旋模型支持需求不明確，特別是大型軟件系統(tǒng)的開發(fā)，并支持面向規(guī)格說明、面向過程、面向?qū)ο蟮榷喾N軟件開發(fā)方法。由于螺旋模型是以風(fēng)險分析驅(qū)動的，一旦在開發(fā)過程中風(fēng)險過大就要停止繼續(xù)開發(fā)，因此，螺旋模型比較適合應(yīng)用于產(chǎn)品研發(fā)或機(jī)構(gòu)內(nèi)部大型的復(fù)雜系統(tǒng)的開發(fā)，而不適合用于合同項(xiàng)目的開發(fā)。如果要將螺旋模型作為合同項(xiàng)目的開發(fā)模型，則必須在簽訂合同之前考慮清楚所有的開發(fā)風(fēng)險，否則，在開發(fā)過程中如果由于風(fēng)險過大而中途停止開發(fā)，就會賠償經(jīng)濟(jì)損

22、失或者承擔(dān)法律責(zé)任。 2021年11月7日星期日第36頁3.2.4 增量模型v采用瀑布模型或演化模型開發(fā)項(xiàng)目時，目標(biāo)都是一次性就把一個滿足所有需求的產(chǎn)品提交給用戶。然而，增量模型則與之不同，它分批地逐步向用戶提交可操作的產(chǎn)品。 2021年11月7日星期日第37頁3.2.4 增量模型v增量模型融合了瀑布模型的基本成分和快速原型模型的迭代特征。該模型采用隨著日程的進(jìn)展而交錯進(jìn)行的線性序列，每一個線性序列產(chǎn)生軟件的一個可發(fā)布的“增量”。v當(dāng)使用增量模型時，第1個增量往往是核心產(chǎn)品，即第1個增量實(shí)現(xiàn)了基本的需求，但很多補(bǔ)充的特征還沒有發(fā)布。客戶對每一個增量的使用和評估都作為下一個增量發(fā)布的新特征和功能

23、，這個過程在每一個增量發(fā)布后不斷重復(fù)，直到產(chǎn)生了最終的完善產(chǎn)品。v增量模型強(qiáng)調(diào)每一個增量均發(fā)布一個可操作的產(chǎn)品。 2021年11月7日星期日第38頁3.2.4 增量模型 分析 設(shè)計 實(shí)現(xiàn) 測試 功能 時間 分析 設(shè)計 實(shí)現(xiàn) 測試 分析 設(shè)計 實(shí)現(xiàn) 測試 分析 設(shè)計 實(shí)現(xiàn) 測試 增量 1 增量 2 增量 3 增量 4 . 發(fā)布可操作的產(chǎn)品 2021年11月7日星期日第39頁3.2.4 增量模型v增量模型的優(yōu)點(diǎn)：增量模型的優(yōu)點(diǎn)：(1) 人員分配靈活，剛開始不用投入大量人力資源，可以避免不必要的浪費(fèi)。(2) 重要功能被首先交付，可以獲得最多的測試，保證軟件產(chǎn)品的質(zhì)量。(3) 早期發(fā)布的可操作產(chǎn)品可以

24、作為原型為后期增量開發(fā)提供需求。(4) 在較短時間內(nèi)向用戶提交部分工作的產(chǎn)品，可以讓用戶對開發(fā)項(xiàng)目和開發(fā)團(tuán)隊有信心。(5) 用戶能看到所開發(fā)軟件的中間版本，可以使最終產(chǎn)品不至于偏離用戶的需求。(6) 可以將技術(shù)難度大的部分作為早期的增量，能夠有效地管理與控制技術(shù)風(fēng)險。 2021年11月7日星期日第40頁3.2.4 增量模型v增量模型的缺點(diǎn)：增量模型的缺點(diǎn)：(1) 在開發(fā)過程中，需求的變化是不可避免的。如果不能有效地控制并管理好需求的變更，增量模型很容易退化為邊寫邊改模式，從而使軟件過程的控制失去整體性。(2) 由于各個增量逐漸并入已有的結(jié)構(gòu)，所以加入的增量部分不能破壞已構(gòu)造好的系統(tǒng)部分，這需要

25、軟件具備開放式的體系結(jié)構(gòu)，對開發(fā)團(tuán)隊的技術(shù)要求更高。(3) 難以對所有增量進(jìn)行有效的集成。 2021年11月7日星期日第41頁3.2.4 增量模型v增量模型與原型模型、演化模型一樣，本質(zhì)上是迭代的，都能應(yīng)用在需求不明確、需求變化大的軟件項(xiàng)目的開發(fā)中，但與其它迭代式的模型不一樣的是，增量模型強(qiáng)調(diào)每一個增量均發(fā)布一個可操作產(chǎn)品。早期的增量是最終產(chǎn)品的“可拆卸”版本。用戶可對每一個可操作產(chǎn)品進(jìn)行評估，能很好地滿足用戶需求，大大提高了項(xiàng)目的成功率。 2021年11月7日星期日第42頁3.3 傳統(tǒng)軟件開發(fā)方法v在傳統(tǒng)的軟件開發(fā)過程中，最重要的是明確和分解系統(tǒng)功能。這種方法看起來很符合人們處理事務(wù)的流程，

26、是實(shí)現(xiàn)預(yù)期目標(biāo)的最直接的途徑。然而，一旦系統(tǒng)的需求發(fā)生變化，這種基于功能分解的系統(tǒng)將會需要大量的修改工作。隨著計算機(jī)技術(shù)、網(wǎng)絡(luò)技術(shù)的不斷發(fā)展，計算機(jī)應(yīng)用范圍不斷擴(kuò)大，軟件系統(tǒng)的規(guī)模也變得越來越龐大?；趥鹘y(tǒng)生命周期的結(jié)構(gòu)化軟件開發(fā)方法逐漸暴露出了它自身的一些缺點(diǎn)：難以理解和維護(hù)、可重用性差等。v這些缺點(diǎn)是由什么原因引起的？ 2021年11月7日星期日第43頁3.3 傳統(tǒng)軟件開發(fā)方法v在結(jié)構(gòu)化軟件開發(fā)（傳統(tǒng)的面向過程的軟件開發(fā)方法）的整個過程中，重點(diǎn)放在了操作上。這些操作是通過函數(shù)、模塊或一條簡單的指令來執(zhí)行的。在整個開發(fā)過程中，過程化程序設(shè)計方法完全將程序中的一個非常重要的方面數(shù)據(jù)，與操作分離

27、開來，使得數(shù)據(jù)可以被所有函數(shù)或過程完全訪問。 函數(shù) 函數(shù) 函數(shù) 數(shù)據(jù) 數(shù)據(jù) 2021年11月7日星期日第44頁3.3 傳統(tǒng)軟件開發(fā)方法v傳統(tǒng)軟件開發(fā)方法遵循軟件生命周期，整個開發(fā)過程包括可行性研究、需求分析、總體設(shè)計、詳細(xì)設(shè)計、編碼、測試和維護(hù)等六個階段。 2021年11月7日星期日第45頁3.3 傳統(tǒng)軟件開發(fā)方法v結(jié)構(gòu)化方法是傳統(tǒng)軟件開發(fā)方法的一個很好的例子，包括結(jié)構(gòu)化分析、結(jié)構(gòu)化設(shè)計、結(jié)構(gòu)化編程和結(jié)構(gòu)化測試等。2021年11月7日星期日第46頁3.3 傳統(tǒng)軟件開發(fā)方法v結(jié)構(gòu)化分析的工具是數(shù)據(jù)流圖和數(shù)據(jù)字典，用來表達(dá)和理解問題的數(shù)據(jù)域和功能域。數(shù)據(jù)域包括數(shù)據(jù)流、數(shù)據(jù)內(nèi)容和數(shù)據(jù)結(jié)構(gòu)，而功能域則

28、反映這三個方面的控制信息。通常將一個復(fù)雜問題按功能進(jìn)行分解并逐層細(xì)化。 2021年11月7日星期日第47頁3.3 傳統(tǒng)軟件開發(fā)方法v結(jié)構(gòu)化設(shè)計的基本思想是模塊化思想。將數(shù)據(jù)流圖進(jìn)一步細(xì)化到每一個子功能都清晰易懂，每個模塊完成一個子功能，每層模塊合成一個高一級的功能?？傮w設(shè)計階段包括數(shù)據(jù)庫結(jié)構(gòu)設(shè)計、用戶界面設(shè)計、功能模塊結(jié)構(gòu)設(shè)計等。詳細(xì)設(shè)計是根據(jù)每個模塊的功能設(shè)計實(shí)現(xiàn)算法以及實(shí)現(xiàn)這些算法的邏輯控制流程。詳細(xì)設(shè)計的表示工具有程序流程圖、pad圖、n-s圖、判定表和判定樹、偽碼和pdl等。2021年11月7日星期日第48頁3.3 傳統(tǒng)軟件開發(fā)方法v編程是指把軟件設(shè)計的結(jié)果轉(zhuǎn)換為用某種程序設(shè)計語言所表

29、示的程序代碼。結(jié)構(gòu)化的程序設(shè)計語言，例如，fortran、pascal、c等，是通過把程序劃分成函數(shù)和功能模塊來控制整個程序的執(zhí)行流程的。2021年11月7日星期日第49頁3.3 傳統(tǒng)軟件開發(fā)方法v傳統(tǒng)軟件開發(fā)方法有以下四個特點(diǎn)：(1) 以模塊作為基本的構(gòu)造單元。使得編程與現(xiàn)實(shí)世界之間存在理解鴻溝。(2) 自頂向下逐步細(xì)分功能。系統(tǒng)重用性很差。(3) 不同模塊之間的信息傳遞通過函數(shù)的調(diào)用來完成。其控制信息傳遞效率極其低下。(4) 堅持嚴(yán)格的階段性評審。雖然能夠保證軟件質(zhì)量，但整個開發(fā)過程缺少應(yīng)有的靈活性。 2021年11月7日星期日第50頁3.3 傳統(tǒng)軟件開發(fā)方法v當(dāng)函數(shù)與被函數(shù)調(diào)用的數(shù)據(jù)分離

30、時，數(shù)據(jù)被破壞的可能性極大。另外，當(dāng)數(shù)據(jù)和函數(shù)相互獨(dú)立時，總存在著用錯誤的數(shù)據(jù)調(diào)用正確的程序模塊或用正確的數(shù)據(jù)調(diào)用了錯誤的程序模塊的可能性。v所以，需要有一種方法來約束所有函數(shù)對數(shù)據(jù)的訪問，即將這些數(shù)據(jù)有效地隱藏起來，這就是面向?qū)ο蟮男畔㈦[藏思想。 2021年11月7日星期日第51頁3.3 傳統(tǒng)軟件開發(fā)方法v傳統(tǒng)的面向過程的結(jié)構(gòu)化開發(fā)方法的另一個問題是它不能很好地表示現(xiàn)實(shí)世界。這些現(xiàn)實(shí)世界中的事物可直接映射到面向?qū)ο蟮慕饪臻g，用面向?qū)ο蟮能浖_發(fā)方法能很好地解決現(xiàn)實(shí)世界的問題。 2021年11月7日星期日第52頁3.3 傳統(tǒng)軟件開發(fā)方法v為了提高系統(tǒng)的可理解性、可維護(hù)性和可重用性，并能很好地表

31、示現(xiàn)實(shí)世界，開發(fā)軟件項(xiàng)目時，最好采用面向?qū)ο筌浖_發(fā)技術(shù)。 2021年11月7日星期日第53頁3.4 面向?qū)ο筌浖_發(fā)技術(shù)v“對象”一詞在現(xiàn)實(shí)生活中經(jīng)常會遇到，它表示現(xiàn)實(shí)世界中的某個具體的事物，例如，一臺計算機(jī)。v現(xiàn)實(shí)世界中的事物包含了物質(zhì)和意識兩大部分，物質(zhì)表達(dá)的是具體的事物，而意識則描述了某一個抽象的概念，是對客觀存在的事物的一種概括。v對象的概念源于用計算機(jī)程序?qū)ΜF(xiàn)實(shí)世界的復(fù)雜事物進(jìn)行建模的過程。2021年11月7日星期日第54頁3.4.1 面向?qū)ο蟮幕靖拍顅概念概念3-1：對象對象對象是指現(xiàn)實(shí)世界中各種各樣的實(shí)體。它既可以是具體的能觸及的事物，如一個人、一棟大樓、一架飛機(jī)，甚至一個地

32、球等；也可以是無法觸及的抽象事物，如一項(xiàng)計劃、一次約會、一場演出等。一個對象既可以非常簡單，又可以非常復(fù)雜，復(fù)雜的對象往往可以由若干個簡單的對象組合而成。 2021年11月7日星期日第55頁3.4.1 面向?qū)ο蟮幕靖拍顅對象定義了狀態(tài)和行為。對象的狀態(tài)用數(shù)據(jù)值來表示，而對象的行為則用來改變對象的狀態(tài)。在面向?qū)ο蟮南到y(tǒng)中，對象是基本的運(yùn)行實(shí)體。2021年11月7日星期日第56頁3.4.1 面向?qū)ο蟮幕靖拍顅所有這些對象，除去它們都是現(xiàn)實(shí)世界中所存在的事物之外，它們都還具有各自不同的特征：(1) 有一個名字用來區(qū)別于其它對象。例如：張三、李四等。 2021年11月7日星期日第57頁3.4.1

33、面向?qū)ο蟮幕靖拍?2) 有一個狀態(tài)用來描述對象的某些特征。例如：v對象張三的狀態(tài)：姓名：張三性別：男身高：179cm體重：71kg 2021年11月7日星期日第58頁3.4.1 面向?qū)ο蟮幕靖拍?3) 有一組操作，每一個操作決定對象的一種功能或行為。對象的操作可分為兩類：一類是自身所承受的操作，使用setter、getter作為操作名；一類是施加于其它對象的操作。例如：v對象張三的操作（可完成的功能）：回答姓名回答性別回答身高回答體重打電話踢足球駕車 屬于對象自身所承受的操作 屬于施加于其它對象的操作 2021年11月7日星期日第59頁3.4.1 面向?qū)ο蟮幕靖拍顅概念概念3-2：類類類

34、是對一組客觀對象的抽象，它將該組對象所具有的共同特征（包括結(jié)構(gòu)特征和行為特征）集中起來，以說明該組對象的性質(zhì)和能力。例如：“人”這個詞就是抽象了所有人（單個的人，如張三、李四等，這些都是對象）的共同之處。 2021年11月7日星期日第60頁3.4.1 面向?qū)ο蟮幕靖拍顅在面向?qū)ο缶幊讨校ǔ０杨惗x為抽象數(shù)據(jù)類型，而對在面向?qū)ο缶幊讨校ǔ０杨惗x為抽象數(shù)據(jù)類型，而對象是類的類型變量。當(dāng)定義了一個類以后，就可以生成任象是類的類型變量。當(dāng)定義了一個類以后，就可以生成任意多個屬于這個類的對象，這個過程叫做實(shí)例化。例如，意多個屬于這個類的對象，這個過程叫做實(shí)例化。例如，用用java語言定義一個類語

35、言定義一個類car為：為：public class car v這時可生成任意多個屬于這時可生成任意多個屬于car類的對象：類的對象：car car1 = new car();car car2 = new car(); 2021年11月7日星期日第61頁3.4.1 面向?qū)ο蟮幕靖拍顅概念概念3-3：類與對象的關(guān)系：類與對象的關(guān)系組成類的對象均為該類的實(shí)例。類與對象之間的關(guān)系就是抽象與具體的關(guān)系。例如，張三是一個學(xué)生，學(xué)生是一個類，而張三作為一個具體的對象，是學(xué)生類的一個實(shí)例。類是多個實(shí)例的綜合抽象，而實(shí)例又是類的個體事物。 2021年11月7日星期日第62頁3.4.1 面向?qū)ο蟮幕靖拍顅在面

36、向?qū)ο缶幊讨?，定義一個類就定義了這個類的一系列屬性與操作，對于同一個類的不同實(shí)例之間，必定具有如下特點(diǎn)：(1) 相同的屬性集合；(2) 相同的操作集合；(3) 不同的對象名。 2021年11月7日星期日第63頁3.4.1 面向?qū)ο蟮幕靖拍顅相同的屬性集合與操作集合用于標(biāo)識這些對象屬于同一個類，用不同的對象名來區(qū)別不同的對象。2021年11月7日星期日第64頁3.4.1 面向?qū)ο蟮幕靖拍顅概念概念3-4：面向?qū)ο螅好嫦驅(qū)ο竺嫦驅(qū)ο螅╫bject-oriented，簡稱oo）是指人們按照自然的思維方式認(rèn)識客觀世界，采用基于對象（實(shí)體）的概念建立模型，模擬客觀世界，從而用來分析、設(shè)計和實(shí)現(xiàn)軟件的

37、方法。把軟件組織成一系列離散的、合并了數(shù)據(jù)結(jié)構(gòu)和行為的對象集。 2021年11月7日星期日第65頁3.4.1 面向?qū)ο蟮幕靖拍顅面向?qū)ο笫钱?dāng)前計算機(jī)界關(guān)注的重點(diǎn)，它是90年代主流軟件開發(fā)方法。通過面向?qū)ο蟮睦砟钍褂嬎銠C(jī)軟件系統(tǒng)能與現(xiàn)實(shí)世界中的系統(tǒng)一一對應(yīng)。面向?qū)ο蟮母拍詈蛻?yīng)用已超越了程序設(shè)計和軟件開發(fā)，擴(kuò)展到很寬的范圍。如數(shù)據(jù)庫系統(tǒng)、分布式系統(tǒng)、人工智能等領(lǐng)域。 2021年11月7日星期日第66頁3.4.1 面向?qū)ο蟮幕靖拍顅采用面向?qū)ο蠹夹g(shù)開發(fā)軟件的方法，稱為面向?qū)ο筌浖_發(fā)方法。面向?qū)ο蠓椒ň哂幸韵聨讉€特性：(1) 對象唯一性v每個對象都有唯一的標(biāo)識（如同人們的身份證號碼），通過這個標(biāo)

38、識，可以找到相應(yīng)的對象。在對象的整個生命周期（從對象的創(chuàng)建到對象的消亡）中，它的標(biāo)識都不會改變。不同的對象（即使其它屬性完全相同，例如兩個完全一樣的球）必須具有不同的標(biāo)識。(2) 封裝性v具有一致的數(shù)據(jù)結(jié)構(gòu)（屬性）和行為（操作）的對象抽象成類。(3) 繼承性v子類自動共享父類的數(shù)據(jù)結(jié)構(gòu)和行為的機(jī)制，這是類之間的一種關(guān)系。繼承性是面向?qū)ο蟪绦蛟O(shè)計語言不同于其它程序設(shè)計語言最重要的特點(diǎn)，是其它語言所沒有的。(4) 多態(tài)性v它是面向?qū)ο笙到y(tǒng)中的又一個重要特性。多態(tài)性描述的是同一個消息可以根據(jù)發(fā)送消息對象的不同采用多種不同的行為方式。即是指相同的操作或函數(shù)可作用于多種類型的對象上并獲得不同的結(jié)果。不同

39、的對象，收到同一消息可以產(chǎn)生不同的結(jié)果，這種現(xiàn)象就稱為多態(tài)性。 2021年11月7日星期日第67頁3.4.1 面向?qū)ο蟮幕靖拍顅概念概念3-5：封裝及面向?qū)ο笙到y(tǒng)的封裝性：封裝及面向?qū)ο笙到y(tǒng)的封裝性封裝也叫做信息隱藏。從字面上理解，封裝就是將某事物包裝起來，使外界不了解其實(shí)際內(nèi)容。從軟件開發(fā)的角度，封裝是指將一個數(shù)據(jù)和與這個數(shù)據(jù)有關(guān)的各種操作放在一起，形成一個能動的實(shí)體對象，使用者不必知道對象的內(nèi)部結(jié)構(gòu)，只需根據(jù)對象提供的外部接口訪問對象。從使用者的角度看，這些對象就像一個“黑盒子”，其內(nèi)部數(shù)據(jù)和行為是被隱藏起來、看不見的。面向?qū)ο笙到y(tǒng)的封裝性是一種信息隱藏技術(shù)，它隱藏了某一方法的具體執(zhí)行步

40、驟，取而代之的是通過消息傳遞機(jī)制傳遞消息給它。 2021年11月7日星期日第68頁3.4.1 面向?qū)ο蟮幕靖拍顅封裝的意義在于保護(hù)或者防止數(shù)據(jù)或者程序代碼被我們無意中破壞，以提高系統(tǒng)的安全性。既然封裝了對象，那么，怎樣才能訪問對象呢？答案是通過對象提供的公共消息接口來訪問對象。下面是一個用java語言所定義的類： 2021年11月7日星期日第69頁3.4.1 面向?qū)ο蟮幕靖拍頿ublic class employee private string name; private int age; private float salary; private string rank; privat

41、e void calculatesalary(float subtract) salary = salary subtract; protected int getage() return age; public void setsalary(float salary) this.salary = salary; public float getsalary() return salary; 2021年11月7日星期日第70頁3.4.1 面向?qū)ο蟮幕靖拍顅在上面所定義的職員（employee）類中，包含的數(shù)據(jù)有職員姓名（name）、年齡（age）、工資（salary）、職位（rank）。這些

42、數(shù)據(jù)被定義為私有數(shù)據(jù)（用private定義），就被隱藏起來，對于外部對象來說就不可以直接訪問了。它所包含的成員方法或成員函數(shù)（操作）有三種類型的可見性： 2021年11月7日星期日第71頁3.4.1 面向?qū)ο蟮幕靖拍顅(1) 私有的用private關(guān)鍵字標(biāo)識，如：calculatesalary，這樣的成員方法或函數(shù)不向外部公開，只供對象內(nèi)部自己使用。v(2) 受保護(hù)的用protected關(guān)鍵字標(biāo)識，如：getage，這樣的成員方法或函數(shù)只向部分外界公開，只對派生類對象提供服務(wù)。v(3) 公有的用public關(guān)鍵字標(biāo)識，如：getsalary等，這樣的成員方法或函數(shù)向所有的外界公開，它可以響應(yīng)

43、外界對象的請求。 2021年11月7日星期日第72頁3.4.1 面向?qū)ο蟮幕靖拍顅定義為公有的成員方法或函數(shù)，才是對象提供的公共消息接口。外部對象只有通過這些公共接口才能訪問到對象的內(nèi)部數(shù)據(jù)，這就是所謂的信息隱藏技術(shù)。 2021年11月7日星期日第73頁3.4.1 面向?qū)ο蟮幕靖拍顅根據(jù)對封裝的定義可以看出，封裝應(yīng)該具有下面幾個條件：(1) 具有一個清晰的邊界。對象所有的私有數(shù)據(jù)、成員方法或函數(shù)的實(shí)現(xiàn)細(xì)節(jié)都被固定在這個邊界內(nèi)。(2) 具有一個接口。這個接口描述了對象之間的交互作用，它就是消息。(3) 對象內(nèi)部的實(shí)現(xiàn)代碼受到封裝體的保護(hù)，其它對象不能直接修改本對象所擁有的數(shù)據(jù)和代碼。 202

44、1年11月7日星期日第74頁3.4.1 面向?qū)ο蟮幕靖拍顅面向?qū)ο笙到y(tǒng)中的封裝以對象為單位，即主要是指對象的封裝，該對象的特性是由它所屬的類說明來描述，也就是說在類的定義中實(shí)現(xiàn)封裝。被封裝的對象通常被稱為抽象數(shù)據(jù)類型。封裝性提高了對象內(nèi)部數(shù)據(jù)的安全性。 2021年11月7日星期日第75頁3.4.1 面向?qū)ο蟮幕靖拍顅概念概念3-6：繼承及面向?qū)ο笙到y(tǒng)的繼承性：繼承及面向?qū)ο笙到y(tǒng)的繼承性繼承是指一個類能夠從另一個類那里獲得一些特性。在這個過程中，超類把它的特性賦給了子類。面向?qū)ο笙到y(tǒng)的繼承性是對具有層次關(guān)系的類的屬性和操作進(jìn)行共享的一種方式。在面向?qū)ο笙到y(tǒng)中，若沒有引入繼承的概念，所有的類就

45、會變成一盤各自為政、彼此獨(dú)立的散沙，軟件重用級別較低，每次軟件開發(fā)就只能從“零”開始。 2021年11月7日星期日第76頁3.4.1 面向?qū)ο蟮幕靖拍顅繼承是面向?qū)ο筌浖夹g(shù)中的一個概念。如果一個類a繼承自另一個類b，就把這個a稱為b的“子類”或“派生類”，而把b稱為a的“父類”或“超類”或“基類”。例如，在通常的信息管理應(yīng)用系統(tǒng)中，都會涉及到用戶權(quán)限管理，常常會有“一般用戶”和“系統(tǒng)管理員”兩種角色，而“一般用戶”和“系統(tǒng)管理員”都是“用戶”，所以，“一般用戶”類和“系統(tǒng)管理員”類都可以繼承自“用戶”類。在這里，“一般用戶”類和“系統(tǒng)管理員”類都是“用戶”類的子類，而“用戶”類則是“一般用

46、戶”類和“系統(tǒng)管理員”類的父類。 2021年11月7日星期日第77頁3.4.1 面向?qū)ο蟮幕靖拍顅繼承可以使得子類具有父類的各種屬性和方法，而不需要再次編寫相同的代碼。在子類繼承父類時，既可以重新定義子類的某些屬性和方法，也可以重寫某些方法，來覆蓋父類的原有屬性和方法，使其獲得與父類不同的功能。2021年11月7日星期日第78頁3.4.1 面向?qū)ο蟮幕靖拍顅繼承有兩個方面的作用：避免代碼冗余，提高可理解性和可維護(hù)性；繼承是從老對象生成新對象的一種代碼重用機(jī)制，使系統(tǒng)更具靈活性和適應(yīng)性，它使得解釋多態(tài)性成為可能。2021年11月7日星期日第79頁3.4.1 面向?qū)ο蟮幕靖拍顅繼承有單繼承和

47、多繼承之分。 圖形 三角形 矩形 橢圓形 圓形 正方形 長方形 對話框 列表框 文本框 組合框 復(fù)選框 各種按鈕 單繼承多繼承2021年11月7日星期日第80頁3.4.1 面向?qū)ο蟮幕靖拍顅多重繼承的引入，使面向?qū)ο笙到y(tǒng)大大增加了模擬現(xiàn)實(shí)世界的能力，但是系統(tǒng)結(jié)構(gòu)變得非常復(fù)雜，增加了系統(tǒng)的理解與維護(hù)難度。v在面向?qū)ο蟪绦蛟O(shè)計語言中，c+支持多繼承，而java語言只支持單繼承，不支持多繼承。 2021年11月7日星期日第81頁3.4.1 面向?qū)ο蟮幕靖拍顅在面向?qū)ο箝_發(fā)中，繼承性不僅作用在對操作的繼承，還作用在對數(shù)據(jù)的繼承，也就是說，既具有結(jié)構(gòu)特性的繼承性，又具有行為特性的繼承性。v子類是否可

48、以訪問父類的所有成員變量和成員方法（或成員函數(shù)）？在前面介紹封裝性時談到，定義類的數(shù)據(jù)成員與方法成員有三種訪問域（三種可見性），即公有訪問域（public）、受保護(hù)訪問域（protected）、私有訪問域（private）。父類的成員若定義為受保護(hù)訪問域和公有訪問域，子類是可以訪問的；若父類成員定義為私有訪問域，子類則無權(quán)訪問。2021年11月7日星期日第82頁3.4.1 面向?qū)ο蟮幕靖拍顅概念概念3-7：重載及面向?qū)ο笙到y(tǒng)的多態(tài)性：重載及面向?qū)ο笙到y(tǒng)的多態(tài)性一個類中的操作具有相同的名稱和不同的參數(shù)，這樣的操作被稱為“重載”。面向?qū)ο笙到y(tǒng)的多態(tài)性是指，當(dāng)不同的對象收到相同的消息時產(chǎn)生不同的動

49、作。常用在功能相同但參數(shù)的數(shù)據(jù)類型有微小差別的操作中。 2021年11月7日星期日第83頁3.4.1 面向?qū)ο蟮幕靖拍顅操作名、參數(shù)及其類型和操作的返回類型合在一起稱為操作的簽名（注：這里的操作就是方法或函數(shù)）。一個類中的所有操作都必須具有唯一的簽名，即是說一個類中不能存在兩個相同簽名的操作。v具有相同名稱和參數(shù)但是返回類型不同的操作不能稱為重載，因?yàn)樵谡{(diào)用操作時并沒有描述操作的返回類型，被調(diào)用的對象不能分辨出僅僅是返回類型不同的兩個操作，因此這樣的操作具有歧義性，是無效的。2021年11月7日星期日第84頁3.4.2 面向?qū)ο蟮拈_發(fā)v傳統(tǒng)的軟件開發(fā)生命周期包含了六個階段：制定計劃、需求分析

50、和定義、設(shè)計、編碼、測試、運(yùn)行與維護(hù)，面向?qū)ο蟮拈_發(fā)和傳統(tǒng)的軟件開發(fā)方法不同，它是一種基于現(xiàn)實(shí)世界抽象的新的軟件開發(fā)方法。v那么，面向?qū)ο蟮能浖_發(fā)中，軟件生命周期又可分為哪幾個階段？各個階段主要完成哪些任務(wù)？2021年11月7日星期日第85頁3.4.2 面向?qū)ο蟮拈_發(fā)v在面向?qū)ο蟮能浖_發(fā)中，軟件生命周期可分為以下幾個階段：v(1) 系統(tǒng)分析階段在這個階段，需要建立一個反映現(xiàn)實(shí)客觀世界情形的模型。為了建立這個模型，需要分析員和需求人員共同明確現(xiàn)實(shí)世界中的問題。這個模型應(yīng)該解決系統(tǒng)必須做什么，而不是怎么做的問題。分析之后將得到分析模型：對象模型、動態(tài)模型和功能模型。v(2) 系統(tǒng)設(shè)計階段這個階

51、段需要給出怎樣解決問題的決策。包括將系統(tǒng)劃分成子系統(tǒng)和子系統(tǒng)軟硬件如何配置，確定系統(tǒng)的整體框架結(jié)構(gòu)。 2021年11月7日星期日第86頁3.4.2 面向?qū)ο蟮拈_發(fā)v(3) 對象設(shè)計階段該階段將應(yīng)用領(lǐng)域的概念轉(zhuǎn)換為計算機(jī)軟件領(lǐng)域的概念。在系統(tǒng)分析階段所定義的問題，在這個階段來確定解決問題的方法。將分析模型的邏輯結(jié)構(gòu)映射到一個程序的物理組織，得到設(shè)計模型。v(4) 實(shí)現(xiàn)階段在這個階段，將在對象設(shè)計階段開發(fā)的類轉(zhuǎn)換成用特定的程序設(shè)計語言編寫的代碼或數(shù)據(jù)庫。v(5) 測試階段傳統(tǒng)軟件開發(fā)的測試通常經(jīng)過單元測試、集成測試、系統(tǒng)測試三個環(huán)節(jié)。由于面向?qū)ο笥衅渥陨淼奶攸c(diǎn)，參考面向?qū)ο筌浖_發(fā)模式，面向?qū)ο箝_

52、發(fā)測試包括面向?qū)ο蠓治龅臏y試、面向?qū)ο笤O(shè)計的測試、面向?qū)ο缶幊痰臏y試、面向?qū)ο髥卧獪y試、面向?qū)ο蠹蓽y試和面向?qū)ο笙到y(tǒng)測試。 2021年11月7日星期日第87頁3.4.2 面向?qū)ο蟮拈_發(fā)v面向?qū)ο箝_發(fā)同樣包含了傳統(tǒng)軟件開發(fā)的幾個階段：分析、設(shè)計、編碼、測試等，但面向?qū)ο箝_發(fā)是用“面向?qū)ο蟆钡挠^點(diǎn)去認(rèn)識客觀世界，用“面向?qū)ο蟆钡姆椒ㄈツM客觀世界，所以，在分析階段主要分析現(xiàn)實(shí)世界中的對象以及對象與對象之間的關(guān)系，在設(shè)計階段除了對整個系統(tǒng)的架構(gòu)設(shè)計外，主要針對對象（或類）以及對象（或類）與對象（或類）之間的關(guān)系進(jìn)行設(shè)計，在編碼階段使用面向?qū)ο缶幊陶Z言實(shí)現(xiàn)類的各項(xiàng)功能，而在測試階段則使用面向?qū)ο蟮臏y

53、試方法與技術(shù)。 2021年11月7日星期日第88頁3.4.2 面向?qū)ο蟮拈_發(fā)v人們對客觀世界的認(rèn)識是一個從簡單到復(fù)雜、從知之不多到知之甚多的反復(fù)的認(rèn)識過程，因此，面向?qū)ο蟮能浖_發(fā)也將是一個反復(fù)的迭代過程，但這種反復(fù)不是簡單的重復(fù)，而是在前一個迭代周期基礎(chǔ)上對于問題領(lǐng)域的認(rèn)識有所提高。 2021年11月7日星期日第89頁3.4.2 面向?qū)ο蟮拈_發(fā)v面向?qū)ο箝_發(fā)生命周期是一個迭代的增量式過程，因此，使用面向?qū)ο筌浖_發(fā)技術(shù)能很好地適應(yīng)系統(tǒng)需求的變化，并能提高軟件的可理解性、可維護(hù)性和可重用性，以致于提高軟件企業(yè)的可持續(xù)發(fā)展性。 2021年11月7日星期日第90頁3.4.2 面向?qū)ο蟮拈_發(fā)v面向?qū)?/p>

54、象的分析與設(shè)計過程適合于使用uml來建模，同時，使用uml建模工具可以將模型（對于嵌入式系統(tǒng)，通常指狀態(tài)圖；而對于一般系統(tǒng)，則是指類圖）映射為特定編程語言的程序代碼，也可以將永久類映射為關(guān)系數(shù)據(jù)庫結(jié)構(gòu)，還能將分析模型中得到的邊界類的屬性與操作部分映射為用戶界面中的圖形元素。v面向?qū)ο箝_發(fā)特別適合采用下一節(jié)將要介紹的rup統(tǒng)一軟件開發(fā)過程。 2021年11月7日星期日第91頁3.5 rup統(tǒng)一軟件開發(fā)過程vrup（rational unified process，統(tǒng)一軟件開發(fā)過程），是由ibm rational公司提出來的。它是一個通用的過程框架，適用面非常廣，可以適用于不同種類的軟件系統(tǒng)、應(yīng)用

55、領(lǐng)域、組織類型、性能水平和項(xiàng)目規(guī)模。它是一個演化的開發(fā)過程。 2021年11月7日星期日第92頁3.5 rup統(tǒng)一軟件開發(fā)過程vrup是基于構(gòu)件的開發(fā)過程，在開發(fā)過程中非常重視構(gòu)件的應(yīng)用。這意味著利用它開發(fā)的軟件系統(tǒng)是由構(gòu)件組成的，構(gòu)件之間通過定義良好的接口相互聯(lián)系。與其它軟件過程相比，rup具有三個顯著的特點(diǎn)：2021年11月7日星期日第93頁3.5 rup統(tǒng)一軟件開發(fā)過程v(1) 它是用例驅(qū)動的過程。根據(jù)需求分析的用例來構(gòu)建需要的系統(tǒng)行為。用例定義了系統(tǒng)功能的使用環(huán)境和上下文，每個用例描述的是一個完整的系統(tǒng)服務(wù)。 2021年11月7日星期日第94頁3.5 rup統(tǒng)一軟件開發(fā)過程v(2) 它

56、是迭代和增量式的過程。每次迭代都產(chǎn)生一個可執(zhí)行的版本。每次迭代時，都選用一組還沒有實(shí)現(xiàn)的用例來作為增量進(jìn)行開發(fā)，優(yōu)先識別并著手實(shí)現(xiàn)風(fēng)險較大的用例，例如，集中所有的技術(shù)力量優(yōu)先解決技術(shù)難度最大的用例。 2021年11月7日星期日第95頁3.5 rup統(tǒng)一軟件開發(fā)過程v(3) 它是以基本架構(gòu)為中心的過程。在開發(fā)之前，首先根據(jù)平臺而不考慮用例來設(shè)計系統(tǒng)架構(gòu)，然后，選用其中幾個成熟的用例來修改或擴(kuò)展先前的架構(gòu)，用系統(tǒng)架構(gòu)來概念化、建立管理和發(fā)展開發(fā)之中的系統(tǒng)。 2021年11月7日星期日第96頁3.5.1rup生命周期vrup是一種軟件開發(fā)過程，包括開發(fā)過程、管理過程和支撐過程，它的生命周期是怎樣的呢

57、？ 2021年11月7日星期日第97頁3.5.1rup生命周期v與傳統(tǒng)的一維瀑布開發(fā)模型不同，rup軟件開發(fā)生命周期是一個二維的開發(fā)模型。橫軸表示軟件過程的時間維，是過程展開的生命周期特征，體現(xiàn)開發(fā)過程的動態(tài)結(jié)構(gòu)，被分成四個順序階段，分別是：先啟階段（inception），精化階段（elaboration），構(gòu)造階段（construction），移交階段（transition）。每個階段以一個主要里程碑結(jié)束。每個階段結(jié)束時都要安排一次技術(shù)評審，以確定是否符合該階段的目標(biāo)。如果評審令人滿意，則允許項(xiàng)目進(jìn)入下一個階段?？v軸表示內(nèi)容維，體現(xiàn)開發(fā)過程的靜態(tài)結(jié)構(gòu)，描述按性質(zhì)將活動邏輯地進(jìn)行分組的工作流程

58、。 2021年11月7日星期日第98頁3.5.1rup生命周期 先啟 精化 構(gòu)造 移交 階階 段段 環(huán)境 項(xiàng)目管理 配置和變更管理 部署 測試 實(shí)施 分析與設(shè)計 需求 業(yè)務(wù)建模 工作流程工作流程 初始 e1 c1 t1 t2 c2 cn e2 迭迭 代代 2021年11月7日星期日第99頁3.5.1rup生命周期v(1) 先啟階段這是開發(fā)生命周期的第一階段。其主要目標(biāo)是實(shí)現(xiàn)所有項(xiàng)目相關(guān)人員在項(xiàng)目的生命周期目標(biāo)上達(dá)成一致，把開發(fā)的主要思想確定為現(xiàn)實(shí)的目標(biāo)。其任務(wù)是為系統(tǒng)建立業(yè)務(wù)模型并確定項(xiàng)目的軟件范圍和邊界條件，識別出系統(tǒng)的關(guān)鍵用例，確定至少一個體系結(jié)構(gòu)方案，評估整個項(xiàng)目的整體成本和進(jìn)度安排、評

59、估潛在風(fēng)險，準(zhǔn)備項(xiàng)目的支持環(huán)境。這個階段所關(guān)注的是整個項(xiàng)目的業(yè)務(wù)和需求方面的主要風(fēng)險。主要包括以下幾個基本活動： 2021年11月7日星期日第100頁3.5.1rup生命周期v 明確項(xiàng)目規(guī)模建立項(xiàng)目的軟件規(guī)模和邊界條件，包括驗(yàn)收標(biāo)準(zhǔn)，了解環(huán)境及重要的需求和約束，識別系統(tǒng)的關(guān)鍵用例。v 評估項(xiàng)目風(fēng)險針對軟件開發(fā)涉及到的風(fēng)險，包括在軟件開發(fā)中可能出現(xiàn)的風(fēng)險和軟件實(shí)施過程中外部環(huán)境的變化可能引起的風(fēng)險等進(jìn)行評估。v 制定項(xiàng)目計劃綜合考慮備選構(gòu)架，評估設(shè)計和自制或外購或重用方面的方案，從而估算出項(xiàng)目成本、進(jìn)度和資源等。v 準(zhǔn)備項(xiàng)目環(huán)境評估項(xiàng)目和組織，選擇開發(fā)工具，確定要改進(jìn)哪些流程部分。v 階段技術(shù)評

60、審在評審過程中，需要考慮項(xiàng)目的規(guī)模定義，成本和進(jìn)度估算是否適中，估算根據(jù)是否可靠，需求是否正確，開發(fā)方和用戶方對軟件需求的理解是否達(dá)成一致，是否已確定所有風(fēng)險，并且針對每個風(fēng)險有相應(yīng)的風(fēng)險回避措施等問題。 2021年11月7日星期日第101頁3.5.1rup生命周期v初始階段結(jié)束時是第一個重要的里程碑：生命周期目標(biāo)（lifecycle objective）里程碑。用來評價項(xiàng)目基本的生存能力，決定是繼續(xù)該項(xiàng)目還是取消它。2021年11月7日星期日第102頁3.5.1rup生命周期v(2) 精化階段這是開發(fā)過程的第二階段。該階段的目標(biāo)是建立系統(tǒng)架構(gòu)的基線，為構(gòu)造階段中的大量設(shè)計和實(shí)施工作提供穩(wěn)固基