上課內容軟件工程知識要點

軟件工程要點軟件計算機系統(tǒng)中與硬件相互依存的另一部分，它是包括程序、數據及其相關文檔的完整集合。軟件的特征軟件是一種邏輯產品，而不是物理產品，具有抽象性。沒磨損，老化問題軟件產品的成本主要體現在軟件的開發(fā)和維護上，制造幾乎沒有成本大多數軟件都是從頭開發(fā)的。軟件危機軟件代價高開發(fā)過程難以控制軟件工作量估計困難軟件質量底軟件修改、維護困難軟件工程–應用計算機科學、數學及管理科學等原理開發(fā)軟件的過程。它借鑒傳統(tǒng)工程的原則、方法，以提高質量、降低成本為目的。軟件工程層次質量焦點：軟件工程必須以有組織的質量保證為基礎過程：軟件過程是開發(fā)和維護軟件及其相關產品（項目計劃、設計文件、編程代碼、測試、用戶手冊）的一系列活動、方法、實踐和變換。方法：軟件工程方法為軟件開發(fā)提供“如何做”的技術工具：軟件工具為過程和方法提供自動的或半自動的支持。這些軟件工具被集成起來，建立起一個支持軟件開發(fā)的系統(tǒng)，稱之為計算機輔助軟件工程（CASE，

Computer

AidedSoftware

Engineering）。軟件工程層次軟件過程軟件生命周期軟件產品或系統(tǒng)一系列相關活動的全周期。軟件生命周期分成以下幾個階段軟件定義問題定義、可行性研究、需求分析軟件開發(fā)總體設計、詳細設計、編碼和單元測試、綜合測試軟件維護軟件過程模型又稱軟件工程開發(fā)模型，或稱軟件生命期模型，是軟件開發(fā)的全部過程、資源、活動和任務的結構框架。典型軟件過程模型瀑布模型(Waterfall

Model）V模型：更加強調、測試過程應如何于分析、設計等開發(fā)過程相關聯(lián)快速原型模型增量模型螺旋模型：它將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析–制定計劃、風險分析、實施工程、客戶評估噴泉模型：主要支持面向對象的開發(fā)方法。"噴泉"一詞本身體現了迭代和無間隙特性智能模型(Intelligent

Model）瀑布模型(WaterfallModel）問題定義需求分析總體設計詳細設計編碼實現維護讓位瀑布模型各階段的任務問題定義：確定用戶要求解決的性質、工程的目標和規(guī)模。對要開發(fā)的軟件進行可行性研究（經濟可行性、技術可行性、法律可行性、不同的方案），確定軟件元素的作用范圍，并對軟件進行成本估算，制定進度安排，最后提交軟件計劃。軟件需求分析：最根本的任務是確定為了滿足用戶需求系統(tǒng)必須

“做什么”。即確定系統(tǒng)必須具有的功能和性能，系統(tǒng)要求的運行環(huán)境，并預測系統(tǒng)發(fā)展的前景。提交軟件需求規(guī)格說明書?？傮w設計：總體設計的基本任務是確定模塊分解、各模塊功能和模塊間接口，設計全局數據結構。詳細設計：確定各模塊的實現細節(jié)和局部數據結構。編碼：把軟件設計轉換成計算機可以接受的程序代碼。測試：發(fā)現軟件錯誤。維護：使用期間對軟件進行補充、修改和增加工作。矯正性維護：識別與矯正軟件中的錯誤適應性維護：使軟件適應新的環(huán)境和數據需求的改變完善性維護：擴充軟件功能或改善軟件性能預防性維護：為便于將來的維護和性能提高所進行的預防性措施瀑布模型的特點階段間的順序性和依賴性文檔驅動瀑布模型存在的問題依賴于早期進行的唯一次需求調查，不能適應需求變化階段的劃分完全固定，階段間產生大量的文檔，極大地增加了工作量；開發(fā)是線性的，用戶只有等到整個過程的末期才能見到開發(fā)成果，增加了開發(fā)的風險；早期的錯誤可能要等到開發(fā)后期的測試階段才能發(fā)現，進而帶來嚴重的后果?？焖僭湍Ｐ蛯τ脩羲岢龅能浖a品的部分實現，是真實系統(tǒng)的一個模型使用原型的目的明確并完善需求探索設計方案發(fā)展為最終的產品原型拋棄型原型不作為最終交付產品的一部分；用來檢驗討論中的需求或方案是否確實是用戶需要。進化型原型將作為最終產品的一部分；用于檢驗和解釋問題。增量模型(Incremental

Model）軟件被作為一系列的增量構件來設計、實現、集成和測試；每一個線性序列產生軟件的一個可發(fā)布的增量第一個增量往往是實現基本需求的核心產品。核心產品交付用戶使用后，經過評價形成下一個增量的開發(fā)計劃，它包括對核心產品的修改和一些新功能的發(fā)布。這個過程在每個增量發(fā)布后不斷重復，直到產生最終的完善產品。傳統(tǒng)方法學與面向對象方法學結構化方法采用“抽象”和“分解”兩個基本手段。通常包括SA、SD和SP三個方面屬于功能/數據方法，即將系統(tǒng)的功能和涉及的數據或多或少地分開來處理面向對象建模方法面向對象方法學出現于20世紀80年代中后期，并迅速成為20世紀90年代的主流開發(fā)方法。以客觀世界中實體為基礎，將客觀實體的屬性與操作封裝成對象，對象之間通過傳遞消息互相聯(lián)系，以模擬現實中不同事物彼此之間的聯(lián)系。采用“封裝”、“分類”和“繼承”三個基本原則。包括OOA、OOD、OOP、OOT四個方面典型的面向對象方法–OMT（Object

Modeling

Technique）方法–Coad/Yourdon方法–Booch方法–OOSE（Object-Oriented

Software

Engineering）方法OMT方法三種模型對象模型（類圖）：描述系統(tǒng)的靜態(tài)結構，包括構成系統(tǒng)的類和對象，它們的屬性和操作，以及它們之間的關系。動態(tài)模型（狀態(tài)圖）：描述在任何時刻對象及其關系的改變。功能模型（數據流圖）：表明通過計算，從輸入數據能得到什么樣的輸出數據，不考慮參加計算的數據按什么時序執(zhí)行。開發(fā)過程的四個階段分析：基于問題和用戶需求的描述，建立現實世界的模型（對象模型，動態(tài)模型，功能模型）系統(tǒng)設計：結合問題域的知識和目標系統(tǒng)的體系結構（求解域），將目標系統(tǒng)分解為子系統(tǒng)。對象設計：基于分析模型和求解域中的體系結構等添加的實現細節(jié)，完成系統(tǒng)設計。實現：將設計轉換為特定的編程語言或硬件。Coad/Yourdon方法–OOA模型的五個層次主題（Subject

Layer）類-對象（Class-&-ObjectLayer）結構（Structure

Layer）屬性（AttributeLayer）方法（Service

Layer）–

OOD模型的四個部件人機交互問題域數據管理任務管理主題層

類與對象層結構層屬性層服務層Booch方法OOD步驟在給定的抽象層次上識別類和對象識別這些對象和類的語義識別這些類和對象之間的關系實現類和對象圖形技術類圖、對象圖、狀態(tài)轉移圖、時態(tài)圖、模塊圖、進程圖Ivar

Jacobson的OOSE方法–

是一種use

case驅動的開發(fā)方法。use

case是指行為相

關的事務序列，該序列將由用戶在與系統(tǒng)對話中執(zhí)行。因此，每一個use

case就是一個使用系統(tǒng)的方式。過程改進：在軟件工程中為了更有效地達到優(yōu)化軟件過程的目的所實施的改善或改變其軟件過程的系列活動。過程改進的兩種模式：目標驅動模式、缺陷驅動模式CMM(Capability

Maturity

Model)：即能力成熟度模型，是國際公認的對軟件組織進行成熟度等級認證的重要標準。軟件過程能力(SoftwareProcessCapability)：描述開發(fā)組織或項目組遵循其軟件過程能夠實現預期結果的程度。軟件過程性能(Software

Process

Performance)：表示開發(fā)組織或項目組遵循其軟件過程所得到的實際結果。軟件過程成熟度(SoftwareProcessMaturity)：一個特定軟件過程被明確和有效地定義，管理測量和控制的程度。成熟度等級(MaturityLevels)：軟件開發(fā)組織在走向成熟的途中幾個具有明確定義的表示軟件過程能力成熟度的平臺。需求定義用戶解決問題或達到目標所需要的條件或能力（Capability）系統(tǒng)或系統(tǒng)部件要滿足合同、標準、規(guī)范或其他正式規(guī)定文檔所需具有的條件或能力反映上述兩個定義中所描述的條件或能力的文檔說需求分析需求描述原型及測試文檔化及驗證尚未掌握所有的需求描述方法不得當功能不合實際需求的獲取與分析需求定義與規(guī)格說明確定需求的過程需求的層次與種類業(yè)務需求：反映了組織機構或客戶對系統(tǒng)和產品高層次的目標要求。體現在項目前景與范圍文檔中。用戶需求：描述了用戶使用軟件產品所必須完成的任務。體現在用例文檔或方案腳本中。功能需求和非功能需求：定義了開發(fā)人員必須實現的軟件功能，體現在需求文檔中。功能需求：物理環(huán)境、接口、用戶、功能、數據、資源、安全性非功能需求：可移植性、可靠性、效率或性能、易用性、可重用性、安全性需求的驗證審查需求文檔依據需求編寫測試用例編寫用戶手冊確定合格的標準好的需求應具有的特性正確性：與用戶對軟件產品的期望一致無二義性完整性一致性可行性可驗證性可跟蹤性非計算機人員能夠理解需求描述靜態(tài)描述方法間接引用、關系遞歸、公理化定義、語言描述、數據抽象動態(tài)描述方法決策表、函數描述和狀態(tài)轉移圖、Petri網面向對象的描述方法Warnier圖數據流圖需求文檔需求定義文檔（Requirements

Definition）從用戶的角度出發(fā)，將用戶希望系統(tǒng)實現的功能作一個匯總，通常由用戶和開發(fā)者共同撰寫主要讀者為用戶需求規(guī)格說明(Requirements

Specification)又稱功能規(guī)格說明、需求協(xié)議和系統(tǒng)規(guī)格說明精確地闡述了一個軟件系統(tǒng)必須提供的功能和性能以及它所要考慮的限制條件由系統(tǒng)分析師撰寫主要讀者為系統(tǒng)設計與開發(fā)人員需求管理變更控制版本控制需求跟蹤需求狀態(tài)面向對象=對象+類+繼承+消息通信類:一組具有相同屬性和相同行為的對象的集合消息：一個對象與另一個對象的通信單元，是要求某個對象執(zhí)行某個操作的規(guī)格說明。繼承：子類自動地共享父類（超類）的屬性和方法OO系統(tǒng)設計任務系統(tǒng)分解成子系統(tǒng)識別問題中固有的并發(fā)性將子系統(tǒng)分配給處理器和任務選擇數據存儲管理方法處理對全局資源的訪問選擇軟件控制機制處理邊界條件設置平衡的優(yōu)先級用委派替換繼承l(wèi)istaddremovefirstlaststackpushpoplistaddremovefirstlaststackpushpopDemeter法則只與你直接的朋友交談不要跟陌生人說話每個軟件單位對其他單位都只有最少的知識，而且局限于那些與本單位相關的軟件單位某人朋友陌生人某人朋友陌生人朋友圈Call

forwordingUMLUML是一種可視化建模語言UML不是一種開發(fā)方法，不局限于特定開發(fā)過程用例（Use-Case）是系統(tǒng)的一種行為，它為執(zhí)行者產生一定的價值結果。用例描述執(zhí)行者想要系統(tǒng)完成的事情。用例應該是一個完整的任務。參與者(Actor)是同系統(tǒng)交互的所有事物，如人、其它軟件、數據存儲、硬件設備或網絡。每個執(zhí)行者定義一種特定角色。用例圖：表示一組用例、參與者及它們之間的關系，從用戶的角度出發(fā)對系統(tǒng)建模順序圖（Sequence

Diagram）描述執(zhí)行系統(tǒng)功能的各個角色之間相互傳遞消息的順序關系，是強調消息的時間順序的交互圖。協(xié)作圖（Collaboration

Diagram）除了描述對象間的關聯(lián)外，還顯示對象間的消息傳遞狀態(tài)圖（State

Diagram）描繪對象的狀態(tài)、觸發(fā)狀態(tài)轉換的事件、以及對象的行為（對事件的響應）?；顒訄D（Activity

Diagram）狀態(tài)圖的一個變體，但狀態(tài)是計算過程的活動狀態(tài)（計算過程中命令的執(zhí)行或工作流中活動的進行），而不是普通對象狀態(tài)?；顒訄D本質上是一個流程圖，表示從活動到活動的控制流。部署圖（Deploy

Diagram）表示系統(tǒng)運行時包含的節(jié)點以及節(jié)點間的聯(lián)系，節(jié)點包含構件的配置，每個構件必須存在于某個節(jié)點上構件圖（Component

Diagram）系統(tǒng)建模過程中將可重用的塊包裝成具有可替代性的物理單元，這些單元稱為構件；構件圖用構件及構件間的接口和依賴關系來表示設計元素的具體實現RUP(Rational

Unified

Process)用例驅動以架構為中心迭代和增量開發(fā)過程驗證實現完成實現模型測試模型設計模型用例模型用例驅動初始迭代架構迭代架構迭代開發(fā)迭代開發(fā)迭代開發(fā)迭代過渡迭代過渡迭代迭代和增量開發(fā)過程四個階段開始（Inception）

-定義項目范圍精化（Elaboration）

-項目計劃、需求、架構構造（Construction）

-軟件產品過渡（Transition）

-軟件產品過渡給用戶迭代：一系列明確的具有建立計劃和評估準則的活動，將產生一個可執(zhí)行的發(fā)布（內部或外部）開始

精化

構造

過渡次里程碑:

發(fā)布設計內容數據設計：信息模型、軟件數據結構體系結構設計：定義軟件部件間的關系接口設計：軟件內部、外部及與人之間的通信過程設計：軟件組件的過程性描述分解與模塊化的基本原理C

(P1+P2)>C

(P1)+C

(P2)E

(P1+P2)>E

(P1)+E

(P2)C為問題的復雜度，E為解題需要的工作量軟件體系結構：組成系統(tǒng)的元素、元素間的交互、元素組成的模式以及模式的約束。軟件體系結構風格：描述某一特定應用領域中系統(tǒng)組織方式的慣用模式。它反映了領域中眾多系統(tǒng)所共有的結構和語義特性，并指導如何將各個模塊和子系統(tǒng)有效地組織成一個完整的系統(tǒng)典型的體系結構風格管道/過濾器面向對象風格隱式調用分層數據倉庫（Repository）解釋器管道/過濾器–

每個構件都有一組輸入和輸出，構件讀輸入的數據流，經過內部處理，然后產生輸出數據流。過濾器表示數據轉換的構件，彼此相互獨立；管道將一個過濾器的輸出傳到另一過濾器的輸入隱式調用構件不直接調用一個過程，而是觸發(fā)或廣播一個或多個事件。系統(tǒng)中的其它構件中的過程在一個或多個事件中注冊，當一個事件被觸發(fā)，系統(tǒng)自動調用在這個事件中注冊的所有過程，這樣，一個事件的觸發(fā)就導致了另一模塊中的過程的調用。分層層次系統(tǒng)組織成一個層次結構，每一層為上層服務，并作為下層客戶。分為：封閉式、開放式模式–是一種思想，它已經適用于一個實踐環(huán)境中，并有可能適用于其他的環(huán)境。–每一個模式描述了一個在我們周圍不斷重復發(fā)生的問題，以及該問題的解決方案的核心，這樣，你就能一次又一次的使用該方案而不必做重復的勞動模式的四個基本要素模式名稱（pattern

name）問題(problem)解決方案(solution)效果(consequences）構件獨立性內聚（cohesion）：模塊內部各成分之間耦合（coupling）：一個模塊與其它模塊之間塊內聯(lián)系強，塊間聯(lián)系弱耦合內容耦合公共耦合控制耦合特征耦合數據耦合非直接耦合content

couplingcommon

couplingcontrol

couplingstamp

couplingdata

couplingno

direct

coupling內聚cohesion功能性內聚：模塊中各個組成部分構成一個整體并共同完成一個單一的功能順序性內聚：模塊中的各個部分都與同一個功能密切相關，并且必須按照先后順序執(zhí)行(通常前一個部分的輸出數據就是后一個部分的輸入數據)通訊性內聚：模塊中的各個部分使用同一個輸入數據或產生同一個輸出數據過程性內聚：模塊中的各個部分相關，并且必須按特定的次序執(zhí)行時間性內聚：模塊包含了在同一時間段中執(zhí)行的多個任務邏輯性內聚：模塊可實現多個邏輯上相同或相似的一類功能偶然性內聚：模塊由多個完成不同任務的語句段組成，各語句段之間的聯(lián)系十分松散或根本沒有任何聯(lián)系程序設計風格程序設計風格的作用就是使代碼容易讀風格良好的代碼更容易閱讀和理解，其中的錯