【文章內容簡介】 入庫信息；查詢產(chǎn)品信息 管理權限 普通權限 13 第二章 概要設計 一、軟件體系結構模型 大型軟件系統(tǒng)總是被 分解成一系列子系統(tǒng)，由子系統(tǒng)提供一些相關的服務。軟件體系結構設計過程就是識別出這些子系統(tǒng)，并建立子系統(tǒng)控制和通信的框架，最后給出軟件體系結構的一個描述。 ⒈系統(tǒng)構成模型 系統(tǒng)構成模型有容器模型、客戶 服務器模型和抽象機模型三種。 ⑴容器模型 構成一個系統(tǒng)的子系統(tǒng)一定要澆灌換信息，以便能有效地在一起工作。子系統(tǒng)交換信息、 協(xié)調工作有兩種基本方法： 全部共享書防在一個中央數(shù)據(jù)庫中，所有子系統(tǒng)都能從中存取數(shù)據(jù)； 每個子系統(tǒng)用各自的數(shù)據(jù)庫與其他子系統(tǒng)進行數(shù)據(jù)交互，通過消息傳遞來實現(xiàn)。 一般情況下，大多數(shù)使用大量數(shù)據(jù)的 系統(tǒng)都是圍繞共享數(shù)據(jù)庫（或稱為容器）組織的，所以，基于一個共享數(shù)據(jù)庫的系統(tǒng)的系統(tǒng)模型稱為容器模型。這個模型適合于數(shù)據(jù)由一個子系統(tǒng)產(chǎn)生，而其他子系統(tǒng)共享使用的系統(tǒng)結構。這種類型的系統(tǒng)有命令控制系統(tǒng)、管理信息系統(tǒng)、 CAD 系統(tǒng)和 CASE 工具集成系統(tǒng)等。 共享容器模型的優(yōu)點是能夠高效地共享大量的數(shù)據(jù)，生產(chǎn)數(shù)據(jù)的子系統(tǒng)不需要關心數(shù)據(jù)如何被其他子系統(tǒng)使用，可以集中進行備份、保密、訪問控制和錯誤恢復等活動。其缺點是子系統(tǒng)一定要與容器數(shù)據(jù)一致，系統(tǒng)變更或進化比較困難，難以集成，以及很難將容器分布到多臺機器上。 ⑵客戶 服務 器模型 客戶 服務器模型的主要組成部分是： 一組給其他子系統(tǒng)提供服務的單機服務器； 一組向服務器請求服務的客戶機； 一個連接客戶和服務器的網(wǎng)絡 (可選 )。 客戶機必須知道可用的服務器的名字和它們所提供的服務，并通過遠程調用獲取服務器提供的服務。反之，服務器沒有必要知道客戶機的身份，以及到底有 14 多少客戶機在運行。 客戶 服務器模型能夠實現(xiàn)基于容器模型的系統(tǒng)，容器就充當了系統(tǒng)的服務器。子系統(tǒng)需要訪問容器，因而扮演了客戶機的角色。當然，當運行大量數(shù)據(jù)交換時，這種系統(tǒng)就會產(chǎn)生性能問題?？蛻?服務器模型的最大優(yōu)點是：這是 一個分布式結構，通過網(wǎng)絡可以很容易地添加新的客戶機和服務器，而不會 影響 系統(tǒng)的其他部分。 ⑶抽象機模型 抽象機模型也稱為分層模型，是建立子系統(tǒng)的接口模型，它把子系統(tǒng)組織成一系列的層次，每一層提供一組服務，每一層定義為一個抽象機。 每個抽象機都是由其下層的抽象機的代碼構成的。每一層提供給上一層服務，同時調用下一層的服務。每一層的實現(xiàn)只影響相鄰層，不會影響到系統(tǒng)的其他各層。分層的方法支持系統(tǒng)的增量式開發(fā)，若一層開發(fā)完成，該層提供的服務就可以被用戶使用了。 分層的缺點是：用這種方法構建系統(tǒng)比較困難。幾乎所有抽象機都 需要的基本服務（如文件管理）需要由內層提供，因此，用戶的服務可能需要訪問較深層的抽象機。這一點有悖于一個外層只需要訪問臨近下層抽象機的分層原則。性能也可能是一個問題，因為需要多層的指令解釋過程。如果層次太多，層次管理就將成為系統(tǒng)的一個重要負擔。 根據(jù)三種系統(tǒng)構成模型的介紹，很明顯地可以知道本倉庫管理系統(tǒng)是基于 容器 模型設計的。倉庫管理系統(tǒng)只使用到一個總數(shù)據(jù)庫，而其中提供的所有服務都直接訪問該數(shù)據(jù)庫 ，因此本倉庫管理系統(tǒng)具備容器模型的各種特性。 ⒉系統(tǒng)控制模式 軟件體系結構除了要明確系統(tǒng)構成模型之外，還要給出子系 統(tǒng)的控制模式，使子系統(tǒng)能夠根據(jù)控制模式工作。在體系結構層次上的控制模式主要反映子系統(tǒng)之間的控制流。 系統(tǒng)控制模式有兩種一般性的建模方法，即集中式控制和事件驅動控制。 ⑴集中式控制 在集中式控制模型中，一個子系統(tǒng)被定義為系統(tǒng)控制器來負責管理其他系統(tǒng)的執(zhí)行。集中式控制模型又可分為調用 返回模型和管理者模型兩類。 15 ①調用 返回模型。 這是一個自上而下的子過程模型。控制始于系統(tǒng)（程序）的頂層，在子系統(tǒng)（程序）調用過程中，控制逐步傳遞到更低的層次中。該模型適用于順序執(zhí)行的系統(tǒng)。 ②管理者模型。 這是一種適用于并發(fā)系統(tǒng) 的模型。一個系統(tǒng)組件被指定為系統(tǒng)管理者， 控制其他系統(tǒng)過程的啟動、終止和協(xié)調。一個過程就是一個能和其他過程并發(fā)執(zhí)行的子系統(tǒng)或模塊。 ⑵事件驅動控制 在集中式控制模型中，控制決斷通常決定于一些系統(tǒng)狀態(tài)變量值。相反，事件驅動的控制模型是通過外部產(chǎn)生的事件驅動系統(tǒng)的。有多種不同的基于事件驅動的系統(tǒng)，如電子表格、基于規(guī)則的產(chǎn)生式系統(tǒng)等。下面是兩種事件驅動的控制模型。 ①廣播模型。 發(fā)生的事件廣播到所有子系統(tǒng)，任何能處理該事件的子系統(tǒng)都會響應。該模型適用于基于網(wǎng)絡的分布式系統(tǒng)。 ②中斷驅動模型。 由中斷處理器對來自外部 的中斷進行檢測，然后在其他組件中處理這些中斷。該模型適用于對定時有嚴格要求的實時系統(tǒng)。 廣播模型中的子系統(tǒng)注冊其感興趣的特別事件，當這些事件發(fā)生的時候，控制被轉換到處理這些 事件 的子系統(tǒng)。所有的事件都可以被發(fā)送到所有的子系統(tǒng)，但這樣做增加了子系統(tǒng)的開銷。一般地，事件和消息處理器要維護子系統(tǒng)的注冊和這些子系統(tǒng)所感興趣的事件。 廣播模型的優(yōu)點是進化比較簡單，處理特別類型事件的新的子系統(tǒng)可以通過在事件處理器中注冊這些事件來達到集成；其缺點是子系統(tǒng)相互競爭地處理事件，這可能會引起沖突。 中斷驅動模型只用在硬件實時系統(tǒng) 中，要求對一些事件能作出及時響應，這可以與集中式控制模型結合起來使用。中央管理者處理系統(tǒng)的一般性運轉，而中斷控制用于對緊急事件作出反應。 16 而本倉庫管理系統(tǒng)顯然屬于前者，所有的子系統(tǒng)都是由 一個總的系統(tǒng)控制的，觸發(fā)子系統(tǒng)的調用主要取決于系統(tǒng)狀態(tài)量的改變 。并且可以看出，倉庫管理系統(tǒng)是屬于管理者模型的。 二、用面向數(shù)據(jù)流的方法設計系統(tǒng)軟件結構 ⒈倉庫管理軟件結構 在需求分析中，已經(jīng)使用結構化方法分析了“倉庫管理系統(tǒng)”。因此，可以從圖 16 所示的倉庫管理系統(tǒng) 流 圖出發(fā)來設計倉庫管理系統(tǒng)的結構。 17 圖 15 倉庫管理系統(tǒng)數(shù)據(jù)流圖 下一個設計步驟是完成“第一級分解”。所謂“第一級分解”就是確定系統(tǒng)的總體控制結構。通常，變換分析得出的系統(tǒng)高層結構是一個“三叉”控制結構。針對“倉庫管理”得出的高層控制結構如圖 16所示。 用戶數(shù)據(jù) D1 倉庫數(shù)據(jù) 產(chǎn)品入庫 維護模塊 D1 倉庫數(shù)據(jù) 用戶 客戶管理 用戶管理 退出系統(tǒng) D2 客戶資料 D3 用戶資料 產(chǎn)品出庫 產(chǎn)品查詢 用 戶 數(shù) 據(jù) 幫助模塊 18 圖 16 倉庫管理的“第一級分解” 再下一個設計步驟是完成“第二級分解”。所謂“第二級分解”，就是把數(shù)據(jù)流圖中的每個處理映射成軟件結構中的一個適當?shù)哪K。變換分析的映射規(guī)則是從變換中心的邊界開始沿著輸入通 路向外移動，把輸入通路中每個處理映射成軟件結構中“輸入信息處理控制模塊”控制下的一個低層模塊；然后沿著輸出通路向外移動，把輸出通路中每個處理映射成直接或間接接受“輸出信息處理控制模塊”控制的一個低層模塊；最后把變換中心內的每個處理映射成接受“變換中心控制模塊”控制的一個低層模塊。 對于“倉庫管理”來說，“第二級分解”的結果如圖 17 所示。 圖 17 倉庫管理的“第二級分解” 最后洋設計步驟是對倉庫管理的初步結果優(yōu)化。結合倉庫管理的“第二級分解”圖可以將其 優(yōu)化成如下的軟件結構圖。 倉庫管理 接收數(shù)據(jù) 處理 數(shù)據(jù) 輸出 數(shù)據(jù) 倉庫管理 接收數(shù)據(jù) 處理數(shù)據(jù) 輸出數(shù)據(jù) 幫助信息 驗證用戶 權限 收集數(shù)據(jù) 審核數(shù)據(jù) 修改更新 統(tǒng)計數(shù)據(jù) 匯總數(shù)據(jù) 分析數(shù)據(jù) 19 圖 18 優(yōu)化后的倉庫管理軟件結構 ⒉ 系統(tǒng)帳戶管理軟件結構 根據(jù)數(shù)據(jù)流圖，能夠得到系統(tǒng)帳戶管理軟件結構如下圖所示。 圖 19 系統(tǒng)帳戶管理軟件結構 綜合上面的分析，可進一步得到包含系統(tǒng)帳戶管理、倉庫管理和系統(tǒng)數(shù)據(jù)管理三大子功能的軟件結構如圖 20所示。 倉庫管理 接收數(shù)據(jù) 處理數(shù)據(jù) 打印報表 驗證用戶 權限 收集數(shù)據(jù) 審核數(shù)據(jù) 修改更新 統(tǒng)計數(shù)據(jù) 匯總數(shù)據(jù) 分析數(shù)據(jù) 系統(tǒng)帳戶管理 修改更新授權 驗證用戶 查詢用戶 20 圖 20 倉庫管理系統(tǒng)細化的軟件結構 結合上述的分析描述，得到倉 庫管理系統(tǒng)的完整軟件結構圖，如圖 21 所示。 倉庫管理 接收數(shù)據(jù) 處理數(shù)據(jù) 幫助信息 驗證用戶 權限 收集數(shù)據(jù) 審核數(shù)據(jù) 修改更新 統(tǒng)計數(shù)據(jù) 匯總數(shù)據(jù) 分析數(shù)據(jù) 系統(tǒng)帳戶管理 修改更新授權 查詢用戶 21 圖 21 倉庫管理系統(tǒng)的完整軟件結構 三、數(shù)據(jù)庫邏輯結構設計 數(shù)據(jù)庫邏輯結構設計的任務是根據(jù) ER模型和需求分析所產(chǎn)生的文檔，并綜合考慮所選擇的具體 DBMS 的特點，設計出整個數(shù)據(jù)庫的邏輯結構 。 一般來說，選擇哪一種 DBMS 存放數(shù)據(jù)，是由系統(tǒng)分析員和用戶（一般是企業(yè)的高級管理人員）決定的。需要考慮的因素包括 DBMS 產(chǎn)品的性能和價格，以及所設計的應用系統(tǒng)的功能復雜程度 。 如果選擇的是關系型 DBMS 產(chǎn)品，那么邏輯結構的設計就是指設計數(shù)據(jù)庫中所包含的各個關系模式的結構，包括關系模式的名稱、每 一 關系模式中各屬性的名稱、數(shù)據(jù)類型和取值范圍等