軟件工程復(fù)習(xí)

1、第一章導(dǎo)論軟件工程關(guān)注于開(kāi)發(fā)成本和軟件質(zhì)量問(wèn)題軟件的3個(gè)特性，以及補(bǔ)充的四個(gè)本質(zhì)特性a）軟件不會(huì)被磨損，并不意味著軟件容易修改b）所有成功的軟件都會(huì)發(fā)生變更，并不意味著變更越多，軟件越成功軟件的類型a）從軟件的功能角度分為系統(tǒng)軟件和應(yīng)用軟件b）從服務(wù)對(duì)象的角度分為通用軟件和定制軟件，能區(qū)分什么是通用軟件和定制軟件軟件質(zhì)量的定義？a）如何評(píng)判軟件質(zhì)量的好壞？軟件質(zhì)量通常采用質(zhì)量模型來(lái)建立軟件質(zhì)量特性間的關(guān)系常見(jiàn)的有如Bohem質(zhì)量模型，McCall的質(zhì)量模型，ISO的質(zhì)量模型m.用McCall的質(zhì)量模型判斷軟件質(zhì)量，給出了哪11個(gè)質(zhì)量要素，分哪三類？iv, 為了讓11個(gè)質(zhì)量要素定量化，給出了 2

2、0質(zhì)量評(píng)價(jià)準(zhǔn)則“運(yùn)行正確的軟件就是高質(zhì)量的軟件?！闭_嗎？軟件危機(jī)是指在計(jì)算機(jī)軟件的開(kāi)發(fā)和維護(hù)過(guò)程中遇到的一系列嚴(yán)重問(wèn)題人們?cè)?0世紀(jì)60年代末普遍認(rèn)識(shí)到“軟件危機(jī)”的存在。軟件工程的定義（正EE） ?軟件工程至今尚未解決大型復(fù)雜軟件開(kāi)發(fā)的問(wèn)題a）軟件工程是一個(gè)正在興起的年輕學(xué)科軟件工程的三要素？a）軟件工程方法提供如何構(gòu)造軟件的技術(shù)b）工具提供自動(dòng)化或半自動(dòng)化的支持。c）軟件工程過(guò)程是用合適的方法、語(yǔ)言和工具由軟件工程師進(jìn)行軟件活動(dòng)的集合。即 確定軟件開(kāi)發(fā)分為哪些過(guò)程活動(dòng)，活動(dòng)之間的先后次序等。軟件工程的方法：典型的兩類？a）結(jié)構(gòu)化分析的基本原則是分解和抽象b）結(jié)構(gòu)化分析的結(jié)果是DFD圖c）

3、結(jié)構(gòu)化設(shè)計(jì)時(shí)將DFD轉(zhuǎn)化為系統(tǒng)結(jié)構(gòu)模型（功能模塊圖）d）面向?qū)ο蠓椒ǎ篛OA,OOD,OOP, OOTQOSMe）分析類和設(shè)計(jì)類是多對(duì)多的工具的集合稱之為計(jì)算機(jī)輔助軟件工程，簡(jiǎn)稱CASE （ Computer-Aided SoftwareEngmeering,計(jì)算機(jī)輔助軟件工程）CASE分成三個(gè)層次：工具、工作臺(tái)和集成的軟件開(kāi)發(fā)環(huán)境a）工具往往完成軟件過(guò)程活動(dòng)中的單一任務(wù)b）工作臺(tái)支持軟件過(guò)程某個(gè)階段的活動(dòng)c）集成的軟件開(kāi)發(fā)環(huán)境則是支持整個(gè)軟件開(kāi)發(fā)過(guò)程中所有活動(dòng)或核心活動(dòng)軟件工程知識(shí)體系（SWEBOK）,將軟件工程知識(shí)分解成層次化的10個(gè)知識(shí)域第二章軟件過(guò)程可概括為三類P18常見(jiàn)的六種過(guò)程模型

4、a）模型圖（區(qū)分模型圖）b）使用范圍c）優(yōu)缺點(diǎn)瀑布模型適用：在開(kāi)發(fā)的早期階段軟件需求被完整確定缺點(diǎn)：各個(gè)階段的劃分完全固定，階段之間產(chǎn)生大量的文檔，極大地增加了工作量用戶只有等到整個(gè)過(guò)程的末期才能見(jiàn)到開(kāi)發(fā)成果，從而增加了開(kāi)發(fā)的風(fēng)險(xiǎn)開(kāi)發(fā)過(guò)程中很難響應(yīng)客戶的變更要求早期的錯(cuò)誤可能要等到開(kāi)發(fā)后期的測(cè)試階段才能發(fā)現(xiàn)，進(jìn)而帶來(lái)嚴(yán)重的后果演化式開(kāi)發(fā)模型適用：軟件需求不確定，常用于命周期較短、中小規(guī)模的系統(tǒng)。當(dāng)然在大型系統(tǒng)中， 視具體情況部分采用演化式開(kāi)發(fā)也是可行的。優(yōu)點(diǎn)在及時(shí)響應(yīng)用戶需求改變方面比瀑布模型更為有效，軟件改變的代價(jià)較小 缺陷-系統(tǒng)的結(jié)構(gòu)通常不好-軟件過(guò)程可見(jiàn)性不好-開(kāi)發(fā)過(guò)程通常需要特殊的工具

5、和技術(shù)支持形式變換模型適用特別適合于那些對(duì)安全性、可靠性和保密性要求極高的軟件系統(tǒng)，這些系統(tǒng)需要在投入 運(yùn)行前進(jìn)行驗(yàn)證優(yōu)點(diǎn)由于數(shù)學(xué)方法具有嚴(yán)密性和準(zhǔn)確性，形式化方法開(kāi)發(fā)過(guò)程所交付的軟件系統(tǒng)具有較少的 缺陷和較高的安全性由IBM建議的凈室開(kāi)發(fā)過(guò)程（Cleanroom）是一個(gè)典型的形式化開(kāi)發(fā)過(guò)程面向復(fù)用的開(kāi)發(fā)主要建立在己有大量可利用的軟件組件和組件的集成框架基礎(chǔ)上，可以有效提高開(kāi)發(fā)效率和 質(zhì)量?jī)?yōu)點(diǎn)充分體現(xiàn)軟件復(fù)用的思想實(shí)現(xiàn)快速交付軟件 缺點(diǎn)商業(yè)組件的修改受到限制，影響系統(tǒng)的演化增量開(kāi)發(fā)是將系統(tǒng)的需求定義、設(shè)計(jì)和實(shí)現(xiàn)分解成若干增量依次開(kāi)發(fā)和交付，以減少開(kāi)發(fā)過(guò)程中的 返工，也可以讓用戶通過(guò)體驗(yàn)先期交付

6、的系統(tǒng)更準(zhǔn)確、詳細(xì)地給出需求。優(yōu)點(diǎn)整個(gè)產(chǎn)品被分解成若干個(gè)構(gòu)件逐步交付，用戶可以不斷地看到所開(kāi)發(fā)軟件的可運(yùn)行中間 版本將早期增量作為原型有助于明確后期增量的需求降低開(kāi)發(fā)風(fēng)險(xiǎn)重要功能被首先交付，從而使其得到最多的測(cè)試缺點(diǎn)需要軟件具備開(kāi)放式的體系結(jié)構(gòu)需求難以在增量實(shí)現(xiàn)之前詳細(xì)定義，因此增量與需求的準(zhǔn)確映射以及所有增量的有效集 成可能會(huì)比較困難容易退化為邊做邊改方式，使軟件過(guò)程的控制失去整體性螺旋模型a)將瀑布模型和快速原型模型結(jié)合起來(lái)，其過(guò)程活動(dòng)不是按順序進(jìn)行而是以螺旋式展 開(kāi)，強(qiáng)調(diào)了其他模型所忽視的風(fēng)險(xiǎn)分析，特別適合于大型復(fù)雜的系統(tǒng)。Rational 統(tǒng)一過(guò)程 RUP (Rational unif

7、ied process)強(qiáng)調(diào)開(kāi)發(fā)和維護(hù)模型其軟件生命周期在時(shí)間上被分解為四個(gè)連續(xù)的階段：分別是？敏捷開(kāi)發(fā)是由業(yè)界專家針對(duì)企業(yè)現(xiàn)狀提出的讓軟件開(kāi)發(fā)團(tuán)隊(duì)具有快速工作、響應(yīng)變化能 力的價(jià)值觀和原則，第三章對(duì)象類之間的聯(lián)系分類結(jié)構(gòu)：一般與特殊的關(guān)系。在面向?qū)ο笮g(shù)語(yǔ)中為泛化組成結(jié)構(gòu)：部分與整體的關(guān)系。在面向?qū)ο笮g(shù)語(yǔ)中為聚合和組合實(shí)例連接：對(duì)象類之間的靜態(tài)聯(lián)系。在面向?qū)ο笮g(shù)語(yǔ)中為關(guān)聯(lián)消息連接：對(duì)象類之間的通信聯(lián)系。在面向?qū)ο笮g(shù)語(yǔ)中為依賴UML ( Unified Modeling Language )統(tǒng)一建模語(yǔ)言是一種直觀化、明確化、構(gòu)建和文檔化軟件系統(tǒng)產(chǎn)物的通用可視化建模語(yǔ)事物結(jié)構(gòu)事物、分組事物、行為亨

8、物注釋事物抵本構(gòu)造塊_ . 依賴關(guān)系、關(guān)聯(lián)關(guān)系事物結(jié)構(gòu)事物、分組事物、行為亨物注釋事物抵本構(gòu)造塊_ . 依賴關(guān)系、關(guān)聯(lián)關(guān)系泛化關(guān)系、實(shí)現(xiàn)關(guān)系用例圖田 類圖、對(duì)象國(guó)、組件圖、分布困、順序圖、協(xié)作囹、狀態(tài)囹、活動(dòng)囹UML語(yǔ)義規(guī)則命名、: 可見(jiàn)性、完楚性、可執(zhí)行性說(shuō)明、修飾-: 通用劃分、擴(kuò)展機(jī)制事物(things) P37分辨圖3.23.5的模型符號(hào)表示系統(tǒng)中的元素，事物是是實(shí)體抽象化的最終結(jié)果，是UML模型中的基本成員包括：結(jié)構(gòu)事物、行為事物、分組事物、注釋事物 關(guān)系(relationships)-表示系統(tǒng)中的元素如何進(jìn)行連接，即將事物聯(lián)系在一起的方式：包括四種：依賴、 關(guān)聯(lián)、泛化、實(shí)現(xiàn)-四種關(guān)

9、系的模型符號(hào)，圖3.9關(guān)聯(lián)中角色多重性的含義聚合組合是特殊的關(guān)聯(lián)，他們的區(qū)別？UML關(guān)系包括關(guān)聯(lián)、聚合、泛化、實(shí)現(xiàn)、依賴等5種類型，請(qǐng)指出下面關(guān)系的類型， 并采用UML符號(hào)表示這些關(guān)系。(1) 在學(xué)校中，一個(gè)學(xué)生可以選修多門(mén)課程，一門(mén)課程可以由多個(gè)學(xué)生選修， 那么學(xué)生和課程之間是什么關(guān)系？(2)類A的一個(gè)操作調(diào)用類B的一個(gè)操作，且這兩個(gè)類之間不存在其他關(guān)系, 那么類A和類B之間是什么關(guān)系？(3)接1及其實(shí)現(xiàn)類或構(gòu)件之間是什么關(guān)系？(4)一個(gè)汽車有四個(gè)輪子，那么類“汽車”和“輪子”之間是什么關(guān)系？(5) 學(xué)生與研究生之間是什么關(guān)系？ 圖(diagrams)對(duì)整個(gè)系統(tǒng)而言，其功能由用例圖描述，靜態(tài)

10、結(jié)構(gòu)由類圖和對(duì)象圖描述，動(dòng)態(tài)行為由狀 態(tài)圖、時(shí)序圖、協(xié)作圖和活動(dòng)圖描述，而物理架構(gòu)則是由組件圖和部署圖描述。用例圖：用例圖定義了系統(tǒng)的功能需求，用例圖表示了用例、參與者及其它們之間的關(guān) 系。類圖(Class Diagram)：類圖描述系統(tǒng)的靜態(tài)結(jié)構(gòu)，表示系統(tǒng)中的類、類與類之間的關(guān) 系以及類的屬性和操作狀態(tài)圖針對(duì)單個(gè)對(duì)象建立模型。側(cè)重于描述某個(gè)對(duì)象在其生命周期中的動(dòng)態(tài)行為，包括 對(duì)象在各個(gè)不同的狀態(tài)間的跳轉(zhuǎn)以及觸發(fā)這些跳轉(zhuǎn)的外部事件，即從狀態(tài)到狀態(tài)的控制 流。必須有一個(gè)初態(tài)。順序圖(Sequence Diagram)順序圖描述了一組交互對(duì)象間的交互方式，它表示完成某項(xiàng)行為的對(duì)象和這些對(duì)象之間 傳

11、遞消息的時(shí)間順序。一般情況下，我們使用順序圖描述一個(gè)用例的事件流，標(biāo)識(shí)參與這個(gè)用例的對(duì)象，并以 服務(wù)的形式將用例的行為分配到對(duì)象上。順序圖和協(xié)作圖是同構(gòu)的，即兩者之間可以相互轉(zhuǎn)換。第四章!1!第四章!1!軟件需求并不單指用戶需求，分為業(yè)務(wù)需求，用戶需求，系統(tǒng)需求，功能需求和非功能 需求業(yè)務(wù)需求是組織或客戶對(duì)于系統(tǒng)的高層次目標(biāo)要求，定義了項(xiàng)目的遠(yuǎn)景和范序I,即確 定軟件產(chǎn)品的發(fā)展方向、功能范圍、目標(biāo)客戶和價(jià)值來(lái)源（P61）用戶需求是從用戶角度描述的系統(tǒng)功能需求和非功能需求，通常只涉及系統(tǒng)的外部行 為，而不涉及系統(tǒng)的內(nèi)部特性；用戶需求用自然語(yǔ)言表達(dá)，容易含糊和不準(zhǔn)確系統(tǒng)需求是更加詳細(xì)地描述系統(tǒng)應(yīng)該

12、做什么，通常包括許多不同的分析模型，諸如對(duì)象 模型、數(shù)據(jù)模型、狀態(tài)模型等功能需求描述系統(tǒng)應(yīng)該提供的功能或服務(wù)，通常涉及用戶或外部系統(tǒng)與該系統(tǒng)之間的 交互，一般不考慮系統(tǒng)的實(shí)現(xiàn)細(xì)節(jié)非功能需求從各個(gè)角度對(duì)系統(tǒng)的約束和限制圖4-1需求工程過(guò)程活動(dòng)？需求獲取需求分析需求定義需求驗(yàn)證需求工程過(guò)程中需求獲取需求獲取主要涉及到聆聽(tīng)用戶的需求，分析和整理所獲取的信 息，形成文檔化的描述基于用例的需求獲?。?.4.2）中四個(gè)步驟？需求定義產(chǎn)生的文檔是需求規(guī)格說(shuō)明書(shū)SRS需求驗(yàn)證對(duì)SRS進(jìn)行驗(yàn)證。第五章本章討論需求工程中的需求分析，采用了面向?qū)ο蠓椒嫦驅(qū)ο笮枨蠓治鍪紫茸R(shí)別分析類，分析類有三種實(shí)體類：表示系統(tǒng)存儲(chǔ)

13、和管理的永久信息邊界類：表示參與者與系統(tǒng)之間的交互控制類：表示系統(tǒng)在運(yùn)行過(guò)程中的業(yè)務(wù)控制邏輯P79 5.2基于UML的需求分析步驟，哪3個(gè)步驟？識(shí)別分析類建模分析對(duì)象之間的 交互構(gòu)建分析類圖看一遍P79頁(yè)識(shí)別分析類的基本原則，根據(jù)用例圖和用例描述（需求工程中需求獲取活動(dòng)產(chǎn)生的模型）識(shí)別分析類。5.2.3構(gòu)建分析類圖時(shí)，對(duì)每個(gè)分析類的職責(zé)，可以使用順序圖把用例行為分配到所識(shí) 別的分析類中6：書(shū)后練習(xí)9第六章軟件設(shè)計(jì)的四個(gè)通用原則？系統(tǒng)模塊化后復(fù)雜性和工作量比原系統(tǒng)小但模塊的分解并非越多越好，模塊之間存在著交互接II,當(dāng)模塊過(guò)多時(shí)，將會(huì)增加接II 的代價(jià)。內(nèi)聚是子系統(tǒng)內(nèi)部的相關(guān)程度，當(dāng)子系統(tǒng)中彼此

14、相關(guān)的多個(gè)對(duì)象執(zhí)行類似的任務(wù)時(shí)，則 認(rèn)為該子系統(tǒng)是高內(nèi)聚的：反之，當(dāng)子系統(tǒng)內(nèi)的多個(gè)對(duì)象彼此不相關(guān)時(shí)，則認(rèn)為是低 內(nèi)聚的。內(nèi)聚越高越好內(nèi)聚度標(biāo)志一個(gè)模塊內(nèi)部各成分彼此結(jié)合的緊密程度。內(nèi)聚度按其高低程度可分為7級(jí)偶然內(nèi)聚，邏輯內(nèi)聚，時(shí)間內(nèi)聚是低級(jí)內(nèi)聚，設(shè)計(jì)時(shí)應(yīng)盡量避免耦合表示兩個(gè)子系統(tǒng)（或類）之間的關(guān)聯(lián)程度。- 當(dāng)一個(gè)子系統(tǒng)（或類）發(fā)生變化時(shí)對(duì)另一個(gè)子系統(tǒng)（或類）的影響很小，則稱它們是 松散耦合的；反之，如果變化的影響很大時(shí)，則稱它們是緊密耦合的。耦合也可分為7級(jí)，耦合度應(yīng)越低越好一般來(lái)說(shuō)，設(shè)計(jì)時(shí)應(yīng)盡量使用數(shù)據(jù)耦合，絕對(duì)禁止內(nèi)容耦合復(fù)用（Reuse ）-對(duì)于建立軟件系統(tǒng)而言，所謂復(fù)用就是利用某些己

15、開(kāi)發(fā)的、對(duì)建立新系統(tǒng)有用的軟 件元素來(lái)生成新的軟件系統(tǒng)。-復(fù)用的好處在于提高生產(chǎn)效率，提高軟件質(zhì)量，改善軟件系統(tǒng)的可維護(hù)性常見(jiàn)的體系結(jié)構(gòu)設(shè)計(jì)策略：管道一過(guò)濾器結(jié)構(gòu)分層體系結(jié)構(gòu)倉(cāng)庫(kù)系統(tǒng)結(jié)構(gòu)客戶/服務(wù)器模式（ATM是胖客戶，網(wǎng)站是瘦客戶）MVC模式第七章面向?qū)ο笤O(shè)計(jì)過(guò)程識(shí)別設(shè)計(jì)類的基本原則如果一個(gè)“分析類”比較簡(jiǎn)單，代表著單一的邏輯抽象，那么可以將其映射為“設(shè)計(jì)類氣 通常，主動(dòng)參與者對(duì)應(yīng)的邊界類、控制類和一般的實(shí)體類都可以直接映射成設(shè)計(jì)類。如果“分析類”的職責(zé)比較復(fù)雜，很難由單個(gè)“設(shè)計(jì)類”承擔(dān)，則應(yīng)該將其映射成“子系統(tǒng) 接I”或“子系統(tǒng)氣通常，被動(dòng)參與者對(duì)應(yīng)的邊界類被映射成子系統(tǒng)接口識(shí)別完設(shè)計(jì)類后

16、，需要識(shí)別設(shè)計(jì)類的方法，識(shí)別類屬性，識(shí)別類關(guān)系，最后建模設(shè)計(jì)類 圖，產(chǎn)生面向?qū)ο笤O(shè)計(jì)結(jié)果識(shí)別類方法：一般，設(shè)計(jì)類的方法首先可由分析類的職責(zé)得到（需細(xì)化），其次，遍歷 用例實(shí)現(xiàn)和畫(huà)狀態(tài)圖，找遺漏的方法識(shí)別類屬性：設(shè)計(jì)類的屬性可繼承自分析類，有時(shí)，分析類的屬性隱含著設(shè)計(jì)類需要的 一個(gè)或多個(gè)屬性，一個(gè)類的屬性不能被多個(gè)設(shè)計(jì)對(duì)象共享識(shí)別類關(guān)系：找設(shè)計(jì)類之間的關(guān)聯(lián)（包括聚合和組合），依賴，泛化關(guān)系，可從分析模 型中得到設(shè)計(jì)時(shí)會(huì)復(fù)用設(shè)計(jì)模式設(shè)計(jì)模式描述了系統(tǒng)設(shè)計(jì)過(guò)程中常見(jiàn)問(wèn)題的解決方案，它是從大量的成功實(shí)踐中總結(jié) 出來(lái)的Composite模式針對(duì)系統(tǒng)中存在單個(gè)對(duì)象和組合對(duì)象的情況，Composite模式模

17、糊了單個(gè) 對(duì)象和組合對(duì)象的概念，客戶程序可以像處理單個(gè)對(duì)象一樣來(lái)處理組合對(duì)象Absuact Factory模式：適用于封裝具體平臺(tái)，使應(yīng)用可在不同平臺(tái)上運(yùn)行Adaptor模式：該模式的目的是封裝遺留系統(tǒng)的代碼第11章軟件實(shí)現(xiàn)并非單純地將設(shè)計(jì)模型轉(zhuǎn)換為代碼，包括P176多種基本活動(dòng)編碼風(fēng)格是指編程時(shí)表現(xiàn)出來(lái)的特點(diǎn)、習(xí)慣、邏輯思維等。軟件編碼更多地是一種工程，而不是一種個(gè)人藝術(shù)。如果不統(tǒng)一編程規(guī)范，最終寫(xiě)出的 程序，其可讀性將較差，這不僅給代碼的理解帶來(lái)障礙，增加維護(hù)階段的工作量，同時(shí) 不規(guī)范的代碼隱含錯(cuò)誤的可能性也比較大。軟件編碼規(guī)范目的提高編碼質(zhì)量，避免不必要的程序錯(cuò)誤增強(qiáng)程序代碼的可讀性、可

18、重用性和可移植性第十二章有錯(cuò)是軟件的屬性，而且是無(wú)法改變的。關(guān)鍵在于如何避免錯(cuò)誤的產(chǎn)生和消除己經(jīng)產(chǎn)生的錯(cuò)誤，使程序中的錯(cuò)誤密度達(dá)到盡可能 低的程度。Solution:進(jìn)行驗(yàn)證和確認(rèn)活動(dòng)驗(yàn)證和確認(rèn)（Veiificatioii & Validation,簡(jiǎn)稱V&V）工作是在整個(gè)軟件生命周期中對(duì)軟件的規(guī)范性評(píng)估活動(dòng)，以保證軟件開(kāi)發(fā)各個(gè)環(huán)節(jié)的正確性。系統(tǒng)開(kāi)發(fā)完畢后再測(cè)試的觀念是錯(cuò)誤的。驗(yàn)證和確認(rèn)是兩個(gè)相互獨(dú)立但卻相輔相成的活動(dòng)，二者很容易混淆驗(yàn)證強(qiáng)調(diào)對(duì)于過(guò)程的檢驗(yàn)！確認(rèn)強(qiáng)調(diào)對(duì)于結(jié)果的檢驗(yàn)！第十三章Lehman定律：著名的關(guān)于系統(tǒng)變更的定律對(duì)軟件變更引起的各種問(wèn)題，人們通常采用軟件維護(hù)和軟件再工程策略處理。軟件維護(hù)活動(dòng)可以分為三種典型的類別：改正性維護(hù)、適應(yīng)性維護(hù)、完善性維護(hù)。另外不排除其他類型的一些維護(hù)，如預(yù)防性維護(hù)。在幾種維護(hù)活動(dòng)中，完善性維護(hù)所占的比重最大（50%）,即大部分維護(hù)工作是改變和加強(qiáng)軟件，而不是糾錯(cuò)第十四章軟件項(xiàng)目管理是為了使軟件項(xiàng)目能夠按照預(yù)定的成本、進(jìn)度、質(zhì)量順利完成，而對(duì)成 本、人員、進(jìn)度、質(zhì)量、風(fēng)險(xiǎn)等進(jìn)行分析和管理的活動(dòng)。降低復(fù)雜性和控制變化是軟 件項(xiàng)目管理的關(guān)鍵問(wèn)題軟件項(xiàng)目計(jì)劃管理目的：是項(xiàng)目管理者對(duì)資源、成本和進(jìn)度作出合理的估算，制定出切