軟件工程復(fù)習(xí)資料整理

1、第一章 軟件工程介紹軟件工程的概念I(lǐng)EEE對軟件工程的定義:（1）將系統(tǒng)化的、嚴格約束的、可量化的方法應(yīng)用于軟件的開發(fā)、運行和維護，即將工程化應(yīng)用于軟件。（2）在（1）中所述方法的研究。過程、方法和工具過程：為了獲取高質(zhì)量的軟件所需要完成的一系列任務(wù)的框架，它規(guī)定了完成各項任務(wù)的工作步驟。方法：各項任務(wù)的技術(shù)方法，回答“怎么做”的問題。工具：為運用方法而提供的自動或半自動的軟件工程支撐環(huán)境軟件工程層次圖軟件危機與軟件工程的關(guān)系、產(chǎn)生的原因及其表現(xiàn)軟件工程的提出：軟件工程主要是針對20世紀60年代的軟件危機而提出的軟件危機定義：軟件危機是指在計算機軟件的開發(fā)和維護過程中所遇到的一系列嚴重問題。產(chǎn)

2、生軟件危機的原因：客觀原因：軟件缺乏“可見性”，管理和控制其開發(fā)過程相對困難軟件大多規(guī)模龐大，而復(fù)雜性隨規(guī)模以指數(shù)速度上升主觀原因：錯誤的認識和做法忽視軟件需求分析的重要性急于求成，倉促上陣認為軟件開發(fā)就是寫程序編程只占全部工作量的10%-20%，軟件配置主要包括程序、文檔和數(shù)據(jù)輕視軟件維護維護費用占總費用的55%-70%軟件神話一些錯誤認識管理神話：我們已經(jīng)有了一本寫滿軟件開發(fā)標(biāo)準和規(guī)程的寶典。它無所不包，囊括了我們可能問到的所有問題如果我們未能按時完成計劃，我們可以通過增加程序員人數(shù)而趕上進度如果將一個軟件外包給另一家公司，則我們可以完全放手不管。用戶神話：有了對項目目標(biāo)的大概了解，便足以

3、開始編寫程序，我們可以在之后的項目開發(fā)過程中逐步了解細節(jié)。雖然項目需求不斷變更，但是因為軟件是彈性的，因此可以很容易地適應(yīng)變化從業(yè)者神話：當(dāng)我們完成程序并將其交付使用之后，我們的任務(wù)就完成了。直到程序開始運行，才能評估其質(zhì)量對于一個成功的軟件項目，可執(zhí)行程序是惟一可交付的成果。軟件工程將導(dǎo)致我們產(chǎn)生大量無用文檔，并因此降低工作效率。第二章 過程模型掌握五個最基本的框架活動：將整個軟件過程再進一步細分為各個相對獨立的功能塊，即過程框架。（以工作開展的時間為線索）。五個最基本的框架活動：溝通：與客戶之間的交流與寫作策劃：為后續(xù)的軟件工程工作制定計劃建模：包括分析和設(shè)計構(gòu)建：編碼和測試部署：軟件交付

4、用戶，用戶對其進行評估并反饋意見。了解典型的普適性活動適用于任何一個框架活動：軟件項目跟蹤和控制；風(fēng)險管理；軟件質(zhì)量保證；正式技術(shù)評審；測量；軟件配置管理；可復(fù)用管理；工作產(chǎn)品的準備和生產(chǎn)了解什么是CMMI能力成熟度模型集成（CMMI），用于預(yù)測軟件開發(fā)組織所開發(fā)的系統(tǒng)和軟件工程能力（5個能力成熟等級）CMMI定義了每一個過程域的“特定目標(biāo)”，以及達到該目標(biāo)所需的“特定實踐”。理解瀑布模型；增量模型；RAD模型；原型模型；螺旋模型；協(xié)同開發(fā)模型；基于構(gòu)件模型；形式化方法模型；面向方面模型；統(tǒng)一過程適用范圍、特點、優(yōu)缺點瀑布模型：也稱為線性模型或傳統(tǒng)生存周期，V模型適用范圍：通常發(fā)生在對一個已有

5、系統(tǒng)進行明確定義的適應(yīng)性調(diào)整和增強的時候?qū)τ谝粋€新的項目，需求必須是準確定義和相對穩(wěn)定的線性順序模型特點:階段間的順序性和依賴性；文檔驅(qū)動性；嚴格階段評估；開發(fā)初期需要清楚全部需求；開發(fā)周期長、風(fēng)險大。瀑布模型的缺點：順序太嚴格。實際工作經(jīng)常是在多個環(huán)節(jié)之間來回反饋調(diào)整，而不是將一個環(huán)節(jié)完成后再繼續(xù)前進。產(chǎn)品在最后階段才與客戶見面，從心里學(xué)的角度講有些考驗客戶。另外，如果此時才發(fā)現(xiàn)問題，需要改正，工作量將會很大。效率可能不高。瀑布模型的優(yōu)點：它提供了一個摸板，這個摸板使得分析、設(shè)計、編碼、測試和支持的方法可以在該摸板下有一個共同的指導(dǎo)。雖然有不少缺陷但比在軟件開發(fā)中隨意的狀態(tài)要好得多。增量模型

6、：以迭代方式運用瀑布模型。特點：一般來講，最重要的增量放在前面。每次交付的增量產(chǎn)品都是可用的。適合于功能可以劃分，而且時間不緊迫的情況?？梢砸?guī)避一定的風(fēng)險。如有些技術(shù)還不穩(wěn)定，將這部分放到后邊。RAD模型：快速應(yīng)用程序開發(fā)（Rapid Application Development，RAD)是一種側(cè)重于短暫的開發(fā)周期的增量軟件模型。瀑布模型的高速變體，通過基于構(gòu)件的方法快速實現(xiàn)。適于工期緊張，又可細分功能，還要有合適的構(gòu)件。缺點：需要投入更多的人力。各團隊要緊密協(xié)作。只適應(yīng)于特殊的系統(tǒng)，必須可以合理模塊化。不適于高性能需求（若需調(diào)構(gòu)件接口 ）系統(tǒng)需求靈活，現(xiàn)有構(gòu)件不容易輕易滿足。技術(shù)風(fēng)險很高的

7、情況下，不宜采用該模型。演化過程模型：軟件，類似于其他復(fù)雜的系統(tǒng)，會隨著時間的推移而演化軟件有技術(shù)能力的限制，時間的限制，認識理解的限制，其它客觀因素的限制。演化模型也是一種迭代模型。包括：原型模型、螺旋模型、協(xié)同開發(fā)模型。原型是一個循環(huán)的過程，所以也是迭代的過程。原型模型：對原型的基本要求：體現(xiàn)主要的功能、提供基本的界面風(fēng)格、展示比較模糊的部分，以便于確定或進一步明確，防患于未然。原型最好是可以運行的，最少要在各主要功能模塊之間能夠建立相互連接原型的處理方法：拋棄型：在獲取的明確需求的基礎(chǔ)上，重新設(shè)計與開發(fā)，成本相對高，小公司一般慎用。演化型：在原型的基礎(chǔ)上繼續(xù)開發(fā)。原型模型的優(yōu)點：能讓人（

8、開發(fā)者或客戶）很快見到產(chǎn)品，有成就感。能漸進地啟發(fā)客戶提出新的要求或任務(wù)。原型模型的缺點：容易蒙騙客戶，也可能由此給自己帶來麻煩。往往只為結(jié)果，而不考慮技術(shù)手段，為今后埋下隱患。系統(tǒng)可能考慮不周全。與增量模型相比：增量模型在開發(fā)以前基本能確定系統(tǒng)的需求，雖然在以后的過程中也可能不斷完善；原型開發(fā)適應(yīng)于預(yù)先不太清楚系統(tǒng)的需求。增量模型的反饋可能較少，而原型開發(fā)需要不斷的大量反饋信息。螺旋模型：結(jié)合了原形的迭代性質(zhì)和瀑布模型的系統(tǒng)性和可控性特點；風(fēng)險驅(qū)動，引入非常嚴格的風(fēng)險識別、風(fēng)險分析和風(fēng)險控制；早期迭代中可能是一個理論模型或原形。螺旋模型與原型相比：螺旋模型雖不像增量模型中對功能有明確界定，但

9、有比原型要清晰一些。螺旋模型的反饋要求持續(xù)于產(chǎn)品的整個生命期。適合于大型軟件的開發(fā)。協(xié)同開發(fā)模型又叫協(xié)同工程。定義了一個活動的網(wǎng)絡(luò)，網(wǎng)絡(luò)上每個活動、動作和任務(wù)同時存在。過程網(wǎng)絡(luò)中某一點產(chǎn)生的事件可以觸發(fā)狀態(tài)的轉(zhuǎn)換?？蛇m用于所有類型的軟件開發(fā)?；跇?gòu)件模型：什么是構(gòu)件？沒有統(tǒng)一的定義Gartner Group定義：運行時軟件構(gòu)件是一個可動態(tài)綁定的、含一個或多個程序的軟件包，它作為一個獨立單位，通過運行時可辨別的文檔化接口加以管理和存取類似于螺旋模型，本質(zhì)上是演化模型。構(gòu)件開發(fā)的步驟：對所需構(gòu)件進行評估?？紤]構(gòu)件的集成。設(shè)計系統(tǒng)的軟件框架。將構(gòu)件放入框架。進行測試。形式化方法模型的主要活動是生成計

10、算機軟件形式化的數(shù)學(xué)規(guī)格說明。特點：精密、準確。缺點：難度大，成本高，可用人力資源少，用戶不易理解，有時甚至無法完成。方法：有窮狀態(tài)機、Petri網(wǎng)、Z語言等。面向方向的模型：將系統(tǒng)分成若干相對較獨立的組成部分，這些部分稱為方面。面向方面技術(shù)包括面向?qū)ο蠹夹g(shù)，比它大。系統(tǒng)的方面包括用戶接口、協(xié)調(diào)工作、發(fā)布、持續(xù)性、存儲器管理、事務(wù)處理、安全、完整性等。還不成熟。具有螺旋型和協(xié)同型的共同特點。統(tǒng)一過程：試圖將傳統(tǒng)軟件模型（慣例軟件模型）和敏捷過程模型的優(yōu)點結(jié)合起來，即統(tǒng)一起來。一些術(shù)語：面向?qū)ο螅∣bject-Oriented, OO),面向?qū)ο蠓治觯?Object-Oriented Analy

11、sis, OOA),面向?qū)ο蠓治觯?Object-Oriented Design, OOD).統(tǒng)一過程包括：起始，細化，構(gòu)建，轉(zhuǎn)換，生產(chǎn)等步驟。起始：包括客戶溝通和策劃活動，此時的構(gòu)架只是主要子系統(tǒng)及其功能、特性的試探性概括。細化：包括用戶溝通和通過過程模型的建?；顒樱瑪U展體系結(jié)構(gòu)以包括軟件的五種視圖：用例模型、分析模型、設(shè)計模型、實現(xiàn)模型和部署模型。構(gòu)建：與通過軟件過程的構(gòu)建活動相同。采用體系結(jié)構(gòu)模型作為輸入，開發(fā)或獲取軟件構(gòu)件，使得最終用戶能夠操作用例。轉(zhuǎn)換：軟件被提交給最終用戶進行Beta測試，用戶反饋報告缺陷及必要的變更。另外，發(fā)布必須的支持信息：用戶手冊，用戶指南及安裝步驟等。結(jié)束時

12、，軟件增量成為可用的發(fā)布版本。生產(chǎn)：與通過軟件工程的部署一致。提供運行環(huán)境支持，提交并評估缺陷報告和變更請求。第三章 敏捷開發(fā)基于敏捷原則進行的軟件開發(fā)過程，視為敏捷過程。（所謂“基于”，是指充分考慮，而不是全部包含。）有自適應(yīng)和增量提高的過程即是敏捷過程。掌握敏捷開發(fā)宣言普遍存在的變化是敏捷的基本動力理解有哪些敏捷過程模型：極限編程、自適應(yīng)軟件開發(fā)、動態(tài)系統(tǒng)開發(fā)、Scrum、Crystal、特征驅(qū)動開發(fā)極限編程關(guān)鍵思想極限編程（eXtreme Programming, XP）力求用最少的精力活動最大的成果，運用已有成果、方法。Scrum 關(guān)鍵思想Scrum原則與敏捷宣言一致：組織小型團隊以達

13、到“溝通最大化、負擔(dān)最小化、非語言描述、非形式化知識”過程對技術(shù)和業(yè)務(wù)變化必須具有適應(yīng)性，以“保證制造具有最好可能的產(chǎn)品”過程生產(chǎn)頻繁發(fā)布“可檢查、可調(diào)整、可測試、可文檔化、可構(gòu)建”的軟件增量了解一些過程模型。開發(fā)工作和開發(fā)人員分為“清晰的、低耦合的部分或包”堅持在產(chǎn)品構(gòu)建過程中進行測試和文檔化Scrum過程提供“在任何需要的情況下都能完成產(chǎn)品的能力”。自適應(yīng)軟件開發(fā)；自適應(yīng)軟件開發(fā)（Adaptive Software Development, ASD)ASD 的三個重點：思考-啟動項目并完成自適應(yīng)循環(huán)策劃；協(xié)作-但同時鼓勵個人主義；學(xué)習(xí)-三種方式，焦點組（學(xué)習(xí)用戶反饋的信息），正式技術(shù)評審（

14、自我審視），事后剖析（回望自己團隊前面的工作）。動態(tài)系統(tǒng)開發(fā)；動態(tài)系統(tǒng)開發(fā)（Dynamic System Development Method, DSDM）-通過在可控項目環(huán)境中使用增量原型開發(fā)，模式完全滿足對時間有約束的系統(tǒng)的構(gòu)建和維護。特點：在每個增量的環(huán)節(jié)，并不完全完成任務(wù)。留下20%在以后完成。Crystal目的是開發(fā)一種提倡“機動性的”的軟件開發(fā)方法特征驅(qū)動開發(fā)特征驅(qū)動開發(fā)（Feature Driven Development, FDD) 特征：能在更短時間內(nèi)完成的小功能。可行性研究了解可行性研究的目的和任務(wù)掌握數(shù)據(jù)流圖畫法（DFD）第四章 理解需求需求工程（Requirement

15、Engineering, RE)是指致力于不斷理解需求的大量任務(wù)和技術(shù)。需求工程在設(shè)計和構(gòu)造之間建立起聯(lián)系的橋梁。為什么需求工程特別困難？客戶說不清楚需求；需求自身不斷變動；分析人員或客戶理解有誤需求分析的三個層次業(yè)務(wù)需求、用戶需求、功能需求也包括非功能需求業(yè)務(wù)需求:反映了組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求。用戶需求: 文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)。功能需求:定義了開發(fā)人員必須實現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求。 需求工程中的七個活動起始；導(dǎo)出；精化；協(xié)商；規(guī)格說明；確認；管理1. 起始：軟件工程是詢問一些似乎與項目無直接關(guān)系的問題泛談起始，有各種各

16、樣的情況目的是對問題、方案需求方、期望方案的本質(zhì)、客戶和開發(fā)人員之間初步的交流和合作的效果建立基本的諒解2. 導(dǎo)出詢問客戶、用戶和其他人，系統(tǒng)或產(chǎn)品的目標(biāo)是什么？想要實現(xiàn)什么？系統(tǒng)和產(chǎn)品任何滿足業(yè)務(wù)的要求，最終系統(tǒng)和產(chǎn)品如何用于日常工作？非常困難：范圍問題、理解問題、異變問題3. 精化將起始和導(dǎo)出階段獲得的信息進行擴展和提煉是一個分析建模動作精化的最終結(jié)果：一個分析模型，定義了問題的信息域、功能域和行為域4. 協(xié)商需求工程師必須通過協(xié)商的過程調(diào)節(jié)各種沖突按優(yōu)先級討論沖突識別和分析風(fēng)險粗略“估算”開發(fā)工作量，并評估每項需求對項目成本和交付時間的影響使用迭代，刪除、細化或修改需求，以便各方達到一定

17、的滿意度5. 規(guī)格說明(specification)把前面的成果用文字或其它方式明示出來?？梢允且环輰懞玫奈臋n，一套圖形化的模型，一個形式化的數(shù)學(xué)模型，一組使用場景，一個原型或上述各項的任意組合6. 確認：要檢查規(guī)格說明以保證：所有的系統(tǒng)需求已被無歧義地說明；不一致性、疏漏和錯誤已被檢測出并被糾正；工作產(chǎn)品符合為過程、項目和產(chǎn)品建立的標(biāo)準。由第三方（通常為評審組）完成7. 需求管理用于幫助項目組在項目進展中標(biāo)識、控制和跟蹤需求以及變更需求的一組活動。解決方法：特征跟蹤表、來源跟蹤表、依賴跟蹤表、子系統(tǒng)跟蹤表、接口跟蹤表等。導(dǎo)出需求有哪些方法訪談；面向數(shù)據(jù)流自頂向下求精；協(xié)同需求獲??；快速建立軟

18、件原型；質(zhì)量功能部署；用戶場景（用例）質(zhì)量功能部署（Quality Function Development, QFD）QFD對需求的分類：常規(guī)需求：也稱普通需求，包含客戶對項目的最基本需求，是客戶對整個項目最為關(guān)心的部分。 期望需求：客戶可能沒有表達明確或沒有明確提出的需求，但是會讓客戶提升對項目的滿意度。 意外需求：也稱興奮需求，如果實現(xiàn)會給客戶帶來驚喜，但是如果無法實現(xiàn)也不會受到客戶責(zé)備。第五章 需求建模 場景 信息與類分析需求分析產(chǎn)生軟件操作特征的規(guī)格說明，指明軟件和其他系統(tǒng)元素的接口，建立軟件必須滿足的約束。分析時回答“做什么”，設(shè)計時回答“怎么做”。掌握分析建模的方法都有哪些結(jié)構(gòu)化

19、分析：著重考慮數(shù)據(jù)和處理。面向?qū)ο蠓治觯簩Ω鞣N對象加以研究，包括其對應(yīng)的數(shù)據(jù)和處理。關(guān)注于定義類和影響客戶需求的類之間的協(xié)作方式能夠根據(jù)要求繪制：實體-聯(lián)系圖（Entity-Relationship Approach, ERD）；數(shù)據(jù)流圖；概念類圖；狀態(tài)圖；用例圖；活動圖熟悉基本加工邏輯說明的三種方法：結(jié)構(gòu)化英語（PDL）； 判定表； 判定樹第六章 設(shè)計工程理解設(shè)計和需求的目標(biāo)有什么不同軟件需求：解決“做什么”軟件設(shè)計：解決“怎么做”理解設(shè)計的軟件設(shè)計的目標(biāo)和任務(wù)軟件設(shè)計的任務(wù)：問題結(jié)構(gòu)(軟件需求)-à映射 軟件結(jié)構(gòu)從軟件需求規(guī)格說明書出發(fā)，形成軟件的具體設(shè)計方案。根據(jù)用信息域表示的

20、軟件需求，以及功能和性能需求，進行：數(shù)據(jù)設(shè)計、系統(tǒng)結(jié)構(gòu)設(shè)計、過程設(shè)計數(shù)據(jù)設(shè)計側(cè)重于數(shù)據(jù)結(jié)構(gòu)的定義。系統(tǒng)結(jié)構(gòu)設(shè)計定義軟件系統(tǒng)各主要成份之間的關(guān)系。過程設(shè)計/構(gòu)件設(shè)計則是把結(jié)構(gòu)成份轉(zhuǎn)換成軟件的過程性描述。在編碼步驟，根據(jù)這種過程性描述，生成源程序代碼，然后通過測試最終得到完整有效的軟件。接口設(shè)計軟件設(shè)計是后續(xù)開發(fā)步驟及軟件維護工作的基礎(chǔ)。如果沒有設(shè)計，只能建立一個不穩(wěn)定的系統(tǒng)結(jié)構(gòu)。從工程管理的角度來看，軟件設(shè)計分兩步完成：概要設(shè)計（總體設(shè)計）：將軟件需求轉(zhuǎn)化為數(shù)據(jù)結(jié)構(gòu)和軟件的系統(tǒng)結(jié)構(gòu)。詳細設(shè)計（過程設(shè)計，模塊設(shè)計）：通過對結(jié)構(gòu)表示進行細化，得到軟件的詳細的數(shù)據(jù)結(jié)構(gòu)和算法。了解設(shè)計概念抽象 數(shù)據(jù)抽象

21、：具有明確和有限功能的指令序列，如“開”門過程抽象：描述數(shù)據(jù)對象的冠名數(shù)據(jù)集合，如“門”體系結(jié)構(gòu) 軟件的整體結(jié)構(gòu)和這種結(jié)構(gòu)為系統(tǒng)提供概念上的完整性的方式程序各功能模塊的編排順序、作用方式、具體的數(shù)據(jù)結(jié)構(gòu)?？梢杂枚喾N模型來完成一個體系結(jié)構(gòu)設(shè)計。模式 設(shè)計模式描述了在某個特定場景與可能影響模式應(yīng)用和使用方式的“影響力”中解決某個特定的設(shè)計問題的設(shè)計結(jié)構(gòu)。關(guān)注點分離 任何復(fù)雜問題如果被分解為可以獨立解決和（或）優(yōu)化的若干塊，該復(fù)雜問題能夠更容易被處理。一個關(guān)注點是一個特征或行為，被指定為軟件需求模型的一部分。模塊化 軟件被劃分為可以獨立命名的、可尋址的構(gòu)件，有時被稱為模塊兩個問題綜合時的理解復(fù)雜度通

22、常要大于每個問題各自的理解復(fù)雜度之和“分而治之”，將一個策略問題分解成可以管理的若干塊，這樣更容易解決問題。信息隱蔽 每個模塊對其他所有模塊都隱蔽自己的設(shè)計策略隱蔽意味著通過定義一系列獨立的模塊可以得到有效的模塊化，模塊間只交流必須信息，為修改提供很大的益處功能獨立 模塊化、抽象概念和信息隱蔽的直接結(jié)果通過開發(fā)具有“專一”功能和“避免”與其他模塊過多交互的模塊具有獨立模塊的功能更易開發(fā)了解內(nèi)聚和耦合的不同種類模塊的獨立程度可以由兩個定性標(biāo)準來度量：內(nèi)聚模塊之間的互相連接的緊密程度的度量耦合模塊功能強度(一個模塊內(nèi)部各個元素彼此結(jié)合的緊密程度)的度量非直接耦合：兩個模塊之間沒有直接關(guān)系，它們之間

23、的聯(lián)系完全是通過主模塊的控制和調(diào)用來實現(xiàn)的。獨立性最強。數(shù)據(jù)耦合：一個模塊訪問另一個模塊時，彼此之間是通過簡單數(shù)據(jù)參數(shù) (不是控制參數(shù)、公共數(shù)據(jù)結(jié)構(gòu)或外部變量)來交換輸入、輸出信息的。標(biāo)記耦合：一組模塊通過參數(shù)表傳遞記錄信息，就是標(biāo)記耦合。這個記錄是某一數(shù)據(jù)結(jié)構(gòu)的子結(jié)構(gòu)，而不是簡單變量。控制耦合：如果一個模塊通過傳送開關(guān)、標(biāo)志、名字等控制信息，明顯地控制選擇另一模塊的功能，就是控制耦合。外部耦合：一組模塊都訪問同一全局簡單變量而不是同一全局數(shù)據(jù)結(jié)構(gòu)，而且不是通過參數(shù)表傳遞該全局變量的信息，則稱之為外部耦合。公共耦合：若一組模塊都訪問同一個公共數(shù)據(jù)環(huán)境，則它們之間的耦合就稱為公共耦合。公共的數(shù)據(jù)

24、環(huán)境可以是全局數(shù)據(jù)結(jié)構(gòu)、共享的。內(nèi)容耦合：如果發(fā)生下列情形，兩個模塊之間就發(fā)生了內(nèi)容耦合： 一個模塊直接訪問另一個模塊的內(nèi)部數(shù)據(jù);一個模塊不通過正常入口轉(zhuǎn)到另一模塊內(nèi)部;兩個模塊有一部分程序代碼重迭(只可能出現(xiàn)在匯編語言中);一個模塊有多個入口。原則盡量使用數(shù)據(jù)耦合，少用控制耦合，限制公共耦合的范圍，完全不用內(nèi)容耦合。第七章 進行體系結(jié)構(gòu)設(shè)計理解什么階段要做體系結(jié)構(gòu)設(shè)計體系結(jié)構(gòu)設(shè)計需要做的事情：為你提供整體的視圖并保證得到正確的理解。軟件體系結(jié)構(gòu)定義一：描述一個計算機軟件的各個功能模塊內(nèi)部關(guān)系以及不同模塊之間的關(guān)系的構(gòu)造圖（可以是文字的描述，也可以是圖表的描述），類似于硬件設(shè)計中的原理框圖，它

25、是軟件流程圖的上層抽象。軟件體系結(jié)構(gòu)定義二：一個程序和計算機系統(tǒng)軟件體系結(jié)構(gòu)是指系統(tǒng)的一個或者多個結(jié)構(gòu)。結(jié)構(gòu)中包括軟件的構(gòu)件，構(gòu)件的外部可見屬性以及他們之間的關(guān)系。是一定程度上的抽象，非可運行的軟件。憑借體系結(jié)構(gòu)圖，軟件開發(fā)人員可以：分析設(shè)計能否完全滿足需求為設(shè)計中某些方面的變更提供指導(dǎo)降低由于軟件構(gòu)造不合理帶來的風(fēng)險掌握體系結(jié)構(gòu)風(fēng)格的分類及各類的主要特點體系結(jié)構(gòu)風(fēng)格：對完成同一種或同一類工作，不同的設(shè)計人員在體系結(jié)構(gòu)設(shè)計的方式各不一樣，這種方式的一定程度上的抽象。體系結(jié)構(gòu)模式：就是風(fēng)格的具體體現(xiàn)，或者體系結(jié)構(gòu)設(shè)計的一個框架。定義了處理系統(tǒng)某些行為特征的方法。1、以數(shù)據(jù)為中心的體系結(jié)構(gòu)數(shù)據(jù)存儲

26、駐留在這種體系結(jié)構(gòu)的中心，其他構(gòu)件經(jīng)常訪問（增刪改查）數(shù)據(jù)存儲提高了可集成性，便于現(xiàn)有構(gòu)件修改和新構(gòu)件加入2、數(shù)據(jù)流體系結(jié)構(gòu)數(shù)據(jù)服從輸入變換-輸出的簡單流程。管道和過濾器結(jié)構(gòu)擁有一組被稱為過濾器的構(gòu)件，每個構(gòu)件獨立于上游和下游而工作。兩種典型的數(shù)據(jù)流風(fēng)格：管道-過濾器（Pipe-And-Filter）批處理（Batch Sequential)3、調(diào)用和返回體系結(jié)構(gòu)主程序/子程序體系結(jié)構(gòu)：主程序調(diào)用一組程序構(gòu)件，這組程序構(gòu)件又去調(diào)用其程序構(gòu)件遠程過程調(diào)用體系結(jié)構(gòu)：主程序/子程序的構(gòu)件分布在多個計算機上。4、面向?qū)ο篌w系結(jié)構(gòu)封裝了數(shù)據(jù)和必須應(yīng)用到該數(shù)據(jù)上的操作，構(gòu)件間通過信息傳遞進行通信和合作。5

27、、層次體系結(jié)構(gòu)各模塊實現(xiàn)功能的層次不一樣掌握映射數(shù)據(jù)流到“調(diào)用和返回”體系結(jié)構(gòu)的方法第八章 構(gòu)件級設(shè)計建模理解什么是構(gòu)件通俗地講，構(gòu)件是一段程序，該程序能完成一個相對獨立的功能，并有一定的通用性。正式定義：系統(tǒng)中某一定型化的、可配置的和可替換的部件，該部件封裝并暴露一系列接口。針對不同的系統(tǒng)設(shè)計體系，構(gòu)件所指的對象不一樣。了解構(gòu)件設(shè)計的基本原則開關(guān)原則（The Open-Closed Principle ,OCP）模塊應(yīng)該對外延有開放性，對修改具有封閉性。即設(shè)計者應(yīng)該采用一種無需對構(gòu)件自身內(nèi)部（代碼或者內(nèi)部邏輯）做修改就可以進行擴展（在構(gòu)件所確定的功能域內(nèi)）的方式來說明構(gòu)件。Liskov替換原

28、則（Liskov Subsitution Principle, LSP）子類可以替換它們的基類源自基類的任何子類必須遵守基類與使用該基類的構(gòu)件之間的隱含約定（前置條件、后置條件）。依賴倒置原則（Dependency inversion principle, DIP）依賴于抽象，而非具體實現(xiàn)構(gòu)件依賴的其它構(gòu)件（不是依賴抽象類，如接口）愈多，擴展起來就愈困難抽象可以比較容易地對設(shè)計進行擴展接口分離原則(Interface Segregation principle, ISP)多個用戶專用接口比一個通用接口要好設(shè)計者應(yīng)該為每一個主要的客戶類型都設(shè)計一個特定的接口。如SafeHome中FloorPla

29、n類用于安全和監(jiān)督功能，兩處操作有些不同，監(jiān)督功能多關(guān)于攝像頭的操作，定義兩個接口。將多個構(gòu)件組織起來的原則：發(fā)布復(fù)用等價性原則-對類打包管理，同時升級。共同封裝原則-一同變更的類應(yīng)該和在一起。共同復(fù)用原則-可能一起被復(fù)用的類才能打包到一塊。理解構(gòu)件設(shè)計中要完成的任務(wù)1-7步一個典型的構(gòu)件級設(shè)計步驟：1. 標(biāo)識出所有與問題域相對應(yīng)的類2. 確定所有與基礎(chǔ)設(shè)施域相對應(yīng)的類GUI構(gòu)件、操作系統(tǒng)構(gòu)件、對象和數(shù)據(jù)管理構(gòu)件3. 細化所有不能作為復(fù)用構(gòu)件的類（1）說明消息的細節(jié)流（2）為每個構(gòu)件確定適當(dāng)?shù)慕涌冢?）細化屬性并定義數(shù)據(jù)類型和結(jié)構(gòu)（4）描述每個操作中的處理4. 說明持久數(shù)據(jù)源（數(shù)據(jù)庫或文件）等

30、相關(guān)類5. 開發(fā)并細化類的行為表示6. 細化部署圖表示主要構(gòu)件包的位置某些情況下，部署圖在這個時候被細化為實例形式7. 反省和檢查現(xiàn)有的設(shè)計掌握傳統(tǒng)構(gòu)件設(shè)計的方法：會畫程序流程圖、盒圖(N-S圖)、PAD圖第九章 完成用戶界面設(shè)計掌握人機界面設(shè)計的黃金規(guī)則MandelMAN97定義了三條“黃金規(guī)則”：置于用戶的控制之下減少用戶的記憶負擔(dān)保持界面一致理解人機界面設(shè)計中要理解哪些元素？了解通過界面和系統(tǒng)交互的人了解最終用戶為完成工作要做的任務(wù)作為界面的一部分而顯示的內(nèi)容任務(wù)處理的環(huán)境了解一些界面設(shè)計模式完整用戶界面。為高層結(jié)構(gòu)和導(dǎo)航提供設(shè)計指導(dǎo)模式：高層導(dǎo)航 簡要描述：提供高層菜單，通常帶有一個圖

31、像，能夠直接掉轉(zhuǎn)到任一個系統(tǒng)主要功能。頁面布局。負責(zé)頁面概括組織（用于站點）或者清楚的屏幕顯示（用于需要進行交互的應(yīng)用系統(tǒng)）模式：層疊 簡要描述：呈現(xiàn)層疊狀的標(biāo)簽卡，伴隨著鼠標(biāo)每一下點擊的選擇，顯示指定的子功能或者分類內(nèi)容。表格和輸入。考慮了完成表格級輸入的各種設(shè)計方法。模式：填充空格 簡要描述：允許在“文本框”中填寫文字與數(shù)字數(shù)據(jù)。表。為創(chuàng)建和操作各種列表數(shù)據(jù)提供設(shè)計指導(dǎo)。模式：有序表 簡要描述：用來顯示長記錄列表，可以在任何一列上選擇排序機制進行排序。直接數(shù)據(jù)操作。解決數(shù)據(jù)編輯、數(shù)據(jù)修改和數(shù)據(jù)轉(zhuǎn)換問題。模式：現(xiàn)場編輯 簡要描述：為顯示位置上的特定類型內(nèi)容提供簡單的文本編輯能力。導(dǎo)航。輔助用

32、戶在層級菜單、Web頁面和交互顯示屏幕上航行。模式：面包屑 簡要描述：當(dāng)用戶工作于復(fù)雜層次結(jié)構(gòu)的頁面或者屏幕顯示時，提供完全的導(dǎo)航路徑。搜索。對于網(wǎng)站上的信息或保存在可以通過交互應(yīng)用訪問的持久存儲中的數(shù)據(jù)，能夠進行特定內(nèi)容的搜索。模式：簡單搜索 簡要描述：提供在網(wǎng)站或者持久數(shù)據(jù)源中搜索由字符串描述的簡單數(shù)據(jù)項的能力。頁面元素。實現(xiàn)Web頁面或者顯示屏的特定元素模式：向?qū)?簡要描述：通過一系列的簡單窗口顯示來指導(dǎo)完成任務(wù)，使得用戶能夠一次一步地完成某個復(fù)雜的任務(wù)。電子商務(wù)。主要針對于站點，這些模式實現(xiàn)了電子商務(wù)應(yīng)用中的重現(xiàn)元素。模式：購物車 簡要描述：提供一個要購買的項目清單。其它。模式不能簡單

33、地歸類到前面所述的任一類中，在某些情況下，這些模式具有領(lǐng)域的依賴性或者只對特定類別的用戶適用。模式：進展指示器 簡要描述：為某一正在進行的操作提供進展指示。第十章質(zhì)量概念什么是軟件質(zhì)量軟件質(zhì)量是對明確陳述的功能和性能需求、明確記錄的開發(fā)標(biāo)準以及對所有專業(yè)化軟件開發(fā)應(yīng)具備的隱含特征的符合度。第十一章 軟件測試策略理解軟件測試的步驟軟件測試策略測試策略應(yīng)具備的特征：在測試前應(yīng)經(jīng)過認真的技術(shù)評審，將明顯的錯誤消于無形。測試開始于構(gòu)件不同的測試技術(shù)適用于不同的時間點測試由軟件開發(fā)人員和獨立的測試組執(zhí)行測試不同于調(diào)試，它包括調(diào)試單元測試：目標(biāo)；側(cè)重點內(nèi)容：根據(jù)詳細設(shè)計說明書、程序清單，采用白盒、黑盒測試

34、的測試用例，對模塊進行檢查，主要包括以下五部分：(1) 模塊接口測試(2) 局部數(shù)據(jù)結(jié)構(gòu)測試(3) 路徑測試(4) 錯誤處理測試(5) 邊界測試所測試單元不是獨立的程序，它可能和其它部分交互信息，在測試時，應(yīng)模擬這些數(shù)據(jù)或信息（驅(qū)動軟件和樁軟件）集成測試：目標(biāo)；各種集成方法及優(yōu)缺點又稱組裝測試，聯(lián)合測試將所有模塊按設(shè)計要求組裝成系統(tǒng)1. 一次到位：又稱為非增式組裝，一次性組裝或大爆炸集成，這種集成將所有單元在一起編譯并進行一次性測試。缺點：一次成功的可能性不大；當(dāng)發(fā)現(xiàn)缺陷時，沒有多少線索能夠用來幫助確定缺陷位置。2. 增式組裝：逐步組裝成較大的系統(tǒng)，邊組裝邊測試自頂向下的增殖方式；自底向上的增

35、殖方式；混合增殖方式確認測試：目標(biāo)；測試和測試在傳統(tǒng)軟件和面向?qū)ο筌浖g沒有明顯差別。始于集成測試的結(jié)束驗證軟件的功能和性能及其它特性是否與用戶要求一致系統(tǒng)測試：目標(biāo)面向?qū)ο蟮臏y試策略的不同點步驟：進行有效性測試（黑盒測試）1、制定測試計劃、測試步驟，設(shè)計測試用例2、確定所有的功能、性能均滿足要求3、軟件配置復(fù)查4、測試和測試5、驗收測試：由用戶用實際數(shù)據(jù)進行測試。考慮軟件的功能、性能、可移植性、兼容性、可維護性測試：由一個用戶在受控環(huán)境下進行的測試。最終用戶在開發(fā)者的場所進行。目的是評價軟件產(chǎn)品的FLURPS（功能、局域化、可使用性、可靠性、性能、支持），產(chǎn)品的界面和特色測試：由多個用戶在實

36、際使用環(huán)境下的測試。用戶定期向開發(fā)者報告軟件運行的問題。主要衡量產(chǎn)品的FLURPS第十二章 測試戰(zhàn)術(shù)測試技術(shù)分類黑盒測試/白盒測試從要不要看代碼部分來區(qū)分動態(tài)測試/靜態(tài)測試從要不要運行軟件來區(qū)分掌握白盒測試的主要方法，并能根據(jù)要求設(shè)計測試用例主要：條件組合測試、基本路徑測試區(qū)域數(shù)=邊-點+2掌握黑盒測試的主要方法，并能根據(jù)要求設(shè)計測試用例：主要：等價類劃分、邊界值、錯誤推測法理解面向?qū)ο蟮睦^承相關(guān)的測試、隨機測試和類間測試第十三章 評審技術(shù)什么是軟件評審軟件評審是指在軟件開發(fā)過程中，由參與評審的人員對軟件開發(fā)文檔或代碼進行評審或檢查，幫助查找缺陷和改進。軟件評審的目標(biāo)和優(yōu)點目標(biāo)：在軟件過程中發(fā)

37、現(xiàn)錯誤，以使他們不會在軟件交付之后變成缺陷。優(yōu)點：可以早些發(fā)現(xiàn)錯誤，以防止將錯誤傳遞到軟件過程的后續(xù)階段。軟件評審與測試的區(qū)別1）表現(xiàn)形式測試的表現(xiàn)形式有：單元測試、集成測試、系統(tǒng)測試、用戶驗收測試 評審的表現(xiàn)形式有：審查、小組評審、走查、結(jié)對編程、同級桌查、輪查、臨時評審 2）工作對象測試的工作對象為：可執(zhí)行系統(tǒng)（指編譯后可運行的程序）評審的工作對象為：需求規(guī)格說明書、架構(gòu)（概要）設(shè)計文檔、詳細設(shè)計文檔、項目計劃、項目過程文檔、源代碼、系統(tǒng)界面、測試計劃、測試用例和數(shù)據(jù)、用戶手冊 3）識別缺陷的階段測試識別缺陷的階段：測試階段（編碼完成后）評審識別缺陷的階段：需求階段、設(shè)計階段、編碼階段、測

38、試階段 4）識別缺陷的成效測試的成效：最多識別軟件所有缺陷中30-35%的缺陷 評審的成效：最多識別軟件所有缺陷中70-75%的缺陷 5）識別缺陷的成本測試的成本：識別一個重要缺陷平均花費15-25小時 評審的成本：需求階段識別一個重要缺陷平均花費2-3小時；設(shè)計階段識別一個重要缺陷平均花費3-4小時；代碼評審階段識別一個重要缺陷3-5小時；測試計劃評審識別一個重要缺陷3-5小時 6）解決缺陷的成本 測試的成本：消除一個重要缺陷平均花費30-80小時（包括識別缺陷時間）在開發(fā)后期才能識別缺陷，成本較高 評審的成本：需求及設(shè)計階段消除一個重要缺陷5-10小時；代碼評審階段消除一個重要缺陷5-15

39、小時更傾向于在開發(fā)前期識別缺陷，成本較低7）投入回報比較 某研究表明，客戶使用過程中發(fā)現(xiàn)、糾正與需求相關(guān)的缺陷的費用是比需求開發(fā)階段發(fā)現(xiàn)和糾正同樣缺陷的費用的68110倍(Boehm 1981;Grady 1999)。即 68110 : 1第十四章 項目管理理解項目管理涉及的范圍人員、產(chǎn)品、過程、項目了解W5HH原則檢查點(Check Point): 指在規(guī)定的時間間隔內(nèi)對項目進行的檢查與復(fù)審工作，通過比較實際進展與計劃進度的差距，并根據(jù)差距進行調(diào)整。里程碑(Mile Stone): 完成階段性工作的標(biāo)志，往往是一些重要活動的完工，或重要文檔的交付，或階段評審的通過?；€(Base Line)

40、: 指一個（或一組）配置項在項目生命期的不同時間點上通過正式評審而進入正式受控的一種狀態(tài)?；€其實是一些重要的里程碑。基線一旦建立后，以后的任何更改都需要受到控制。第十五章 過程和項目度量理解項目度量的概念和項目度量的步驟項目度量使軟件項目管理者能夠：評估正在進行的項目的狀態(tài)；跟蹤潛在的風(fēng)險；在問題造成不良影響之前發(fā)現(xiàn)他們；調(diào)整工作流程或任務(wù)；評估項目團隊控制軟件工作產(chǎn)品質(zhì)量的能力。項目度量的目的是雙重的：首先，這些度量能夠指導(dǎo)進行一些必要的調(diào)整以避免延遲，并減少潛在問題及風(fēng)險，從而使得開發(fā)時間減到最少；其次，項目度量可在項目進行的基礎(chǔ)上評估產(chǎn)品質(zhì)量，并且可在必要時修改技術(shù)方法以改進質(zhì)量。項目度量的步驟：建立歷史數(shù)據(jù)基線；對工作量等的估算；將實際工作量等的測量與估算值比較，以控制項目的進度；收集技術(shù)度量、評價設(shè)計質(zhì)量、測試等的方法。記錄和跟蹤所發(fā)現(xiàn)的錯誤；補充歷史數(shù)據(jù)基線。掌握項目度量方法有哪些；掌握面向功能的度量和面向規(guī)模的度量面向功能度量用一種稱為“功能點”(Function Point, FP)的測量。使用軟件所提供的功能的測量作為規(guī)范化值。因為“功能”不能直接測量，所以必須通過其他直接的測量來導(dǎo)出。功能點是基于軟件信息領(lǐng)域的可計算的(直接的)測量及軟件復(fù)雜性的評估而導(dǎo)出的。掌握功能點的計算方法Lorenz和Kidd提出了下列用于OO項目的場景： 場景腳