現(xiàn)代軟件工程復習要點

第一章軟件是什么？1、 軟件是指在執(zhí)行時提供所需的功能和性能的指令（計算機程序［instructions。2、 軟件是使稈序能夠充分處理信息的數(shù)據(jù)結構datastructures。3、 軟件是描述稈序操作和使用的描述性信息descriptiveimformation。為什么說軟件是雙重角色dualroles？1、 軟件是一種產(chǎn)品。能提供計算潛在的生產(chǎn)、管理、獲取、修改、顯示或傳遞信息。2、 軟件是交付產(chǎn)品的工具。能夠實現(xiàn)計算機的控制（如操作系統(tǒng)）、信息的傳播（如網(wǎng)絡軟件）和其他程序的創(chuàng)建和控制（如軟件工具和環(huán)境）。軟件不會損壞，所謂的軟件“壞了”指1、 出現(xiàn)了Bug。2、 軟件的環(huán)境變了。3、 軟件不能滿足新的需求了。軟件和硬件的區(qū)別：1、 軟件是設計開發(fā)的，不是傳統(tǒng)意義上的生產(chǎn)制造的。2、 軟件不會“磨損”3、 雖然整個工業(yè)向著基于構件模式發(fā)展，然而大多數(shù)軟件仍是根據(jù)顧客需求定制的。為什么軟件必須改變（上圖的change）1、 軟件必須適應新的計算機環(huán)境或者技術的需要。2、 必須增強軟件來實現(xiàn)新的業(yè)務需求。3、 軟件必須擴展，來實現(xiàn)與其他更現(xiàn)代的系統(tǒng)或數(shù)據(jù)庫的互操作4、 軟件必須重新架構，使其在網(wǎng)絡環(huán)境中可運行。軟件的種類：系統(tǒng)軟件，應用軟件，工程/科學軟件，嵌入式軟件，產(chǎn)品線軟件，網(wǎng)絡/手機應用程序），人工智能軟件（機器人、神經(jīng)網(wǎng)絡、游戲）。云計算為網(wǎng)絡計算設備提供分布式數(shù)據(jù)存儲和處理資源。計算資源駐留在云之外，并且可以訪問云中的各種資源。產(chǎn)品線軟件是一組軟件密集型系統(tǒng)，具有共同的特點，滿足特定市場的需求。軟件產(chǎn)品線共享一組資產(chǎn)，包括需求、體系結構、設計模式、可重用組件、測試用例和其他工作產(chǎn)品。Webapp的特點1、 網(wǎng)絡密集性。大量用戶可以一次訪問webapp2、 不可預測的負載。網(wǎng)絡應用的用戶數(shù)量可能會因每天的數(shù)量級而變化。3、 性能。用戶等待時間太長，可能會取消訪問。4、 可用性。5、 數(shù)據(jù)驅動的。6、 內(nèi)容敏感。內(nèi)容的質量和審美性是重要決定因素。7、 持續(xù)的進化。8、 即時性。9、 安全性。10、 美學。第二章CMMIcapabilitymaturitymodelintegration能力成熟度模型集成PSPpersonalsoftwareprocess個人軟件過程TSPteamsoftwareprocess團隊軟件過程IEEE給出的定義軟件工程的定義：1、 將系統(tǒng)化、規(guī)范的、可量化的方法應用于軟件的開發(fā)、運行和維護，即將工程化方法應用于軟件。2、 在1中所述方法的研究。軟件工程是一種層次化的技術。軟件工程的根基在于質量關注點qualityfocus。軟件工程的基礎是過程process。過程：活動的集合,行動,和任務執(zhí)行時要創(chuàng)建一些工作產(chǎn)品軟件工程方法method為建造軟件提供了技術上的解決方法“如何做”。軟件工程工具tool為過程和方法提供自動化或半自動化的支持。工具集成起來稱為計算機輔助軟件工程（computer-aidedsoftwareengineering）自上而下軟件工程的層次是：工具、方法、過程、質量關注點。通用過程框架(genericprocessframework)：1、 溝通communication2、 策劃planning3、 建模modeling包括需求分析analysisofrequirements和設計design4、 構建construction包括編碼codegeneration和測試testing5、 部署deployment軟件保護活動umbrellaactivities：1、 軟件項目跟蹤和控制2、 風險管理3、 軟件質量保證4、 正式技術評審5、 測量6、 軟件配置管理7、 可復用管理8、 工作產(chǎn)品的準備和生產(chǎn)過程模式定義：過程模式提供了一個模板——一種描述軟件過程中重要特征的一致性方法。通過過程模式軟件團隊可以定義能最好滿足項目需求的開發(fā)過程。過程模式processmodel的模板：1、 模式名稱。模式名稱應該清楚表達該模式在軟件過程中的的功能。2、 目的。簡介描述模式目的。3、 類型。定義模式類型。4、 啟動條件。模式應用的前提條件。5、 問題。模式將要解決的問題。6、 解決方法。描述模式的實現(xiàn)。7、 結束條件。模式成功執(zhí)行后的結果。8、 相關模式。9、 已知應用實例。過程評估processevaluation模板：1、 啟動initiating2、 診斷diagnosing3、 建立establishing4、 執(zhí)行acting5、 學習learningPSP個人軟件過程模板：1、 策劃2、 高層設計。3、 高層設計評審。4、 開發(fā)。5、 后驗。解決問題步驟：1、 理解問題。2、 計劃解決方案。3、 執(zhí)行。4、測試結果正確性。—-Vr.第三章過程模型種類：1、慣例過程模型。2、 瀑布模型。3、增量過程模型。4、演化過程模型。5、專用過程模型。慣例過程模型提供了一個過程框架，由對應于軟件工程動作的明確的任務集組成。瀑布模型。又稱經(jīng)典生命周期。溝通-＞策劃-＞建模-＞構建-＞部署出現(xiàn)問題：1、實際項目很少嚴格遵守這個順序。2、客戶通常難以清楚地描述所有需求。而瀑布模型要求客戶明確需求。3、客戶必須有耐心，只有在項目接近尾聲的時候，他們才能得到可執(zhí)行程序。增量過程模型1、增量模型增量模型以迭代的方式運用瀑布模型。

第一個增量往往是核心產(chǎn)品。增量模型側重于每個增量都提交一個可以操作的增量。優(yōu)點：1/可以規(guī)避技術風險。2/可以保證部分功能按時交付給最終客戶，不至于造成過分的延期。2、RAD模型RADrapidapplicationdevelopment快速應用程序開發(fā)，是一種側重于短暫的開發(fā)周期的增量軟件過程模型。通過基于構件的構建方法實現(xiàn)快速開發(fā)。能使開發(fā)團隊在非常短的時間內(nèi)創(chuàng)造出“全功能系統(tǒng)”。RAD模型建模部分包括三個主要階段：業(yè)務建模、數(shù)據(jù)建模、過程建模。不足之處：1/需要大量人力資源。2/如果開發(fā)者和客戶沒有為短時間急速完成整個系統(tǒng)做好準備，RAD項目將會失敗。3/如果系統(tǒng)不能很好地模塊化，RAD構件建立會有很多問題。4/如果系統(tǒng)需求是高性能，并且需要通過調(diào)整構建接口的方式來提高性能，不能采用RAD模型。5/技術風險很高的情況下，不宜采用RAD。演化過程模型演化模型是迭代的過程模型。1、原型開發(fā)模型0otypingmodel

缺點：1/客戶看到了軟件的工作版本，但不知道整個軟件是粗糙的。2/開發(fā)者為了使一個原型快速運行起來，往往在實現(xiàn)過程中采用折衷的手段。2、螺旋模型spiralmodel

優(yōu)點：1/采用循環(huán)的方式逐步加深系統(tǒng)定義和實現(xiàn)的深度，同時降低風險。2/確定一系列里程碑，確保共利益者都支持可行和令人滿意的系統(tǒng)解決方案。螺旋模型是開發(fā)大型系統(tǒng)和軟件的理想方法。開發(fā)者可以在產(chǎn)品演進的任何階段使用原型開發(fā)方法。3、協(xié)同開發(fā)模型concurrentdevelopmentmodel專用過程模型1、 形式化方法模型2、面向方面的軟件開發(fā)統(tǒng)一過程unifiedprocessUPUP的起始，包括客戶溝通和策劃活動UP的細化，包括用戶溝通和通用過程模型的建?；顒覷P的構建，與軟件過程中構建活動一致UP的轉換UP的生產(chǎn)，與通用過程的部署活動一致五個UP階段并不是順序進行，而是階段性并發(fā)進行。第四章Agiledevelopment敏捷開發(fā)敏捷的含義：1/有效地響應變化。2/所有利益相關者之間的有效溝通。3/將客戶吸引到團隊。4/項目計劃必須是靈活的。5/快速、增量地交付軟件。敏捷過程必須具有自適應性。應使用增量式開發(fā)策略，必須在很短的時間間隔內(nèi)交付軟件增量來適應不可預測的變化的步伐。敏捷開發(fā)中的人的因素humanfactors1、 基本能力。2、共同目標3、 精誠合作4、 決策能力5、 模糊問題解決能力6、 相互信任和尊重7、自我組織。包括三點：a、組織自身完成工作。b、團隊組織最能適應當前環(huán)境的過程。C、團隊組織最好的進度安排以完成軟件增量交付極限編程extremeprogrammingXPXP的關鍵活動：1、 策劃。策劃活動開始于建立一些列描述待開發(fā)軟件必要特征與功能的“故事”。2、 設計。XP設計嚴格遵循KISkeepitsimple保持簡潔原則。XP鼓勵重構。重構定義：是以不改變代碼外部行為而改進內(nèi)部結構的方式來修改軟件系統(tǒng)的過程。3、 編碼。4、 測試。第七章RErequirementengineering需求工程。需求工程定義：需求工程和其他軟件工程活動類似，必須適應過程、項目、產(chǎn)品和工作人員的要求。從軟件過程的角度來看，需求工程是一個軟件工程動作，開始與溝通并持續(xù)到建模。需求工程過程通過執(zhí)行七個不同的活動來完成：1、 起始。Inception2、 導出。Elicitation3、 精化。Elaboration4、 協(xié)商。Negotiation5、 規(guī)格說明。Specification6、 確認。Validation7、 管理。Management1、 起始A、 建立基本的理解B、 識別利益相關者stakeholdersC、 識別多種觀點D、協(xié)同合作2、 導出A、 會議討論B、 QFD質量功能部署普通需求、期望需求、令人興奮的需求C、 用例場景用例圖3、 精化精化的最終結果是形成一個分析模型，該模型定義了問題的信息域、功能域和行為域。數(shù)據(jù)流圖dataflowdiagram活動圖activitydiagram分析模型的元素：A、 基于場景的元素B、 基于類的元素C、 行為元素D、面向信息流的元素4、 協(xié)商A、 識別每個利益相關者，這些相關者參與協(xié)商B、 確定每個利益相關者的贏得條件C、 談判5、 規(guī)格說明規(guī)格說明是需求工程師完成的最終工作產(chǎn)品，它將作為軟件工程師后續(xù)活動的基礎。6、 確認A、 對需求工程的工作產(chǎn)品進行質量評估B、 檢查不一致、遺漏、錯誤的規(guī)格說明C、 正式技術評審是最主要的需求確認機制7、 需求管理幫助項目團隊識別、控制和跟蹤需求并更改需求軟件配置管理SCM第八章分析模型必須實現(xiàn)三個目標：1、描述客戶需要什么2、 為軟件設計奠定基礎3、 定義在軟件完成后可以被確認的一組需求分析的經(jīng)驗原則：1、模型應關注在問題域或業(yè)務域內(nèi)可見的需求，抽象的級別應該相對高一些。2、分析模型的每個元素都應能增加對軟件需求的整體理解，并提供對信息域、功能和系統(tǒng)行為的深入了解。3、關于基礎結構和其他非功能的模型應推延到設計階段再考慮4、最小化整個系統(tǒng)內(nèi)的關聯(lián)5、確認分析模型為所有共利益者都帶來價值6、盡可能保持模型簡潔分析建模的方法：1、結構化分析。一種考慮數(shù)據(jù)和處理的分析建模方法，其中數(shù)據(jù)作為獨立實體轉換。2、面向對象分析。該方法關注于定義類和影響客戶需求的類之間的協(xié)作方式?！铩铩锓治瞿Ｐ偷脑?、 基于場景的元素A、 用例文本B、 用例圖C、 活動圖D、泳道圖2、 面向信息流的元素A、 數(shù)據(jù)流圖B、 控制流圖C、 處理說明3、 基于類的元素A、 類圖B、 分析包C、 CRC模型D、 協(xié)作圖4、 行為元素A、 狀態(tài)圖B、 順序圖分析建模通常開始于數(shù)據(jù)建模數(shù)據(jù)對象是幾乎任何必須被軟件理解的復合信息的表示。ERD實體/關系圖面向對象的分析1、 在客戶和軟件工程師之間必須對基本的用戶需求進行交流2、必須確定類（也就是說，定義屬性和方法）3、定義類的層次結構4、 表現(xiàn)對象與對象的關系（對象連接）5、 必須為對象行為建模6、上述1-5的工作步驟重復迭代直至模型完成PSPEC處理規(guī)格說明CRC建模class-responsibility-collaborator類-職責-協(xié)作者行為模型顯示了軟件如何響應外部事件或刺激。要創(chuàng)建模型，分析師必須執(zhí)行以下步驟1、評估所有的用例，以充分理解系統(tǒng)內(nèi)交互的順序2、 識別驅動交互序列的事件，并理解這些事件如何與特定對相關聯(lián)3、為每個用例創(chuàng)建一個序列4、 為系統(tǒng)構建狀態(tài)圖5、 檢查行為模型以驗證正確性和一致性。需求模型描述中最基本的元素是用例。為webapp需求建模1、 內(nèi)容分析2、相互作用分析3、 功能分析4、 配置分析第九章設計工程的目標是創(chuàng)作出堅固、適用和賞心悅目的模型或設計表示堅固性firmness：一個程序不應該有任何阻礙其功能的錯誤適用性commodity：一個程序應該適合它的目的賞心悅目delight：使用這個程序的體驗應該是令人愉悅的通用框架活動：1、 溝通2、策劃3、 建模需求分析和設計4、 構建編碼和測試5、 部署評價良好設計演化的三個特征：1、設計必須實現(xiàn)所有包含在分析模型中的明確需求，而且必須滿足客戶期望的所有隱含需求。2、對于那些生成代碼的人和那些進行測試以及隨后維護軟件的人而言，設計必須是可讀的可理解的指南。3、設計必須提供軟件的全貌，從實現(xiàn)的角度說明數(shù)據(jù)域功能域和行為域。FTP正式技術評審質量屬性FURPSF功能性functionalityU易用性usabilityR可靠性reliabilityP性能performanceS可支持性supportability設計模式模板designpatterntemplate模式名稱目的類別動機適用性結構參與者協(xié)作結果相關的模式模塊化P184為什么要信息隱蔽informationhiding：1、 減少“副作用”的可能性2、限制本地設計決策的全球影響3、強調(diào)通過控制接口進行通信4、不鼓勵使用全局數(shù)據(jù)5、導致封裝——高質量設計的一個屬性6、 導致更高質量軟件的產(chǎn)生功能獨立獨立性可以使用兩條定性的標準評估：內(nèi)聚性cohesion和耦合性couplingo內(nèi)聚性顯示了某個模塊相關功能的強度；耦合性顯示了模塊間的相互依賴性。內(nèi)聚性是信息隱蔽的自然拓展。一個內(nèi)聚的模塊執(zhí)行一個獨立的任務，與程序的其他部分只需要很少的交互。耦合性表明軟件結構中多個模塊之間的相互連接。在軟件設計中，我們將盡力得到盡可能低的耦合。一個組織良好的設計類的四個特征1、完整性與充分性sufficient2、 原始性primitiveness3、 高內(nèi)聚性highcohesion4、低耦合性lowcoupling★★★設計模型中的元素1、數(shù)據(jù)設計元素dataelements2、 體系結構設計元素architecturalelements3、接口設計元素interfaceelementsa、用戶界面（Ul）b、和其他系統(tǒng)、設備、網(wǎng)絡或其他的信息生產(chǎn)者或使用者的外部接口。C、各種設計構建之間的內(nèi)部接口。4、 構件級設計元素componentelements5、 部署級設計元素deploymentelements第十章什么是體系結構：一個程序和計算系統(tǒng)軟件體系結構是指系統(tǒng)的一個或多個結構。結構中包括軟件的構件，構件的外部可見屬性以及它們之間的相互關系。體系結構不是可運行軟件。它能使軟件工程師能夠：1、分析設計在滿足規(guī)定需求方面的有效性。2、在設計變更相對容易的階段，考慮體系結構可能的選擇方案。3、降低與軟件構件相關聯(lián)的風險。為什么體系結構這么重要：1、 軟件體系結構的表示有助于對計算機系統(tǒng)開發(fā)感興趣的各方（共利益者）開展交流。2、 體系結構突出了早期設計決策。這些決策對隨后的所有軟件工程工作有深遠影響，同時對系統(tǒng)作為一個可運行實體的最后成功有重要作用。3、 體系結構“構建了一個相對小的，易于理解的模型，該模型描述了系統(tǒng)如何構成以及其構件如何一起工作”。什么是體系結構風格：每種體系結構風格描述一種系統(tǒng)類別：1、一組構件asetofcomponents完成系統(tǒng)需要的某種功能。2、一組連接器asetofconnectors，它們能使構件間實現(xiàn)“通信、合作和協(xié)調(diào)”3、約束constraints，定義構件如何繼承為一個系統(tǒng)。4、語義模型semanticmodels，它能使設計者通過分析系統(tǒng)的構成成分的性質來理解系統(tǒng)的整體性質。體系結構風格簡單分類：1、 以數(shù)據(jù)為中心的體系結構data-centeredarchitectures2、 數(shù)據(jù)流體系結構dataflowarchitectures3、 調(diào)用和返回體系結構callandreturnarchitectures4、 面向對象體系結構object-orientedarchitectures5、 層次體系結構layeredarchitectures體系結構模式三種特性：1、 并發(fā)性concurrency2、 持久性persistence3、 分布性distribution體系結構設計1、系統(tǒng)的環(huán)境表示軟件架構師用體系結構環(huán)境圖ACD對軟件和外部實體交互方式進行建模2、 定義原始模型A、 結點nodeB、 探測器detectorC、 指示器indicatorD、 控制器controller3、 將體系結構精化為構件4、 描述系統(tǒng)實例ADL體系結構描述語言，為描述軟件體系結構提供一套語義和語法。映射數(shù)據(jù)流到軟件體系結構1、 變換流信息必須以“外部世界”信息的形式進出軟件2、 事務流事務流通過數(shù)據(jù)沿某輸入路徑的移動來呈現(xiàn)其特征，對輸入路徑將外部信息轉換成一個事務。3、 變換映射^變換映射是一組設計步驟，可以將具有變換流特征的DFD映射為某個特定的體系結構風格。A、 評審基本系統(tǒng)模型。B、 評審和精化軟件的數(shù)據(jù)流圖。C、 確定DFD是否含有變換流或事務流特征D、 通過確定輸入和輸出流的邊界，分理處變換中心E、 完成“第一級分解”F、 完成“第二級分解”G、 使用提高軟件質量的設計啟發(fā)式方法，精化第一次迭代得到的體系結構。P2154、 事務映射★P222第十一章什么是構件：構件是系統(tǒng)中某一定型化的、可配置的和可替換的部件，該部件封裝了實現(xiàn)并暴露一系列接口。構件有三個重要觀點：1、 面向對象的觀點object-orientedview2、 傳統(tǒng)觀點traditionalview傳統(tǒng)構件也被稱為模塊它承擔下列三個重要角色之一：a、控制構件。B、問題域構件。C、基礎設施構件。3、 過程相關的觀點process-relatedview構件級設計的基本設計原則：1、 開關原則OCP2、 Liskov替換原則LSP3、依賴倒置原則DIP4、接口分離原則ISP5、 發(fā)布復用等價性原則REP6、 共同封裝原則CCP7、 共同復用原則CRP內(nèi)聚性■Levelsofcohesion■Function芻1LayerCommunicationalSequentialProceduralTemporalutility耦合性■LevelofcouplingContent（構A修改了B的內(nèi)部數(shù)器）Common（全局變量/缺省值〉Control〔構件A向其他構件傳遞了控制標記〉Stamp（類B被聲明為類A每一操作的一個參數(shù)類型〉Data（模塊之間傳遞長數(shù)據(jù)）Routinecall（一個操作調(diào)用另一個換作）Typeuse〔構件A調(diào)用構件B中定文的一個數(shù)據(jù)類型）Inclusionorimport（構件A包含構件B中的內(nèi)容）External（與基礎設施進行通訊和協(xié)作〉最簡單的OCL語言語句由四個部分組成：1、 語境context定義了哪些情況語句是正確的2、 特性property描述語境的一些特征。3、