1、第一章導論軟件工程關注于開發成本和軟件質量問題軟件的3個特性，以及補充的四個本質特性a）軟件不會被磨損，并不意味著軟件容易修改b）所有成功的軟件都會發生變更，并不意味著變更越多，軟件越成功軟件的類型a）從軟件的功能角度分為系統軟件和應用軟件b）從服務對象的角度分為通用軟件和定制軟件，能區分什么是通用軟件和定制軟件軟件質量的定義？a）如何評判軟件質量的好壞？軟件質量通常采用質量模型來建立軟件質量特性間的關系常見的有如Bohem質量模型，McCall的質量模型，ISO的質量模型m.用McCall的質量模型判斷軟件質量，給出了哪11個質量要素，分哪三類？iv, 為了讓11個質量要素定量化，給出了 2

2、0質量評價準則“運行正確的軟件就是高質量的軟件。”正確嗎？軟件危機是指在計算機軟件的開發和維護過程中遇到的一系列嚴重問題人們在20世紀60年代末普遍認識到“軟件危機”的存在。軟件工程的定義（正EE） ?軟件工程至今尚未解決大型復雜軟件開發的問題a）軟件工程是一個正在興起的年輕學科軟件工程的三要素？a）軟件工程方法提供如何構造軟件的技術b）工具提供自動化或半自動化的支持。c）軟件工程過程是用合適的方法、語言和工具由軟件工程師進行軟件活動的集合。即 確定軟件開發分為哪些過程活動，活動之間的先后次序等。軟件工程的方法：典型的兩類？a）結構化分析的基本原則是分解和抽象b）結構化分析的結果是DFD圖c）

3、結構化設計時將DFD轉化為系統結構模型（功能模塊圖）d）面向對象方法：OOA,OOD,OOP, OOTQOSMe）分析類和設計類是多對多的工具的集合稱之為計算機輔助軟件工程，簡稱CASE （ Computer-Aided SoftwareEngmeering,計算機輔助軟件工程）CASE分成三個層次：工具、工作臺和集成的軟件開發環境a）工具往往完成軟件過程活動中的單一任務b）工作臺支持軟件過程某個階段的活動c）集成的軟件開發環境則是支持整個軟件開發過程中所有活動或核心活動軟件工程知識體系（SWEBOK）,將軟件工程知識分解成層次化的10個知識域第二章軟件過程可概括為三類P18常見的六種過程模型

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

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

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

7、ied process)強調開發和維護模型其軟件生命周期在時間上被分解為四個連續的階段：分別是？敏捷開發是由業界專家針對企業現狀提出的讓軟件開發團隊具有快速工作、響應變化能 力的價值觀和原則，第三章對象類之間的聯系分類結構：一般與特殊的關系。在面向對象術語中為泛化組成結構：部分與整體的關系。在面向對象術語中為聚合和組合實例連接：對象類之間的靜態聯系。在面向對象術語中為關聯消息連接：對象類之間的通信聯系。在面向對象術語中為依賴UML ( Unified Modeling Language )統一建模語言是一種直觀化、明確化、構建和文檔化軟件系統產物的通用可視化建模語事物結構事物、分組事物、行為亨

8、物注釋事物抵本構造塊_ . 依賴關系、關聯關系事物結構事物、分組事物、行為亨物注釋事物抵本構造塊_ . 依賴關系、關聯關系泛化關系、實現關系用例圖田 類圖、對象國、組件圖、分布困、順序圖、協作囹、狀態囹、活動囹UML語義規則命名、: 可見性、完楚性、可執行性說明、修飾-: 通用劃分、擴展機制事物(things) P37分辨圖3.23.5的模型符號表示系統中的元素，事物是是實體抽象化的最終結果，是UML模型中的基本成員包括：結構事物、行為事物、分組事物、注釋事物 關系(relationships)-表示系統中的元素如何進行連接，即將事物聯系在一起的方式：包括四種：依賴、 關聯、泛化、實現-四種關

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

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

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

12、做什么，通常包括許多不同的分析模型，諸如對象 模型、數據模型、狀態模型等功能需求描述系統應該提供的功能或服務，通常涉及用戶或外部系統與該系統之間的 交互，一般不考慮系統的實現細節非功能需求從各個角度對系統的約束和限制圖4-1需求工程過程活動？需求獲取需求分析需求定義需求驗證需求工程過程中需求獲取需求獲取主要涉及到聆聽用戶的需求，分析和整理所獲取的信 息，形成文檔化的描述基于用例的需求獲取（4.4.2）中四個步驟？需求定義產生的文檔是需求規格說明書SRS需求驗證對SRS進行驗證。第五章本章討論需求工程中的需求分析，采用了面向對象方法面向對象需求分析首先識別分析類，分析類有三種實體類：表示系統存儲

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

14、相關的多個對象執行類似的任務時，則 認為該子系統是高內聚的：反之，當子系統內的多個對象彼此不相關時，則認為是低 內聚的。內聚越高越好內聚度標志一個模塊內部各成分彼此結合的緊密程度。內聚度按其高低程度可分為7級偶然內聚，邏輯內聚，時間內聚是低級內聚，設計時應盡量避免耦合表示兩個子系統（或類）之間的關聯程度。- 當一個子系統（或類）發生變化時對另一個子系統（或類）的影響很小，則稱它們是 松散耦合的；反之，如果變化的影響很大時，則稱它們是緊密耦合的。耦合也可分為7級，耦合度應越低越好一般來說，設計時應盡量使用數據耦合，絕對禁止內容耦合復用（Reuse ）-對于建立軟件系統而言，所謂復用就是利用某些己

15、開發的、對建立新系統有用的軟 件元素來生成新的軟件系統。-復用的好處在于提高生產效率，提高軟件質量，改善軟件系統的可維護性常見的體系結構設計策略：管道一過濾器結構分層體系結構倉庫系統結構客戶/服務器模式（ATM是胖客戶，網站是瘦客戶）MVC模式第七章面向對象設計過程識別設計類的基本原則如果一個“分析類”比較簡單，代表著單一的邏輯抽象，那么可以將其映射為“設計類氣 通常，主動參與者對應的邊界類、控制類和一般的實體類都可以直接映射成設計類。如果“分析類”的職責比較復雜，很難由單個“設計類”承擔，則應該將其映射成“子系統 接I”或“子系統氣通常，被動參與者對應的邊界類被映射成子系統接口識別完設計類后

16、，需要識別設計類的方法，識別類屬性，識別類關系，最后建模設計類 圖，產生面向對象設計結果識別類方法：一般，設計類的方法首先可由分析類的職責得到（需細化），其次，遍歷 用例實現和畫狀態圖，找遺漏的方法識別類屬性：設計類的屬性可繼承自分析類，有時，分析類的屬性隱含著設計類需要的 一個或多個屬性，一個類的屬性不能被多個設計對象共享識別類關系：找設計類之間的關聯（包括聚合和組合），依賴，泛化關系，可從分析模 型中得到設計時會復用設計模式設計模式描述了系統設計過程中常見問題的解決方案，它是從大量的成功實踐中總結 出來的Composite模式針對系統中存在單個對象和組合對象的情況，Composite模式模

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

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