中國海洋大學 考研復習軟工復習整理_第1頁
中國海洋大學 考研復習軟工復習整理_第2頁
中國海洋大學 考研復習軟工復習整理_第3頁
中國海洋大學 考研復習軟工復習整理_第4頁
中國海洋大學 考研復習軟工復習整理_第5頁
已閱讀5頁,還剩88頁未讀 繼續(xù)免費閱讀

下載本文檔

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

文檔簡介

1、 各階段的基本任務:各階段的基本任務: 1. 問題定義 必須回答的關(guān)鍵問題是:“要解決的問題是什么?” 2. 可行性研究 必須回答的關(guān)鍵問題是:“對于上一個階段所確定的問題有行得通的解決辦法嗎?” 3. 需求分析 準確的確定“為了解決這個問題,目標系統(tǒng)必須做什么”,主要是確定目標系統(tǒng)必須具備那些功能。 4. 總體設計 必須回答的關(guān)鍵問題是:“概括地說,應該如何解決這個問題?”。 有兩個任務: (1)考慮幾種可能的解決方案。 低成本解決方案;中等成本解決方案;高成本“十全十美”的系統(tǒng); (2)設計軟件結(jié)構(gòu),即確定程序由哪些模塊組成以及模塊間的關(guān)系。 5.詳細設計 關(guān)鍵問題是:“應該怎樣具體地實現(xiàn)

2、這個系統(tǒng)?” 6.編碼和單元測試 關(guān)鍵任務是寫出正確的容易理解、容易維護的程序模塊。 7.綜合測試 關(guān)鍵任務是通過各種類型的測試(及相應的調(diào)試)使軟件達到預定的要求。 8.軟件維護 關(guān)鍵任務是,通過各種必要的維護活動使系統(tǒng)持久地滿足用戶的需要。 維護類型:改正性維護、適應性維護、完善性維護、預防性維護。 1.4.1 1.4.1 瀑布模型瀑布模型 把生命周期劃分為階段的目的及實質(zhì)是:控制開發(fā)工作的復雜性;通過有限的確定步驟,把用戶需求從抽象的邏輯概念逐步轉(zhuǎn)化為具體的物理實現(xiàn)。圖圖1.2 1.2 傳統(tǒng)的瀑布傳統(tǒng)的瀑布 模型模型問題定義問題定義總體設計總體設計需求分析需求分析可行性研究可行性研究詳細

3、設計詳細設計綜合測試綜合測試編碼與單元測試編碼與單元測試軟件維護軟件維護 按照傳統(tǒng)的瀑布模型開發(fā)軟件,有如下幾個特點:1.階段間具有順序性和依賴性 這個特點由兩重含義: (1)必須等前一階段的工作完成之后,才能開始后一階段的工作;(2)前一階段的輸出文檔就是后一階段的輸入文檔,因此只有前一階段的輸出文檔正確,后一階段的工作才能獲得正確的結(jié)果。2.推遲實現(xiàn)地觀點3.質(zhì)量保證的觀點 在瀑布模型的每個階段都應該堅持兩個重要做法: (1)每個階段都必須完成規(guī)定的文檔,沒有交出合格的文檔就是沒有完成該階段的任務。 (2)每個階段結(jié)束前都要對所完成的文檔進行評審,以便及早發(fā)現(xiàn)問題,改正錯誤。 圖圖1.3

4、1.3 實際的瀑布模型實際的瀑布模型需求分析需求分析驗證驗證規(guī)格說明規(guī)格說明驗證驗證設計設計驗證驗證編碼編碼測試測試綜合測試綜合測試維護維護變化的需求變化的需求驗證驗證1.4.2 1.4.2 快速原型模型快速原型模型 所謂快速原型是快速建立起來的可以在計算機上運行的程序,它所能完成的功能一般是最終產(chǎn)品能完成的功能的一個子集。如圖1.4所示。 快速原型快速原型驗證驗證規(guī)格說明規(guī)格說明驗證驗證設計設計驗證驗證編碼編碼測試測試綜合測試綜合測試維護維護變化的需求變化的需求驗證驗證圖圖1.4 1.4 快速原型模型快速原型模型注:實線箭頭表示開發(fā)過程注:實線箭頭表示開發(fā)過程 虛線箭頭表示維護過程虛線箭頭表

5、示維護過程 從圖1.4可以看出,快速原型模型是不帶反饋環(huán)的,這正是這種過程模型的主要優(yōu)點:軟件產(chǎn)品的開發(fā)基本上是線性順序進行的。 (1)原型系統(tǒng)已經(jīng)通過與用戶交互而得到驗證,據(jù)此產(chǎn)生的規(guī)格說明文檔正確地描述了用戶需求,因此,在開發(fā)過程的后續(xù)階段不會因為發(fā)現(xiàn)了規(guī)格說明文檔的錯誤而進行較大的返工。 (2)開發(fā)人員通過建立原型已經(jīng)掌握很多東西。因此,在設計和編碼階段發(fā)生錯誤的可能性也較小,這自然減少后續(xù)階段修改前面錯誤的可能性。1.4.3 1.4.3 增量模型增量模型 增量模型也稱為漸增模型,如圖1.5所示。圖圖1.5 1.5 增量模型增量模型需求分析需求分析驗證驗證規(guī)格說明規(guī)格說明驗證驗證概要設計

6、概要設計驗證驗證針對每個構(gòu)件,完成詳細針對每個構(gòu)件,完成詳細設計、編碼和集成,經(jīng)測設計、編碼和集成,經(jīng)測試后交付給用戶試后交付給用戶維護維護 使用增量模型開發(fā)軟件時,把軟件產(chǎn)品作為一系列的增量構(gòu)件來設計、編碼、集成和測試。每個構(gòu)件由多個相互作用的模塊構(gòu)成,并且能夠完成特定的功能。使用增量模型時,第一個增量構(gòu)件往往實現(xiàn)軟件的基本需求,提供最核心的功能。 圖1.5所示的增量模型表明,必須在開始實現(xiàn)各個構(gòu)件之前就全部完成需求分析、規(guī)格說明和概要設計的工作。由于在開始構(gòu)建第一個構(gòu)件之前就已經(jīng)有了總體設計,因此風險較小。圖1.6描繪一種風險更大的增量模型:一旦確定了用戶需求之后,就著手擬定第一個構(gòu)件的規(guī)

7、格說明文檔,完成后規(guī)格說明組將轉(zhuǎn)向第二個構(gòu)件的規(guī)格說明,與此同時設計組開始設計第一個構(gòu)件用這種方式開發(fā)軟件,不同的構(gòu)件將并行的構(gòu)建,因此有可能加快工程進度。但是,使用這種方法將冒構(gòu)件無法集成到一起的風險。規(guī)格說明規(guī)格說明設計設計編碼和集成編碼和集成交付客戶交付客戶規(guī)格說明規(guī)格說明設計設計編碼和集成編碼和集成交付客戶交付客戶規(guī)格說明規(guī)格說明設計設計編碼和集成編碼和集成交付客戶交付客戶構(gòu)件構(gòu)件1:構(gòu)件構(gòu)件2:構(gòu)件構(gòu)件n:圖圖1.6 1.6 風險更大的增量模型風險更大的增量模型1.4.4 1.4.4 螺旋模型螺旋模型 軟件開發(fā)總要冒一定風險,項目越大,軟件越復雜,承擔該項目所冒的風險也越大。軟件風險

8、可能在不同程度上損害軟件開發(fā)過程和軟件產(chǎn)品質(zhì)量。因此,在軟件開發(fā)過程中必須及時識別和分析風險,并且采取適當措施以消除或減少風險的危害。 螺旋模型的基本思想是,使用原型及其他方法來盡量降低風險。理解這種模型的簡便方法是,把它看作在每個階段之前都增加了風險分析過程的快速原型模型,如圖1.7所示。風險分析快速原型驗證風險分析規(guī)格說明驗證風險分析設計驗證風險分析編碼測試風險分析綜合測試維護風險分析變化的需求驗證圖圖1.7 1.7 簡化的螺旋模型簡化的螺旋模型圖圖1.8 1.8 完整的螺旋模型完整的螺旋模型1.4.5 1.4.5 噴泉模型噴泉模型 迭代是軟件開發(fā)過程中普遍存在的一種內(nèi)在屬性。經(jīng)驗表明,軟

9、件過程各個階段之間的迭代或一個階段內(nèi)各個工作步驟之間的迭代,在面向?qū)ο蠓缎椭斜仍诮Y(jié)構(gòu)化范型中更常見。 圖1.9所示的噴泉模型,是典型的面向?qū)ο蟮能浖^程模型?!皣娙边@個詞體現(xiàn)了面向?qū)ο筌浖_發(fā)過程迭代和無縫的特性。維護期維護期進一步開發(fā)進一步開發(fā)運行狀態(tài)運行狀態(tài)集成和測試階段集成和測試階段編碼階段編碼階段面向?qū)ο笤O計階段面向?qū)ο笤O計階段面向?qū)ο蠓治鲭A段面向?qū)ο蠓治鲭A段需求階段需求階段圖圖1.9 1.9 噴泉模型噴泉模型 圖中代表不同階段的圓圈相互重疊,這明確表示兩個活動之間存在交疊。圖中在一個階段內(nèi)的向下箭頭代表該階段內(nèi)的迭代(或求精)。 為避免使用噴泉模型開發(fā)軟件時開發(fā)過程過分無序,應該把

10、一個線性過程(如圖1.9中的中心垂線)作為總目標。1.1.最佳實踐最佳實踐迭代式開發(fā)管理需求使用基于構(gòu)件的體系結(jié)構(gòu)可視化建模驗證軟件質(zhì)量控制軟件變更1.4.6 1.4.6 Rational 統(tǒng)一過程統(tǒng)一過程 Rational統(tǒng)一過程(Rational Unified Process, RUP)是由Rational公司推出的一種軟件過程。 RUP總結(jié)了6條最有效的軟件開發(fā)經(jīng)驗,這些經(jīng)驗被稱為“最佳實踐”。2. RUP2. RUP軟件開發(fā)生命周期軟件開發(fā)生命周期 RUP軟件開發(fā)生命周期是一個二維的生命周期模型。如下圖所示。圖中縱軸代表核心工作流,橫軸代表時間。(1 1)核心工作流)核心工作流 RU

11、P中有9個核心工作流,其中前6個為核心過程工作流(Core Process Workflows),后3個為核心支持工作流(Core Supporting Workflows)。 業(yè)務建模(Business Modeling) 需求(Requirements) 分析和設計(Analysis & Design) 實現(xiàn)(Implementation) 測試(Test) 部署(Deployment) 配置和變更管理(Configuration & Change Management) 項目管理(Project Management) 環(huán)境(Environment)(2 2)工作階段)工

12、作階段 RUP中的軟件生命周期在時間上被分解為四個連續(xù)的階段,每個階段都有明確的目標,并且定義了用來評估是否達到這些目標的里程碑。如果評估結(jié)果令人滿意的話,可以允許項目進入下一個階段。 四個階段的工作目標分別是:初始階段(Inception):建立業(yè)務模型,定義最終產(chǎn)品視圖,并且確定項目的范圍。精化階段(Elaboration):設計并確定系統(tǒng)的體系結(jié)構(gòu),制定項目計劃,確定資源需求。構(gòu)建階段(Construction):開發(fā)出所有構(gòu)件和應用程序,把它們集成為客戶需要的產(chǎn)品,并且詳盡地測試所有功能。移交階段(Transition):把開發(fā)出的產(chǎn)品提交給用戶使用。(3 3)RUPRUP迭代式開發(fā)迭

13、代式開發(fā)RUP強調(diào)采用迭代和漸增的方式來開發(fā)軟件,整個項目開發(fā)過程由多個迭代過程組成。一個迭代是一個完整的開發(fā)循環(huán),產(chǎn)生一個可執(zhí)行的產(chǎn)品版本,是最終產(chǎn)品的一個子集,它增量式地發(fā)展,從一個迭代過程到另一個迭代過程到成為最終的系統(tǒng)。RUP重復一系列組成軟件生命周期的循環(huán),但是,在不同的迭代過程中是以不同的工作重點和強度對這些核心工作流程進行訪問的。1.4.7 1.4.7 敏捷過程與極限編程敏捷過程與極限編程1.1.敏捷過程敏捷過程 為了使軟件開發(fā)團隊具有高效工作和快速響應變化的能力,17位著名的軟件專家于2001年2月聯(lián)合起草了敏捷軟件開發(fā)宣言,它由4格簡單的價值觀聲明組成。(1)個體和交互勝過過

14、程和工具(2)可以工作的軟件勝過面面俱到的文檔(3)客戶合作勝過合同談判(4)響應變化勝過遵循計劃2.2.極限編程極限編程 極限編程(eXtreme Programming, XP)是敏捷過程中最富盛名的一個,其名稱中極限二字的含義是指把好的開發(fā)實踐運用到極致。目前,極限編程已經(jīng)成為一個典型的開發(fā)方法,廣泛應用于需求模糊且經(jīng)常改變的場合。(1 1)極限編程的有效實踐)極限編程的有效實踐 客戶作為開發(fā)團隊的成員 使用用戶素材(正在進行的關(guān)于需求的談話內(nèi)容的助記符。)使用用戶素材可以合理安排實現(xiàn)該項需求的時間 短交付周期驗收測試結(jié)對編程測試驅(qū)動開發(fā)集體所有持續(xù)集成:一天之內(nèi)多次集成,不斷回歸測試可

15、持續(xù)的開發(fā)速度開放的工作空間及時調(diào)整計劃簡單的設計重構(gòu):在不改變系統(tǒng)行為的前提下,重新調(diào)整和優(yōu)化系統(tǒng)內(nèi)部結(jié)構(gòu),以降低復雜性、消除冗余、增加靈活性和提高性能。使用隱喻:描述系統(tǒng)如何運作,用何種方式加入新功能。(2 2)極限編程的整體開發(fā)過程)極限編程的整體開發(fā)過程 圖1.11描述了極限編程的整體開發(fā)過程。圖圖1.11 XP1.11 XP項目的整體開發(fā)過程項目的整體開發(fā)過程(3 3)極限編程的迭代過程)極限編程的迭代過程圖1.12描述了極限編程的迭代開發(fā)過程。圖圖1.12 XP1.12 XP迭代開發(fā)過程迭代開發(fā)過程 綜上所述,以極限編程為杰出代表的敏捷過程,具有對變化和不確定性的更快速,更敏捷的反

16、映特性,而且在快速的同時仍然能保持可持續(xù)的開發(fā)速度。上述這些特點使得敏捷過程能夠較好的適應商業(yè)競爭環(huán)境下對小型項目提出的有限資源和有限開發(fā)時間的約束。項目計劃應該兼顧未來的不確定因素用有效的風險管理來減少不確定因素的影響經(jīng)常生成并快速地測試軟件地過渡版本,從而提高產(chǎn)品地穩(wěn)定性和可預測性1.4.8 1.4.8 微軟過程微軟過程 作為世界上最大的同時也是最成功的軟件公司之一,Microsoft(微軟)公司擁有自己獨特的軟件開發(fā)過程,幾十年的實踐證明微軟過程是非常成功和行之有效的。 1 1、微軟過程準則、微軟過程準則 微軟過程遵循下述的基本準則:采用快速循環(huán),遞進地開發(fā)過程用創(chuàng)造性地工作來平衡產(chǎn)品特

17、性和產(chǎn)品成本項目進度表應該具有較高穩(wěn)定性和權(quán)威性使用小型項目組并發(fā)地完成開發(fā)工作在項目早期把軟件配置項基線化,項目后期則凍結(jié)產(chǎn)品使用原型驗證概念,對項目進行早期論證把零缺陷作為追求的目標里程碑評審會的目的是改進工作,切忌相互指責2.2.微軟軟件生命周期微軟軟件生命周期 微軟過程把軟件生命周期劃分成5個階段。圖1.13描繪了生命周期的階段及每個階段的主要里程碑。規(guī)劃階段規(guī)劃階段項目目標項目目標得到認可得到認可設計階段設計階段開發(fā)階段開發(fā)階段穩(wěn)定階段穩(wěn)定階段發(fā)布階段發(fā)布階段完成產(chǎn)品完成產(chǎn)品設計設計完成開發(fā)完成開發(fā)工作工作準備好可準備好可發(fā)布版本發(fā)布版本完成產(chǎn)品完成產(chǎn)品發(fā)布發(fā)布圖圖1.13 1.13

18、 微軟軟件生命周期階段劃分和主要里程碑微軟軟件生命周期階段劃分和主要里程碑(1)規(guī)劃階段 主要任務是,根據(jù)從市場上獲得的用戶情況和客戶需求等信息,在調(diào)查、統(tǒng)計和分析的基礎上,完成下述工作。 確定產(chǎn)品目標。 獲取競爭對手的信息。 完成對客戶和市場的調(diào)研分析。 確定新版本產(chǎn)品應具備的主要特征。 確定相對于前一版本而言,新版本應該解決的問題和需要增加的功能。(2)設計階段 主要工作如下: 根據(jù)產(chǎn)品目標編寫系統(tǒng)的特性規(guī)格說明書。主要描述軟件特性、系統(tǒng)結(jié)構(gòu)、各構(gòu)件間的相關(guān)性以及接口標準。 從系統(tǒng)高層著手開始進行系統(tǒng)設計,主要完成:系統(tǒng)設計方案,描繪系統(tǒng)結(jié)構(gòu)圖,確定系統(tǒng)中存在的風險因素,分析系統(tǒng)的可重用性

19、。 劃分出系統(tǒng)的子系統(tǒng),給出各自系統(tǒng)和各個構(gòu)件的規(guī)格說明。 根據(jù)產(chǎn)品特性規(guī)格說明書制定產(chǎn)品開發(fā)計劃。(3)開發(fā)階段 主要任務是,完成產(chǎn)品中所有構(gòu)件的開發(fā)工作,包括編寫程序代碼和書寫文檔。(4)穩(wěn)定階段 主要任務是對產(chǎn)品進行測試和調(diào)試,以確保已經(jīng)正確地實現(xiàn)了整個解決方案,產(chǎn)品可以發(fā)布了。 (5)發(fā)布階段 發(fā)布產(chǎn)品或解決方案,并把項目移交到運營和支持人員手中,以獲得最終用戶對項目的認可。3.3.微軟過程模型微軟過程模型 微軟過程的每一個生命周期發(fā)布一個遞進的軟件版本,各個生命周期持續(xù),快速地迭代循環(huán)。如圖1.14所示。圖圖1.12 1.12 微軟過程的生命周期模型微軟過程的生命周期模型 2.2 2

20、.2 可行性研究的過程可行性研究的過程 步驟如下:1.復查系統(tǒng)規(guī)模和目標2.研究目前正在使用的系統(tǒng) 從兩個方面出發(fā):(1)原系統(tǒng)的功能和優(yōu)點; (2)原系統(tǒng)存在的缺陷。3.導出新系統(tǒng)的高層邏輯模型 優(yōu)秀的設計通常按以下步驟進行:現(xiàn)有的物理系統(tǒng)現(xiàn)有系統(tǒng)的邏輯模型新的物理系統(tǒng)目標系統(tǒng)的邏輯模型4. 進一步定義問題:新系統(tǒng)必須做什么?分析員和用戶看法一致。5. 導出和評價供選擇的解法 首先從技術(shù)角度提出一些可能的物理系統(tǒng)后,應根據(jù)技術(shù)可行性的考慮初步排除一些不現(xiàn)實的系統(tǒng)。 其次,考慮操作方面的可行性。 最后應該考慮經(jīng)濟方面的可行性。6. 推薦行動方針:是否繼續(xù)開發(fā)?是則推薦最佳方案7. 草擬開發(fā)計劃

21、 包括:工程進度表、各種開發(fā)人員和各種資源的需求情況、下一階段(需求分析)的詳細進度表和成本估計。8. 書寫文檔提交審查 數(shù)據(jù)字典定義中用到的符號: = 意思是等價于(或定義為); + 意思是和(即,連接兩個分量); 意思是或(即,從方括號內(nèi)列出的若干個分量中選擇一個); 意思是重復(即,重復花括號內(nèi)的分量); ( ) 意思是可選(即,圓括號內(nèi)的分量可有可無); 3.2 3.2 與用戶溝通獲取需求的方法與用戶溝通獲取需求的方法3.2.1 3.2.1 訪談訪談 訪談是最早開始使用的獲取用戶需求的技術(shù),也是迄今為止仍然廣泛使用的需求分析技術(shù)。 訪談有兩種基本形式,分別是正式的和非正式的。 在訪問用

22、戶的過程中,使用情景分析技術(shù)往往非常有效。所謂情景分析就是對用戶將來使用目標系統(tǒng)解決某個具體問題的方法和結(jié)果進行分析。 情景分析技術(shù)的用處主要體現(xiàn)在下述兩個方面:v 它能在某種程度上演示目標系統(tǒng)的行為,從而便于用戶理解,而且還可能進一步揭示出一些分析員目前還不知道的需求。v 由于情景分析較易為用戶所理解,使用這種技術(shù)能保證用戶在需求分析過程中始終扮演一個積極主動地角色。3.2.2 3.2.2 面向數(shù)據(jù)流自頂向下求精面向數(shù)據(jù)流自頂向下求精 結(jié)構(gòu)化分析方法(SA)就是面向數(shù)據(jù)流自頂向下逐步求精進行需求分析的方法。其過程如下圖示:圖圖3.1 3.1 面向數(shù)據(jù)流自頂向下求精過程面向數(shù)據(jù)流自頂向下求精過

23、程 分析追蹤數(shù)據(jù)流圖用戶復查細化數(shù)據(jù)流圖有補充修正無補充修正需要分解不需要分解3.2.3 3.2.3 簡易的應用規(guī)格說明技術(shù)簡易的應用規(guī)格說明技術(shù)(P60)(P60) 面向團隊的需求收集法,用戶與開發(fā)者密切合作3.2.4 3.2.4 快速建立軟件原型快速建立軟件原型 快速原型應該具備的第一個特性是“快速”。 快速原型應該具備的第二個特性是“容易修改”。 為了快速地構(gòu)建和修改軟件,通常使用下述幾種方法和工具: (1)第四代技術(shù)第四代技術(shù) (2)可重用的軟件構(gòu)件可重用的軟件構(gòu)件 (3)形式化規(guī)格說明和原型環(huán)境形式化規(guī)格說明和原型環(huán)境3.3.2 3.3.2 軟件需求規(guī)格說明軟件需求規(guī)格說明 軟件需求

24、規(guī)格說明,應包括以下內(nèi)容:系統(tǒng)規(guī)格說明:系統(tǒng)規(guī)格說明:主要描述目標系統(tǒng)的概貌、功能要求、性能要求、可靠性和可用性要求、約束和將來可能提出的要求等。數(shù)據(jù)要求:數(shù)據(jù)要求:主要包括數(shù)據(jù)字典、描繪數(shù)據(jù)結(jié)構(gòu)的層次方框圖或Warnier圖。用戶系統(tǒng)描述:用戶系統(tǒng)描述:一份初步的用戶手冊。主要包括對系統(tǒng)功能和性能的扼要描述,使用系統(tǒng)的主要步驟和方法,以及系統(tǒng)用戶的責任等。 3.7 3.7 其他圖形工具其他圖形工具3.7.1 3.7.1 層次方框圖層次方框圖 層次方框圖用樹形結(jié)構(gòu)的一系列的矩形框描繪數(shù)據(jù)的層次結(jié)構(gòu)。 產(chǎn)品硬件軟件服務處理機存儲器外部設備系統(tǒng)軟件應用軟件軟件服務硬件服務培訓圖圖3.5 3.5 層

25、次方框圖例子層次方框圖例子3.7.2 Warnier圖圖軟件產(chǎn)品系統(tǒng)軟件應用軟件操作系統(tǒng)(P1)編譯程序(P2)軟件工具編輯程序(P3)測試驅(qū)動程序(P4)設計輔助工具(P5)圖圖3.6 Warnier圖例子圖例子 Warnier圖也用樹形結(jié)構(gòu)描繪信息,它可以表明信息的邏輯組織,即它可以指出一類信息或一個信息元素是重復出現(xiàn)的,也可以表示信息有條件出現(xiàn)。舊的主文件事務文件1.校驗主記錄2.校驗事務記錄3.更新主記錄有效的主記錄有效的事務記錄更新后的主文件輸入處理輸出圖圖3.7 IPO3.7 IPO圖的一個例子圖的一個例子IPO表系統(tǒng):_作者:_模塊:_日期:_編號:_ 注釋:被調(diào)用:調(diào)用:輸入:

26、輸出:處理:局部數(shù)據(jù)元素:圖圖3.8 3.8 改進的改進的IPOIPO圖的形式圖的形式 1. 1. 耦合耦合耦合的種類:耦合的種類:數(shù)據(jù)耦合控制耦合特征耦合公共環(huán)境耦合內(nèi)容耦合 數(shù)據(jù)耦合數(shù)據(jù)耦合:如果兩個模塊彼此間通過參數(shù)交換信息,而且交換的信息僅僅是數(shù)據(jù),那么這種耦合稱為數(shù)據(jù)耦合。這是一種低耦合??刂岂詈峡刂岂詈希喝绻麅蓚€模塊彼此間通過參數(shù)交換信息,并且傳遞的信息中有控制信息(盡管有時這種控制信息以數(shù)據(jù)的形式出現(xiàn)),那么這種耦合稱為控制耦合。是中等程度的耦合。控制耦合往往是多余的,把模塊適當分解后通??捎脭?shù)據(jù)耦合代替它。特征耦合特征耦合:當把整個數(shù)據(jù)結(jié)構(gòu)作為參數(shù)傳遞而被調(diào)用的模塊只需要使用其

27、中一部分元素時,就出現(xiàn)了特征耦合。這時,被調(diào)用模塊可以使用的數(shù)據(jù)多于它確實需要的數(shù)據(jù),將導致對數(shù)據(jù)的訪問失控,從而給計算機犯罪提供機會。公共環(huán)境耦合公共環(huán)境耦合:當兩個或多個模塊通過一個公共數(shù)據(jù)環(huán)境相互作用時,它們之間的耦合稱為公共環(huán)境耦合。公共環(huán)境可以是全程變量、共享的通信區(qū)、內(nèi)存的公共覆蓋區(qū)等。 公共環(huán)境耦合的復雜程度隨耦合的模塊數(shù)目而變化,當耦合的模塊個數(shù)增加時復雜程度顯著增加。如果只有兩個模塊有公共環(huán)境,這種耦合有以下兩種可能: (1)一個模塊往公共環(huán)境送數(shù)據(jù),另一個模塊從公共環(huán)境取數(shù)據(jù)。這是數(shù)據(jù)耦合的一種形式,是較松散的耦合。 (2)兩個模塊都既往公共環(huán)境送數(shù)據(jù),又從里面取數(shù)據(jù)。這種

28、耦合比較緊密,介于數(shù)據(jù)耦合和控制耦合之間。內(nèi)容耦合內(nèi)容耦合:如果出現(xiàn)下列情況之一,兩個模塊間就發(fā)生了內(nèi)容耦合:u一個模塊訪問另一個模塊的內(nèi)部數(shù)據(jù);u一個模塊不通過正常入口而轉(zhuǎn)到另一個模塊的內(nèi)部;u兩個模塊有一部分程序代碼重疊(只可能出現(xiàn)在匯編程序中); u一個模塊有多個入口(這意味著一個模塊有幾種功能)。 內(nèi)容耦合是最高程度的耦合,應堅決避免使用。 2. 2. 內(nèi)聚內(nèi)聚 衡量一個模塊內(nèi)部各個元素彼此結(jié)合的緊密程度。 模塊化設計期望產(chǎn)生高內(nèi)聚的模塊低內(nèi)聚中內(nèi)聚高內(nèi)聚0分1分3分5分7分9分10分內(nèi)聚的種類:內(nèi)聚的種類:偶然內(nèi)聚 邏輯內(nèi)聚時間內(nèi)聚過程內(nèi)聚通信內(nèi)聚順序內(nèi)聚功能內(nèi)聚 偶然內(nèi)聚偶然內(nèi)聚:

29、如果一個模塊完成一組任務,這些任務彼此間即使有關(guān)系,關(guān)系也是很松散的,就叫做偶然內(nèi)聚。 邏輯內(nèi)聚邏輯內(nèi)聚:如果一個模塊完成的任務在邏輯上屬于相同或相似的一類,則稱為邏輯內(nèi)聚。例如,一個模塊產(chǎn)生各種類型的全部輸出。l 時間內(nèi)聚時間內(nèi)聚:如果一個模塊包含的任務必須在同一段時間內(nèi)執(zhí)行,就叫時間內(nèi)聚。例如,模塊完成各種初始化工作。通信內(nèi)聚通信內(nèi)聚:如果模塊中所有元素都使用同一個輸入數(shù)據(jù)(或)產(chǎn)生同一個輸出數(shù)據(jù),則稱為通信內(nèi)聚。過程內(nèi)聚過程內(nèi)聚:如果一個模塊內(nèi)的處理元素是相關(guān)的,而且必須以特定次序執(zhí)行,則稱為過程內(nèi)聚。按程序流程圖設計軟件時,往往得到的是過程內(nèi)聚的模塊。順序內(nèi)聚順序內(nèi)聚:如果一個模塊內(nèi)的

30、處理元素和同一個功能密切相關(guān),而且這些處理必須順序執(zhí)行(通常一個處理元素的輸出數(shù)據(jù)是下一個處理元素的輸入數(shù)據(jù)),則稱為順序內(nèi)聚。按數(shù)據(jù)流圖劃分模塊時,通常得到順序內(nèi)聚的模塊。功能內(nèi)聚功能內(nèi)聚:如果模塊內(nèi)所有處理元素屬于一個整體,完成一個單一的功能,則稱為功能內(nèi)聚。5.3 5.3 啟發(fā)式規(guī)則啟發(fā)式規(guī)則1.1.改進軟件結(jié)構(gòu)提高模塊獨立性改進軟件結(jié)構(gòu)提高模塊獨立性 通過模塊分解和合并,力求降低耦合提高內(nèi)聚。2.2.模塊規(guī)模應該適中模塊規(guī)模應該適中3.3.深度、寬度、扇出和扇入都應適當深度、寬度、扇出和扇入都應適當 深度:深度:表示軟件結(jié)構(gòu)中控制的層數(shù)。 寬度:寬度:軟件結(jié)構(gòu)內(nèi)同一個層次上的模塊總數(shù)的

31、最大值。 扇出:扇出:一個模塊直接控制(調(diào)用)的模塊數(shù)目。扇出大意味著模塊過分復雜,需控制和協(xié)調(diào)過多的下級模塊。 扇入:扇入:一個模塊的扇入表明有多少個上級模塊直接調(diào)用它。扇入越大則說明共享該模塊的模塊數(shù)目越多,這是好的。但不能為追求高扇入違背模塊獨立原理。4. 4. 模塊的作用域應該在控制域之內(nèi)模塊的作用域應該在控制域之內(nèi) 模塊的作用域:模塊的作用域:受該模塊內(nèi)一個判定影響的所有模塊的集合。 模塊的控制域:模塊的控制域:該模塊本身以及所有直接或間接從屬于它的模塊的集合。 圖圖5.2 5.2 模塊的作用域和控制域模塊的作用域和控制域 在上圖中,若 A 的判定只影響 B ,則是符合該規(guī)則的;但是

32、,如果A 的判定還影響到 G,則就不符合該規(guī)則了,可有兩種方法:一是將判定點 A 上移到 M 中;另一種方式是將 G 移到 A 的 下方。MAGBCDEF5. 5. 力爭降低模塊接口的復雜程度力爭降低模塊接口的復雜程度6. 6. 設計單入口單出口的模塊設計單入口單出口的模塊7. 7. 模塊功能應該可以預測模塊功能應該可以預測 如果一個模塊可以當作一個黑盒子,即只要輸入的數(shù)據(jù)相同就產(chǎn)生同樣的輸出,這個模塊的功能就是可以預測的。系統(tǒng)系統(tǒng)輸入輸入輸出輸出編輯編輯加加標題標題存儲存儲檢索檢索編編目錄目錄格格式化式化添加添加刪除刪除插入插入修改修改合并合并列表列表圖圖5.3 5.3 正文加工系統(tǒng)的層次圖

33、例子正文加工系統(tǒng)的層次圖例子5.4 5.4 描繪軟件結(jié)構(gòu)圖形工具描繪軟件結(jié)構(gòu)圖形工具 5.4.1 5.4.1 層次圖和層次圖和HIPOHIPO圖圖 層次圖是用樹形結(jié)構(gòu)的一系列的矩形框描繪軟件的層次結(jié)構(gòu)。圖圖5.5 5.5 結(jié)構(gòu)圖的例子結(jié)構(gòu)圖的例子產(chǎn)生最佳解的一般結(jié)構(gòu)產(chǎn)生最佳解的一般結(jié)構(gòu)讀輸入讀輸入編輯輸入編輯輸入顯示結(jié)果顯示結(jié)果結(jié)果格式化結(jié)果格式化產(chǎn)生最佳解產(chǎn)生最佳解得到好輸入得到好輸入計算最佳解計算最佳解輸出結(jié)果輸出結(jié)果好好輸輸入入解解好輸入好輸入解解原始原始輸入輸入編輯編輯結(jié)果結(jié)果原始原始輸入輸入格式格式化的化的解解解解格式格式化的化的解解習題vP141/習題6 第三題畫出右側(cè)偽碼程序的程

34、序流程圖和盒圖習題vP141/習題6 第四題P1P2(a)(a)順序順序P1P2C(b)(b)選擇選擇P1P2PnX=L1 L2 Ln(c)Case (c)Case 型多分支型多分支While CP(d)while (d)while 型循環(huán)型循環(huán)PUntil C(e)until (e)until 型循環(huán)型循環(huán)(f)(f)語句標號語句標號 def(g)(g)定義定義圖圖6.5 PAD 6.5 PAD 圖的基本符號圖的基本符號 圖圖6.6 6.6 使用使用PAD PAD 圖提供的定義功能來逐步求精的例子圖提供的定義功能來逐步求精的例子PAD圖補充例子:圖補充例子:圖圖1 1 流程圖流程圖abx1x

35、5x2fx6cdex3x4ghix7x8j循環(huán)循環(huán)結(jié)構(gòu)結(jié)構(gòu)分支分支結(jié)構(gòu)結(jié)構(gòu)多分支多分支結(jié)構(gòu)結(jié)構(gòu)aUntil X8bX1fX6Until X7ighXiwhile X5cdeX2X3X4j對應的對應的PADPAD圖如下示圖如下示:循環(huán)體循環(huán)體分支結(jié)構(gòu)分支結(jié)構(gòu)多分支結(jié)多分支結(jié)構(gòu)構(gòu)順順序序結(jié)結(jié)構(gòu)構(gòu)循環(huán)結(jié)構(gòu)循環(huán)結(jié)構(gòu)規(guī)則規(guī)則 表表6.1 6.1 用判定表表示計算行李費的算法用判定表表示計算行李費的算法6.3.5 6.3.5 判定樹判定樹行李費行李費 算法算法行李重量行李重量 W W3030行李重量行李重量 W30W30免費免費外國乘客外國乘客國內(nèi)乘客國內(nèi)乘客頭等艙頭等艙頭等艙頭等艙其他艙其他艙其他艙其他

36、艙殘疾乘客殘疾乘客殘疾乘客殘疾乘客殘疾乘客殘疾乘客殘疾乘客殘疾乘客正常乘客正常乘客正常乘客正常乘客正常乘客正常乘客正常乘客正常乘客(W-30)(W-30)2 2(W-30)(W-30)4 4(W-30)(W-30)3 3(W-30)(W-30)6 6(W-30)(W-30)4 4(W-30)(W-30)8 8(W-30)(W-30)6 6(W-30)(W-30)1212 圖圖6.7 6.7 用判定樹表示計算行李費的算法用判定樹表示計算行李費的算法習題vP142/習題6 第七題由由PDLPDL翻譯成的流圖翻譯成的流圖 7.3 7.3 單元測試單元測試 單元測試集中檢驗軟件設計的最小單元-模塊。

37、單元測試可以使用白盒法,用詳細設計描述做指南,對重要的執(zhí)行通路進行測試,以便發(fā)現(xiàn)模塊內(nèi)部的錯誤。單元測試可以對多個模塊并行進行。 7.4 7.4 集成測試集成測試 集成測試是組裝軟件的系統(tǒng)技術(shù),主要目標是發(fā)現(xiàn)與接口有關(guān)的問題。集成測試過程漸增式非漸增式 非漸增式測試:非漸增式測試:先分別測試每個模塊,再把所有模塊按設計要求放在一起結(jié)合成所要的程序。 漸增式測試:漸增式測試:把下一個要測試的模塊同已經(jīng)測試好的那些模塊結(jié)合起來進行測試,測試完以后再把下一個應該測試的模塊結(jié)合起來進行測試。 7.5 7.5 確認測試確認測試 確認測試也稱為驗收測試,它的目標是驗證軟件的有效性。 驗證,指的是保證軟件正

38、確地實現(xiàn)了某個特定要求的一系列活動;確認指的是為了保證軟件確實滿足了用戶需求而進行的一系列活動。 什么是軟件有效性? 如果軟件的功能和性能如同用戶所合理地期待的那樣,則軟件是有效的。補充:系統(tǒng)測試補充:系統(tǒng)測試 系統(tǒng)測試是把軟件、硬件和環(huán)境連在一起全面的測試。測試的內(nèi)容同被測試系統(tǒng)的特點有關(guān)。測試某個具體系統(tǒng)時,可根據(jù)情況選擇下面其中的幾種:(1 1)功能測試)功能測試(Function Testing) 檢查系統(tǒng)是否真正實現(xiàn)了需求說明書描述的每一個功能。(2 2)容量測試)容量測試(Volume Testing) 容量測試是讓系統(tǒng)經(jīng)受大數(shù)據(jù)量的考驗。例如,讓編譯程序編譯一個特別長的源程序;讓

39、連結(jié)程序連結(jié)成千個模塊。課堂練習:課堂練習:課堂練習:7.8 7.8 調(diào)試調(diào)試 測試本身的目的是盡可能多地暴露程序中的錯誤,但是,發(fā)現(xiàn)錯誤的最終目的還是為了改正錯誤。 在成功地測試之后,必須進一步診斷和改正程序中的錯誤,這就是調(diào)試的任務。 調(diào)試過程由兩個步驟組成,它從表示程序中存在錯誤的某些跡象開始,首先確定錯誤的準確位置,也就是找出是哪個模塊或哪些接口引起的錯誤;然后,仔細研究這段代碼以確定問題的原因。其中第一個步驟所需工作量約占調(diào)試總工作量的95%。7.8.1 7.8.1 調(diào)試過程調(diào)試過程 2. 2. 對象的定義對象的定義(3)定義定義3:對象:=。其中,ID是對象的標識和名字,MS是對象

40、的操作集合,DS是對象的數(shù)據(jù)結(jié)構(gòu),MI是對象受理的消息名集合(即對外接口)。 這個定義是個形式化的定義。對象是封裝了數(shù)據(jù)結(jié)構(gòu)及可以施加在這些數(shù)據(jù)結(jié)構(gòu)上的操作的封裝體,這個封裝體有可以唯一的識別它的名字,而且向外界提供一組服務(即共有的操作)。9.2.2 9.2.2 其他概念其他概念1.1.類類(class)(class) 類就是對具有相同數(shù)據(jù)和相同操作的一組相似對象的定義,也就是說,類是對具有相同屬性和行為的一個或多個對象的描述,通常在這種描述中也包括對怎樣創(chuàng)建該類的新對象的說明。2.2.實例實例 實例就是由某個特定的類所描述的一個具體的對象。類是對具有相同屬性和行為的一組相似的對象的抽象。類是建立對象時使用的“樣板”,按照這個樣板所建立的一個個具體的對象,就是類的實際例子,通常稱為實例。3.3.消息消息 消息就是要求某個對象執(zhí)行在定義它的那個類中所定義的某個操作的規(guī)格說明。通常,一個消息有下述3部分組成:接收消息的對象;消息選擇符(也稱為消息名);零個或多個變元。 MyCircle.Show(GREEN)4.4.方法方法(method)(method) 方法就是對象所能執(zhí)行的

溫馨提示

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

評論

0/150

提交評論