一、軟件工程概論

概念

• 軟件危機（軟件開發(fā)和維護過程中遇到的一系列嚴重的問題）
  • 軟件開發(fā)成本日益增長
  • 軟件開發(fā)進度難以控制
  • 軟件質量難以保證
  • 軟件維護困難

成本，質量難以保證，維護難，開發(fā)過程難控制

• *軟件危機的原因
  • 軟件的復雜性
    • 開發(fā)結構的逐漸復雜性
    • 軟件技術的發(fā)展復雜性
  • 軟件的特殊性
  • 人們認識的局限性

圍繞軟件越來越“復雜”

• *軟件工程定義：將系統(tǒng)化的、規(guī)范的、可度量的方法應用于軟件的開發(fā)、運行和維護的過程，即將工程化應用于軟件中。

簡單的背為將工程化應用在軟件中

• 軟件生命周期

  • 需求分析
  • 系統(tǒng)設計
  • 系統(tǒng)實現(xiàn)
  • 測試
  • 維護

• *軟件系統(tǒng)分析與設計的重要性

  • 需求分析為整個軟件打下良好基礎
  • 設計階段為軟件的編寫打下良好基礎
  • 這兩個階段若做好可以從根本上減少軟件開發(fā)過程的時間和成本
  • 反之，帶來的損失是不可估量的

整本書的重要性，肯定要背下來，需求分析打下基礎，設計打下基礎，做的好有很多好處，做的不好損失太大了

軟件工程學的三個核心元素

• 軟件開發(fā)過程模型

  • 線性模型（瀑布模型）
    • 優(yōu)點：1.有利于開發(fā)人員管理2.有利于使用軟件開發(fā)工具，提高了效率
    • 缺點：1.開發(fā)是線性的，開發(fā)結果得到慢，與用戶交互少了2.前期的的錯誤擴散到后期3.無法解決復雜情況
  • 增量模型
    • 優(yōu)點：1.靈活性高2.需要人員少
    • 缺點：1.需要開發(fā)式的體系結構2.退化成邊做邊改模型，失去整體性
  • 螺旋模型
    • 優(yōu)點：1.支持用戶需求動態(tài)變化2.方便用戶參與，提高軟件適應能力3.方便管理人員及時調整管理決策，降低開發(fā)風險
    • 缺點：1.需要豐富的風險評估經(jīng)驗和專業(yè)知識2.不適用于合同項目的開發(fā)3.過多的迭代造成成本增加，延遲提交時間

• 軟件開發(fā)方法

  • 結構化方法
  • 面向對象方法
  • 相同點：
    • 都是軟件系統(tǒng)的開發(fā)方法
    • 在運用分解和抽象原則上的要求是完全一致的。
    • 局部化和重用性設計上的一致。
  • 不同點：
    • 結構化方法是一種面向數(shù)據(jù)流的開發(fā)方法，面向對象方法是一種面向對象的開發(fā)方法
    • 處理問題時的出發(fā)點不同。前者是一種面向過程的開發(fā)方法
    • 處理問題的基本單位和層次邏輯關系不同
    • 數(shù)據(jù)處理方式與控制程序方式不同
    • 分析設計與編碼轉換方式不同

• 軟件工程工具（泛指軟件開發(fā)全過程中使用的各種程序系統(tǒng)）

  • 工具
  • 工具接口
  • 用戶接口

• *CASE（計算機輔助軟件工程）原指支持管理信息系統(tǒng)開發(fā)的、由各種計算機輔助軟件和工具組成的大型綜合性軟件開發(fā)環(huán)境；現(xiàn)已轉化為支持整套獨立

• *CASE的分類

  1. 事務系統(tǒng)規(guī)劃工具(Business System Planning Tools)
  2. 項目管理工具(Project Management Tools)
  3. 支撐工具(Support Tools)
  4. 分析與設計工具(Analysis and Design Tools)
  5. 程序設計工具(Programming Tools)
  6. 測試與分析工具(Test and Analysis Tools)
  7. 原型建造工具(Prototyping Tools)
  8. 維護工具(Maintenance Tools)
  9. 框架工具(Frame Tools)

二、結構化分析和設計方法

結構化方法的基本思想

• 結構化方法的特點：自頂向下地分析與設計，逐步求精。

• 結構化分析

  • 功能建模
  • 數(shù)據(jù)建模（數(shù)據(jù)流圖、層次化數(shù)據(jù)流圖）

• 結構化設計

  • 概要設計（軟件結構圖）
  • 詳細設計

• 數(shù)據(jù)流圖

  
  

中間的訂書組去掉

• 軟件結構圖

  
  
  
  

三、面向對象分析和設計方法概述

概念

• 面向對象=對象+類+繼承+通信

• 面向對象的特點

  • 抽象性
  • 封裝性
  • 共享性（共享【數(shù)據(jù)結構和行為特征】）
    • 同一類中所有實例共享數(shù)據(jù)結構和行為特征
    • 同一應用中所有實例通過繼承共享數(shù)據(jù)結構和行為特征
    • 不同應用中所有實例通過復用共享數(shù)據(jù)結構和行為特征

• RUP統(tǒng)一開發(fā)過程：核心在于用例驅動；以體系結構為核心；以質量控制和風險管理為目標；迭代的、增量的過程

• RUP的特點

UML統(tǒng)一建模語言

• *UML的意義

1. UML統(tǒng)一了各種方法對不同類型的系統(tǒng)、不同開發(fā)階段以及不同內部概念的不同觀點，從而有效的消除了各種建模語言之間不必要的差異。
2. UML建模能力比其它面向對象建模方法更強。它不僅適合于一般系統(tǒng)的開發(fā)，而且對并行、分布式系統(tǒng)的建模尤為適宜。
3. 使用UML使硬件組件和軟件組件之間將會有更大的透明度。便攜性和綜合效率將會增加。

• UML視圖
  • 用例視圖
  • 邏輯視圖
  • 構件視圖
  • 進程視圖
  • 部署視圖

• 四種關系
  • 依賴：一個元素的變化將影響到某個元素或向其提供信息
    ------ ?
  • 關聯(lián)
    ——?
  • 泛化（繼承）
    ——?
  • 實現(xiàn)
    ------?

虛線為依賴，實線為關聯(lián)（沒屁意義），空心箭頭的很容易另記。

四、需求分析與用例建模

概念

• 需求分析的任務是發(fā)現(xiàn)、求精、建模和規(guī)格說明的過程。包括
  • 細化在項目開發(fā)計劃中規(guī)定的軟件范圍
  • 創(chuàng)建所需要的數(shù)據(jù)模型、功能模型和控制模型
  • 分析可選擇的解決方案，并將它們分配到各個軟件成分中去
• 需求分析的步驟
  • 問題識別（需求獲?。?/li>
  • 分析與綜合（需求建模）
  • 編制需求分析階段的文檔（需求描述）
  • 驗證（需求評審）

就背括號里的步驟了

• 場景和用例：用例：系統(tǒng)執(zhí)行的完整動作，場景：用例的實例

• 場景的作用

  • 幫助我們驗證用例是否能滿足客戶提出來的需求
  • 驅動測試用例的編寫

• 規(guī)格說明

  • 用例名稱
  • 用例簡述
  • 行為者
  • 前置條件
  • 后置條件
  • 基本事件流
  • 備選事件流
  • 異常事件流

用例圖后要寫，必背

用例建模

• 用例之間的關系（包含、擴展、泛化）

• 一個用例圖示例：

• 關系的使用（這段文字太繞了不看了）
  • 一個用例偶爾使用另一個用例的功能描述時，采用繼承關系
  • 兩個以上用例重復處理同樣的動作，可采用使用關系或包含關系
  • 用例要采用多種控制方式對異常或任選動作進行處理時，采用擴展關系

一個例子

包括可以簡單理解成這個用例有什么，比如訂購的內容是提供用戶信息、付款安排等
擴展就是定購額外做的事情，我理解呢就是這個這個事物本身不一定要，但是在這次建模里有特殊性才附加

案例（一定要看書上兩個案例）

• 本人寫的只具有參考作用

1. 請根據(jù)以下要求畫出一個保險業(yè)務相關的用例圖。
   參保顧客與保險公司業(yè)務員簽署保險憑單；保險公司業(yè)務員統(tǒng)計自己業(yè)務范圍內的保險金額和參保顧客人數(shù)；保險公司業(yè)務經(jīng)理查詢統(tǒng)計公司所有保險總金額和參保顧客總人數(shù)。

1.先畫出頂層用例圖

下面針對保險業(yè)務處理、統(tǒng)計個人業(yè)務、查詢統(tǒng)計全公司業(yè)務分別進行細化

• 保險業(yè)務處理
  • 查看并選擇保險業(yè)務
  • 簽署保險憑證
• 統(tǒng)計個人業(yè)務
  • 統(tǒng)計自己參保顧客人數(shù)
  • 統(tǒng)計自己業(yè)務金額
• 查詢統(tǒng)計全公司業(yè)務
  • 查看公司總保險人數(shù)
  • 查看公司保險總金額

我覺得這樣寫的太馬虎了考試一定多想點方面

2.再畫出細化用例圖