1.4 軟件工程

定義：將系統(tǒng)的、規(guī)范的、可度量的工程化方法應(yīng)用于軟件開(kāi)發(fā)、運(yùn)行和維護(hù)的全過(guò)程即上述方法的研究

軟件工程由方法、工具和過(guò)程三個(gè)部分組成

1.4.1 需求分析

軟件需求是指用戶對(duì)新系統(tǒng)在功能、行為、性能、設(shè)計(jì)約束等方面的期望。

需求層次

1. 業(yè)務(wù)需求：是反映企業(yè)或客戶對(duì)系統(tǒng)高層次的目標(biāo)要求，通常來(lái)自項(xiàng)目投資人、購(gòu)買(mǎi)產(chǎn)品的客戶、客戶單位的管理人員、市場(chǎng)營(yíng)銷部門(mén)或產(chǎn)品策劃部門(mén)
2. 用戶需求：描述的是用戶的具體目標(biāo)，或用戶要求系統(tǒng)必須完成的任務(wù)
3. 系統(tǒng)需求：從系統(tǒng)的角度來(lái)說(shuō)明軟件的需求，包括功能需求、非功能需求和設(shè)計(jì)約束

質(zhì)量功能部署

質(zhì)量功能部署：QFD-Quality Function Deployment，是一種將用戶需求轉(zhuǎn)化成軟件需求的技術(shù)，其目的是最大限度的提升軟件工程過(guò)程中用戶的滿意度

• 常規(guī)需求：用戶認(rèn)為系統(tǒng)應(yīng)該做到的功能或性能
• 期望需求：用戶想當(dāng)然認(rèn)為系統(tǒng)應(yīng)具備的功能或性能，但不能正確描述自己想要得到這些功能或性能需求，如果期望需求沒(méi)有得到實(shí)現(xiàn)，用戶會(huì)感到不滿意
• 意外需求：也稱為興奮需求，使用戶要求范圍外的功能或性能

需求獲取

需求獲取是一個(gè)確定或理解不同的項(xiàng)目干系人的需求和約束的過(guò)程。

常見(jiàn)的需求獲取方法：用戶訪談、問(wèn)卷調(diào)查、采樣、情節(jié)串聯(lián)版、聯(lián)合需求計(jì)劃
信息系統(tǒng)項(xiàng)目需求獲取的方法：問(wèn)卷調(diào)查、會(huì)議討論、界面原型、可運(yùn)行原型系統(tǒng)

需求分析

需求分析人員需要把雜亂無(wú)章的用戶要求和期望轉(zhuǎn)化為用戶需求、這就是需求分析工作。

一個(gè)好的需求應(yīng)該具有：無(wú)二義性、完整性、一致性、可測(cè)試性、確定性、可跟蹤性、正確性、必要性。

需求分析的方法：

• 結(jié)構(gòu)化分析方法：
  • 數(shù)據(jù)模型：實(shí)體聯(lián)系圖、ER圖
  • 功能模型：數(shù)據(jù)流圖、DFD–Data Flow Diagram
  • 行為模型：狀態(tài)轉(zhuǎn)化圖、STD–State Transform Diagram
• 面向?qū)ο蠓治龇椒?#xff1a;OOA
  • 使用用例模型方法來(lái)描述系統(tǒng)需求
  • 使用分析模型描述系統(tǒng)的基本邏輯結(jié)構(gòu)，展示對(duì)象和類如何組成系統(tǒng)（靜態(tài)模型），以及他們?nèi)绾伪３滞ㄐ?#xff0c;實(shí)現(xiàn)系統(tǒng)行為（動(dòng)態(tài)模型）

需求軟件規(guī)格說(shuō)明書(shū)

需求軟件規(guī)格說(shuō)明書(shū)：Software Requirement Specification SRS，是需求開(kāi)發(fā)活動(dòng)的產(chǎn)物，編制目的是是項(xiàng)目干系人與開(kāi)發(fā)團(tuán)隊(duì)對(duì)系統(tǒng)的初始規(guī)定有一個(gè)共同的理解，使其成為整個(gè)開(kāi)發(fā)工作的基礎(chǔ)。

• 范圍
• 引用文件
• 需求（SRS主體部分）
• 合格性規(guī)定
• 需求可追蹤性
• 尚未解決的問(wèn)題
• 注解
• 附錄

需求驗(yàn)證

需求驗(yàn)證也成需求確認(rèn)，主要確認(rèn)下面幾個(gè)內(nèi)容：

• SRS正確的描述了預(yù)期的、滿足干系人需求的系統(tǒng)行為和特征
• SRS中的軟件需求是從系統(tǒng)需求、業(yè)務(wù)規(guī)格和其他來(lái)源中正確推導(dǎo)而來(lái)的
• 需求是完整的和高質(zhì)量的
• 需求的表示在所有的地方都是一致的
• 需求為繼續(xù)進(jìn)行系統(tǒng)設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試提供了足夠基礎(chǔ)
• 通過(guò)需求評(píng)審和需求測(cè)試工作來(lái)對(duì)需求進(jìn)行驗(yàn)證

對(duì)象 = 屬性+方法

UML

UML：Unified Modeling Language，統(tǒng)一建模語(yǔ)言，支持從需求分析開(kāi)始的軟件開(kāi)發(fā)的全過(guò)程。是一個(gè)支持模型化和軟件系統(tǒng)開(kāi)發(fā)的圖形化語(yǔ)言、為軟件開(kāi)發(fā)的所有階段提供模型化和可視化支持，包括由需求分析到規(guī)格，到構(gòu)造和配置。

組成UML的3個(gè)要素

• 基本構(gòu)造塊（事物、關(guān)系和圖）
• 規(guī)則（支配這些構(gòu)造塊如何放置在一起）
• 機(jī)制（運(yùn)用于整個(gè)語(yǔ)言的機(jī)制）

事物：也成建模元素

• 結(jié)構(gòu)事物：是靜態(tài)部分，類、接口、協(xié)作、用例、活動(dòng)類、構(gòu)件和節(jié)點(diǎn)
• 行為事物：是動(dòng)態(tài)部分，代表時(shí)間和空間上的動(dòng)作，一種是交互，另一種是狀態(tài)機(jī)
• 分組事物：是組織部分，UML只有一種分組事物，稱為包
• 注釋事物：UML解釋部分

關(guān)系：UML用關(guān)系把事物結(jié)合在一起

• 依賴：兩個(gè)事物之間的語(yǔ)義關(guān)系，其中一個(gè)事物發(fā)生變化會(huì)影響另一個(gè)事物的語(yǔ)義
• 關(guān)聯(lián)：描述一組對(duì)象之間連接的結(jié)構(gòu)關(guān)系
• 泛化：一般化和特殊化的關(guān)系，描述特殊元素的對(duì)象可替換一般元素的額對(duì)象
• 實(shí)現(xiàn)：類之間的語(yǔ)義關(guān)系，其中的一個(gè)類指定了有另一個(gè)類保證執(zhí)行的契約

圖：

• 類圖：實(shí)體類的靜態(tài)關(guān)系，是軟件的藍(lán)圖，詳細(xì)描述了系統(tǒng)內(nèi)各個(gè)對(duì)象的相關(guān)的類，以及這些類之間的靜態(tài)關(guān)系
  

• 對(duì)象圖：表示某一時(shí)刻類的對(duì)象靜態(tài)結(jié)構(gòu)和行為
  

• 構(gòu)件圖：描述類的實(shí)現(xiàn)環(huán)境
  

• 用例圖：用戶觀察到系統(tǒng)功能的模型圖，列出了系統(tǒng)中的用例和參與者。顯示哪個(gè)參與者參與了哪個(gè)用例的執(zhí)行。用于業(yè)務(wù)建模、需求獲取、定義。靜態(tài)
  

• 順序圖：用于顯示對(duì)象間的交互活動(dòng)，關(guān)注對(duì)象之間消息傳送的時(shí)間順序。
  

• 狀態(tài)圖：利用狀態(tài)和事件描述對(duì)象本身的行為。動(dòng)態(tài)
  

• 活動(dòng)圖：通過(guò)動(dòng)態(tài)來(lái)組織，主要用于描述某一方法、機(jī)制或用例的內(nèi)部行為
  

• 部署圖：描述系統(tǒng)所需的硬件構(gòu)件的物理部署。
  
  UML 視圖：就是對(duì)上面圖的分類

• 用例視圖：最基本的需求分析模型，如用例視圖

• 邏輯視圖：也稱為設(shè)計(jì)視圖，如類圖、對(duì)象圖以及包圖

• 進(jìn)程視圖：可執(zhí)行線程和進(jìn)程作為活動(dòng)類的建模，他是邏輯視圖的一次執(zhí)行實(shí)例，描述了并發(fā)與同步結(jié)構(gòu)，如狀態(tài)圖、活動(dòng)圖、時(shí)序圖等

• 實(shí)現(xiàn)視圖：對(duì)組成基于系統(tǒng)的物理代碼的文件和構(gòu)件進(jìn)行建模，如構(gòu)件圖

• 部署視圖：把構(gòu)件部署到一組物理節(jié)點(diǎn)上，表示軟件到硬件的映射和分布結(jié)構(gòu)，如部署圖

面向?qū)ο蠓治?/h4>

1.4.2 軟件架構(gòu)設(shè)計(jì)

軟件架構(gòu)設(shè)計(jì)核心問(wèn)題：是能否達(dá)到架構(gòu)級(jí)的軟件復(fù)用，能否在不同的系統(tǒng)中，使用同一個(gè)軟件架構(gòu)。

解決好軟件的復(fù)用、質(zhì)量和維護(hù)問(wèn)題，是研究軟件架構(gòu)的根本目的。

軟件復(fù)用有利于節(jié)省工期、減少成本、保持質(zhì)量

軟件架構(gòu)的風(fēng)格

1. 數(shù)據(jù)流風(fēng)格：包括批處理序列和管道/過(guò)濾器風(fēng)格
   

2. 調(diào)用/返回風(fēng)格：包括主程序/子程序、數(shù)據(jù)抽象和面向?qū)ο?#xff0c;以及層次結(jié)構(gòu)
   

3. 獨(dú)立架構(gòu)風(fēng)格：包括進(jìn)程通信和事件驅(qū)動(dòng)系統(tǒng)
   基于事件驅(qū)動(dòng)的系統(tǒng)，有點(diǎn)類似設(shè)計(jì)模型的觀察者模式，由構(gòu)件公布或者廣播一些事件，其他構(gòu)件對(duì)此事件進(jìn)行注冊(cè)。當(dāng)這個(gè)事件被觸發(fā)時(shí)，立即通知這個(gè)事件上注冊(cè)的過(guò)程

4. 虛擬機(jī)風(fēng)格：包括解釋器和基于規(guī)則的系統(tǒng)
   具有解釋器風(fēng)格的軟件中含有一個(gè)虛擬機(jī)，可以仿真硬件的執(zhí)行過(guò)程和一些關(guān)鍵的應(yīng)用，解釋器通常被用來(lái)建立一種虛擬機(jī)一彌補(bǔ)語(yǔ)義上的差異

5. 倉(cāng)庫(kù)風(fēng)格：包括數(shù)據(jù)庫(kù)系統(tǒng)、黑板系統(tǒng)和超文本系統(tǒng)
   

軟件架構(gòu)評(píng)估

敏感點(diǎn)：一個(gè)或者多個(gè)構(gòu)件的額特性

權(quán)衡點(diǎn)：是影響多個(gè)質(zhì)量屬性的特性，是多個(gè)質(zhì)量屬性敏感點(diǎn)

• 基于調(diào)查問(wèn)卷方式
• 基于場(chǎng)景方式
• 基于度量方式

1.4.3 軟件設(shè)計(jì)

軟件設(shè)計(jì)是需求分析的延伸和拓展

需求分析階段：解決“做什么”的問(wèn)題
軟件設(shè)計(jì)階段：解決“怎么做”的問(wèn)題

1. 結(jié)構(gòu)化設(shè)計(jì)SD：
   • 自頂向下、逐步求精
   • 模塊化、相對(duì)獨(dú)立
   • 高內(nèi)聚、低耦合
2. 面向?qū)ο蟮脑O(shè)計(jì)OOD
   • 抽象、封裝和可擴(kuò)展
   • 遵循OOD設(shè)計(jì)原則
3. 設(shè)計(jì)模式
   • 包含模式名稱、問(wèn)題、目的、解決方案、效果、實(shí)例代碼等

1.4.4 軟件工程的過(guò)程管理

CMMI：Capability Maturity Model Integration是指能力成熟度模型集成

CMMI是一種為組織有效性提供基本要素的過(guò)程改進(jìn)方法，它的目的是幫助軟件企業(yè)對(duì)軟件工程進(jìn)行管理和改進(jìn)，增強(qiáng)開(kāi)發(fā)與改進(jìn)能力從而能按時(shí)、不超預(yù)算的開(kāi)發(fā)出高質(zhì)量的軟件。

CMMI過(guò)程域可分為4類：項(xiàng)目管理、過(guò)程管理、工程和支持四個(gè)級(jí)別

CMMI有階段式和連續(xù)式兩種表現(xiàn)方式：

• 使用階段式表示法使你能達(dá)到“成熟度級(jí)別”，階段式表示法用于模型整體
• 使用連續(xù)式表示法使你能達(dá)成“能力級(jí)別”。連續(xù)式表示用于單個(gè)過(guò)程域

過(guò)程域的階段式分組

連續(xù)式分組

1.4.5 軟件測(cè)試及管理

測(cè)試是在軟件交付給客戶之前所必須完成的重要步驟。

1.4.5.1 測(cè)試方法

• 靜態(tài)測(cè)試：采用人工檢測(cè)和計(jì)算機(jī)輔助靜態(tài)分析的手段對(duì)程序進(jìn)行檢測(cè)。
• 動(dòng)態(tài)測(cè)試：在計(jì)算機(jī)上實(shí)際運(yùn)行程序進(jìn)行軟件測(cè)試。白盒測(cè)試與黑盒測(cè)試

1.4.5.2 測(cè)試類型

• 單元測(cè)試：模塊測(cè)試
• 集成測(cè)試：模塊之間接口聯(lián)調(diào)
• 確認(rèn)測(cè)試：驗(yàn)證軟件功能、性能和其它特性是否與用戶需求一致
• 系統(tǒng)測(cè)試：對(duì)象是完整的、集成的計(jì)算機(jī)系統(tǒng)。黑盒測(cè)試，真實(shí)環(huán)境下驗(yàn)證
• 配置測(cè)試：軟件配置
• 回歸測(cè)試：軟件變更之后

1.4.5.3 面向?qū)ο鬁y(cè)試

• 封裝性：考慮信息隱蔽對(duì)測(cè)試的影響
• 繼承性：考慮繼承對(duì)充分性的影響
• 多態(tài)性：考慮動(dòng)態(tài)綁定對(duì)測(cè)試充分性影響

1.4.5.4 軟件調(diào)試

測(cè)試與調(diào)試的區(qū)別

• 測(cè)試的目的是找出錯(cuò)誤，調(diào)試的目的是定位錯(cuò)誤并修正錯(cuò)誤
• 調(diào)試是測(cè)試之后的活動(dòng)，測(cè)試和調(diào)試在目標(biāo)、方法和思路上都有所不同
• 測(cè)試從一個(gè)已知的條件開(kāi)始，使用預(yù)先定義的過(guò)程，由預(yù)知的結(jié)果；調(diào)試從一個(gè)未知的條件開(kāi)始，結(jié)束的過(guò)程不可預(yù)計(jì)
• 測(cè)試過(guò)程事先設(shè)計(jì)，進(jìn)度可以事先確定；調(diào)試不能描述過(guò)程或持續(xù)時(shí)間

1.4.5.5 軟件測(cè)試管理

• 過(guò)程管理
• 配置管理
• 評(píng)審工作
  • 測(cè)試就緒評(píng)審
  • 測(cè)試評(píng)審

1.4.5.6 軟件集成技術(shù)

企業(yè)應(yīng)用集成：Enterprise Application Integration EAI，企業(yè)應(yīng)用集成可以消除信息孤島，將多個(gè)企業(yè)信息系統(tǒng)連接起來(lái)，實(shí)現(xiàn)無(wú)縫集成，使之像一個(gè)整體一樣。EAI所連接的應(yīng)用包括各種電子商務(wù)系統(tǒng)、ERP、CRM、SCM、OA、數(shù)據(jù)庫(kù)系統(tǒng)和數(shù)據(jù)倉(cāng)庫(kù)。

1. 表示集成
   也稱頁(yè)面集成，是把原有零散的系統(tǒng)頁(yè)面集中在一個(gè)新的頁(yè)面中；為用戶提供看上去統(tǒng)一，但是有多個(gè)系統(tǒng)組成的應(yīng)用系統(tǒng)；當(dāng)只有可能在顯示界面上實(shí)現(xiàn)集成時(shí)。
   

2. 數(shù)據(jù)集成

   • 通過(guò)不同的中間件工具完成數(shù)據(jù)集成
   • 數(shù)據(jù)集成比表示集成更加靈活，但是當(dāng)業(yè)務(wù)邏輯發(fā)生變化時(shí)，數(shù)據(jù)集成就會(huì)面臨困難
     

3. 控制集成
   也稱功能集成和應(yīng)用集成

   • 在業(yè)務(wù)邏輯層上對(duì)應(yīng)用系統(tǒng)進(jìn)行集成
   • 借助于遠(yuǎn)程過(guò)程或方法調(diào)用、面向消息的中間件、分布式對(duì)象技術(shù)和事物處理監(jiān)控器來(lái)實(shí)現(xiàn)
   • 與數(shù)據(jù)集成和表示集成相比，靈活性更高
   • 當(dāng)被集成業(yè)務(wù)系統(tǒng)沒(méi)有提供API時(shí)，集成難度會(huì)增加
     

4. 業(yè)務(wù)集成
   也稱過(guò)程集成
   業(yè)務(wù)流程集成超越了數(shù)據(jù)和系統(tǒng)，有一些列基于標(biāo)準(zhǔn)、統(tǒng)一數(shù)據(jù)格式的工作流完成

5. 企業(yè)之間集成
   EAI技術(shù)使用用大多數(shù)電子商務(wù)企業(yè)，完成企業(yè)之間的應(yīng)用集成。目的是實(shí)現(xiàn)信息共享，是企業(yè)充分利用外部資源。