軟件工程第四章系統(tǒng)設計

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