軟件工程 總結(jié)

1、軟件工程復(fù)習(xí)提綱第1章軟件工程介紹2軟件是什么2第2章過程綜述2軟件工程定義2層次化3通用過程框架3第3章 過程模型4各種過程模型4第4章 敏捷視角下的過程6敏捷宣言6第5章 系統(tǒng)工程7第6章 需求工程8質(zhì)量功能部署（QFD）8分析模型的元素11第7章 構(gòu)建分析模型11第8章 設(shè)計(jì)工程11第9章 進(jìn)行體系結(jié)構(gòu)設(shè)計(jì)12體系結(jié)構(gòu)風(fēng)格的分類12第10章 構(gòu)件級(jí)設(shè)計(jì)建模13第11章 完成用戶界面設(shè)計(jì)13黃金規(guī)則13第12章 軟件測試策略14軟件測試需要計(jì)劃和執(zhí)行一系列的測試步驟14第13章 測試技術(shù)15兩個(gè)不同的測試用例設(shè)計(jì)技術(shù)15第14章 產(chǎn)品度量15第1章軟件工程介紹軟件是什么軟件是形成配置的一組

2、術(shù)語或?qū)ο?，包括：程?計(jì)算機(jī)程序): 指令的集合,通過執(zhí)行這些指令可以滿足預(yù)期的特征、功能和性能需求數(shù)據(jù)結(jié)構(gòu):它使得程序可以充分利用信息文檔:描述程序操作和使用的文檔（圖文資料）1. 舉例說明“意外效應(yīng)法則”（law of unintended consequences）在計(jì)算機(jī)軟件方面的應(yīng)用。某些新科技的發(fā)明創(chuàng)造會(huì)給其他一些看似無關(guān)的技術(shù)領(lǐng)域、商業(yè)企業(yè)、公眾甚至整個(gè)社會(huì)文化帶來深遠(yuǎn)而出人意料的影響和作用。如：2. 用自己的語言描述保證通曉規(guī)律（ The Law of Conservation of Familiarity）、質(zhì)量衰減規(guī)律（ The Law of Declining Qual

3、ity ）以及組織穩(wěn)定性守恒規(guī)律（ The Law of Conservation of Organizational Stability ）。保證通曉性規(guī)律 (1980): 隨著E類型系統(tǒng)的演化，所有相關(guān)人員（如開發(fā)人員、銷售人員和用戶）都必須清楚地了解演化的內(nèi)容和過程，以便達(dá)到滿意的演化效果。 質(zhì)量衰減規(guī)律 (1996): 如果沒有嚴(yán)格的維護(hù)和適應(yīng)性調(diào)整使之適應(yīng)運(yùn)行環(huán)境的變化，E類型系統(tǒng)的質(zhì)量有衰減的趨勢。組織穩(wěn)定性守恒規(guī)律 (1980): 一個(gè)不斷演化的E類型系統(tǒng)，其組織在全球范圍內(nèi)的平均有效活動(dòng)率在產(chǎn)品的生命周期中是保持不變的。3. 在交付最終用戶之前，或者第1個(gè)版本投入使用之后，許多

4、應(yīng)用程序都會(huì)有頻繁的變更。為防止變更引起軟件失效，請(qǐng)?zhí)岢鲆恍┯行У慕鉀Q措施。首先從心態(tài)上承認(rèn)變化是必然的，我們可以通過在軟件發(fā)布之前進(jìn)行alpha , beta 測試，利用迭代模式，在吸取測試過程中的經(jīng)驗(yàn)之后，立刻改進(jìn)軟件。同時(shí)保持和用戶的良好溝通，在提交用戶時(shí)進(jìn)行適當(dāng)培訓(xùn)，讓用戶按照開發(fā)思路進(jìn)行試用，可以見減少因使用方法不當(dāng)引起的變化。第2章過程綜述軟件工程定義軟件工程是：（1）將系統(tǒng)化、規(guī)范的、可量化的方法應(yīng)用于軟件的開發(fā)、運(yùn)行和維護(hù)，即將工程化方法應(yīng)用于軟件。（2）在（1）中所述的方法的研究。層次化通用過程框架1. 溝通（Communication）2. 策劃（Planning）3. 建

5、模（Modeling）a) 需求分析（Analysis of requirements）b) 設(shè)計(jì)（Design）4. 構(gòu)建（Construction）a) 代碼生成（Code generation）b) 測試（Testing）5. 部署（Deployment）重點(diǎn)：1. Baetjer說過“軟件過程為用戶和設(shè)計(jì)者之間、用戶和開發(fā)工具之間以及設(shè)計(jì)者和開發(fā)工具之間提供交互的途徑技術(shù)?！痹O(shè)計(jì)下面問題“ 設(shè)計(jì)者應(yīng)該問用戶的； 用戶應(yīng)該問設(shè)計(jì)者的； 用戶對(duì)將要構(gòu)建的軟件的自問； 設(shè)計(jì)者對(duì)于軟件產(chǎn)品和建造該產(chǎn)品采取的軟件過程的自問。（如何獲取需求）2. 為溝通活動(dòng)設(shè)計(jì)一個(gè)任務(wù)集1. 識(shí)別主要客戶和其他共

6、利益者2. 與客戶會(huì)談環(huán)境無關(guān)的話題3. 寫一頁項(xiàng)目范圍4. 評(píng)審范圍說明5. 討論項(xiàng)目大致的階段6. 商定各個(gè)部門的代表，并使他們相互認(rèn)識(shí)7. 為計(jì)劃活動(dòng)做準(zhǔn)備3. 用自己的話描述過程框架。當(dāng)我們談到框架活動(dòng)適用于所有的項(xiàng)目時(shí)，是否意味著對(duì)于不同規(guī)模和復(fù)雜度的項(xiàng)目，可應(yīng)用相同的工作任務(wù)？請(qǐng)解釋。過程框架定義了若干小的框架活動(dòng)，為完整的軟件開發(fā)過程建立的基礎(chǔ)，這些框架活動(dòng)可以廣泛用于所有的軟件開發(fā)項(xiàng)目，無論這些項(xiàng)目的復(fù)雜性和規(guī)模如何，此外，還包括一些適用于各個(gè)軟件過程的普適性活動(dòng)。雖然過程框架是普適性的，但是對(duì)于不同規(guī)模和復(fù)雜度的項(xiàng)目不能應(yīng)用相同的工作任務(wù)。首先在軟件開發(fā)的不同階段，工作任務(wù)不

7、同。其次不同的軟件項(xiàng)目有不同的需求，有特殊的背景，找不到一種通用的工作任務(wù)。4. 圖2-1中，基于“質(zhì)量關(guān)注點(diǎn)”指明了軟件工程三個(gè)層次。這意味著在整個(gè)開發(fā)組織內(nèi)采用質(zhì)量管理活動(dòng)，如“全面質(zhì)量管理”。仔細(xì)研究，并列出全面質(zhì)量管理活動(dòng)中關(guān)鍵原則的大綱。第3章 過程模型各種過程模型慣例軟件過程模型力圖給軟件開發(fā)帶來秩序和結(jié)構(gòu)。盡管每一傳統(tǒng)過程模型都建議了一種不同的過程流，但均實(shí)現(xiàn)了同樣的一組通用框架活動(dòng)：溝通、計(jì)劃、建模、構(gòu)建和部署。瀑布模型建議線性流程的框架活動(dòng)，與軟件世界里當(dāng)代軟件開發(fā)實(shí)際（持續(xù)的變更、演化的系統(tǒng)、緊迫的開發(fā)時(shí)間）不符；但瀑布模型確實(shí)適用于需求定義清楚且穩(wěn)定的軟件開發(fā)；增量軟件過

8、程模型通過一系列的增量發(fā)布產(chǎn)生軟件。RAD模型快速應(yīng)用程序開發(fā)，是為大型且必須在嚴(yán)格的時(shí)間內(nèi)提交的項(xiàng)目而設(shè)計(jì)的；演化過程模型認(rèn)識(shí)到大多數(shù)軟件工程項(xiàng)目的迭代特性，其設(shè)計(jì)的目的是為了適應(yīng)變更演化模型（如原型模型、螺旋模型），其快速產(chǎn)生增量的工作產(chǎn)品（或是軟件的工作版本），這些模型可以應(yīng)用于所有的軟件工程活動(dòng)從概念開發(fā)到長期的軟件維護(hù)?；跇?gòu)建的模型強(qiáng)調(diào)構(gòu)件復(fù)用及組裝。形式化方法模型提倡采用數(shù)學(xué)的方法進(jìn)行軟件開發(fā)和驗(yàn)證。面向方面的模型目的是解決跨整個(gè)軟件體系結(jié)構(gòu)的橫切關(guān)注點(diǎn)；統(tǒng)一過程模型是一種“用例驅(qū)動(dòng)、以體系結(jié)構(gòu)為核心、迭代及增量”的軟件過程框架，由UML方法和工具支持。統(tǒng)一過程是一種增量模型，定

9、義了五個(gè)階段：起始階段：包括用戶溝通和計(jì)劃活動(dòng)兩個(gè)方面，強(qiáng)調(diào)定義和細(xì)化用例，并將其作為主要模型；細(xì)化階段：包括用戶溝通和建?；顒?dòng)，重點(diǎn)是創(chuàng)建分析和設(shè)計(jì)模型，強(qiáng)調(diào)類的定義和體系結(jié)構(gòu)的表示；構(gòu)建階段：細(xì)化設(shè)計(jì)模型，并將設(shè)計(jì)模型轉(zhuǎn)化為軟件構(gòu)建實(shí)現(xiàn)；轉(zhuǎn)化階段：將軟件從開發(fā)人員傳遞給最終用戶，并由用戶完成Beta測試和驗(yàn)收測試；生產(chǎn)階段：持續(xù)地監(jiān)控軟件的運(yùn)行，并提供技術(shù)支持。重點(diǎn)：1. 開發(fā)質(zhì)量“足夠好”的軟件，其優(yōu)點(diǎn)和缺點(diǎn)是什么？當(dāng)我們追求開發(fā)速度勝過產(chǎn)品質(zhì)量的時(shí)候，會(huì)產(chǎn)生什么后果？我們總在質(zhì)量和開發(fā)速度之間做取舍，開發(fā)質(zhì)量“足夠好”的軟件，明顯強(qiáng)調(diào)質(zhì)量，優(yōu)點(diǎn)是使軟件符合或超出客戶的預(yù)期，在性能上，交

10、互上力圖做到盡善盡美。缺點(diǎn)是忽視了開發(fā)成本，很容易造成開發(fā)時(shí)間延期，影響軟件工程后幾個(gè)階段的工作，對(duì)全局造成不利影響。2. 當(dāng)沿著螺旋過程流發(fā)展的時(shí)候，你對(duì)正在開發(fā)或者維護(hù)的軟件的看法是什么？ 在螺旋模式下，開發(fā)過程是迭代式的，采用循環(huán)的方式逐步加深系統(tǒng)定義和實(shí)現(xiàn)的深度，同時(shí)降低風(fēng)險(xiǎn)。當(dāng)軟件交付使用后，螺旋模式?jīng)]有停止，它將永遠(yuǎn)保持可操作性，每一圈完成后都會(huì)計(jì)算成本，可以更好的維護(hù)軟件。3. 可以合用幾種過程模型嗎？如果可以，舉例說明?？梢浴追N過程模型，都是相互兼容可以相互擴(kuò)展的，如螺旋模型結(jié)合了原型的迭代性質(zhì)和瀑模型的系統(tǒng)性和可控性的特點(diǎn)。在具體項(xiàng)目實(shí)施中，對(duì)于某一部分可以合用幾種過程模型

11、，比如形式語言與自動(dòng)機(jī)演示軟件在算法開發(fā)過程，就需要使用形式化方法模型，用嚴(yán)格的數(shù)學(xué)符號(hào)定義形式語言和自動(dòng)機(jī)。還有一些桌面應(yīng)用程序的前臺(tái)UI部分，可以單獨(dú)使用RAD模型，比如用delphi語言開發(fā)桌面窗體就是一種RAD實(shí)現(xiàn)。而其他部分可以使用其他如瀑布式模型等方法。第4章 敏捷視角下的過程敏捷宣言l 個(gè)體和交互勝過過程和工具（Individuals and interactions over processes and tools ）l 可工作軟件勝過寬泛的文檔（Working software over comprehensive documentation） l 客戶合作勝過合同談判（Cu

12、stomer collaboration over contract negotiation）l 響應(yīng)變化勝過遵循計(jì)劃（Responding to change over following a plan ）重點(diǎn)：1. 是否每一個(gè)敏捷過程都可以用第2章所提及的通用框架性活動(dòng)來描述？建一張表，將通用活動(dòng)和每個(gè)敏捷過程所定義的活動(dòng)對(duì)應(yīng)起來。2. 用自己的語言描述（用于軟件項(xiàng)目的）敏捷性？普遍存在的變化是敏捷的基本動(dòng)力，敏捷需要有效的響應(yīng)變化，它鼓勵(lì)在共利益者之間進(jìn)行更便利的溝通和協(xié)作，強(qiáng)調(diào)可運(yùn)行軟件的快速交付。敏捷允許項(xiàng)目團(tuán)隊(duì)調(diào)整并合理安排任務(wù)，理解易變性并制定計(jì)劃。精簡并維持最基本的工作產(chǎn)品，強(qiáng)

13、調(diào)增量交付，快速提供可運(yùn)行軟件。3. 許多敏捷過程模型推薦面對(duì)面交流，實(shí)際上，現(xiàn)在軟件開發(fā)團(tuán)隊(duì)成員及其客戶在地理上是分散的。你是否認(rèn)為這意味著這種地理上的分散應(yīng)當(dāng)避免？能否想出一個(gè)辦法克服這個(gè)問題。我認(rèn)為這種地理上的分散是現(xiàn)實(shí)，是無法避免的。我認(rèn)為可以分為客戶和開發(fā)人員的分散，開發(fā)人員內(nèi)部分散兩種情況。對(duì)于第一種：產(chǎn)品經(jīng)理需要同客戶建立一條良好的通信信道，如通過email,即時(shí)聊天工具進(jìn)行定期溝通。對(duì)于第二種：開發(fā)人員需定期組織交流，通過web group 消除地理上的分散。4. 為什么需求變化這么大，人們終究無法確定他們想要什么嗎？ 我認(rèn)為是這樣的。其實(shí)需求是客戶對(duì)他們心目中軟件的一種描述，

14、因?yàn)檐浖€沒有實(shí)現(xiàn)，這種描述便是不確定的，模糊的。同時(shí)當(dāng)今世界處于高速變化之中，人們的需求會(huì)隨著環(huán)境的改變而改變。所以敏捷開發(fā)承認(rèn)變化，認(rèn)為普遍存在的變化是敏捷的基本動(dòng)力。第5章 系統(tǒng)工程在寫下每行代碼之前l(fā) 理解所要解決的問題(詳見溝通與建模)l 理解基本的設(shè)計(jì)原則和概念l 選擇一種能夠滿足軟件構(gòu)建以及運(yùn)行環(huán)境要求的編程語言l 選擇一種能提供工具以簡化工作的編程環(huán)境l 構(gòu)件級(jí)編碼完成后進(jìn)行單元測試系統(tǒng)工程層次圖重點(diǎn)：1. 對(duì)你熟悉的系統(tǒng)、產(chǎn)品或服務(wù)，建立它們的層次系統(tǒng)。層次應(yīng)該向下擴(kuò)展到簡單系統(tǒng)要素（硬件、軟件等），至少得到層次樹的一個(gè)分支。 即時(shí)聊天系統(tǒng)2. 系統(tǒng)工程師由3種來源：系統(tǒng)開發(fā)

15、人員、用戶或一些外部組織。討論一下每種來源的利與弊。描述一個(gè)理想的系統(tǒng)工程師。3. 研究文獻(xiàn)并寫出一篇簡短文章描述建模和模擬工具是如何工作的?；蛘呤鞘占瘍蓚€(gè)或更多的商用建?；蚰M工具的文獻(xiàn)，并且比較它們的相似處與不同處。第6章 需求工程質(zhì)量功能部署（QFD）是一種將客戶要求轉(zhuǎn)化成軟件技術(shù)需求的技術(shù)。QFD“目的是最大限度地讓客戶從軟件工程過程中感到滿意”，并強(qiáng)調(diào)“什么是對(duì)客戶有價(jià)值的”。確認(rèn)三類需求：l 正常需求：反映了在和客戶開會(huì)時(shí)確定的針對(duì)某產(chǎn)品或系統(tǒng)的目標(biāo)。如果實(shí)現(xiàn)了這些需求，將滿足客戶（例如：所要求的圖形顯示類型、特定的系統(tǒng)功能以及已定義的性能級(jí)別）。l 期望需求：隱含在產(chǎn)品或系統(tǒng)中，

16、并且可能是非?；A(chǔ)的以至于客戶沒有顯式地說明，但缺少這些將導(dǎo)致客戶明顯不滿（例如：易交互性、可操作性、可靠性、易安裝等）。l 令人興奮的需求：反映了客戶期望之外的特點(diǎn)，但如果實(shí)現(xiàn)了這些特點(diǎn)，將會(huì)使客戶非常滿意。重點(diǎn)：1. 為如下活動(dòng)之一開發(fā)一個(gè)完整的用例： 在ATM提款； 在餐廳使用信用卡付費(fèi)； 使用一個(gè)在線經(jīng)紀(jì)人賬戶購買股票； 使用在線書店搜索書（某個(gè)指定主題）；ATM用例圖“ATM取款”用例規(guī)約用例名稱：ATM取款簡述：客戶持銀行卡（本行或其他行）從ATM提取現(xiàn)金actors:客戶和銀行主機(jī)基本流：1. 客戶插入銀行卡。2. ATM從銀行卡讀入卡號(hào)（含銀行標(biāo)識(shí)和賬號(hào)），驗(yàn)證卡的有效性。3.

17、 客戶輸入密碼。4. ATM驗(yàn)證帳號(hào)和密碼。5. ATM顯示包括取款在內(nèi)的服務(wù)功能，客戶選擇“取款”。6. 輸入取款額：客戶輸入數(shù)量為50元的倍數(shù)的取款額。7. ATM向銀行主機(jī)通知卡號(hào)、密碼、賬號(hào)和取款額，獲得含有最新余額的取款成功確認(rèn)信息。8. ATM打印并吐出憑條。9. ATM清點(diǎn)并吐出現(xiàn)金，記錄取款成功。10. ATM詢問客戶是否繼續(xù)服務(wù)。11. 客戶選擇否，ATM吐出銀行卡，結(jié)束用例，否則回到步驟5。用例結(jié)束備選流：3-7，10a. 客戶取消服務(wù)：ATM記錄服務(wù)取消，打印憑條，吐出憑條和銀行卡，用例失敗3,6,11a. 客戶未及時(shí)輸入超過30秒：ATM吞卡，用例失敗2a. 卡無效：A

18、TM吞卡，用例失敗2b. 讀卡器或卡被損壞：ATM吞卡，用例失敗4a. 密碼錯(cuò)：4a1. 客戶重新輸入密碼a. 累計(jì)3次密碼錯(cuò)誤：ATM吞卡，用例失敗4b. 無此帳號(hào)：ATM吞卡，用例失敗5a. ATM無現(xiàn)金：ATM不顯示“取款”功能，客戶可選擇其他服務(wù)， 用例失敗6a. 取款額超過ATM現(xiàn)金余額：ATM要求客戶重新輸入取款額。7a. 帳戶余額不足：ATM要求客戶重新輸入取款額。7b. 取款額超過當(dāng)日最高限額：ATM要求客戶重新輸入取款額。7c. 網(wǎng)絡(luò)或銀行主機(jī)失效、通訊超時(shí)：ATM記錄服務(wù)取消，打印憑條，吐出憑條和銀行卡，用例失敗8a. 憑條打印失敗，紙用完或卡紙：8a1. ATM通知銀行主

19、機(jī)取消取款8a2. ATM記錄服務(wù)取消，吐出銀行卡，用例失敗9a. 吐現(xiàn)金失敗：9a1. ATM通知銀行主機(jī)取消取款9a2. ATM記錄服務(wù)取消，吐出銀行卡，用例失敗11a. 客戶未及時(shí)取走卡： ATM吞卡，用例失敗業(yè)務(wù)規(guī)則：7b 單日取款不得超過5000元6c 每次取款不得超過2000元2. 為什么大量的軟件開發(fā)人員沒有足夠重視需求工程？以前有沒有什么情況讓你可以跳過需求工程？首先軟件開發(fā)人員認(rèn)為客戶已經(jīng)把需求說清楚了，但是大多數(shù)情況初步的需求都是模糊的。其次工程的進(jìn)度要求很緊迫，軟件開發(fā)人員迫切希望投入到代碼編寫階段。最后和客戶溝通比較困難，使得大多數(shù)軟件開發(fā)人員不重視需求工程。又一次，項(xiàng)

20、目時(shí)間很短，要求一個(gè)月完成，我們只是大體上對(duì)需求有一個(gè)認(rèn)識(shí)，就跳過需求工程開始動(dòng)手編碼，結(jié)果當(dāng)然失敗了。3. 簡短地討論一個(gè)分析模型的每個(gè)元素，指出每個(gè)元素對(duì)模型的貢獻(xiàn)，每個(gè)元素為什么是唯一的以及每個(gè)元素所表示的概要信息。分析模型的元素基于場景的元素(用例圖)：使用基于場景的方法可以從用戶的視角描述系統(tǒng)。例如基本的用例和基于模板的用例。通常的分析模型的第一步，作為創(chuàng)建其他模型的輸入?；陬惖脑兀悎D）:每個(gè)使用場景都暗示著當(dāng)一個(gè)參與者與系統(tǒng)交互時(shí)所操做的一組對(duì)象，這些對(duì)象被分成類具有相似屬性和共同行為的事務(wù)集合。行為元素(狀態(tài)圖)：狀態(tài)指明了在某個(gè)特殊事件后采取什么動(dòng)作。面向信息流的模式：描

21、述信息的轉(zhuǎn)換。第7章 構(gòu)建分析模型重點(diǎn)：1. 簡單用幾句話嘗試說明結(jié)構(gòu)化分析和面向?qū)ο蠓治龅闹饕顒e？結(jié)構(gòu)化分析考慮數(shù)據(jù)和處理，其中數(shù)據(jù)作為獨(dú)立的實(shí)體轉(zhuǎn)換，數(shù)據(jù)對(duì)象建模定義了對(duì)象的屬性和關(guān)系，操作對(duì)象的處理建模應(yīng)當(dāng)表明數(shù)據(jù)對(duì)象在系統(tǒng)內(nèi)流動(dòng)時(shí)處理如何轉(zhuǎn)換數(shù)據(jù)。面向?qū)ο蠓治鲫P(guān)注于定義類和影響客戶需求的類之間的協(xié)作方式。2. 有沒有可能在分析模型創(chuàng)建后立即開始編碼？解釋你的答案，然后說服反方。第8章 設(shè)計(jì)工程重點(diǎn)：1. 如果軟件設(shè)計(jì)不是程序（它確定不是），那么它是什么？是一套堅(jiān)固、適用和賞心悅目的模型或設(shè)計(jì)表示。它包括數(shù)據(jù)、類設(shè)計(jì)，體系結(jié)構(gòu)設(shè)計(jì)、接口設(shè)計(jì)、構(gòu)件設(shè)計(jì)。2. 當(dāng)你“編寫”程序時(shí)你設(shè)計(jì)軟件

22、嗎？軟件設(shè)計(jì)和編碼有什么不同嗎？設(shè)計(jì)。軟件設(shè)計(jì)是逐步細(xì)化一個(gè)可以工作的模型，而編碼是在生成一個(gè)可執(zhí)行的程序。軟件設(shè)計(jì)主要關(guān)注是否實(shí)現(xiàn)了用戶需求，必須從實(shí)現(xiàn)的角度說明數(shù)據(jù)域、功能域和行為域，是編碼工作的指導(dǎo)。3. 用你自己的話說明軟件體系結(jié)構(gòu)。系統(tǒng)結(jié)構(gòu)是程序構(gòu)件（模塊）的結(jié)構(gòu)或組織，這些構(gòu)件交互的形式以及這些構(gòu)件所以數(shù)據(jù)的結(jié)構(gòu)。構(gòu)件可以被推廣，用于代表主要的系統(tǒng)元素及其交互。第9章 進(jìn)行體系結(jié)構(gòu)設(shè)計(jì)體系結(jié)構(gòu)風(fēng)格的分類以數(shù)據(jù)為中心的體系結(jié)構(gòu)數(shù)據(jù)流體系結(jié)構(gòu)：當(dāng)輸入數(shù)據(jù)經(jīng)過一系列的計(jì)算和操作構(gòu)件的變換形成輸出數(shù)據(jù)時(shí)，可以應(yīng)用這種體系結(jié)構(gòu)。信息流被描述為單個(gè)數(shù)據(jù)項(xiàng)，被稱為事務(wù)，他可以沿多條路徑中的一條觸

23、發(fā)其他數(shù)據(jù)流。調(diào)用和返回體系結(jié)構(gòu)面向?qū)ο篌w系結(jié)構(gòu)層次體系結(jié)構(gòu)重點(diǎn)：1. 使用數(shù)據(jù)流程圖和處理敘述，描述一個(gè)具有明顯數(shù)據(jù)流特征和一個(gè)具有明顯事務(wù)流特性的計(jì)算機(jī)系統(tǒng)。數(shù)據(jù)流特征：opengl管線事務(wù)流特性：銀行轉(zhuǎn)賬以房子或建筑的體系結(jié)構(gòu)作比喻，與軟件體系結(jié)構(gòu)進(jìn)行對(duì)比。傳統(tǒng)的建筑體系結(jié)構(gòu)學(xué)科和軟件體系結(jié)構(gòu)有何相似之處？有何不同之處？第10章 構(gòu)件級(jí)設(shè)計(jì)建模構(gòu)件：系統(tǒng)中某一定型化的、可配置的和可替換的部件，該部件封裝并暴露了一些列接口。內(nèi)聚性：內(nèi)聚性cohesion 意味著構(gòu)件或者類只封裝那些相互關(guān)聯(lián)密切，以及與構(gòu)件或類自身有密切關(guān)系的屬性和操作。耦合性：類之間彼此聯(lián)系程度的一種定性度量第11章 完成

24、用戶界面設(shè)計(jì)黃金規(guī)則 置用戶于控制之下；以不強(qiáng)迫用戶進(jìn)入不必要的或不希望的動(dòng)作的方式來定義交互模式。 提供靈活度的交互。 允許用戶交互被中斷和撤銷。 當(dāng)技能級(jí)別增長時(shí)可以使交互流線化并允許定制交互。 使用戶與內(nèi)部技術(shù)細(xì)節(jié)隔離開來。 設(shè)計(jì)允許用戶與出現(xiàn)在屏幕上的對(duì)象直接交互。 減少用戶的記憶負(fù)擔(dān)； 減少對(duì)短期記憶的要求。 建立有意義的缺省。 定義直觀的快捷方式。 界面的視覺布局應(yīng)該基于真實(shí)世界的象征。 以不斷進(jìn)展的方式揭示信息。 保持界面一致性。允許用戶將當(dāng)前任務(wù)放入有意義的環(huán)境中。 在應(yīng)用系統(tǒng)家族內(nèi)保持一致性。 如果過去的交互模型已經(jīng)建立起了用戶期望，除非有不得已的理由，否則不要改變它。重點(diǎn)：1. 試給出兩個(gè)附加的“降低用戶記憶負(fù)擔(dān)”、“保持界面一致性”的設(shè)計(jì)原則。2. 假設(shè)你被邀請(qǐng)開發(fā)一個(gè)基于WEB的家庭銀行系統(tǒng)。請(qǐng)給出用戶模型、設(shè)計(jì)模型、心理模型和實(shí)現(xiàn)模型。第12章 軟件測試策略軟件測試需要計(jì)劃和執(zhí)行一系列的測試步驟 單元測試 集成測試 確認(rèn)測試 系統(tǒng)測試重點(diǎn)：1. 用自己的話描述驗(yàn)證與確認(rèn)的不同。兩者都要使用測試用例設(shè)計(jì)方法和測試策略嗎？驗(yàn)證是確保軟件正確的實(shí)現(xiàn)某一特定功能的一些列活動(dòng)；確認(rèn)是指確保開發(fā)的軟件可追溯到用戶需求的另外一系列活動(dòng)。都需要。2. 誰應(yīng)該完成確認(rèn)測試是軟件開發(fā)人員還是軟件使用者，說明你的理由。最終