第三部軟件設計與建模

第三部軟件設計與建模第1頁，共173頁，2023年，2月20日，星期一2023/4/15第9講軟件設計軟件設計概述模塊化設計軟件體系結構與模式第2頁，共173頁，2023年，2月20日，星期一2023/4/15第9講軟件設計軟件設計概述模塊化設計軟件體系結構與模式第3頁，共173頁，2023年，2月20日，星期一2023/4/15軟件設計概述軟件設計階段的基本目標是構造系統(tǒng)“怎么做”的模型描述?！霸O計先于編碼”，這是軟件工程“推遲實現(xiàn)”基本原則軟件系統(tǒng)設計是把軟件需求“變換”為用于構造軟件的藍圖。“輸入”是需求分析各種模型元素“輸出”是軟件設計模型和表示軟件設計的目標是對將要實現(xiàn)的軟件系統(tǒng)的體系結構、系統(tǒng)的數(shù)據(jù)、系統(tǒng)模塊間的接口，以及所采用的算法給出詳盡的描述。第4頁，共173頁，2023年，2月20日，星期一2023/4/15軟件設計三類活動總體設計，也稱概要設計，軟件結構設計，或高層設計。分析需求規(guī)格說明模塊劃分，形成具有預定功能的模塊組成結構表示出模塊間的控制關系給出模塊之間的接口軟件詳細設計，也稱為（模塊）過程設計，或低層設計。設計模塊細節(jié)確定模塊所需的算法和數(shù)據(jù)結構等測試和復審第5頁，共173頁，2023年，2月20日，星期一2023/4/15概要設計說明書1范圍1.1系統(tǒng)目標1.2主要軟件需求1.3軟件設計約束、限制2數(shù)據(jù)設計2.1數(shù)據(jù)對象和形成的數(shù)據(jù)結構2.2文件和數(shù)據(jù)庫結構外部文件結構①邏輯結構②邏輯記錄描述③訪問方法全局數(shù)據(jù)文件和數(shù)據(jù)交叉索引3體系結構設計3.1數(shù)據(jù)和控制流復審3.2得出的程序結構4接口設計4.1人機界面規(guī)約4.2人機界面設計規(guī)約4.3外部接口設計外部數(shù)據(jù)接口外部系統(tǒng)或設備接口4.4內部接口設計規(guī)約5（每個模塊）過程設計5.1處理說明5.2接口描述5.3設計語言描述5.4使用的模塊5.5內部設計結構5.6注釋/約束/限制6需求交叉索引7測試部分7.1測試方針7.2集成策略7.3特殊考慮8附錄（包括特殊注解）第6頁，共173頁，2023年，2月20日，星期一2023/4/15詳細設計說明書1引言1.1編寫目的：闡明編寫詳細設計說明書的目的，指明讀者對象。1.2項目背景：應包括項目的來源和主管部門等。1.3定義：列出本文檔中所用到的專門術語的定義和縮寫詞。●列出有關資料的作者、標題、編號、發(fā)表日期、出版單位或資料來源●文檔所引用的資料、軟件開發(fā)的標準或規(guī)范。1.4參考資料：項目經核準的計劃任務書、合同或上級機關的批文；項目開發(fā)計劃；需求規(guī)格說明書；概要設計說明書；測試計劃（初稿）；用戶操作手冊。2總體設計2.1需求概述2.2軟件結構：如給出軟件系統(tǒng)的結構圖。3程序描述3.1逐個模塊給出以下說明：●性能●輸出項目●功能●輸入項目3.2算法：模塊所選用的算法。3.3程序邏輯：詳細描述模塊實現(xiàn)的算法，可采用：標準流程圖；PDL語言；N-S圖；判定表等描述算法的圖表。3.4接口●限制條件●存儲分配3.5測試要點：給出測試模塊的主要測試要求。第7頁，共173頁，2023年，2月20日，星期一2023/4/15軟件模塊化設計模塊是一個獨立命名的，擁有明確定義的輸入、輸出和特性的程序實體。把一個大型軟件系統(tǒng)的全部功能，按照一定的原則合理地劃分為若干個模塊，每個模塊完成一個特定子功能，所有的這些模塊以某種結構形式組成一個整體，這就是軟件的模塊化設計（ModularDesign）。軟件模塊化設計可以簡化軟件的設計和實現(xiàn)，提高軟件的可理解性和可測試性，并使軟件更容易得到維護。分解、抽象、逐步求精、信息隱蔽和模塊獨立性，是軟件模塊化設計的指導思想。第8頁，共173頁，2023年，2月20日，星期一2023/4/15模塊數(shù)與開發(fā)工作量開發(fā)工作量模塊數(shù)最小成本區(qū)模塊成本接口成本總成本第9頁，共173頁，2023年，2月20日，星期一2023/4/15抽象分解必然需要抽象的支持。抽象是抓住主要問題，隱藏細節(jié)，這樣才能容易分解。抽象具有不同的級別。人類解決復雜問題的基本方法之一。只有抓住事物的本質，才能準確分析和處理問題，找到合理的解決方案。第10頁，共173頁，2023年，2月20日，星期一2023/4/15信息隱藏信息隱蔽原則建議模塊應該具有的特征是：每個模塊對其他所有模塊都隱蔽自己的設計決策。信息隱蔽意味著通過一系列獨立的模塊可以得到有效的模塊化。獨立的構件或模塊之間的“接口”簡單而清晰。第11頁，共173頁，2023年，2月20日，星期一2023/4/15模塊的獨立性模塊的獨立性（ModuleIndependence）是模塊化、抽象、信息隱蔽等概念的直接結果，也是判斷模塊化結構是否合理的標準。模塊獨立性是指開發(fā)具有獨立功能而和其他模塊沒有過多關聯(lián)的模塊。模塊獨立性兩大優(yōu)點：獨立的模塊由于分解了功能，簡化了接口，使得軟件比較容易開發(fā)；獨立的模塊比較容易測試和維護。模塊獨立性由兩個定性標準度量：模塊自身的內聚（Cohesion）），也稱為塊內聯(lián)系或模塊強度，模塊之間的耦合（Coupling)，也稱為塊間聯(lián)系。模塊獨立性愈高，則塊內聯(lián)系越強，塊間聯(lián)系越弱。第12頁，共173頁，2023年，2月20日，星期一2023/4/15內聚性分類偶然性內聚弱邏輯性內聚時間性內聚過程性內聚通信性內聚順序性內聚功能性內聚強低內聚中內聚高內聚第13頁，共173頁，2023年，2月20日，星期一2023/4/15耦合性分類非直接耦合弱數(shù)據(jù)耦合特征耦合控制耦合外部耦合公共耦合內容耦合強弱耦合中耦合強耦合較強耦合第14頁，共173頁，2023年，2月20日，星期一2023/4/15逐步求精逐步求精，或稱逐步細化，是一種自頂向下的設計策略。逐步求精是人類采用抽象到具體的過程把一個復雜問題趨于簡單化控制和管理的有效策略。抽象和精化是互補的概念。第15頁，共173頁，2023年，2月20日，星期一2023/4/15重構重構是一種重新組織的技術，可以簡化構件或模塊的設計或編碼而無需改變其功能或行為。重構是一種改進程序內部結構但不改變代碼或設計的外部行為。“先使它轉起來，再使它快起來”。第16頁，共173頁，2023年，2月20日，星期一2023/4/15軟件結構圖軟件結構圖（StructureChart,簡稱SC）是軟件系統(tǒng)的模塊層次結構，反映了整個系統(tǒng)的功能實現(xiàn)。軟件結構以層次表示程序的系統(tǒng)結構，即一種控制的層次體系，并不表示軟件的具體過程。件結構一般用樹狀或網狀結構的圖形來表示。軟件結構圖的主要元素有：模塊：模塊用帶有名字的方框表示，名稱應體現(xiàn)模塊的功能?？刂脐P系：控制關系用單向箭頭或直線表示模塊間的調用關系。信息傳遞：用帶注釋的短箭頭表示模塊調用過程中傳遞的信息。循環(huán)調用和選擇調用：在上部模塊底部加一個菱形符號表示選擇調用，在上部模塊的下方家一個弧形箭頭，表示循環(huán)調用。第17頁，共173頁，2023年，2月20日，星期一2023/4/15軟件結構圖MNOPQGHICDATJKLEFBRS第18頁，共173頁，2023年，2月20日，星期一2023/4/15模塊化設計的優(yōu)化改進軟件結構提高模塊獨立性在滿足模塊化要求的前提下盡量減少模塊數(shù)量，在滿足信息需求的前提下盡可能減少復雜的數(shù)據(jù)結構模塊規(guī)模應適中軟件結構的深度、寬度、扇入數(shù)和扇出數(shù)都要適當模塊的作用域應該在控制域之內力求降低模塊接口的復雜程度，設計單入口、單出口的模塊第19頁，共173頁，2023年，2月20日，星期一2023/4/15軟件體系結構模型軟件體系結構是一種表達，使軟件工程師能夠分析設計是否滿足需求、選擇合理的方案和降低風險。大型軟件系統(tǒng)總是被分解成一系列子系統(tǒng)，由子系統(tǒng)提供一些相關的服務。軟件體系結構設計過程就是識別出這些子系統(tǒng)，并建立子系統(tǒng)控制和通信的框架，最后給出軟件體系結構的一個描述。兩類結構模型：系統(tǒng)構成模型系統(tǒng)控制模型第20頁，共173頁，2023年，2月20日，星期一2023/4/15系統(tǒng)構成模型以數(shù)據(jù)為中心的結構模型數(shù)據(jù)流結構模型客戶機/服務器結構模型抽象機結構模型第21頁，共173頁，2023年，2月20日，星期一2023/4/15以數(shù)據(jù)為中心的結構模型由一組子系統(tǒng)構成，子系統(tǒng)交換信息，協(xié)調工作有兩種基本方法：全部共享數(shù)據(jù)放在一個中央數(shù)據(jù)庫中，所有子系統(tǒng)都能從中存取數(shù)據(jù)。每個子系統(tǒng)用各自的數(shù)據(jù)庫與其他子系統(tǒng)進行數(shù)據(jù)交互，通過消息傳遞來實現(xiàn)。共享數(shù)據(jù)模型的優(yōu)點是能夠高效地共享大量的數(shù)據(jù)，生產數(shù)據(jù)的子系統(tǒng)不需要關心數(shù)據(jù)如何被其他子系統(tǒng)使用，可以集中進行如備份、保密性、訪問控制和錯誤恢復等活動；缺點是子系統(tǒng)一定要與以數(shù)據(jù)為中心的體系結構模型一致，系統(tǒng)變更或進化比較困難，子系統(tǒng)的需求會不同，難以集成，以及很難將數(shù)據(jù)分布到多臺機器上。第22頁，共173頁，2023年，2月20日，星期一2023/4/15數(shù)據(jù)流體系結構模型當輸入數(shù)據(jù)經過一系列的計算和操作構件或模塊的變換形成輸出數(shù)據(jù)時，可以應用數(shù)據(jù)流體系結構。管道和過濾器結構通過一組由管道連接的過濾器來變換數(shù)據(jù)，并向下傳遞。第23頁，共173頁，2023年，2月20日，星期一2023/4/15管道和過濾器結構過濾器過濾器過濾器過濾器過濾器過濾器過濾器過濾器第24頁，共173頁，2023年，2月20日，星期一2023/4/15客戶機/服務器結構模型客戶機/服務器結構模型的主組要成部分是：一組給其他子系統(tǒng)提供服務的單機服務器一組向服務器請求服務的客戶機 一個連接客戶機和服務器的網絡（可選）服務器模型能實現(xiàn)以數(shù)據(jù)為中心的體系結構模型的系統(tǒng)客戶機/服務器模型的最大優(yōu)勢在于可以是一個分布式結構第25頁，共173頁，2023年，2月20日，星期一2023/4/15多媒體服務系統(tǒng)結構網絡目錄服務器目錄視頻服務器電影文件圖片服務器圖片文件web服務器超文本文件客戶1客戶2客戶n………第26頁，共173頁，2023年，2月20日，星期一2023/4/15抽象機模型抽象機模型也稱為分層模型，是建立子系統(tǒng)的接口模型。它把子系統(tǒng)組織成一系列的層次，每一層提供一組服務，每一層定義為一個抽象機。例如：網絡協(xié)議OSI參考模型通信介質應用層表示層會話層傳輸層網絡層數(shù)據(jù)鏈路層物理層用戶B應用層表示層會話層傳輸層網絡層數(shù)據(jù)鏈路層物理層用戶A第27頁，共173頁，2023年，2月20日，星期一2023/4/15系統(tǒng)控制模型集中式控制模型調用—返回模型：這是一個自上而下的子過程模型?？刂剖加谙到y(tǒng)（程序）的頂層，在子系統(tǒng)（程序）調用過程中，控制逐步傳遞到更低的層次中。該模型適用于順序執(zhí)行的系統(tǒng)。管理者模型：這是一種適用于并發(fā)系統(tǒng)的模型。一個系統(tǒng)組件被指定為系統(tǒng)管理者，控制其他系統(tǒng)過程的啟動、終止和協(xié)調。一個過程就是一個能和其他過程并發(fā)執(zhí)行的子系統(tǒng)或模塊。第28頁，共173頁，2023年，2月20日，星期一2023/4/15并發(fā)系統(tǒng)的集中式控制模型系統(tǒng)控制器故障處理器用戶界面?zhèn)鞲衅鬟M程傳動裝置進程計算進程第29頁，共173頁，2023年，2月20日，星期一2023/4/15系統(tǒng)控制模型事件驅動系統(tǒng)廣播模型：發(fā)生的事件廣播到所有子系統(tǒng)，任何能處理該事件的子系統(tǒng)都會響應。該模型適用于基于網絡的分布式系統(tǒng)。廣播模型中的子系統(tǒng)注冊其感興趣的特別事件廣播模型的優(yōu)點是進化比較簡單缺點是子系統(tǒng)都知道是否和什么時候處理事件，這可能會引起沖突。中斷驅動模型：由中斷處理器對來自外部的中斷進行檢測，然后在其他組件中處理這些中斷。該模型適用于對定時有嚴格要求的實時系統(tǒng)。只用在硬件實時系統(tǒng)中，要求對一些事件能做出及時響應第30頁，共173頁，2023年，2月20日，星期一2023/4/15軟件的體系結構模式軟件的體系結構模式定義了處理系統(tǒng)某些行為特征的方法并發(fā)性系統(tǒng)必須以一種模擬并行的方式來操作多個任務操作系統(tǒng)進程管理模式任務調度器模式包括一組含有tick()操作的活動對象持久性如果數(shù)據(jù)從創(chuàng)建它的進程執(zhí)行以來一直存在，則該數(shù)據(jù)是持久性存在的數(shù)據(jù)。數(shù)據(jù)庫管理系統(tǒng)模式將DBMS的存儲和存取能力用于應用系統(tǒng)的體系結構中。應用級的持久模式在應用體系結構中建立了持久性特征。分布性強調系統(tǒng)或系統(tǒng)中構件或模塊在一個分布的環(huán)境中相互通信的方式。分布性問題有兩個元素：一是實體間連接方式二是實體間通信的特性代理模式是一種普遍的體系結構模式CORBA就是代理模式的一個范例第31頁，共173頁，2023年，2月20日，星期一2023/4/15小結設計的基本原理和概念包括模塊化、抽象、體系結構、信息隱蔽、模塊獨立、逐步求精和重構等，這些原理和概念描述了計算機軟件的屬性、所使用的設計方法和所使用的編程語言。設計通常被描述為一個多步過程，其主要任務是從需求信息中綜合出數(shù)據(jù)的表示、程序結構、接口特征和過程細節(jié)。軟件體系結構提供了待建系統(tǒng)的整體視圖，它描述軟件構件或模塊的結構和組織、構件或模塊的性質以及他們之間的連接。第32頁，共173頁，2023年，2月20日，星期一2023/4/15第10講結構化設計方法（1）結構化設計階段數(shù)據(jù)流設計方法第33頁，共173頁，2023年，2月20日，星期一2023/4/15結構化設計概述設計先于編碼”，這是軟件工程“推遲實現(xiàn)”基本原則的又一體現(xiàn)。結構化設計方法（StructuredDesign,SD)是基于模塊化、自頂向下細化、結構化程序設計等程序設計技術基礎上發(fā)展起來的。結構化設計方法用模塊結構圖來表達程序模塊之間的關系。軟件設計分為兩個階段：概要設計詳細設計第34頁，共173頁，2023年，2月20日，星期一2023/4/15概要設計概要設計也稱總體設計，確定軟件的結構以及各組成成分(子系統(tǒng)或模塊)之間的相互關系。概要設計的主要任務是：將系統(tǒng)劃分成模塊；決定每個模塊的功能；決定模塊的調用關系；決定模塊的界面，即模塊間傳遞的數(shù)據(jù)。概要設計階段的主要任務是通過數(shù)據(jù)流圖來確定系統(tǒng)的結構圖，并且對這些結構圖進行分析和細化。在概要設計階段，結構化設計主要采用面向數(shù)據(jù)流的設計方法。第35頁，共173頁，2023年，2月20日，星期一2023/4/15詳細設計詳細設計就是在概要設計的基礎上決定如何具體實現(xiàn)各模塊的內部細節(jié)，直到對系統(tǒng)中的每個模塊給出足夠詳細的過程描述。在編碼實現(xiàn)階段就可以完全按照詳細設計的細節(jié)過程來映射到代碼，最終實現(xiàn)整個系統(tǒng)。一般使用結構化程序設計工具來描述第36頁，共173頁，2023年，2月20日，星期一2023/4/15數(shù)據(jù)流類型根據(jù)基本系統(tǒng)模型，數(shù)據(jù)信息必須以“外部”信息形式進入軟件系統(tǒng)，經過內部處理以后再以“外部”的形式離開系統(tǒng)。有三種數(shù)據(jù)流類型：變換型數(shù)據(jù)流事務型數(shù)據(jù)流混合型數(shù)據(jù)流第37頁，共173頁，2023年，2月20日，星期一2023/4/15變換型數(shù)據(jù)流信息可以通過各種路徑進入系統(tǒng)，信息在“流”入系統(tǒng)的過程中由外部形式變換成內部數(shù)據(jù)形式，這被標識為輸入流。在軟件的核心，輸入數(shù)據(jù)經過一系列加工處理，這被標識為變換流。通過變換處理后的輸出數(shù)據(jù)，沿各種路徑轉換為外部形式“流”出軟件，這被標識為輸出流。整個數(shù)據(jù)流體現(xiàn)了以輸入、變換、輸出的順序方式，沿一定路徑前行的特征，這就是變換型數(shù)據(jù)流，簡稱變換流。第38頁，共173頁，2023年，2月20日，星期一2023/4/15變換型數(shù)據(jù)流時間輸入流輸出流變換流信息第39頁，共173頁，2023年，2月20日，星期一2023/4/15事務型數(shù)據(jù)流當數(shù)據(jù)流經過一個具有“事務中心”特征的數(shù)據(jù)處理時，它可以根據(jù)事務類型從多條路徑的數(shù)據(jù)流中選擇一條活動通路。這種具有根據(jù)條件選擇處理不同事務的數(shù)據(jù)流，就是事務型數(shù)據(jù)流，簡稱事務流。第40頁，共173頁，2023年，2月20日，星期一2023/4/15事務型數(shù)據(jù)流……活動通路……………………事務中心⊕⊕⊕第41頁，共173頁，2023年，2月20日，星期一2023/4/15混合型數(shù)據(jù)流在一個大型系統(tǒng)的DFD中，變換流和事務流往往會同時出現(xiàn)。例如，在一個事務型的DFD中，分支動作路徑上的信息流也可能會體現(xiàn)出變換流的特征。這種具有將事務流和變換流組合出現(xiàn)，就是混合型數(shù)據(jù)流，簡稱混合流。第42頁，共173頁，2023年，2月20日，星期一2023/4/15混合型數(shù)據(jù)流第43頁，共173頁，2023年，2月20日，星期一2023/4/15混合型數(shù)據(jù)流變換3……變換2傳出數(shù)據(jù)傳入數(shù)據(jù)事務中心變換1結果第44頁，共173頁，2023年，2月20日，星期一2023/4/15數(shù)據(jù)流設計方法面向數(shù)據(jù)流分析（DFA，DataFlowAnalysis）的設計是一種結構化的軟件體系結構設計方法。面向數(shù)據(jù)流分析的設計能與大多數(shù)需求規(guī)格說明技術配合，可以使模塊達到高內聚性（順序性內聚）。這一設計技術是從數(shù)據(jù)流圖（DFD）分析模型映射為軟件模塊組成結構設計的描述，所以也稱為結構化設計（SD，StructuredDesign）方法。第45頁，共173頁，2023年，2月20日，星期一2023/4/15數(shù)據(jù)流映射步驟復查基本系統(tǒng)模型，并精化系統(tǒng)數(shù)據(jù)流圖分析數(shù)據(jù)流類型，確定數(shù)據(jù)流具有變換流特征還是事務流特征如果是變換流特征，確定輸入流和輸出流的邊界（也分別稱為最高輸入/輸出抽象點），輸入流邊界和輸出流邊界之間就是變換流，也稱為“變換中心”。變換流加工處理的是某些形式的內部數(shù)據(jù)。如果是事務流特征，則可確定一個接收分支和一個發(fā)送分支。其中發(fā)送分支包含一個“事務中心”和各個事務動作流。采用自頂向下、逐步求精的方式完成模塊分解，確定相應的軟件組成結構根據(jù)模塊獨立性原理和運用設計度量標準，對導出的軟件結構進行優(yōu)化第46頁，共173頁，2023年，2月20日，星期一2023/4/15變換流設計變換流設計的要點是分析數(shù)據(jù)流圖，確定輸入流、輸出流邊界，根據(jù)輸入、變換、輸出三個數(shù)據(jù)流分支將軟件映射成一個標準的“樹型”體系結構。在有多個輸入流和多個輸出流時，應分別找出各個輸入流和輸出流的邊界，即最高抽象點，然后分別連接這些輸入流的最高抽象點和輸出流的最高抽象點，分別形成輸入邊界和輸出邊界。下面設計一個“統(tǒng)計輸入文件中單詞數(shù)目”程序。輸入流邊界輸出流邊界有效的文件名單詞總數(shù)格式化單詞數(shù)驗證文件名統(tǒng)計單詞數(shù)格式化單詞數(shù)讀文件名文件名單詞總數(shù)顯示單詞數(shù)文件名第47頁，共173頁，2023年，2月20日，星期一2023/4/15第一次分解文件單詞數(shù)目統(tǒng)計讀取和驗證文件名統(tǒng)計單詞數(shù)目格式化和顯示單詞數(shù)第48頁，共173頁，2023年，2月20日，星期一2023/4/15第二次分解文件單詞數(shù)目統(tǒng)計讀取和驗證文件名統(tǒng)計單詞數(shù)目格式化和顯示單詞數(shù)格式化單詞數(shù)顯示單詞數(shù)讀文件名驗證文件名第49頁，共173頁，2023年，2月20日，星期一2023/4/15事務流設計事務流分析設計是把事務流映射成包含一個接收分支和一個發(fā)送分支的軟件結構。接收分支的映射方法和變換流設計映射出輸入結構的方法相似，即從事務中心的邊界開始，把沿著接收流通路的處理映射成一個個模塊。發(fā)送分支結構包含了一個分類控制模塊和它下層的各個動作模塊。數(shù)據(jù)流圖的每一個事務動作流路徑應映射成與其自身信息流特征相一致的結構。第50頁，共173頁，2023年，2月20日，星期一2023/4/15事務流設計事務選擇確定事務類型審計記錄事務1事務2事務3事務4審計信息事務5更新事務v有效事務查詢更新事務w有效事務存款更新事務x有效事務取款更新事務y有效事務轉賬更新事務z有效事務修改密碼第51頁，共173頁，2023年，2月20日，星期一2023/4/15ATM機系統(tǒng)結構ATM機處理事務主控調度器更新文件查詢編輯事務分析器事務選擇存款轉賬取款修改密碼第52頁，共173頁，2023年，2月20日，星期一2023/4/15混合流設計讀入數(shù)據(jù)判別

訂貨處理

訂貨輸入

提貨發(fā)票進貨輸入

庫存修改

進貨票據(jù)

訂單記錄

分析統(tǒng)計生成統(tǒng)計表第53頁，共173頁，2023年，2月20日，星期一2023/4/15混合流設計第54頁，共173頁，2023年，2月20日，星期一2023/4/15第11講結構化設計方法（2）結構化程序設計案例分析第55頁，共173頁，2023年，2月20日，星期一2023/4/15結構化程序設計方法結構化程序設計的理念是在20世紀60年代，由Dijkstra等人提出并加以完善的。結構化的程序一般只需要用三種基本的邏輯結構就能實現(xiàn)。這三種基本邏輯結構是順序結構、選擇結構和循環(huán)結構。結構化程序設計是一種設計程序的技術，它采用自頂向下逐步求精的設計方法和單入口單出口的控制結構。第56頁，共173頁，2023年，2月20日，星期一2023/4/15結構化程序設計工具圖形工具：把過程的細節(jié)表示成一個圖的組成部分，在這個圖上，邏輯構造用具體的圖形來表示。列表工具：用一個表來表示過程的細節(jié)，這個表列出了各種操作及其相應的條件。也即，描述了輸入、處理和輸出信息。語言工具：用類語言來表示過程的細節(jié)，這種類語言很接近于編程語言。第57頁，共173頁，2023年，2月20日，星期一2023/4/15程序流程圖程序流程圖又稱為程序框圖，Goldstine于1946年首先采用。它的主要優(yōu)點是對控制流程的描繪很直觀，便于初學者掌握。程序流程圖的主要缺點：程序流程圖本質上不是逐步求精的好工具，它誘使程序員過早地考慮程序的控制流程，而不去考慮程序的全局結構；程序流程圖中用箭頭代表控制流，因此程序員不受任何約束，可以完全不顧結構程序設計的精神，隨意轉移控制；程序流程圖不易表示數(shù)據(jù)結構。第58頁，共173頁，2023年，2月20日，星期一2023/4/15程序流程圖符號（a）預處理（b）選擇（c）多分支（d）循環(huán)上界（e）循環(huán)下界（f）開始/結束（g）準備（h）注釋（i）虛線（j）省略（k）并行方式（l）控制流第59頁，共173頁，2023年，2月20日，星期一2023/4/15盒圖盒圖是由Nassi和Shneiderman提出的，所以又稱為N-S圖。每個處理步驟都用一個盒子來表示，這些處理步驟可以是語句或語句序列，在需要時，盒子中還可以嵌套另一個盒子，嵌套深度一般沒有限制。盒圖具有下述特點：功能域（即，一個特定控制結構的作用域）明確，可以從盒圖上一眼就看出來。由于只能從上邊進入盒子然后從下面走出盒子，除此之外沒有其它的入口和出口，所以盒圖限制了任意的控制轉移，保證程序有良好的結構。很容易確定局部和全程數(shù)據(jù)的作用域。很容易表現(xiàn)嵌套關系，也可以表示模塊的層次結構。盒圖很容易表示程序結構化的層次結構，確定局部和全局數(shù)據(jù)的作用域。由于沒有箭頭，因此不允許隨意轉移控制。第60頁，共173頁，2023年，2月20日，星期一2023/4/15盒圖符號第61頁，共173頁，2023年，2月20日，星期一2023/4/15PAD圖PAD是問題分析圖（ProblemAnalysisDiagram）的英文縮寫，自1973年由日本日立公司發(fā)明。它是由程序流程圖演化而來，用二維樹形結構的圖來表示程序的控制流，將這種圖翻譯成程序代碼比較容易。PAD圖的基本原理：采用自頂向下、逐步細化和結構化設計的原則，力求將模糊的問題解的概念逐步轉換為確定的和詳盡的過程，使之最終可采用計算機直接進行處理。第62頁，共173頁，2023年，2月20日，星期一2023/4/15PAD圖符號第63頁，共173頁，2023年，2月20日，星期一2023/4/15PAD圖舉例第64頁，共173頁，2023年，2月20日，星期一2023/4/15HIPO圖HIPO（HiberarchyPlusInput-Process-Output,層次加輸入-處理-輸出）圖是根據(jù)IBM公司研制的軟件設計與文件編制技術發(fā)展而來的。HIPO圖采用功能框圖和PDL來描述程序邏輯，它由兩部分組成：可視目錄表給出程序的層次關系體系框圖：又稱層次圖（H圖），是可視目錄表的主體，用它表明各個功能的隸屬關系圖例：圖形符號說明描述說明：每一框的補充說明IPO圖則為程序各部分提供具體的工作細節(jié)第65頁，共173頁，2023年，2月20日，星期一2023/4/15盤存／銷售系統(tǒng)工作流程圖第66頁，共173頁，2023年，2月20日，星期一2023/4/15層次圖第67頁，共173頁，2023年，2月20日，星期一2023/4/15說明第68頁，共173頁，2023年，2月20日，星期一2023/4/15IPO圖第69頁，共173頁，2023年，2月20日，星期一2023/4/15詳細的IPO圖第70頁，共173頁，2023年，2月20日，星期一2023/4/15圖書館系統(tǒng)第71頁，共173頁，2023年，2月20日，星期一2023/4/15圖書館系統(tǒng)第72頁，共173頁，2023年，2月20日，星期一2023/4/15維護管理系統(tǒng)第73頁，共173頁，2023年，2月20日，星期一2023/4/15第12講面向對象設計面向對象設計構件設計設計模式第74頁，共173頁，2023年，2月20日，星期一2023/4/15系統(tǒng)模型描述模型就是為了理解事物而對事物所做的一種抽象，是對事物規(guī)范的、無歧義描述的一種工具。系統(tǒng)模型主要建立三種模型：功能模型：指明了系統(tǒng)應該“做什么”動態(tài)模型：規(guī)定在何種狀態(tài)下，接受什么事件的觸發(fā)而“做什么”對象模型：定義了“做什么”的實體統(tǒng)一建模語言（UML）從不同視角為系統(tǒng)建模。用例模型結構（邏輯）模型行為模型實現(xiàn)模型實施模型第75頁，共173頁，2023年，2月20日，星期一2023/4/15邏輯架構邏輯架構是軟件類的宏觀組織結構，它將軟件類組織為包（或命名空間）、子系統(tǒng)和層等。層是對類、包或子系統(tǒng)的甚為粗粒度的分組，具有對系統(tǒng)主要方面加以內聚的職責。通常包括的層有：用戶界面層：處理用戶交互信息。應用邏輯和領域對象：表示領域概念的軟件對象，這些對象實現(xiàn)了應用需求。例如計算銷售總額。 技術服務：提供支持性技術服務的常用對象和子系統(tǒng)。UML包圖通常用于描述系統(tǒng)得邏輯架構—層、子系統(tǒng)、包等。層可以建模為UML包。第76頁，共173頁，2023年，2月20日，星期一2023/4/15對象識別對象識別實際上是識別對象類，設計就是使用這些類來描述的。識別的方法：對系統(tǒng)的自然語言描述做文法分析，即名詞標識技術。對象和屬性是名詞，操作和服務是動詞，可以推理文本描述來識別候選類，然后分析去掉不能成為類的候選類。使用應用領域中的真實實體、職務、事件、交互、位置、機構等，在存在的系統(tǒng)中尋找對象。也可以通過識別存儲結構（抽象數(shù)據(jù)結構）來識別對象。使用行為方法CRC：這種方法要求設計者了解系統(tǒng)的全部行為，了解各部分的各種不同的行為。對每個行為要了解是誰發(fā)起的，以及哪些實體參與了這個行為。參與一個行為，并在其中產生重要作用者即可視為對象。識別系統(tǒng)使用的各個腳本，并依次對其進行分析。第77頁，共173頁，2023年，2月20日，星期一2023/4/15設計模型面向對象設計模型是對系統(tǒng)中包含的對象或對象類，以及它們之間的不同類型關系的描述。面向對象的設計兩類設計模型:靜態(tài)模型:通過系統(tǒng)對象類及其之間的關系來描述系統(tǒng)的靜態(tài)結構。在UML中常用類圖、用例圖、構件圖、包圖等描述系統(tǒng)中元素的關系。動態(tài)模型:描述系統(tǒng)的動態(tài)結構和系統(tǒng)對象之間的交互。在UML中常用時序圖、協(xié)作圖、狀態(tài)圖、活動圖等來描述系統(tǒng)的行為。域類模型領域分析確定域類包模型：用包圖表示第78頁，共173頁，2023年，2月20日，星期一2023/4/15域類模型<BusinessObject>Item-id:integer+findonTitle()+findonid()+findonReservation()create()destroy<BusinessObject>Loan-id:integer-borroweddate:date-returndate:date-borrowerid:integercreate()destroybeloanedina<BusinessObject>Borrower-borrowerid:integer-name:string-borrowednum:integer-fine:number+find()create()destroyhashasbereservedina<BusinessObject>Title-bookid:string-borrowednum:integer-reservatednum:integer+finde()create()destroy<BusinessObject>Reservation-reserveddate:date-noticedate:date-borrowerid:integer-isbn:string+find()create()destroycopyof第79頁，共173頁，2023年，2月20日，星期一2023/4/15包圖《子系統(tǒng)》圖書流通《子系統(tǒng)》圖書維護《子系統(tǒng)》信息查詢圖書流通《子系統(tǒng)》交互界面管理所有的與外部通信《子系統(tǒng)》標識圖書標識圖書并更新信息《子系統(tǒng)》標識借閱標識借閱者并更新信息第80頁，共173頁，2023年，2月20日，星期一2023/4/15對象接口描述接口設計中應該避免涉及接口的具體表示正確的方式是將具體的接口實現(xiàn)方法隱藏起來，只提供對象操作來訪問對象和修改數(shù)據(jù)接口可以用UML中的類圖形式來描述UML的格式標記“interface”中必須包含名字部分第81頁，共173頁，2023年，2月20日，星期一2023/4/15圖書館系統(tǒng)中借書者的接口interfaceborrower{ publicvoidborrower(intborrowerid,intbookid); publicvoidsetborrower(intborrowerid); publicvoidaddload(Loadloaditem); publicvoidgetload(); publicvoidgetnoload(); publicvoidremoveload(); publicvoidwrite(); publicvoidread(); …}//borrower第82頁，共173頁，2023年，2月20日，星期一2023/4/15構件級設計構件級設計定義了數(shù)據(jù)結構、算法、接口特征和分配給每個軟件構件的通信機制。每個構件的類定義或者處理敘述都轉化為一種詳細設計，設計采用圖形或基于文本的形式來詳細說明內部的數(shù)據(jù)結構、局部接口細節(jié)和處理邏輯。設計符號包括UML圖和一些輔助表示。通過一系列結構化編程結構來說明程序的設計。第83頁，共173頁，2023年，2月20日，星期一2023/4/15構件類構件是計算機軟件中的一個模塊化的構造塊在OMGUML規(guī)范中將構件定義為“系統(tǒng)中某一定型化的、可配置的和可替換的部件，該部件封裝了實現(xiàn)并暴露一系列接口”。面向對象的觀點：構件中的每一個類都被詳細闡述，包括所有的屬性和與其實現(xiàn)相關的操作。從分析模型開始，詳細描述分析類（對于構件而言該類與問題域相關）和基礎類（對于構件而言該類為問題域提供了支持性服務）。傳統(tǒng)觀點：模塊控制構件，協(xié)調問題域中所有其他構件的調用；問題域構件，完成部分或全部用戶的需求；基礎設施構件，負責完成問題域中所需要相關處理的功能。第84頁，共173頁，2023年，2月20日，星期一2023/4/15構件級設計步驟步驟1：標識出所有與問題域相對應的設計類步驟2：確定所有與基礎設施相對應的設計類步驟3：細化所有不能作為復用構件的設計類在類或構件的協(xié)作時說明消息的細節(jié)為每一個構件確定適當?shù)慕涌诩毣瘜傩圆⑶叶x相應的數(shù)據(jù)類型和數(shù)據(jù)結構詳細描述每個操作中的處理流步驟4：說明持久性數(shù)據(jù)源（數(shù)據(jù)庫和文件）并確定管理數(shù)據(jù)源所需要的類步驟5：開發(fā)并且細化類或構件的行為表示步驟6：細化部署圖以提供額外的實現(xiàn)細節(jié)步驟7：考慮每一個構件級設計表示，并且時刻考慮其他選擇第85頁，共173頁，2023年，2月20日，星期一2023/4/15基于類的構件設計原則開關原則(TheOpen-ClosedPrinciple,OCP)：模塊應該對外延具有開放性，對修改具有封閉性。替換原則(SubsitutionPrinciple,SP)：子類可以替換它們的基類。依賴倒置原則(DependencyInversionPrinciple,DIP)：依賴于抽象、而非具體實現(xiàn)接口分離原則(InterfaceSegregationPrinciple,ISP)：多個用戶專用接口比一個通用接口要好。發(fā)布復用等價性原則（ReleaseReuseEquivalencyPrinciple,REP）：復用的粒度就是發(fā)布的粒度。共同封裝原則（CommonClosurePrinciple,CCP）： 一同變更的類應該和在一起。共同復用原則（CommonReusePrinciple，CRP）：不能一起復用的類不能被分到一組。第86頁，共173頁，2023年，2月20日，星期一2023/4/15設計模式有經驗的軟件開發(fā)者建立了既有通用原則又有慣用方案的指令系統(tǒng)來指導他們編制軟件。如果以結構化形式對這些問題、解決方案和命名進行描述使其系統(tǒng)化，那么這些原則和習慣用法就可以稱為模式?；诼氊熢O計對象（GeneralResponsibilityAssignmentSoftwarePatterns,GRASP）信息專家、創(chuàng)建者、控制器、高內聚、低耦合、多態(tài)、純虛構、間接性和防止變異GoF(GangofFour)模式23種設計模式，其中基本的有適配器、工廠、單實例類、策略、組合、外觀和觀察者等模式第87頁，共173頁，2023年，2月20日，星期一2023/4/15基于職責的設計職責驅動設計也即基于職責的設計。在設計中軟件對象具有職責，即對其所作所為進行抽象。UML把職責定義為“類元的契約或義務”。就對象的角色而言，職責與對象的義務和行為相關。職責分為以下兩種類型：對象的行為職責包括：自身執(zhí)行一些行為，如創(chuàng)建對象或計算初始化其他對象中的動作控制和協(xié)調其他對象中的活動對象的認知職責包括：對私有封裝數(shù)據(jù)的認知對相關對象的認知對其能夠導出或計算的事物得認知職責的粒度會影響職責到類和方法的轉換第88頁，共173頁，2023年，2月20日，星期一2023/4/15GRASP職責不同于方法，職責是一種抽象，而方法實現(xiàn)了職責。繪制UML交互圖時，就是在決定職責的分配。通過GRASP中的基本原則來指導如果分配職責給一個對象。五種基本的GRASP模式：創(chuàng)建者模式信息專家模式控制器模式低耦合模式高內聚模式第89頁，共173頁，2023年，2月20日，星期一2023/4/15職責與方法第90頁，共173頁，2023年，2月20日，星期一2023/4/15創(chuàng)建者模式問題：一個對象由誰（哪個對象）創(chuàng)建？指導原則是：將創(chuàng)建一個對象A的職責分配給對象B的條件是B“包含”或組成聚集了A、B記錄A、B緊密地使用A或者B具有A初始化數(shù)據(jù)并且在創(chuàng)建A時會將這些數(shù)據(jù)傳遞給A。簡而言之，就是一個對象要由擁有或者使用其信息的、與其有密切關系的另一個已存在的對象創(chuàng)建。例如在POS機系統(tǒng)中的Sale對象是由那個對象類創(chuàng)建？對于對象Sale由誰創(chuàng)建，分析一下領域模型就會發(fā)現(xiàn)，可以認為Register是記錄Sale的類。因此Register對象是創(chuàng)建Sale對象的合理選擇。第91頁，共173頁，2023年，2月20日，星期一2023/4/15POS機系統(tǒng)中誰創(chuàng)建Sale對象第92頁，共173頁，2023年，2月20日，星期一2023/4/15信息專家模式信息專家（通常稱為專家）模式是最基本的職責分配原則之一。創(chuàng)建者是對象的行為職責，而信息專家常常指的是對象的認知職責。指導原則是：給對象分配職責時，應該把職責分配給具有完成該職責所需要信息的那個類。例如在POS機系統(tǒng)中，銷售的總額該如果確定？決定總額的一些元素應該是屬于哪些對象的信息？按照信息專家的建議，這里應當尋找具有確定總額所需信息的那個對象類。分析領域模型和設計模型得到，要計算總額應該知道銷售的所有SalesLineItem實例及其小計之和。Sale實例包含了上述信息。為了確定商品的小計，這里需要SalesLineItem.quantity、和ProductDescription.price。SalesLineItem知道其數(shù)量和與其關聯(lián)的ProductDescription。第93頁，共173頁，2023年，2月20日，星期一2023/4/15計算銷售總額第94頁，共173頁，2023年，2月20日，星期一2023/4/15控制器模式根據(jù)MVS（ModelViewSeparation）原則，UI對象不應當包含應用邏輯或業(yè)務邏輯。應該把UI層的操作或者請求委派給一個協(xié)調者，由協(xié)調者把任務轉發(fā)給領域層的領域對象?？刂破骶褪沁@樣一個協(xié)調者。例如在POS機系統(tǒng)中，enterItem和endSale這樣的系統(tǒng)事件，應使用誰作為控制器？指導原則是：控制器是UI層之上的第一個對象，它負責接收和處理系統(tǒng)操作消息?？刂破鞯倪x擇原則是：代表全部“系統(tǒng)”、“根對象”、運行軟件的設備或主要的子系統(tǒng)（如，外觀控制器）；代表發(fā)生系統(tǒng)操作的用例場景（如，會話控制器）。在用例場景中發(fā)生的系統(tǒng)事件通常命名為<UseCaseName>Handler、<UseCaseName>Coordinator或<UseCaseName>Session。對于用同一用例場景的所有系統(tǒng)事件使用相同的控制器類。第95頁，共173頁，2023年，2月20日，星期一2023/4/15控制器類第96頁，共173頁，2023年，2月20日，星期一2023/4/15低耦合模式低耦合模式是一個評價模式。低耦合原則適用于軟件開發(fā)的很多方面，它是構件軟件最重要的目標之一。指導原則是：分配職責以使耦合保持在較低的水平。在真實世界領域中，Register記錄了Payment,所以創(chuàng)建者模式建議將Register作為創(chuàng)建Payment的候選者。Register實例會把addPayment消息發(fā)送給Sale，并把新的Payment作為參數(shù)傳遞給它。這種職責分配使Register類和Payment類之間產生了耦合，即Register類要知道Payment類。第97頁，共173頁，2023年，2月20日，星期一2023/4/15高耦合問題第98頁，共173頁，2023年，2月20日，星期一2023/4/15低耦合解決方案第99頁，共173頁，2023年，2月20日，星期一2023/4/15高內聚模式高內聚模式是一個評價模式。內聚是軟件設計中的一種基本品質，內聚可以非正式地用于度量軟件元素操作在功能上的相關程度，也可以用于度量軟件元素完成的工作量。指導原則是：分配職責可保持較高的內聚性。第100頁，共173頁，2023年，2月20日，星期一2023/4/15低內聚問題第101頁，共173頁，2023年，2月20日，星期一2023/4/15高內聚解決方案第102頁，共173頁，2023年，2月20日，星期一2023/4/15第13講面向對象設計方法面向對象詳細設計案例分析第103頁，共173頁，2023年，2月20日，星期一2023/4/15面向對象詳細設計面向對象詳細設計的目的就是不斷精化設計類領域模型也稱為概念模型、領域對象模型和分析對象模型。領域模型的精化對類圖和交互圖的精化起了至關重要的作用，也是設計個良好系統(tǒng)的關鍵。使用泛化、特化、關聯(lián)類、時間間隔、組合和包等概念精化領域模型。第104頁，共173頁，2023年，2月20日，星期一2023/4/15泛化和特化泛化是在多個概念中識別共性和定義超類（普遍概念）與子類（具體概念）關系的活動。例如在POS機系統(tǒng)中CashPayment,CreditPayment和ChequePayment。在領域中識別父類和子類是一個有價值的活動，這樣可以使我們對概念有更概括、精煉和抽象的描述。第105頁，共173頁，2023年，2月20日，星期一2023/4/15POS機系統(tǒng)中Payment第106頁，共173頁，2023年，2月20日，星期一2023/4/15定義概念超類和子類概念超類的定義較子類的定義更為概括或包含范圍更廣。例如，在POS機系統(tǒng)中，考慮超類Payment和它的子類。將概念類劃分為子類的動機有：子類有額外的有意義的屬性；子類有額外的有意義的關聯(lián)；子類概念的操作、處理、反應或使用的方式不同于其超類或其他子類，而這些方式是我們所關注的；子類概念表示了一個活動體，其行為與超類或者其他子類不同，而這些行為是我們所關注的。泛化和定義概念超類的動機：潛在的概念子類表示的是相似概念的不同變體；子類滿足100%準則（即概念超類的定義必須100%適用于子類，子類必須100%與超類一致。）；所有子類都具有相同的屬性，可以將其解析出來并在超類中表達；所有子類都具有相同的關聯(lián)，可以將其解析出來并與超類關聯(lián)。第107頁，共173頁，2023年，2月20日，星期一2023/4/15Payment類層次劃分第108頁，共173頁，2023年，2月20日，星期一2023/4/15關聯(lián)類原則：在領域模型中，如果類A可能同時有多個相同的屬性B，則不要將屬性B置于A之中。應該將屬性B放在另一個類C中，并且將其與類A關聯(lián)。這樣就得出一個關聯(lián)類C。在POS機系統(tǒng)中，授權服務給每個商店分配一個商業(yè)ID，商店發(fā)送授權服務的支付授權請求需要商業(yè)ID標識商店，商店對于每個服務有不同的商業(yè)ID。Store可能有多個merchantID值，所以將merchantID作為Store的屬性是不正確的。同理，放入AuthorizationService中也不正確?？梢杂靡粋€關聯(lián)類ServiceContract來擁有屬性merchantID關聯(lián)類的增加具有原則：有某個屬性與關聯(lián)相關；關聯(lián)類的實例具有依賴于關聯(lián)的生命期；兩個概念之間有多對多關聯(lián)，并且存在與關聯(lián)自身相關的信息。第109頁，共173頁，2023年，2月20日，星期一2023/4/15關聯(lián)類第110頁，共173頁，2023年，2月20日，星期一2023/4/15聚合關系和組合關系聚合是UML中的是UML中的一種模糊關聯(lián)，其不明確的暗示了整體和部分關系。組合也稱組成聚合，是一種強的整體—部分聚合關系，并且在某些模型中具有效用。組合關系意味著：在某一時刻，部分的一個實例只屬于一個組成實例；部分必須總是屬于組成；組成要負責創(chuàng)建和刪除部分，可以自己創(chuàng)建和刪除部分也可以和其它對象協(xié)作進行創(chuàng)建和刪除部分；組成被銷毀，其部分必須要銷毀。組合關系的識別準則是：部分的生命期在組成的生命期之內，部分的創(chuàng)建餓刪除依賴于整體；在物理或者邏輯組裝上，有明確的整體—部分關系；組成的某些屬性會傳遞給部分；對組成的操作可能傳遞給部分。第111頁，共173頁，2023年，2月20日，星期一2023/4/15識別和顯示組合關系好處：有利于澄清部分對整體的依賴的領域約束；有助于使用GRASP創(chuàng)建者模式識別創(chuàng)建者；對整體的復制、拷貝這些操作經常會傳遞給部分。在POS機系統(tǒng)中，SalesLineItems可以被視為Sale的組成部分。ProductCatalog是ProductDescriptions的一個組成。第112頁，共173頁，2023年，2月20日，星期一2023/4/15組合關系第113頁，共173頁，2023年，2月20日，星期一2023/4/15時間間隔例如，POS機系統(tǒng)在初始設計時，SalesLineItems與ProductDescriptions關聯(lián)，記錄了銷售項的價格。在精化過程中，需要關注與信息、合同等相關的時間間隔問題。如果SalesLineItems從ProductDescriptions取得當前價格，當價格改變時，以前的銷售將指向新的價格，這很顯然是不正確的。需要區(qū)別銷售發(fā)生時的歷史價格和當前價格?；谛畔⑿枨?，可以采用兩種方法對此問題解決：一是可以在ProductDescriptions中保存當前價格，僅將銷售發(fā)生時的價格寫入SalesLineItem；二是將一組ProductPrices與ProductDescriptions關聯(lián)，每個ProductPrices關聯(lián)適用的時間間隔。第114頁，共173頁，2023年，2月20日，星期一2023/4/15區(qū)別歷史價格和當前價格第115頁，共173頁，2023年，2月20日，星期一2023/4/15使用包來組織領域模型將領域模型劃分成包結構時，將滿足下述條件的元素放在一起：在同一個主題領域，概念或目標密切相關的元素；在同一個類層次結構中的關系；參與同一個用例的元素；有很強的關聯(lián)性的元素。例如，在POS機系統(tǒng)領域模型中包的結構第116頁，共173頁，2023年，2月20日，星期一2023/4/15POS機系統(tǒng)領域模型第117頁，共173頁，2023年，2月20日，星期一2023/4/15包嵌套第118頁，共173頁，2023年，2月20日，星期一2023/4/15邏輯架構精化在邏輯架構精化設計中主要更細化各層內部元素、層與層之間關系和分層架構中一些模式的應用。遵循模型-視圖-控制器（MVC）三層模型。在精化邏輯模型時首先要進一步指出個系統(tǒng)層之間、包之間的關系。可以用依賴線來表達包或者包內類型之間的耦合。依賴線可以由一個包發(fā)出例如在POS機系統(tǒng)中從Sale包指向POSRuleEngineFacade類，從Domain包指向Log4J包。第119頁，共173頁，2023年，2月20日，星期一2023/4/15第120頁，共173頁，2023年，2月20日，星期一2023/4/15簡單包和子系統(tǒng)第121頁，共173頁，2023年，2月20日，星期一2023/4/15外觀和控制器第122頁，共173頁，2023年，2月20日，星期一2023/4/15模型-視圖分離和“向上”通信第123頁，共173頁，2023年，2月20日，星期一2023/4/15包設計準則包在水平和垂直劃分上的功能性內聚由一族接口組成的包正式包和聚集不穩(wěn)定類的包職責越多的包越需要穩(wěn)定將不相關的類型分離出去使用工廠模式減少對具體包的依賴第124頁，共173頁，2023年，2月20日，星期一2023/4/15分離不相關的類型第125頁，共173頁，2023年，2月20日，星期一2023/4/15具體包的依賴第126頁，共173頁，2023年，2月20日，星期一2023/4/15工廠模式減少對具體包的依賴第127頁，共173頁，2023年，2月20日，星期一2023/4/15精化的交互圖在交互圖中，領域模型指出了需要設計的軟件對象，設計模型中的設計類是以領域模型的類為基礎的。在順序圖和協(xié)作圖精化設計中，一些類直接來自前面的分析模型中的類，還有一些針對軟件系統(tǒng)的更好的實現(xiàn)虛構出來的。例如設計makeNewSale操作。要處理一次新的銷售，首先必須創(chuàng)建軟件對象Sale。根據(jù)控制器模式我們還需要設計一個轉發(fā)makeNewSale請求的對象Register。Register是記錄Sale的類。又根據(jù)創(chuàng)建者模式得出應該由Register創(chuàng)建Sale。在銷售過程中必須設計一個集合來存儲一系列的商品，所有由Sale對象創(chuàng)建了記錄所有將來會添加的集合SalesLineItem實例。第128頁，共173頁，2023年，2月20日，星期一2023/4/15精化設計類第129頁，共173頁，2023年，2月20日，星期一2023/4/15輸入商品第130頁，共173頁，2023年，2月20日，星期一2023/4/15結束銷售第131頁，共173頁，2023年，2月20日，星期一2023/4/15獲取總價第132頁，共173頁，2023年，2月20日，星期一2023/4/15處理支付第133頁，共173頁，2023年，2月20日，星期一2023/4/15計算找零第134頁，共173頁，2023年，2月20日，星期一2023/4/15精化的類圖類圖和對象圖是設計階段的主要制品順序圖和協(xié)作圖中的消息映射為類圖中的方法，交互消息的對象映射為類的對象，每個消息的交互實現(xiàn)映射為類圖和對象圖中方法的實現(xiàn)。在類圖的精化設計中不僅要得到每個類中的屬性和方法，還要有方法的粗略實現(xiàn)（也即方法的實現(xiàn)過程）第135頁，共173頁，2023年，2月20日，星期一2023/4/15可見性的設計可見性的設計主要有四種：屬性可見性參數(shù)可見性局部可見性全局可見性classRegister{

…… privateProductCalatogcatalog; publicvoidenterItem(itemID,qty){

…… desc=catalog.getProductDesc(itemID);

…… }

……}第136頁，共173頁，2023年，2月20日，星期一2023/4/15類圖的細化類圖的設計是以交互圖的設計為基礎的，類圖中的元素也是從交互圖中抽象提取出來的。通過交互圖中對象之間的交互，找出對象所屬的類以及類之間的關系。通過對交互圖中對象之間消息的交互的分析和細化得到類圖中的屬性和方法。對類圖進行分析的時候也必須理解類圖和類之間的關系如何映射得到具體的實現(xiàn)類。第137頁，共173頁，2023年，2月20日，星期一2023/4/15輸入商品條目的類圖第138頁，共173頁，2023年，2月20日，星期一2023/4/15細化的類圖第139頁，共173頁，2023年，2月20日，星期一2023/4/15實現(xiàn)publicclassRegister{ privateProductCatalogcatalog； privateSalecurrentSale；

publicRegister（ProductCatalogpc）{…} publicvoidendSale（）{…} publicvoidenterItem（ItemIDid，intqty）{…} publicvoidmakeNewSale（）{…} publicvoidmakePayment（MoneycashTendered）{…} }第140頁，共173頁，2023年，2月20日，星期一2023/4/15持久性設計持久性設計的目的就是讓對象能夠方便、快捷的持久化存儲。所以在系統(tǒng)中要持久存儲的對象也叫做持久性對象。例如：在POS系統(tǒng)中的SaleLineItem對象、ProductDescription對象。在運用關系型數(shù)據(jù)庫來存儲對象信息時需要第三方或者系統(tǒng)擁有的持久性服務。通過這種持久性服務來解決面向對象和面向記錄的數(shù)據(jù)之間的失配問題。用對象數(shù)據(jù)庫來存儲對象時就不需要設計持久性服務。但對象數(shù)據(jù)庫應用比較少。在設計持久性服務時不僅僅對于存儲在關系型數(shù)據(jù)庫中，還設計其他的存儲機制，如普通的文件形式、XML結構、層次數(shù)據(jù)庫等等。第141頁，共173頁，2023年，2月20日，星期一2023/4/15持久化設計的基本原理持久性服務又稱為O-R（對象-關系）映射服務。持久性服務主要完成兩件事：一是在存儲數(shù)據(jù)時，把對象轉換為記錄（或其他數(shù)據(jù)格式如XML），并將其存儲到數(shù)據(jù)庫中；二是在讀取數(shù)據(jù)時，從數(shù)據(jù)庫中讀出記錄型數(shù)據(jù)（或其他格式數(shù)據(jù)），并將其轉換成對象。概念：映射：在類和持久性存儲（如數(shù)據(jù)庫中的表）之間，對象的屬性和記錄的域（屬性列）之間必須存在著一定的映射關系。對象標識：為了方便將記錄與對象聯(lián)系起來并確保沒有重復，所以對象和記錄都必須有唯一的對象標識。具體化和虛化：具體化是指將以某些格式存儲的非對象數(shù)據(jù)（如數(shù)據(jù)庫中的記錄，XML中的數(shù)據(jù)）轉換為對象型數(shù)據(jù)。虛化是指將需要持久化的對象數(shù)據(jù)轉換為非對象形式的數(shù)據(jù)（如記錄）進行存儲。數(shù)據(jù)庫映射器：主要負責具體化和虛化的純虛構映射器。第142頁，共173頁，2023年，2月20日，星期一2023/4/15類ProductDescription表示為表PRODUCTDESCRIPTION表第143頁，共173頁，2023年，2月20日，星期一2023/4/15對象標識符記錄和對象的相互映射都通過對象標識符（OID）來實現(xiàn)。OID的值通常由字母和數(shù)字組成，每個對象具有惟一的OID。有各種方法可以生成惟一的OID，包括對于一個數(shù)據(jù)庫的惟一OID乃至全局性的惟一OID。這些方法包括：數(shù)據(jù)庫序列生成器High-Low鍵生成策略等。在對象領域，OID由封裝實際值及其表示的OID接口或類來表示；在關系數(shù)據(jù)庫中，OID通常被存儲為固定長度的字符串值。每個表都有一個OID作為主鍵，每個對象也（直接或間接的有一個OID）。第144頁，共173頁，2023年，2月20日，星期一2023/4/15通過OID來映射對象和記錄第145頁，共173頁，2023年，2月20日，星期一2023/4/15持久性框架的設計持久性框架是一組通用的、可復用的、可擴展的類型，它提供支持持久性對象的功能，即提供持久性服務。在持久化設計中，可以通過外觀來訪問持久化服務。根據(jù)指定的OID提取對象的操作，當然子系統(tǒng)還必須知道具體化對象的類型，所以在這里要提供具體化后類的類型。例如，在POS機系統(tǒng)中使用外觀訪問持久服務。持久化設計兩種具體化和虛化對象的方式：直接映射：持久性對象類本身定義了自己存儲到數(shù)據(jù)庫中的代碼。但是這種方式使類的耦合性增加了，同時對象類的內聚性也降低。間接映射：使用了數(shù)據(jù)庫代理模式，即創(chuàng)建一個類來負責對象的具體化和虛化。第146頁，共173頁，2023年，2月20日，星期一2023/4/15持久化外觀第147頁，共173頁，2023年，2月20日，星期一2023/4/15數(shù)據(jù)庫映射器第148頁，共173頁，2023年，2月20日，星期一2023/4/15使用模板設計持久性框架使用模板設計持久性框架的思想是，在超類中定義一種方法，這種方法叫模板方法。超類中定義了算法的框架，其中既有固定的部分也有可變的部分。通過模板方法調用其他一些方法，這些方法中有些可能會被子類覆蓋。子類覆蓋這些變化的方法，增加自己特有的行為。第149頁，共173頁，2023年，2月20日，星期一2023/4/15使用模板第150頁，共173頁，2023年，2月20日，星期一2023/4/15部署與構件圖部署圖表示的是如何將具體軟件制品（例如可執(zhí)行文件）分配到計算節(jié)點（具有處理服務的某種事物）上。部署圖表示了軟件元素在物理架構上的部署，以及物理元素之間的通信。部署圖有助于溝通物理或者部署架構。部署圖中最基本的元素是節(jié)點，有兩種類型的節(jié)點：設備節(jié)點：具有處理和存儲能力，可執(zhí)行軟件的物理計算資源，例如典型的計算機或者移動電話。執(zhí)行環(huán)境節(jié)點：在外部節(jié)點中運行的軟件計算資源，其自身可以容納和執(zhí)行其他可執(zhí)行軟件元素。第151頁，共173頁，2023年，2月20日，星期一2023/4/15構件圖構件是系統(tǒng)中用來描述客觀事物的一個實體，它是構成系統(tǒng)的、支持即插即用的基本組成單位，一個構件由一個或多個對象經過包裝構成，通過接口獨立地時外提供服務。一個構件由四部分組成:構件名是構件的唯一標識，采用118位全局唯一標識符GUID來表示。屬性是用來描述構件靜態(tài)特征的一個數(shù)據(jù)項。服務是用來描述構件動態(tài)特征的一個操作序列。接口是用來描述構件對外界提供服務的圖形界面。UML構件是設計級別的視圖，并不存在于具體軟件視圖，但是可以映射為具體的軟件制品。第152頁，共173頁，2023年，2月20日，星期一2023/4/15實例分析：POS機系統(tǒng)第153頁，共173頁，2023年，2月20日，星期一2023/4/15實例分析：POS機系統(tǒng)第154頁，共173頁，2023年，2月20日，星期一2023/4/15實例分析：POS機系統(tǒng)第155頁，共173頁，2023年，2月20日，星期一2023/4/15實例分析：POS機系統(tǒng)第156頁，共173頁，2023