軟件工程 系列爲本學期（2020春季）軟件工程以及軟件工程實踐課程筆記整理~
天朗氣清，惠風和暢，空氣裏漸漸飄起了調皮的柳絮
今天軟工老師終於上課啦，來更新一波筆記~
目錄
(三)問題分析圖(problem analysis diagram, PAD)
(四)HIPO圖（Hirearchy plus input/processing/output）
(七)過程設計語言（Process design language，PDL）
軟件設計：根據需求分析的“做什麼”來確定系統該“怎樣做”。需要有經驗的軟件設計師完成、設計方法遵循一系列的原則和策略、經過專家和用戶的評審
一、軟件設計的目標的任務
1.軟件設計的兩個階段
(1)概要設計
- 包含數據設計、體系結構設計、接口設計、過程設計
- 任務-->將需求分析轉化爲軟件的系統結構和數據結構
- 分解獨立的軟件部件
- 建立模塊之間的層次結構、調用關係、模塊間的接口、人機交互界面
(2)詳細設計-->對概要設計階段建立的模型進行詳細的定義和說明
- 確定每個模塊的具體算法
- 模塊內部數據結構和數據庫的物理結構
- 模塊接口的具體實現
- 每個模塊設計測試用例
- 文檔->複審
2.軟件設計的目標
通過一系列迭代過程生成一個要構造的實體的模型/表示
3.軟件設計中的信息流
在需求分析基礎上，將分析模型中的數據、功能、行爲模型-->設計模型中的數據設計、體系結構設計、接口設計、構件設計
(1)體系結構設計：軟件主要結構性元素及其之間的關係，從需求規約、分析模型和分析模型定義的系統交互中導出
(2)數據設計：將信息模型（E-R圖定義的對象和關係、數據字典中的詳細數據內容）-->數據結構/數據庫結構
(3)接口設計：內部模塊之間、軟件和外部系統之間、軟件和人之間的通信 基於數據流圖和控制流圖
(4)過程設計（構件設計）：描述軟件構件的內部實現細節
4.軟件設計的指導性原則
(1)可跟蹤性：設計階段的單獨一個元素可跟蹤到需求的一個或多個方面
(2)一致性：一致的概念、符號、術語；一致的內部接口、軟硬件接口
(3)可靠性：即使遇到異常數據、事件、操作也可以平滑巧妙地降級
(4)簡單性
(5)適應性：構件具有良好的可擴展性
(6)清晰性
二、軟件設計的基本原理
(一)模塊化
1.模塊
- 由一個總體標識符來代表的，包含輸入/輸出、邏輯處理功能、內部信息以及運行計劃的語句集合
- 模塊是構件的一種形式，eg:過程、函數宏、子函數
- 特點：接口、功能、邏輯（功能的實現方法）、狀態（運行環境和調用關係）
2.模塊化
- 將軟件系統劃分爲可獨立命名、單獨訪問的模塊，每個模塊具有特定的功能屬性，模塊集成到一起即可構成滿足用戶需求的軟件系統
- 可提高代碼的可使用、可重用、可理解性；簡化軟件維護
3.Merey標準-->如何分解、模塊大小如何設計
- 模塊可分解性
- 可組裝性
- 可理解性：不參照其他模塊可單獨理解
- 連續性：修改軟件模塊時只對少數模塊進行修改，且修改後不影響整體功能
- 保護性：模塊出現錯誤異常時隻影響自身
(二)抽象
1.抽象方法：從考慮的問題出發，撇開事物現象的、外部的、偶然的東西，抽出事物本質的、內在的、必然的東西，從空間形式和數量關係上揭示客觀對象的本質和規律。
2.軟件生命週期過程中每前進一步都是對軟件抽象層次的進一步細化。抽象的最低層次是源程序代碼。
3.兩種常用的抽象手段：
- 過程抽象-->任何一個完成明確功能的操作都可被當做單個實體
- 數據抽象-->定義數據類型和對該類型的操作、限制對象值的範圍
(三)逐步求精
1.是一種自頂向下的設計策略，逐步細化問題的實質和細節，最終完善地解決問題
2.在軟件設計中，逐步求精就是把軟件設計中的問題按照優先級和層次進行排隊，並逐步對各個問題進行解決
3.抽象和逐步求精是互補的過程，層次結構的上一層是下一層的抽象，下一層是上一層的求精
(四)信息隱藏
1.信息隱藏：模塊內的數據和過程對不需要這些信息的模塊是不能進行訪問的
2.使模塊更具有獨立性；使軟件維護相對容易
(五)模塊的獨立性
1.模塊獨立性：每個模塊只完成系統要求的獨立子功能，在數據和信息交互與其他模塊沒有或者極少關聯
2.具有獨立性的模塊容易開發-->功能分隔徹底使得接口簡單 容易測試和維護-->錯誤傳播的範圍小
3.衡量獨立程度的度量：耦合 內聚 -->目標：高內聚 低耦合
4.耦合-->軟件系統內部不同模塊之間的相互關聯程度的度量，耦合的強弱取決於模塊間接口的複雜程度、調用模塊的方式、組件間通信接口方式
(1)非直接耦合
模塊具有完全的功能上的獨立性，模塊之間不存在數據信息傳遞，僅依靠調用關係實現軟件功能
(2)數據耦合
模塊間的調用關係通過傳遞數據實現 eg:函數輸出值的傳遞
(3)特徵耦合
一個模塊向另一個模塊傳遞非全局的數據結構
(4)控制耦合
模塊間不僅傳遞數據，還傳遞對運行過程有影響的控制信號
使一個模塊的執行直接影響到接受控制信號模塊的運行
(5)外部耦合
一組模塊均訪問同一個全局簡單變量 eg:extern型的外部變量
(6)公共耦合
多個模塊共同引用公共數據環境（全局數據結構、共享通信區、內存公共覆蓋區、介質上共享文件）
(7)內容耦合
一個模塊直接修改、操作另一模塊的內部數據，或者直接轉入另一個模塊
5.內聚-->模塊內部數據和過程等信息之間的緊密程度。各元素聯繫越緊密，內聚性越高。
(1)偶然內聚
模塊內各處理元素之間沒有任何關係，對其修改需謹慎
(2)邏輯內聚
邏輯相關的功能被放在同一模塊中，eg:一個模塊讀取各種不同類型外設的輸入
邏輯內聚模塊各元素在功能上並無關係
(3)時間內聚
模塊完成的功能必須在同一時間內執行，功能只因爲時間因素關聯在一起。Eg: 系統初始化
(4)過程內聚
模塊內各個元素必須按照一定的順序執行，主要與程序的執行過程有關，而與功能無關 Eg:主模塊
弱點：超越了模塊的功能界限-->可能包含某一級模塊的功能，同時包含更低層模塊的功能
(5)通信內聚
模塊內所有處理元素都在同一數據結構上操作 Eg:事務處理系統
(6)順序內聚
各處理元素都密切相關與同一功能，且必須按照順序執行
弱點：模塊完成多個功能或部分功能-->模塊功能不單一
(7)功能內聚
模塊內所有元素共同完成一個功能，缺一不可
好處：界面清晰、容易理解，複用性較好
啓發式設計規則（不屬於普遍遵循的原理）
1.改進軟件結構提高模塊獨立性：通過模塊分解/合併-->降低耦合 提高內聚
2.模塊規模適中
3.深度、寬度、扇入、扇出合理
- 深度：軟件結構中控制的層數，粗略表示一個系統的大小和複雜程度
- 寬度：軟件結構中同一層次上模塊總數的最大值，寬度越大系統越複雜
- 扇入：直接調用當前模塊的上級模塊數目，扇入越大表明模塊的使用效率越高
![]()
- 扇出：一個模塊直接控制的模塊數目，扇出過大意味着模塊過分複雜
![]()
- 模塊扇出過大時，可以增加中間層次的控制模塊
![]()
4.模塊的作用域應該在控制域內
作用域：受該模塊內的判定影響的所有模塊的集合
控制域：模塊本身及其所有直接或間接從屬與它的模塊的集合
所有受判定影響的模塊都從屬於做出判定的模塊
5.力爭降低模塊接口的複雜程度
6.設計單入口單出口的模塊
7.模塊功能可以預測-->輸入數據相同時輸出相同
三、軟件體系結構設計
1.軟件體系結構的概念
- Dewayne Perry、Alex Wolf
具有一定形式的結構化元素，即構件的集合，包括處理構件(對數據加工)、數據構件(被加工的信息)、連接構件(組合連接不同部分)
- Mary Show 、David Garlan
處理算法與數據結構之上關於整體系統結構設計和描述方面的一些問題，eg:全局組織和全局控制結構、關於通信 同步 與數據存取的協議
- Kruchten
概念角度-->系統的主要構件及其之間的關係
模塊角度-->功能分解與層次結構
運行角度-->描述系統的動態結構
代碼角度-->代碼和庫函數在開發環境中的組織
- Bass 、Cements、Kazman
一個程序/計算機系統的軟件體系結構包括一個/一組 軟件構件、軟件構件外部可見特性(構件提供的服務、性能、特性、錯誤處理、共享資源的使用等)、及其相互關係
- 整理
軟件體系結構爲軟件系統提供了一個結構、行爲、屬性的高級抽象
由構成系統的元素的描述、元素的相互作用、指導元素集成的模式、模式的約束組成
指定了系統的組織結構和拓撲結構，顯示了系統需求和構成系統的元素之間的對應關係
2.軟件體系結構的重要性
- 是軟件風險承擔者溝通的手段
- 突出早期設計決策的選擇，對後續的設計實現以及最終成功產生直接影響
- 具有可複用性
3.軟件體系結構風格
定義了用於描述系統的術語表和一組指導構件系統的規則
軟件體系結構設計的核心問題-->能否到達軟件體系結構級別的軟件重用
- 分層體系結構
（1）系統被組織成一個層次結構，每一層高度內聚併爲上層服務。每一層只對相鄰的層可見，上層通過下層提供的接口調用下層的功能-->鬆散耦合的結構模型
（2）優點
- 支持基於抽象程度遞增的系統設計：開發設計人員在設計某一層時只需關注該層使用的技術及其功能
- 支持功能增強：功能改變最多影響相鄰兩層，便於系統功能的擴展
- 支持重用：提供的服務接口不變時，同一層的不同實現可以交換使用
（3）缺點
- 並不是每個系統都能容易劃分爲分層的模式
- 難以找到合適、正確的層次抽象方法
- 系統進行數據傳輸時需要經過多個層次-->性能和效率的下降
- 程序調試相對困難
- C2體系結構風格
（1）一系列相互協作的、由連接件連接起來的構件
構件相對獨立，構件之間的通信通過以連接件爲中介的異步消息交換機制實現，構件可將任意複雜的功能封裝在一起。
（2）遵守的規則
- 組織規則-->結構構建以構件、連接件爲基礎
![]()
- 通信規則-->構件間通信必須通過消息實現
- 構件的頂端域：可以對哪些通知做出響應、可以發出哪些請求
- 構件的地段域：可以向下層發送哪些通知，可以響應下層哪些請求
- 只感知層次高於自己的構件提供的服務
- C/S體系結構風格
（1）客戶機、服務器是兩個獨立的邏輯系統，服務器負責數據管理，客戶機負責數據顯示、用戶交互和邏輯處理
（2）兩層C/S體系結構的組成
- 客戶機程序：包括用戶界面、業務處理程序；負責向服務器發送請求消息、接收和分析從服務器返回的數據
- 服務器程序：包括數據庫、數據查詢、數據存儲、數據更新程序；負責管理客戶機程序的數據、調度管理、事務處理計算、共享資源管理
- 二者的關係
- 用戶通過客戶機的用戶交界面提出操作請求，客戶機的請求把用戶的操作轉換成通信協議要求的表達方式。通過服務器在客戶機的代理，客戶提出操作請求並獲得服務器返回信息。
- 服務器端的服務器接口提供客戶機與服務器聯繫的標準
（3）優點
- 客戶機、服務器構件位置透明，利於分佈式數據組織
- 可分別運行在不同的操作系統之上，便於異構平臺的不同開發技術的融合匹配
- 構件之間充分隔離並彼此獨立-->軟硬件環境具有極大的靈活性，具有良好的可擴展性
（4）缺點
- 開發成本高：軟硬件配置要求比較高
- 客戶機程序設計複雜
- 數據安全性不好：客戶端可以直接訪問數據庫服務器
- 單一服務器且以局域網爲中心，難以擴展至大型企業廣域網、Internet
- 維護和升級成本高
- 三層C/S體系結構風格
（1）組成
表示層負責處理用戶的輸入和向客戶的輸出，用於系統和用戶之間的交互；功能層負責建立數據庫連接，根據用戶的請求生成訪問數據庫的SQL語句，並把結果返回給客戶機；數據層負責實際的數據庫存儲和檢索，響應功能層的數據處理請求，並將結果返回給功能層。
- 表示層：系統和用戶間的接口，實現系統與系統應用之間的對話
- 功能層：負責處理具體的業務邏輯
- 數據層：負責對數據庫數據的讀寫操作
（2）優點
- 合理劃分三層結構的功能-->邏輯上保持相對獨立，系統的邏輯結構更清晰
- 更靈活、有效地選用相應的平臺和硬件系統
- 各層可進行自主語言的選擇並且 可以並行開發
- 充分利用功能層隔離表示層和數據層，增強數據安全性
- B/S體系結構風格
（1）是三層C/S結構的一種實現方式，由瀏覽器、Web服務器、數據庫服務器組成
（2）優點
- 系統維護和升級方式簡單：主要工作在服務器端，客戶端不需要維護
- 成本低，選擇多：服務器可以選擇多個操作系統，客戶機可以選擇多個瀏覽器
（3）不足
- 缺乏對動態頁面支持能力，沒有集成有效的數據庫處理能力
- 系統擴展能力差，安全性難以保障
- 數據查詢等的響應速度低於C/S
- 正交體系結構風格
（1）正交體系結構風格是一種由組織層和線索組成的層次化結構
每一個組織層都包含具有相同抽象級別的構件
線索：不同的功能模塊，由完成不同層次功能的構件通過相互調用來組成，每一條線索完成整個系統中相對獨立的一部分功能
完全正交：線索之間無關，同一層的構件之間不存在調用關係
（2）特徵
- 正交體系結構由完成不同功能的n個線索組成，n>1
- 系統有m個不同抽象級別的層次，m>1
- 線索之間保持相對的獨立性（正交性）
- 公共頂層-->驅動線索的運行；公共底層-->爲線索提供公共的構件和使用數據
![]()
（3）優點
- 結構清晰，容易理解-->線索功能相互獨立，不進行相互調用
- 易修改，可維護性強-->變更局部化，縮小了變更範圍，減少了修改的工作量
- 可移植性強
- 數據共享體系結構風格（倉庫風格）
（1）包含兩種構件：中央數據結構（資源庫）-->表示系統當前的狀態；獨立構件的集合-->對中央數據結構進行操作
（2）根據中央數據單元和構件之間信息交換方式的不同：
- 根據輸入事務選擇何種處理
- 由中央數據結構的當前狀態決定何種處理-->黑板體系結構
- MVC體系結構風格
（1）爲需要爲同樣數據提供多個視圖的應用程序設計，實現了數據層與表示層的分離，適合開發與GUI有關的應用程序
（2）組成
- 模型：維護數據並提供數據訪問方法
- 視圖：繪製模型的部分數據或所有數據的可視圖
- 控制器：進行事件的處理
（3）優點
- 多個視圖可以對應一個模型-->可減少代碼複製和維護的工作量
- 降低各層間的耦合，提供了應用的可擴展性
- 更符合軟件工程化管理的精神-->不同的層各司其職
（4）問題
- 增加了系統結構和實現的複雜性
- 視圖與控制器的連接過於緊密
- 視圖對模型數據的訪問效率低
- 異構體系結構的集成
多種體系結構並存並相互融合，eg:B/S C/S體系結構的組合
- “內外有別”
- 企業內部人員利用C/S架構通過局域網訪問企業數據庫，可提高系統查詢和修改的響應速度
- 外部通過B/S架構從Internet上通過Web服務器瀏覽企業內部數據庫，保證數據庫的安全，但響應速度慢
- “查改有別”
- 對數據庫瀏覽查詢：採用B/S
- 對數據庫維護修改：採用C/S
4.軟件體系結構設計方法
- 工件驅動的軟件體系結構設計方法
(1)軟件過程每經歷一個階段，就會發生一次知識轉換的過程，最終編碼人員把知識固化在軟件產品中。
軟件成型前，知識的主要載體是文檔和模型-->工件
(2)過程
- 用例驅動的軟件體系結構設計方法
(1)用例建模：使用用例描述系統需求的過程
用例模型：所有用例組合在一起，描述系統的全部功能，獲取系統的功能需求
(2)迭代構建軟件體系結構
- 根據軟件領域範圍建立臨時的軟件體系結構
- 選取重要的用例，使體系結構支持用例
- 選取更多用例，建立更加完美的體系結構
- 每次迭代，選取並實現一組用例-->確認體系結構，每次迭代結束時進行評估
(3)軟件開發項目分成如下幾個階段：
- 初始階段：設定產品功能範圍，建立初始業務案例，從業務角度表明項目的可行性
- 細化階段：建立體系結構基線，捕獲大多數需求
- 構造階段：開發系統，保證產品可移交給客戶，即產品達到最初的可操作能力
- 移交階段：卻被得到準備向用戶社團發佈的產品
體系結構主要是在細化階段的迭代過程中發展起來的
- 模式驅動的軟件體系結構設計-->從模式導出體系結構抽象
- 領域驅動的軟件體系結構設計DSSA
(1)基本思想
- 對具體領域的一系列相似系統可重用信息進行識別、提取、收集和組織
- 對可利用信息進行整理和再加工-->規範化 標準化，有利於重用
- 軟件體系結構模型的建立參考並使用規範化可重用信息
- 是多系統範圍內的體系結構，從一組系統中導出
(2)設計過程
- 需求驅動的軟件體系結構設計方法
描述解決的問題和解決方案之間的動態關係
(1)問題空間：定義所解決的問題
(2)需求分析前期階段：理解問題，考慮組織和非功能需求；後期階段：描述系統的相關功能和屬性
(3)體系結構設計
根據組件或者子系統之間的數據、控制及其他依賴關係描述系統全局結構設計；
1）把體系結構看做抽象的組件通過連接交互的整體，基於細化的需求模型，確定組件滿足的非功能需求和功能需求（用場景表示）
2）通過描述組件和連接的抽象屬性，得到軟件體系結構的抽象模型；
3) 從需求分析模型確定的解決空間中發現體繫結構設計方案，得到具體的體系結構實例；
4）進行評價-->在選定解決方案的同時建立場景模型。
四、系統設計方法（實現設計模型的手段和方法）
(一)程序流程圖
1.基本符號
2.控制結構
3.存在的問題
（1）表示程序控制流程的箭頭不受任何約束，容易造成程序控制結構的混亂；
（2）難以描述逐步求精的過程，導致過早考慮細節而忽略全局；
（3）只描述執行過程，難以表示數據結構；
（4）符號繁多，記憶不便
(二)盒圖(N-S圖)
1.基本控制結構
2.在N-S圖中，每個處理步驟（語句或者語句序列）使用一個盒子表示；盒子可以嵌套另外一個盒子；只能從盒子上邊進入、下邊走出，限制了隨意的控制轉移。
3.優點
（1）形象直觀，具有良好的可見度，容易理解設計意圖，爲編程、複查、選擇測試用例、維護帶來了方便
（2）強制設計人員採用結構化程序設計方法進行思考並描述設計方案，有效保證了設計質量
（3）簡單 易學 易用
（4）容易表現嵌套關係並且不限制嵌套深度
4.問題：手工修改麻煩
(三)問題分析圖(problem analysis diagram, PAD)
1.PAD是面向高級程序設計語言設計的，使用二維樹形結構表示程序的控制流
2.基本符號
3.圖例
4.優點
（1）更容易表示結構化程序控制圖。
（2）程序層次增加，PAD向右延伸，每增加一個層次，向右擴展一條豎線。豎線的總數就是程序的層次數量。
（3）表現程序邏輯易讀易懂-->程序從圖中最左豎線的上端節點開始執行，自上而下、自左向右遍歷所有結點。
（4）可以使用工具軟件自動轉換成高級語言源程序。
（5）支持自頂向下、逐步求精的方法。
(四)HIPO圖（Hirearchy plus input/processing/output）
1.表示軟件系統結構的設計工具
H圖-->描述軟件模塊層次結構
IPO圖-->描述每個模塊的輸入、輸出數據、處理功能、模塊調用的詳細情況
HIPO圖是以模塊分解的層次性以及模塊內輸入、處理輸出三大基本部分爲基礎構建的
2.H圖說明軟件系統由哪些模塊組成以及其控制層次結構
3.IPO圖描述模塊輸入、輸出和處理細節，以及與其他模塊間的調用和被調用關係
(五)判定表
1.判定表是分析和表達多邏輯條件下執行不同操作情況的工具
適合：某些操作的實施依賴多個邏輯條件的組合，即針對不同的邏輯條件組合值，分別執行不同的操作。
2.例子
3.判定表的組成
（1）條件樁-->問題的所有條件
（2）動作樁-->問題規定可能採取的操作
（3）條件項-->在所有可能情況下的真假值
（4）動作項-->在條件項的各種取值情況下采取的動作
4.判定表的建立
（1）確定規則個數，對於n個條件，有2n種規則
規則：一個條件組合的特定取值以及相應執行的操作稱爲規則，判定表中貫穿條件項和動作項的一列就是一條規則
（2）列出所有條件樁、動作樁
（3）填入條件項
（4）填入動作項
（5）合併相似規則
(六)判定樹
更加直觀表示邏輯判斷問題
樹根：加工明
中間：各項條件
最右側：行動
(七)過程設計語言（Process design language，PDL）
1.用於描述模塊中算法和加工的具體細節，具有嚴格的關鍵字外部語法，用於定義控制結構和數據結構
2.語法包括外層語法、內層語法
外側語法：描述程序的結構，採用與一般編程語言類似的關鍵字
內層語法：描述操作，採用任意自然語句
3.優點
（1）可以作爲註釋插入源代碼-->促使維護人員在修改程序的同時修改PDL註釋，保持文檔和程序的一致性
（2）易於被計算機處理和存儲
（3）可以自動產生程序
(八)Jackson圖
1.是面向數據結構的設計方法，即以數據結構作爲程序設計的基礎
2.基本結構
（1）順序
（2）選擇
（3）重複
3.改進-->增加判定條件
4.Jackson方法-->構建Jackson圖
（1）確定輸入數據和輸出數據的邏輯結構
（2）找輸入數據、輸出數據結構中有對應關係的數據單元
（3）導出Jackson圖
針對有對應關係的，在相應層次畫處理框
輸入數據中剩餘的數據單元，在相應層次畫處理框
輸出數據中剩餘的數據單元，在相應層次畫處理框
（4）列出操作和條件 使用僞代碼表示程序
五、用戶界面設計
1.設計原則
（1）以用戶爲中心的可視性原則
系統的設計決策結合用戶的工作和應用環境，理解用戶對系統的需求，同時給出可視性效果良好的界面設計
（2）一致性原則
系統內部具有相似的界面外觀、佈局、相似的人機交互方式以及信息顯示格式
（3）交互性原則
體現系統的狀態反饋信息(用戶在人機操作過程中，用戶從軟件系統得到的信息)，並對人的操作進行適當的反應
（4）重要性原則
按照管理對象在控制系統中的重要性和全局性水平，設計人機界面的主次菜單、對話窗口的位置和凸顯性
（5）功能原則
設計分功能區多級菜單、分層提示信息、多項對話框並舉的窗口
（6）合理性原則
2.設計過程
（1）創建系統需求功能的外部設計模型
設計模型考慮軟件的數據結構、總體結構、過程性描述
需要充分了解不同類型用戶的詳細情況、基本需求
（2）確定完成此係統功能的人、計算機分別完成的任務
（3）構建人機界面原型
（4）評估界面設計
3.設計方法
（1）迭代設計
初步設計-->創建第一級原型-->用戶試用並評估-->根據修改意見設計並實現下一級原型
（2）以用戶爲中心
使用戶充分理解設計者的指導意圖，正確進行實驗操作；設計者從使用者那裏得到有效的反饋信息以改進界面，二者有效地實現雙向互動
