系統的總體設計課件

第六章系統的總體設計6.1系統設計概述6.2軟件體系架構6.3子系統設計和訪問控制設計6.4總體設計報告第六章系統的總體設計6.1系統設計概述6.1系統設計概述系統設計包括總體設計和詳細設計兩部分。系統設計是把分析模型轉變成系統設計模型的過程。1．系統設計的目標系統設計的任務是依據系統的邏輯模型，結合實際情況，設計出一個能在計算機系統上實現的具體設計方案，即新系統的物理模型。系統設計的目標應從以下幾個方面進行考慮。(1)．系統的可靠性(2)．系統的可維護性(3)．系統的用戶友好性(4)．系統的工作效率(5)．系統的合法性下一頁返回6.1系統設計概述系統設計包括總體設計和詳細設計兩部分。系統6.1系統設計概述(6)．系統的經濟性2．系統設計的內容系統設計的內容可分為總體設計和詳細設計兩部分。具體包括如下內容：(1)．系統配置設計設計人員根據系統分析報告中所確定的系統目標、功能、性能、環(huán)境與制約條件，確定合適的計算機處理方式及體系結構，確定合適的計算機系統具體配置。(2)．子系統和功能模塊設計根據系統分析階段得到的數據流程圖和數據詞典，設計出子系統和功能模塊結構圖，明確它們之間的相互關系。上一頁下一頁返回6.1系統設計概述(6)．系統的經濟性上一頁下一頁返回6.1系統設計概述(3)．對象設計根據系統分析報告設計出管理信息系統中用到的各種對象，確定對象類型、屬性、操作、服務及方法等，并形成對象設計文檔。如產品、往來客戶、職工及業(yè)務處理等各類對象的設計。(4)．數據庫設計根據系統分析報告與系統的硬件、軟件配置，進行數據庫的概念設計、邏輯設計、物理設計，設計出系統有關的數據庫文件、數據庫結構、存取路徑、存取方式等。(5)．輸入/輸出設計根據系統的目標、用戶的使用習慣及使用的方便，確定系統輸入的內容、輸入格式、輸入方式與輸入校驗;完成系統輸出的內容、輸出格式及輸出方式等內容的具體設計。上一頁下一頁返回6.1系統設計概述(3)．對象設計根據系統分析報告設計出管理6.1系統設計概述(6)．業(yè)務邏輯處理設計對系統中每一業(yè)務事項的詳細處理過程進行描述，編寫業(yè)務流程圖、處理方法和處理順序等，作為設計開發(fā)詳細設計和實現主要依據。(7)．編寫系統設計報告根據系統設計階段所完成的總體設計及詳細設計內容，以書面的形式編寫符合要求的系統設計報告。系統設計報告既是系統設計階段的主要成果，經過審查批準后又是系統實施階段的主要技術依據。以上內容的設計在系統設計階段是按照一定的先后次序進行的，一般是先進行系統配置設計或系統架構設計，形成系統設計報告。再進行詳細設計包括細化對象設計、數據庫設計、輸入設計、輸出設計、模塊處理過程設計等具體內容，最后再編寫詳細設計文檔。上一頁返回6.1系統設計概述(6)．業(yè)務邏輯處理設計對系統中每一業(yè)務事6.2軟件體系架構隨著系統復雜度的增加，系統分解的說明就變得相當關鍵。一旦開始進行開發(fā)，就很難修改或者糾正一個不好的分解，因為這樣大多數子系統的接口就必須改動。為了認識到這個問題的重要性，出現了軟件體系結構的概念。軟件體系結構包括系統分解、全局控制流、錯誤處理策略和子系統間的通信協議。本節(jié)介紹一些典型的不同的體系結構，并簡要介紹不同軟件體系結構的設計思路。具有代表性的軟件體系結構包括倉庫體系結構、MVC體系結構、客戶/服務器體系結構、B/S結構、對等體系結構和管道過濾器結構等。下一頁返回6.2軟件體系架構隨著系統復雜度的增加，系統分解的說明就變得6.2軟件體系架構6.2.1倉庫體系結構(RepositoryArchitecture)在倉庫體系結構(如圖6-1所示)中，子系統通過一個稱為中心倉庫的單一數據結構訪問并修改數據。子系統相對獨立而且只通過中心數據結構相互作用?；蛘咄ㄟ^中心倉庫(例如數據中的觸發(fā)器調用外設)或者通過子系統(例如，通過倉庫的鎖來實現控制流的獨立和同步)來命令控制流。每個子系統只依賴于倉庫中心數據結構。而倉庫并不清楚其他子系統。對于像工資系統、學籍管理系統和銀行系統這樣的數據庫管理系統來說，倉庫體系結構是比較典型的。以數據為中心易于處理子系統間的并發(fā)和完整性問題。倉庫子系上一頁下一頁返回6.2軟件體系架構6.2.1倉庫體系結構(Repositor6.2軟件體系架構

統可以實現全局控制流。用戶可以調用其中的每個界面，倉庫體系結構也適用于處理任務不斷改變的復雜的應用系統。但是倉庫子系統的主要缺點是子系統與倉庫之間耦合度很高，對倉庫數據結構的修改必然會影響到子系統。6.6.2模型／視圖／控制器體系結構（ModelViewControl--MVCArchitecture）在模型／視圖／控制器(MVC)體系結構(見圖6-2)中，子系統分為三種不同的類型：模型子系統負責維護系統的數據結構和數據信息；視圖子系統負責把系統數據信息顯示給用上一頁下一頁返回6.2軟件體系架構 統可以實現全局控制流。用戶可以調用其中的6.2軟件體系架構

戶；控制器子系統負責管理與用戶交互的順序。模型子系統發(fā)展成完全不依賴于任何視圖或控制器子系統。它們狀態(tài)的變化通過訂閱／通知(subscription／notification)協議傳輸給視圖子系統。MVC體系結構是倉庫體系結構的特例，模型實現了中心數據結構，控制對象指揮著控制流。這種體系結構經常用于WEB服務器系統設計?？刂破魇占瘉碜杂脩舻妮斎氩l(fā)消息給模型。模型保持中心數據結構。視圖顯示模型，每當模型發(fā)生變化時得到通知(通過簽署／通知協議)。MVC體系結構將交互式應用程序分為三個區(qū)域：輸入、處理和輸出。模型組件封裝了內核數據和功能。模型獨立于特定輸出表示法或輸入方式。上一頁下一頁返回6.2軟件體系架構 戶；控制器子系統負責管理與用戶交互的順序6.2軟件體系架構視圖組件子系統向用戶顯示信息。視圖從模型獲得數據?？赡苡心Ｐ偷亩鄠€視圖。每個視圖都有一個相關的控制器組件?？刂破鹘邮茌斎?，通常作為將鼠標移動、鼠標按鈕的活動或鍵盤輸入編碼的事件。事件被翻譯成模型或視圖的服務器請求。用戶僅僅通過控制器與系統交互。模型與視圖和控制器組件的分離將允許同一個模型的多個視圖。如果用戶通過一個視圖的控制器改變了模型，所有依賴于該數據的其他視圖應該反映出這種變化。因此一旦模型的數據發(fā)生了變化，模型要通報所有視圖。視圖反過來從模型恢復新數據并更新所顯示的信息。這種變更-傳播機制相當于訂閱—發(fā)行。上一頁下一頁返回6.2軟件體系架構視圖組件子系統向用戶顯示信息。視圖從模型獲6.2軟件體系架構模型、視圖和控制器之間分離的基本原理在于用戶接口(如視圖和控制器)要比數據處理(如模型)更加易于變化。因此人機交互從核心功能中分離出來。在分析應用程序結構時，將核心功能從設想的輸入和輸出行為中分離出來。設計你的應用程序的模型組件來封裝內核所需的數據和功能。提供訪問中需要顯示數據的功能。確定模型功能的哪一部分應該通過控制器向用戶展示，并給模型添加相應的接口，這將更便于子系統設計和軟件開發(fā)分工。MVC技術也適用于交互式系統，尤其是需要同一個模型的多個視圖時。MVC可以用來保持分布式數據的一致性；然而，與其他倉庫體系結構類似，它也帶來了同樣的性能瓶頸問題。上一頁下一頁返回6.2軟件體系架構模型、視圖和控制器之間分離的基本原理在于用6.2軟件體系架構6.2.3客戶/服務器體系結構（Client/ServerArchitecture）在客戶／服務器體系結構(見圖6-3)中，一個子系統即服務器，為其他稱為客戶的子系統的實例提供服務，客戶端系統負責與用戶的交互。通常由某個遠程程序調用機制或公共對象代理(例如CORBA或JavaRMI)完成請求的服務。除了同步管理請求或者接收結果的時候，客戶和服務器中的控制流都是相互獨立的。上一頁下一頁返回6.2軟件體系架構6.2.3客戶/服務器體系結構（Clien6.2軟件體系架構客戶向一個或多個服務器請求獲得服務。服務器不知道客戶?？蛻簦掌骷夹g是倉庫體系結構的一般化，帶有中心數據庫的信息系統是客戶／服務器體系結構的例子?？蛻糌撠熃邮諄碜杂脩舻妮斎?、檢查范圍，一旦所有必需的數據齊全，便初始化數據庫事務。服務器負責執(zhí)行事務，保證數據的完整性。在這種情況下，客戶／服務器體系結構是倉庫體系結構的特例，它由程管理中心數據結構。但是，客戶／服務器系統并不限于單個服務器。在Internet網中，單個客戶可以訪問數千個不同服務器的數據?？蛻簦掌黧w系結構非常適用于需要管理大量數據的分布式系統。上一頁下一頁返回6.2軟件體系架構客戶向一個或多個服務器請求獲得服務。服務器6.2軟件體系架構優(yōu)點：1．結構簡單，系統中不同類型的任務分別由客戶和服務器承擔，有利于發(fā)揮不同機器平臺的優(yōu)勢；2．支持分布式、并發(fā)環(huán)境，特別是當客戶和服務器之間的關系是多對多時，可以有效地提高資源的利用率和共享程度；3．服務器集中管理資源，有利于權限控制和系統安全。缺點：在大多數client/server風格的系統中，構件之間的連接通過（遠程）過程調用，接近于代碼一級，表達能力較弱。三層客戶／服務器軟件體系結構客戶／服務器軟件體系結構，是基于資源不對等，且為實現共享而提出來的，是20世紀90年代成熟起來的技術，客戶上一頁下一頁返回6.2軟件體系架構優(yōu)點：1．結構簡單，系統中不同類型的任務分6.2軟件體系架構

／服務器結構將應用一分為二，服務器（后臺）負責數據管理，客戶機（前臺）完成與用戶的交互任務?？蛻簦掌黧w系結構具有強大的數據操作和事務處理能力，模型思想簡單，易于人們理解和接受。但隨著企業(yè)規(guī)模的日益擴大，軟件的復雜程度不斷提高，傳統的二層客戶／服務器結構存在以下幾個局限：1．二層客戶／服務器結構是單一服務器且以局域網為中心的，所以難以擴展至大型企業(yè)廣域網或Internet；2．軟、硬件的組合及集成能力有限；3．客戶機的負荷太重，難以管理大量的客戶機，系統的性能容易變壞；上一頁下一頁返回6.2軟件體系架構 ／服務器結構將應用一分為二，服務器（后臺6.2軟件體系架構4．數據安全性不好。因為客戶端程序可以直接訪問數據庫服務器，那么，在客戶端計算機上的其他程序也可想辦法訪問數據庫服務器，從而使數據庫的安全性受到威脅。正是因為二層客戶／服務器有這么多缺點，所以三層客戶／服務器結構應運而生。三層客戶／服務器結構是將整個系統的應用功能分成表示層、功能層和數據層三個層次結構，如下圖6-4所示。表示層是應用的用戶接口部分，它擔負著用戶與應用間的對話功能。它用于檢查用戶從鍵盤等輸入的數據，顯示應用輸出的數據。為使用戶能直觀地進行操作，一般要使用圖形用戶接口，操作簡單、易學易用。在變更用戶接口時，只需上一頁下一頁返回6.2軟件體系架構4．數據安全性不好。因為客戶端程序可以直接6.2軟件體系架構

改寫顯示控制和數據檢查程序，而不影響其他兩層。檢查的內容也只限于數據的形式和取值的范圍，不包括有關業(yè)務本身的處理邏輯。功能層相當于應用的本體，它是將具體的業(yè)務處理邏輯編入程序中。例如，在制作訂購合同時要計算合同金額，按照定好的格式配置數據、打印訂購合同，而處理所需的數據則要從表示層或數據層取得。表示層和功能層之間的數據交往要盡可能簡潔。例如，用戶檢索數據時，要設法將有關檢索要求的信息一次性地傳送給功能層，而由功能層處理過的檢索結果數據也一次性地傳送給表示層。數據層就是數據庫管理系統，負責管理對數據庫數據的讀寫。數據庫管理系統必須能迅速執(zhí)行大量數據的更新和檢索。上一頁下一頁返回6.2軟件體系架構 改寫顯示控制和數據檢查程序，而不影響其他6.2軟件體系架構

因此，一般從功能層傳送到數據層的要求大都使用SQL語言。三層客戶／服務器的解決方案是：對這三層進行明確分割，并在邏輯上使其獨立。原來的數據層作為數據庫管理系統已經獨立出來，所以，關鍵是要將表示層和功能層分離成各自獨立的程序，并且還要使這兩層間的接口簡潔明了。一般情況是只將表示層配置在客戶機中，如果連功能層也放在客戶機中，與二層客戶／服務器結構相比，其程序的可維護性要好得多，但是其他問題并未得到解決?？蛻魴C的負荷太重，其業(yè)務處理所需的數據要從服務器傳給客戶機，所以系統的性能容易變壞。上一頁下一頁返回6.2軟件體系架構 因此，一般從功能層傳送到數據層的要求大都6.2軟件體系架構如果將功能層和數據層分別放在不同的服務器中，則服務器和服務器之間也要進行數據傳送。但是，由于在這種形態(tài)中三層是分別放在各自不同的硬件系統上的，所以靈活性很高，能夠適應客戶機數目的增加和處理負荷的變動。例如，在追加新業(yè)務處理時，可以相應增加裝載功能層的服務器。因此，系統規(guī)模越大這種形態(tài)的優(yōu)點就越顯著。與傳統的二層結構相比，三層客戶／服務器結構具有以下優(yōu)點：1．允許合理地劃分三層結構的功能，使之在邏輯上保持相對獨立性，從而使整個系統的邏輯結構更為清晰，能提高系統和軟件的可維護性和可擴展性。2．允許更靈活有效地選用相應的平臺和硬件系統，使之在上一頁下一頁返回6.2軟件體系架構如果將功能層和數據層分別放在不同的服務器中6.2軟件體系架構邏輯上保持相對獨立性，從而使整個系統的邏輯結構更為清晰，能提高系統和軟件的可維護性和可擴展性。2．允許更靈活有效地選用相應的平臺和硬件系統，使之在處理負荷能力上與處理特性上分別適應于結構清晰的三層；并且這些平臺和各個組成部分可以具有良好的可升級性和開放性。例如，最初用一臺Unix工作站作為服務器，將數據層和功能層都配置在這臺服務器上。隨著業(yè)務的發(fā)展，用戶數和數據量逐漸增加，這時，就可以將Unix工作站作為功能層的專用服務器，另外追加一臺專用于數據層的服務器。若業(yè)務進一步擴大，用戶數進一步增加，則可以繼續(xù)增加功能層的服務器數目，用以分割數據庫。清晰、合理地分割三層上一頁下一頁返回6.2軟件體系架構邏輯上保持相對獨立性，從而使整個系統的邏輯6.2軟件體系架構

結構并使其獨立，可以使系統構成的變更非常簡單。因此，被分成三層的應用基本上不需要修正。3．三層客戶／服務器結構中，應用的各層可以并行開發(fā)，各層也可以選擇各自最適合的開發(fā)語言。使之能并行地而且是高效地進行開發(fā)，達到較高的性能價格比；對每一層的處理邏輯的開發(fā)和維護也會更容易些。4．允許充分利用功能層有效地隔離開表示層與數據層，未授權的用戶難以繞過功能層而利用數據庫工具或黑客手段去非法地訪問數據層，這就為嚴格的安全管理奠定了堅實的基礎；整個系統的管理層次也更加合理和可控制。上一頁下一頁返回6.2軟件體系架構 結構并使其獨立，可以使系統構成的變更非常6.2軟件體系架構6.2.4B/S結構，即瀏覽器/服務器(Browser/Server)結構B/S結構，即Browser/Server(瀏覽器/服務器)結構，是隨著Internet技術的興起，對C/S結構的一種變化或者改進的結構（如圖6-5所示）。在這種結構下，用戶界面完全通過WWW瀏覽器實現，一部分事務邏輯在前端實現，但是主要事務邏輯在服務器端實現。B/S結構，主要是利用了不斷成熟的WWW瀏覽器技術，結合瀏覽器的多種Script語言(VBScript、JavaScript…)和ActiveX技術，用通用瀏覽器就實現了原來需要復雜專用軟件才能實現的強大功能，并節(jié)約了開發(fā)成本，是一種全新的軟件系統構造技術，這種結構更成為當今應用軟件的首選體系結構。顯然B/S結構應用程序相對于傳統的C/S結構應用程序將是巨大的進步。上一頁下一頁返回6.2軟件體系架構6.2.4B/S結構，即瀏覽器/服務器6.2軟件體系架構B/S結構采用星形拓撲結構建立企業(yè)內部通信網絡或利用Internet虛擬專網（VPN）。前者的特點是安全、快捷、準確。后者則具有節(jié)省投資、跨地域廣的優(yōu)點。須視企業(yè)規(guī)模和地理分布確定。企業(yè)內部通過防火墻接入Internet，整個網絡采用TCP/IP協議。B/S結構開發(fā)工作主要是針對于服務器的，并且軟件主要的組成全都布署在服務器一方，客戶通過瀏覽訪問服務器，并下載或利用一些組件實現客戶端的交互訪問功能。當前基于Java技術的J2EE和基于DCOM的.NET是開發(fā)B/S結構的主流。C/S與B/S區(qū)別：上一頁下一頁返回6.2軟件體系架構B/S結構采用星形拓撲結構建立企業(yè)內部通信6.2軟件體系架構Client/Server是建立在局域網的基礎上的，Browser/Server是建立在廣域網的基礎上的。１．硬件環(huán)境不同：C/S一般建立在專用的網絡上，小范圍里的網絡環(huán)境，局域網之間再通過專門服務器提供連接和數據交換服務.B/S建立在廣域網之上的，不必是專門的網絡硬件環(huán)境，例與電話上網，租用設備.信息自己管理.有比C/S更強的適應范圍，一般只要有操作系統和瀏覽器就行２．對安全要求不同：C/S一般面向相對固定的用戶群，對信息安全的控制能力很強.一般高度機密的信息系統采用C/S結構適宜.可以通過B/S發(fā)布部分可公開信息.B/S建立在廣域網之上，對安全的控制能力相對弱，面向是不可知的用戶群.上一頁下一頁返回6.2軟件體系架構Client/Server是建立在局域網的6.2軟件體系架構３．對程序架構不同：C/S程序可以更加注重流程，可以對權限多層次校驗，對系統運行速度可以較少考慮.B/S對安全以及訪問速度的多重的考慮，建立在需要更加優(yōu)化的基礎之上.比C/S有更高的要求B/S結構的程序架構是發(fā)展的趨勢，從MS的.Net系列的BizTalk2000Exchange2000等，全面支持網絡的構件搭建的系統.SUN和IBM推的JavaBean構件技術等，使B/S更加成熟.４．軟件重用不同：C/S程序可以不可避免的整體性考慮，構件的重用性不如在B/S要求下的構件的重用性好.B/S對的多重結構，要求構件相對獨立的功能.能夠相對較好的重用.就入買來的餐桌可以再利用，而不是做在墻上的石頭桌子上一頁下一頁返回6.2軟件體系架構３．對程序架構不同：C/S程序可以更加注重6.2軟件體系架構５．系統維護不同：系統維護是軟件生存周期中，開銷最大，也是極為重要的。C/S程序由于具有整體性，必須整體考察，處理出現的問題以及系統升級應當謹慎，有時系統升級相當于是再做一個全新的系統。B/S構件組成，方面構件個別的更換，實現系統的無縫升級，系統維護開銷減到最小，用戶從網上自己下載安裝就可以實現升級。6.2.5對等體系結構（Peer-to-PeerArchitecture）對等體系結構是客戶／服務器體系結構的一般化，其中子系統既可以作為客戶也可以作為服務器，即每個子系統既可以請求服務也可以提供服務(如圖6-6所示)。每個子系統中的控制流除了在同步請求的時候，都是獨立于其他子系統的。上一頁下一頁返回6.2軟件體系架構５．系統維護不同：系統維護是軟件生存周期中6.2軟件體系架構圖6-6是對等體系結構(UML類圖)。對等體可以向其他對等體請求服務也可以向它們提供服務。對等體系結構的一個例子是雙向通信軟件，各系統之間的連接基于對等結構，它一方面接收來自一個系統的請求，另一方面，自己也可以向其他系統要求連通。另一個例子就基于P2P(點對點協議)的應用軟件如網絡音樂點播軟件。對等系統比客戶／服務器系統要難設計，它們有可能發(fā)生死鎖，并且使控制流更復雜了。6.2.6管道過濾器結構（PipeandFilterArchitecture）在管道和過濾器體系結構中，子系統處理輸入的一組數據，上一頁下一頁返回6.2軟件體系架構圖6-6是對等體系結構(UML類圖)。對等6.2軟件體系架構

并通過一組輸出將結果發(fā)送給其他子系統(如圖6-7所示)。子系統稱為過濾器，子系統之間的聯系稱為管道。每個過濾器只知道來自輸入管道的數據的內容和格式，并不知道生成這些數據的過濾器。每個過濾器并發(fā)執(zhí)行并且通過管道進行同步。管道和過濾器技術是可改動的：一個過濾器可以由其他過濾器替代，或者重新配置以達到不同的目的。一個過濾器可以有多個輸入和輸出。一個管道將某個過濾器的輸出和另外一個過濾器的輸入連接起來管道和過濾器體系結構最有名的例子是UNLX的shell。大多數過濾器寫成可以通過標準管道進行輸入輸出的讀寫。這就允許UNIX用戶以許多不同的方式連接過濾器。上一頁下一頁返回6.2軟件體系架構 并通過一組輸出將結果發(fā)送給其他子系統(如6.2軟件體系架構管道和過濾器體系結構適用于實現數據流的變換而不需要用戶干涉的系統。不適合組件間的交互作用比較復雜的系統，比如信息管理系統或者交互式系統。管道/過濾器體系結構具有許多很好的特點：1．使得軟構件具有良好的隱蔽性和高內聚、低耦合的特點；2．允許設計者將整個系統的輸入/輸出行為看成是多個過濾器的行為的簡單合成；3．支持軟件重用。重要提供適合在兩個過濾器之間傳送的數據，任何兩個過濾器都可被連接起來；上一頁下一頁返回6.2軟件體系架構管道和過濾器體系結構適用于實現數據流的變換6.2軟件體系架構4．系統維護和增強系統性能簡單。新的過濾器可以添加到現有系統中來；舊的可以被改進的過濾器替換掉；5．允許對一些如吞吐量、死鎖等屬性的分析；6．支持并行執(zhí)行。每個過濾器是作為一個單獨的任務完成，因此可與其它任務并行執(zhí)行。但是，這樣的系統也存在著不足方面：1．通常導致進程成為批處理的結構。這是因為雖然過濾器可增量式地處理數據，但它們是獨立的，所以設計者必須將每個過濾器看成一個完整的從輸入到輸出的轉換。2．不適合處理交互的應用。當需要增量地顯示改變時，這個問題尤為嚴重。上一頁下一頁返回6.2軟件體系架構4．系統維護和增強系統性能簡單。新的過濾器6.2軟件體系架構3．因為在數據傳輸上沒有通用的標準，每個過濾器都增加了解析和合成數據的工作，這樣就導致了系統性能下降，并增加了編寫過濾器的復雜性。以上介紹6個的常見軟件體系結構，它們各有不同的特點。在一個復雜的系統開發(fā)中，可以借鑒各種多種軟件體系結構，如B/S結構也可以結合C/S結構來構建軟件系統，靈活運用好體系結構，從而使用軟件開發(fā)過程更加快捷和高效上一頁返回6.2軟件體系架構3．因為在數據傳輸上沒有通用的標準，每個過6.3子系統設計和訪問控制設計系統設計是把分析模型轉變成系統設計模型。在系統設計的過程中，系統設計人員定義項目的設計目標，并且將系統分解成能由單個團隊實現的較小的子系統。系統設計人員也要選擇構造系統的策略，比如系統運行的硬件／軟件平臺、持續(xù)數據管理策略、全局控制流、訪問控制方法以及邊界條件的處理。系統設計的結果是得到一個模型，包括上述各個策略的清晰描述、子系統的分解以及表示系統硬件／軟件映射的UML配置圖。系統設計不是設計算法，然而研究人員已經開發(fā)出了一些固定的模式或方案來解決常見的問題，而且定義了符號來表達軟件結構，UML就是目前最流行的設計語言之一。在本節(jié)下一頁返回6.3子系統設計和訪問控制設計系統設計是把分析模型轉變成系統6.3子系統設計和訪問控制設計

中，我們首先提出這些構造模塊，然后討論對這些模塊產生影響的設計活動。具體地說，系統設計包括：1．定義設計目標；2．分解系統為子系統或功能模塊；3．分析或選擇已開發(fā)組件和標準組件4．子系統映射到軟/硬件平臺；5．數據庫設計；6．定義訪問策略；7．設計系統流程。上一頁下一頁返回6.3子系統設計和訪問控制設計 中，我們首先提出這些構造模塊6.3子系統設計和訪問控制設計分析模型從執(zhí)行者的角度完整地描述了系統，并且充當用戶和系統分析設計人員之間的交流基礎，其分析過程如圖6-8所示。但是，分析模型不包括系統的內部結構信息，或者更一般地說，它的硬件配置不包括系統是如何實現的。系統設計是從內部架構整個系統的第一步。6.3.1定義系統設計目標系統設計應該得到如下結果：構建整個軟件系統的體系結構，建立一系列反映系統設計人員實現整個系統的設計目標。根據子系統的任務、子系統間相關性、子系統與軟/硬件平臺的映射和主要策略決定(如控制流、訪問控制和數據存儲)來描述子系統的分解，這也就是系統設計目標。上一頁下一頁返回6.3子系統設計和訪問控制設計分析模型從執(zhí)行者的角度完整地描6.3子系統設計和訪問控制設計系統設計目標還包括非功能性需求，尤其是需要權衡非功能性需求和系統功能需求的時候，設計目標可以幫助系統設計人員作出決定和取舍。系統設計的大部分內容是子系統分解，即搭建整個系統的框架。為了處理復雜性，系統設計人員把系統分解成易于管理的任務段，把每個子系統分配給一個小組來獨立實現。但是為了使這些成為可能，系統設計人員在分解系統時需要面對整個系統范圍的問題。設計人員在系統設計中應特別注意解決以下問題：1．應用系統開發(fā)的軟／硬件平臺環(huán)境。2．數據庫設計3．定義訪問策略4．設計系統流程上一頁下一頁返回6.3子系統設計和訪問控制設計系統設計目標還包括非功能性需求6.3子系統設計和訪問控制設計圖6-8描述了系統設計活動。每個活動解決上面描述過的一個問題。解決任何一個上述問題都會引起子系統分解中的變化并產生新的問題。系統設計是多次反復的活動，常會導致新的子系統的定義、已有子系統的改變以及影響所有子系統系統范圍的修改。6.3.2定義子系統和功能模塊為了減少應用系統的復雜性，我們把更小的部分定義為類并且把它們封裝成包。類似地，為了減少求解域的復雜性，我們將系統分解成為子系統，形成多個較小的組成部分，子系統就是由許多求解域的類組成的。對于復雜的子系統，我們不斷地使用這個原理，將子系統分解成更為簡單的子系統。上一頁下一頁返回6.3子系統設計和訪問控制設計圖6-8描述了系統設計活動。每6.3子系統設計和訪問控制設計在RationalRose中子系統要以用包或類來表示。學籍管理系統從需求分析可知整個應用系統分為六個子系統。其中交費管理子系統（如圖6-9所示)又可以繼續(xù)進行細分，因為交費管理主要是用來管理學費的交納情況，學費可以根據年級、年制、專業(yè)、學期不同來設置收費類型和收費標準，所以在收費之前應先設置收費類型和收費標準，在VB中設置收費類型和收費標準可以做為一個單獨窗體類來設計，因此可命名為frmTuitionSet，同樣收取學費，學費類型明細及查詢，學生收費明細，學生個人收費情況，學生收費查詢分別設計為frmTuitionCollect、frmTuitionSetBrow、frmTuitionSetQry、frmTuitionDetail、上一頁下一頁返回6.3子系統設計和訪問控制設計在RationalRose中6.3子系統設計和訪問控制設計 frmTuitionStu等，由于系統需求中涉及收費打印，因此還要增加學生收費類型設置、學生收費明細報表來滿足收費打印的需要。圖6-9學籍管理交費子系統(UML類圖)的子系統分解包括包的組成和與主界面的構成關系。子系統表示為UML包，虛線箭頭說明子系統與其他子系統或類之間的依賴關系。同時為了提高查詢效率，快速存取收費信息，也應對收費信息實體類進行設計劃分為收費類型和收費明細兩部分，相當于數據庫中的兩個表。如圖6-10所示,示學費實體類可以繼續(xù)分解為數據表，即學費類型表示某年制某專業(yè)某年級某學期的收費標準，交費信息表示某學生某學期的交費額和欠費客，以及交費日期和收費人。上一頁下一頁返回6.3子系統設計和訪問控制設計 frmTuitionStu等6.3子系統設計和訪問控制設計許多編程語言(比如Java和Modula-2)為子系統的建模(Java中的包，Modula-2中的模塊)提供了構造方法。在其他語言中，比如C或者C++，沒有明確的建模子系統，在這種情況下，系統設計人員按照習慣，對類進行分組(比如，一個子系統可以表示成包含實現子系統的所有文件的目錄)。由于子系統通常是由不同的開發(fā)小組實現的，所以不管編程語言中是否明確表示了子系統，系統設計人員都需要仔細地記錄子系統分解的文檔。1．服務和子系統接口根據一個子系統是通過為其他子系統提供的服務來確定其特點的。一個服務是一組有著共同目標的相關操作。比如，某子系統提供數據訪問服務，它可以定義訪問數據連接、直接上一頁下一頁返回6.3子系統設計和訪問控制設計許多編程語言(比如Java和M6.3子系統設計和訪問控制設計

訪問數據表服務，檢查用戶權限等。學籍管理系統的公用模塊就是一個登錄管理子系統的一個類似的模塊，它為所有的子系統服務的一個子系統，它主要是提供一個訪問數據層的接口，定義公用訪問數據庫的連接，定義全局性的變量和方法供各子系統使用（如圖6-11所示）。某子系統提供給其他子系統用的一組操作形成子系統接口。子系統接口也稱為應用程序接口(API，ApplicationProgrammingInterface)，包括操作的名稱、參數、類型和返回值。系統設計集中定義每個子系統提供的服務，即列舉操作、參數和它們的高層行為。對象設計集中定義子系統的接口，即參數的類型和每個操作的返回值。這里也包括應用軟件調用操作系統的函數接口。上一頁下一頁返回6.3子系統設計和訪問控制設計 訪問數據表服務，檢查用戶權限6.3子系統設計和訪問控制設計以調用Windows系統API的SetWindowPos為例，函數功能：該函數改變一個子窗口，彈出式窗口式頂層窗口的尺寸，位置和Z序。子窗口，彈出式窗口，及頂層窗口根據它們在屏幕上出現的順序排序、頂層窗口設置的級別最高，并且被設置為Z序的第一個窗口。函數原型：PrivateDeclareFunctionSetWindowPosLib"user32"(ByValhwndAsLong，ByValhWndInsertAfterAsLong，ByValXAsLong，ByValYAsLong，ByValcxAsLong，ByValcyAsLong，ByValwFlagsAsLong)AsLong--上一頁下一頁返回6.3子系統設計和訪問控制設計以調用Windows系統API6.3子系統設計和訪問控制設計這樣我們就可以方便的實現一個簡單的系統功能，因此根據子系統提供的服務來對它進行定義，有助于我們把注意力集中在接口上而不是實現上。一個好的子系統接口應提供盡可能少的實現信息，這就使得修改子系統的實現時產生的影響最小。更一般地來說，我們希望通過減少子系統之間的依賴性來降低變化時的影響。2．子系統耦合度與相關性耦合度是兩個子系統之間依賴關系的強度。如果兩個子系統是松散耦合的，它們相互獨立，那么當其中一個發(fā)生變化的時候對另外一個產生的影響就很小。如果兩個子系統是緊密耦合的，其中一個發(fā)生的變化就可能對另外一個產生較大影響。子系統分解想要達到的一個目標就是子系統間要盡可能地松散耦合，這就使得錯誤或潛在變化對系統的正確操作產生的影響達到最小。上一頁下一頁返回6.3子系統設計和訪問控制設計這樣我們就可以方便的實現一個簡6.3子系統設計和訪問控制設計例如交費管理子系統和學生檔案管理子系統，如果學生入學時既錄入學生信息又收取學費則兩個子系統的耦合性將增加（如圖6-12所示）。相關性是子系統內部的依賴程序。如果某個子系統含有多個彼此相關的對象，并且它們執(zhí)行類似的任務，它的相關性就比較高。整個系統被化分為更小的系統如學籍管理系統，劃分六個子系統為學生檔案管理，成績管理、學費管理、課程管理、班級管理和用戶管理等子系統，同時根據系統需求，我們還可以將數據管理抽象到兩個子系統中即系統實體子系統和，這樣得到的子系統要比原有子系統?。航档土藦碗s度。子系統之間的耦合度相對較低，因為兩個子系統之間上一頁下一頁返回6.3子系統設計和訪問控制設計例如交費管理子系統和學生檔案管6.3子系統設計和訪問控制設計

只有一個關系。共享大量數據的一種有效的方法就是允許兩個子系統通過屬性來互相訪問。通常在相關性和耦合度之間存在一個平衡。我們可以通過將系統不斷分解成子系統來增加系統的相關性。但是，隨著接口數量的增加，也會提高耦合度。一般情況下系統設計人員可以處理72個概念。如果給定任一抽象層具有超過9個概念或者有一個子系統提供超過9種服務，則你應該考慮改動子系統的分解。出于同樣的原因，層次的數量也不能超出72。事實上，許多好的系統設計只用三層就完成了。3．分層和分區(qū)上一頁下一頁返回6.3子系統設計和訪問控制設計 只有一個關系。共享大量數據的6.3子系統設計和訪問控制設計系統設計的目標是通過將系統分解成可管理的較小的部分來處理復雜度。這可以通過分而治之的方法解決，即我們循環(huán)地將各部分分解得非常簡單，直到能讓一個人或者一個小組處理為止。系統地使用這個方法就可以得到結構化的分解，其中每個子系統或者每一層根據低層子系統提供的服務為高層服務，每一層還可以向下一層訪問。學籍管理系統可以分別為三個層次（如圖6-13所示）：（1）．上層的登錄管理和主控界面。（2）．中間層為各業(yè)務處理子系統。（3）．底層為實體類層和報表層。上一頁下一頁返回6.3子系統設計和訪問控制設計系統設計的目標是通過將系統分解6.3子系統設計和訪問控制設計

系統設計是把分析模型轉變成設計模型，該模型考慮在問題描述和需求分析文檔中描述的非功能性需求和約束。前面主要考慮了子系統的分解和它們的屬性。本節(jié)描述子系統分解時必要的活動，以確保子系統分解能針對所有的非功能性需求并著手考慮實現階段的所有限制條件。6.3.3確定系統設計目標前面講了許多關于系統設計的概念和一般方法，而定義設計目標是系統設計的第一步，那些概念和方法都是為定義設計目標服務。設計目標給出了系統應該重點考慮的質量要求。許多設計目標可以從非功能性需求或者應用域推斷出來，上一頁下一頁返回6.3子系統設計和訪問控制設計 系統設計是把分析模型轉變成設6.3子系統設計和訪問控制設計

其他的設計目標必須從用戶那里得到。然而，必須明確說明設計目標，根據同一套標準使作出的每個重要的設計決定，并保持一致性。比如，根據需求描述中的的非功能性需求，我們應把可靠性和連接丟失，容錯能力也作為設計目標。然后再將安全性標識為設計目標，因為有很多操作人員利用軟件系統讀取和存儲學生的有關信息。一般而言，我們可以從一系列非常想要達到的質量要求中選擇設計目標。通常把系統設計目標分為五類：功能、性能、可靠性、費用和維護目標。一般從需求中推斷出系統的功能、性能、可靠性。費用和維護目標則由最終用戶（軟件系統購買者）和軟件供應商（擬采購組件或軟件平臺供應者）指定。上一頁下一頁返回6.3子系統設計和訪問控制設計 其他的設計目標必須從用戶那里6.3子系統設計和訪問控制設計性能標準包括對系統的速度和空間需求。系統應該是快速響應的還是實現最多數量的任務？存儲器空間是用于速度優(yōu)化還是應該節(jié)約使用？管理目標可以用技術目標平衡(比如，交付時間與功能性的平衡)。一旦我們對設計目標有了清晰的認識，就可以著手設計初始子系統的分解。下表（表6-1）就是針對學籍管理系統的設計目標的一個定義。6.3.4確定子系統在系統設計的時候得到子系統與在分析的時候得到對象有很多相似之處：它是一項不斷摸索變化的活動。需求分析上的用例和角色識別技術適用于確定子系統。而且，無論什么時候提出了新的問題，都會導致子系統分解的修改；若干簡單上一頁下一頁返回6.3子系統設計和訪問控制設計性能標準包括對系統的速度和空間6.3子系統設計和訪問控制設計

的子系統合并到一個子系統中，復雜的子系統分解成多個部分，或為了實現新的功能而增加了子系統。確定子系統的分解要避免引起急劇的變化，并在設計之初就解決好這些問題。最初的子系統分解應該來自功能性需求。比如，在學籍管理系統中，我們定義了學生檔案管理、學生成績管理、收費管理等子系統都是來自需求分析的用例即功能性需求。另外確定子系統的方法就是將功能相關的對象放在一起，作為獨立的功能或共享的模塊，被多個子系統所共享。再有就是把復雜的子系統分解為較為簡單的子系統。確定子系統的方法可歸納為以下幾個方面將一個用例中確定的對象，分配到同一個子系統中。上一頁下一頁返回6.3子系統設計和訪問控制設計 的子系統合并到一個子系統中，6.3子系統設計和訪問控制設計為兩個以上子系統傳遞數據或提供服務的對象，要創(chuàng)建一個專用的子系統。將子系統與子系統之間的關聯關系降到最小。同一個子系統內的所有對象必須功能相關，業(yè)務處理配合緊密。6.3.5數據管理設計系統數據管理也是一個復雜的任務，數據管理設計就要處理系統中連續(xù)的，需要保存的各種數據。比如，某個作者使用字處理軟件將他的工作存入某個文件，以供重新打開文件使用。類似地，與學生相關的信息，他們的姓名、年齡、學費繳納情況、入學時間和在學期間課程成績等都存放在數據庫上一頁下一頁返回6.3子系統設計和訪問控制設計為兩個以上子系統傳遞數據或提供6.3子系統設計和訪問控制設計

管理系統中。這就允許所有使用學生信息數據的程序可以一致地運行。而且，將數據存儲在數據庫中能讓系統在大量數據集合(比如幾千個學生的記錄)中執(zhí)行比較復雜的查詢。當前的數據存儲管理方式可以分為三種類型：1．普通文件2．關系型數據庫3．面向對象數據庫數據存放的地點以及如何存放會對系統的分解產生影響。比如在有些情況下，學籍管理系統中的某個子系統專門用來建立數據庫連接和訪問數據。特定的數據庫管理系統的選擇也蘊含了總的控制策略和并發(fā)管理。以學籍管理系統為例，實體類的存儲采用關系型數據庫如下圖6-14所示上一頁下一頁返回6.3子系統設計和訪問控制設計 管理系統中。這就允許所有使用6.3子系統設計和訪問控制設計6.3.6定義訪問控制在多用戶系統中，不同的操作者需要訪問不同的功能和數據。比如，每個操作者只能訪問他創(chuàng)建的數據，但是系統管理員可以沒有限制地訪問系統數據和其他用戶的數據。分析時，通過將不同的用例與不同的操作者相聯系來為這些區(qū)別建模。在系統設計時，通過檢查對象模型，定義操作者共享哪些對象以及定義操作者如何控制訪問來為訪問建模。根據系統的安全性需求，還可以定義系統如何鑒別操作者(比如操作人員怎樣向系統證明他是誰)及如何為系統中選定的數據加密。比如在學籍管理系統中采用按用戶名和密碼驗證方式登錄軟件系統，軟件系統根據用戶的已分配權限，控制其可以使用的上一頁下一頁返回6.3子系統設計和訪問控制設計6.3.6定義訪問控制上一頁下6.3子系統設計和訪問控制設計

功能和操作，用戶對系統的功能使用有著各種類型的權限劃分，既形成了不同的角色如表6-2所示，系統管理員是整個系統中管理權限最全的角色，它可以使用系統提供的各種功能。而一般人員只能實現對系統中查詢功能的使用。6.3.7設計全局控制流控制流是系統中操作和系統行為的先后次序。在面向對象的系統中，活動的先后次序包括決定執(zhí)行哪些操作，以及按怎樣的次序執(zhí)行。這些決定基于由操作者或者隨著按時間順序所產生的外部事件?？刂屏魇且粋€設計問題，在分析過程中，控制流程還不是主要問題，但在設計時應考慮整個系統的控制流程。一般控制流程有三種方式包括過程驅動控制、事件驅動控制和線程實現控制。上一頁下一頁返回6.3子系統設計和訪問控制設計 功能和操作，用戶對系統的功能6.3子系統設計和訪問控制設計過程驅動的控制流程。系統設計是基于過程化語言設計的，或者系統設計是基于程序控制的，用戶沒有選擇的余地，只能按程序控制的步驟來實現各種操作。如Ms-Dos下命令行執(zhí)行模式中的應用軟件程序，再如Windows中添加/刪除硬件向導，就是采用過程驅動的方式（如圖6-15所示）。事件驅動的控制流。系統設計基于等待與執(zhí)行的輪循的方式，最常用的Microsoft公司的Word和Excel應用軟件，在實際操作中先后次序不明顯，而是由用戶事件到達次序來選擇。即用戶選擇什么操作，軟件做什么回應和處理。以學籍管理系統為例，主控制界面類設計就是典型的事件驅動控制（如圖6-16所示）。上一頁下一頁返回6.3子系統設計和訪問控制設計過程驅動的控制流程。系統設計是6.3子系統設計和訪問控制設計線程驅動的控制流。系統設計是基于并發(fā)運行機制的軟件系統，系統可以創(chuàng)建多個線程，每個線程可以處理不同的事件或共同完成一個任務，如Flashget，Netants等許多網絡下載軟件都采用線程驅動方式。過程驅動控制流方式設計速度快，實現相對簡單，測試比較容易，但對用戶來說操作不便利，開發(fā)與最終用戶相關的軟件系統應避免采用這種方式；事件驅動的控制流方式便于用戶使用，設計較復雜，但有成熟的開發(fā)工具，是當前主流的系統控制設計方式；線程實現控制流方式能更好地體現多用戶和多任務處理機制，但是在系統實現和系統測試方面則是相當復雜，同時在開發(fā)工具和硬件選用上需要仔細斟酌。上一頁下一頁返回6.3子系統設計和訪問控制設計線程驅動的控制流。系統設計是基6.3子系統設計和訪問控制設計6.3.8確定系統的功能范圍前面講述了子系統設計和對系統的分解，還需要檢查系統的系統功能范圍，也就是說，決定系統什么時候啟動、初始化和關閉，還要定義如何處理主要故障，比如由軟件錯誤或是由斷電引起的數據崩潰，因此還要增加系統管理用例，系統管理用例指定了系統在啟動和關閉階段的行為。通常的情況在分析階段不指定系統管理用例或者把它們單獨處理。一方面，許多系統管理功能可以從日常用戶需求(比如注冊和刪除用戶、管理訪問控制)中推斷出來；另一方面，許多功能是由設計決定的(比如高速緩存的大小、數據庫服務器上一頁下一頁返回6.3子系統設計和訪問控制設計6.3.8確定系統的功能范圍上6.3子系統設計和訪問控制設計

的位置、備份服務器的位置)而不是由需求決定的。如學籍管理管理中應增加重新登錄，修改密碼及用戶名密碼長度限制等系統功能。檢查系統功能范圍時，我們也應該調查一下異常情況。異常就是在系統運行過程中發(fā)生的意料外事件或錯誤。產生異常的原因是下列三種情況之一：1．用戶錯誤。用戶錯誤地或者故意地輸入超出邊界的數據。比如，如果系統不檢查錯誤的話，學生的年齡、成績等出現無法預料的錯誤。2．硬件錯誤。硬件老化并且發(fā)生故障。比如，網絡連接故障隨時可能會斷開系統兩個節(jié)點之間的聯系。硬盤崩潰可能會導致數據的永久性丟失。上一頁下一頁返回6.3子系統設計和訪問控制設計 的位置、備份服務器的位置)而6.3子系統設計和訪問控制設計3．軟件故障。如果系統或者系統的任何一個組件存在設計錯誤，則運行中都可能出錯。盡管編寫無錯誤的軟件非常困難，但是單個子系統能夠預料來自其他子系統的錯誤并加以防護。異常處理就是系統如何處置異常情況的機制。用戶發(fā)生錯誤時，系統應該向用戶顯示意義明確的錯誤信息，軟件系統可以糾正錯誤的輸入。如果是網絡連接有問題，需要保存臨時狀態(tài)以便當網絡恢復正常時，系統能夠回復到原來的狀態(tài)。因此在系統設計階段要綜合考慮這些因素如在學籍管理系統中增加系統的自動備份功能，軟件訪問數據的錯誤處理（OnErrorGotoLineMark<行號或行標簽>或OnErrorResumeNext等）機制。上一頁下一頁返回6.3子系統設計和訪問控制設計3．軟件故障。如果系統或者系統6.3子系統設計和訪問控制設計6.3.9系統配置設計與映射到軟/硬件平臺1．選擇硬件配置和平臺許多系統運行在多臺計算機上，并且組成局域網Intranet或連接互聯網Internet。使用多臺計算機提出了對連接的高性能要求，以及如何組織連接多個分散的用戶。因此，需要仔細檢查計算機子系統的位置并且認真設計支持子系統間通信的基本設施。UML配置圖中把這些計算機建模成節(jié)點。節(jié)點可以表示一個特定的實例(比如計算機A、計算機B、服務器H)，也可以表示一類計算機或設備(比如文件服務器、遠程客戶機、打印機等)。由于硬件映射活動會對系統的性能和復雜度產生巨大的影響，故我們一般在系統設計的早期進行這項活動。上一頁下一頁返回6.3子系統設計和訪問控制設計6.3.9系統配置設計與映射到6.3子系統設計和訪問控制設計選擇硬件配置還包括選擇將系統建造在怎樣的虛擬機上。虛擬機包括操作系統和所有必要的軟件組件，比如數據庫管理系統和通信包。虛擬設備的選擇縮小了系統和系統運行的硬件平臺之間的距離。組件提供的功能越多，則涉及的工作越少。但是虛擬設備的選擇要受限于項目啟動前擁有硬件的顧客。虛擬設備的選擇可能還要考慮費用：在有些情況下，很難估計構造一個組件的費用是否比購買一個組件的費用要高。在學籍管理系統中，我們從需求中推斷出必備的硬件設備（如圖6-17所示），包括教師專用計算機N臺、數據庫服務器、打印服務器及打印機等。其中學籍管理系統部署在教師專用計算機上，數據庫部署在專用的服務器上，打印服務器則不需要上一頁下一頁返回6.3子系統設計和訪問控制設計選擇硬件配置還包括選擇將系統建6.3子系統設計和訪問控制設計

設計開發(fā)專用的應用軟件，操作系統為Windows系列操作系統，其中服務器要求是WindowsNTServer4.0SP6或最近發(fā)布升級的服務器操作系統。2．將對象和子系統分配給節(jié)點一旦定義了硬件配置，選定了虛擬機，對象和子系統就被分配給節(jié)點。為了在節(jié)點間傳送數據，經常會定義新的對象和子系統。一般來說，將子系統分配給硬件節(jié)點使得我們能夠將功能和處理能力分布到最需要它們的地方。但同樣也引起了與子系統間存儲、傳送、復制和同步數據相關的問題。因此，系統設計人員也選擇適用的組件和合理的組合關系，用來開發(fā)軟件系統。上一頁下一頁返回6.3子系統設計和訪問控制設計 設計開發(fā)專用的應用軟件，操作系統的總體設計課件6.3子系統設計和訪問控制設計UML配置圖用來描述運行時組件和硬件節(jié)點間的關系。組件是為其他組件或執(zhí)行者提供服務的獨立實體。比如，學籍管理系統的組件圖根據需求分析，我們以VisualBasic為開發(fā)工具，其組件圖可設計如下（如圖6-18所示），這些為用戶提供服務的組件，組成了整個應用軟件系統。在UML配置圖中，ADO是一組獨立的數據訪問組件，是微軟公司開發(fā)可以自由進行發(fā)布的。微軟公司的ActiveXDataObjects(ADO)使您能夠編寫通過OLEDB提供者對在數據庫服務器中的數據進行訪問和操作的應用程序。其主要優(yōu)點是易于使用、高速度、低內存支出和占用磁盤空間較少。ADO支持用于建立基于客戶端/服務器和Web的應用程序的主要功能。另外ADO同時具有遠程數據服務上一頁下一頁返回6.3子系統設計和訪問控制設計UML配置圖用來描述運行時組件6.3子系統設計和訪問控制設計 (RemoteDataService–RDS)功能，通過RDS可以在一次往返過程中實現將數據從服務器移動到客戶端應用程序或Web頁、在客戶端對數據進行處理然后將更新結果返回服務器的操作，以便簡化客戶端數據的遠程操作。VB運行支持庫組件是應用程序為在安裝后能正確運行而必備的文件。VisualBasic應用程序所用的VB運行支持庫包括：Msvbvm60.dll，Stdole2.tlb，Oleaut32.dll，Olepro32.dll，Comcat.dll，Asycfilt.dll，Ctl3d32.dll。打印機驅動程序則由硬件供應廠商來提供，無需另行開發(fā)或設計，直接在軟件發(fā)布期間進行安裝調試。上一頁下一頁返回6.3子系統設計和訪問控制設計 (RemoteData6.3子系統設計和訪問控制設計圖6-19描述了教師專用機節(jié)點的組件的位置和組件間依賴關系。教師專用機節(jié)點包含了學籍管理系統中的主要組件如主程序、VB運行支持庫、ADO組件以及打印機驅動程序等。圖6-20描述數據庫服務器部署了Access數據庫文件，打印服務器部署了打印機驅動程序。硬件節(jié)點之間的關系參見圖6-17所示。隨著系統復雜度的增加和推上市場時間的縮短，開發(fā)人員非常愿意復用代碼并依靠供應商提供的組件。比如，交互式系統很少從零做起，而寧愿使用那些提供很多對話框、窗口、按鈕或其他標準接口對象的用戶接口工具包。其他項目只上一頁下一頁返回6.3子系統設計和訪問控制設計圖6-19描述了教師專用機節(jié)點6.3子系統設計和訪問控制設計側重于重做現有系統的一部分。比如團體信息系統，設計和構建的代價很高，需要升級新的用戶硬件。通常只將系統的客戶端用新技術升級而系統的后端不動，不管是處理現行組件還是處理遺留下來的代碼，開發(fā)人員都需要處理現已有的代碼，而這些代碼他們即無法修改，也無法集成進他們的系統。我們可以通過封裝現有組件(如代碼)來處理它們。這個方法的優(yōu)點將系統從封裝代碼中分離出來，以此減小現有軟件對設計的影響。當封裝代碼與新系統的代碼用同一種語言編寫時，可以用適配器模式來完成。進程間的通信協議(比如管道和套接字)常常是由操作系統提供的，因此與編程語言無關。對于使用分布式組件和進程上一頁下一頁返回6.3子系統設計和訪問控制設計側重于重做現有系統的一部分。比6.3子系統設計和訪問控制設計

通信的情況，調用服務的開銷要比在同一個進程中發(fā)送消息的開銷高得多。當選定響應時間和其他性能設計目標后，需要仔細評價采購和使用現有組件對整個系統性能所產生的影響。上一頁返回6.3子系統設計和訪問控制設計 通信的情況，調用服務的開銷要6.4總體設計報告系統設計的管理主要挑戰(zhàn)在于維護一致性，同時利用盡可能多的資源，系統設計報告(SoftwareDesignedDocument–SDD)就是完整、一致地詳細記錄系統設計的最新成果，在系統設計的最后階段，系統設計報告將軟件體系結構和系統接口描述成為開發(fā)人員能夠理解的一個完整而且一致的系統。形成完整的系統設計報告，首先要有記錄系統結果的文件模板，其次記錄系統設計中的任務分配和系統設計中的各方成果，最后按照一定的結構形成系統設計報告。系統設計報告在初始系統分解時就應該開始編寫，而不是在所有的系統設計確定之后才進行編寫，設計決策變更或發(fā)現問題都要修改系統設計報告，系統設計報告也應有相應的版本控制，記錄修改的簡要描述、修改的作者、修改的日期等。下一頁返回6.4總體設計報告系統設計的管理主要挑戰(zhàn)在于維護一致性，同時6.4總體設計報告6.4.1系統設計報告內容系統設計記錄在系統設計報告中，它通過項目、子系統分解、硬件／軟件映射、數據管理、訪問控制、全局控制流機制、功能范圍和設計標準等來描述系統設計目標。系統設計報告還用于定義開發(fā)小組間的接口，并作為需要重新評價體系結構層次的決策時的參考。系統設計報告的讀者包括項目經理、系統設計人員(比如參與系統設計的開發(fā)人員)和設計實現每個子系統的開發(fā)人員。系統設計報告的具體內容參看附錄。6.4.2系統設計報告的不斷優(yōu)化上一頁下一頁返回6.4總體設計報告6.4.1系統設計報告內容上一頁下一頁返回6.4總體設計報告與需求階段一樣，系統設計在不斷的反復和變化中進行。但是應該控制變化，以避免混亂，尤其是在有多個參與者的復雜項目中。系統設計報告要完整記錄系統設計的架構思路、保證體現系統設計的最新版本。由于每個系統設計活動可能同時被啟動，系統設計早期的主要決策且會影響子系統的分解，當評估原型用于評估特定問題時，子系統的接口將會發(fā)生變化，后期發(fā)現的錯誤和疏漏會引起子系統接口的變化，有時會改變系統分解自身，因此要保證設計報告的不斷優(yōu)化和更新。系統設計報告的優(yōu)化應注意以下幾個方面的問題。1．設計人員掌握整個系統是一個過程，各種定義和模型仍然不斷變化，必須以形式或過程為代價最大限度地進行交流。上一頁下一頁返回6.4總體設計報告與需求階段一樣，系統設計在不斷的反復和變化6.4總體設計報告在基于小組的項目中，最初的系統分解通常在完成分析是時就設計好了。分解系統就可以將不同子系統的任務分配給不同的小組，因此系統設計報告優(yōu)化是一個不斷整合的過程，系統報告應能夠適應設計的變化，避免將來在詳細設計和實現時出現理解上的不一致。2．系統設計報告對于需要解決的困難和關注的問題要進行細致描述和變化跟蹤，比如特定供應商的軟件產品或技術的選擇，子系統是否穩(wěn)定，特定的包或組件是否適于系統。在此期間，設計人員還應該對關鍵用例測試其分解的適當性。系統設計報告還可以幫助設計人員盡可能早地發(fā)現控制流中的問題并加以解決。上一頁下一頁返回6.4總體設計報告在基于小組的項目中，最初的系統分解通常在完6.4總體設計報告3．編寫系統設計報告也要追蹤需求變化，從而減少在開發(fā)實現中可能出現的反復糾正。記錄設計過程的詳細變化，要認真與需求分析人員、開發(fā)人員進行交流，修正系統設計中瑕疵，避免在開發(fā)過程中出現反復，特別是對子系統記錄要保持一定的獨立性，避免設計報告中出現混亂。上一頁返回6.4總體設計報告3．編寫系統設計報告也要追蹤需求變化，從而圖6-1倉庫體系結構的軟件系統(UML類圖)

返回圖6-1倉庫體系結構的軟件系統(UML類圖)返回圖6-2模型／視圖／控制器體系結構返回圖6-2模型／視圖／控制器體系結構返回圖6-3客戶／服務器體系結構返回圖6-3客戶／服務器體系結構返回圖6-4三層C/S結構示意圖返回圖6-4三層C/S結構示意圖返回圖6-5B/S結構示意圖返回圖6-5B/S結構示意圖返回圖6-6對等體系結構示意圖返回圖6-6對等體系結構示意圖返回圖6-7管道和過濾器體系結構(UML類圖)

返回子系統3子系統1子系統2過濾器過濾器過濾器管道管道輸入輸出輸入輸出圖6-7管道和過濾器體系結構(UML類圖)返回子系統3子系圖6-8系統總體設計活動圖返回圖6-8系統總體設計活動圖返回圖6-9學籍管理交費子系統分解返回圖6-9學籍管理交費子系統分解返回圖6-10學費信息分解示意圖返回圖6-10學費信息分解示意圖返回圖6-11服務與子系統接口示意圖返回圖6-11服務與子系統接口示意圖返回圖6-12學生交費子系統與學生檔案管理子系統示意圖返回圖6-12學生交費子系統與學生檔案管理子系統示意圖返回圖6-13學籍管理系統的分層設計返回圖6-13學籍管理系統的分層設計返回圖6-14利用ADO組件進行數據訪問存取示意圖返回圖6-14利用ADO組件進行數據訪問存取示意圖返回圖6-15過程驅動的設計返回圖6-15過程驅動的設計返回圖6-16學籍管理系統的事件驅動設計示例返回下一頁圖6-16學籍管理系統的事件驅動設計示例返回下一頁圖6-16學籍管理系統的事件驅動設計示例返回上一頁圖6-16學籍管理系統的事件驅動設計示例返回上一頁圖6-17學籍管理系統硬件配置圖返回圖6-17學籍管理系統硬件配置圖返回圖6-18學籍管理系統組件圖返回圖6-18學籍管理系統組件圖返回圖6-19含有組件的節(jié)點配置圖返回圖6-19含有組件的節(jié)點配置圖返回圖6-20含有組件的節(jié)點配置圖返回圖6-20含有組件的節(jié)點配置圖返回表6-1學籍管理系統設計目標明細表返回下一頁表6-1學籍管理系統設計目標明細表返回下一頁表6-1學籍管理系統設計目標明細表返回上一頁表6-1學籍管理系統設計目標明細表返回上一頁表6-2學籍管理系統用戶訪問控制權限明細表返回√:為指定欄目內的全部功能表6-2學籍管理系統用戶訪問控制權限明細表返回√:為指第六章系統的總體設計6.1系統設計概述6.2軟件體系架構6.3子系統設計和訪問控制設計6.4總體設計報告第六章系統的總體設計6.1系統設計概述6.1系統設計概述系統設計包括總體設計和詳細設計兩部分。系統設計是把分析模型轉變成系統設計模型的過程。1．系統設計的目標系統設計的任務是依據系統的邏輯模型，結合實際情況，設計出一個能在計算機系統上實現的具體設計方案，即新系統的物理模型。系統設計的目標應從以下幾個方面進行考慮。(1)．系統的可靠性(2)．系統的可維護性(3)．系統的用戶友好性(4)．系統的工作效率(5)．系統的合法性下一頁返回6.1系統設計概述系統設計包括總體設計和詳細設計兩部分。系統6.1系統設計概述(6)．系統的經濟性2．系統設計的內容系統設計的內容可分為總體設計和詳細設計兩部分。具體包括如下內容：(1)．系統配置設計設計人員根據系統分析報告中所確定的系統目標、功能、性能、環(huán)境與制約條件，確定合適的計算機處理方式及體系結構，確定合適的計算機系統具體配置。(2)．子系統和功能模塊設計根據系統分析階段得到的數據流程圖和數據詞典，設計出子系統和功能模塊結構圖，明確它們之間的相互關系。上一頁下一頁返回6.1系統設計概述(6)．系統的經濟性上一頁下一頁返回6.1系統設計概述(3)．對象設計根據系統分析報告設計出管理信息系統中用到的各種對象，確定對象類型、屬性、操作、服務及方法等，并形成對象設計文檔。如產品、往來客戶、職工及業(yè)務處理等各類對象的設計。(4)．數據庫設計根據系統分析報告與系統的硬件、軟件配置，進行數據庫的概念設計、邏輯設計、物理設計，設計出系統有關的數據庫文件、數據庫結構、存取路徑、存取方式等。(5)．輸入/輸出設計根據系統的目標、用戶的使用習慣及使用的方便，確定系統輸入的內容、輸入格式、輸入方式與輸入校驗;完成系統輸出的內容、輸出格式及輸出方式等內容的具體設計。上一頁下一頁返回6.1系統設計概述(3)．對象設計根據系統分析報告設計出管理6.1系統設計概述(6)．業(yè)務邏輯處理設計對系統中每一業(yè)務事項的詳細處理過程進行描述，編寫業(yè)務流程圖、處理方法和處理順序等，作為設計開發(fā)詳細設計和實現主要依據。(7)．編寫系統設計報告根據系統設計階段所完成的總體設計及詳細設計內容，以書面的形式編寫符合要求的系統設計報告。系統設計報告既是系統設計階段的主要成果，經過審查批準后又是系統實施階段的主要技術依據。以上內容的設計在系統設計階段是按照一定的先后次序進行的，一般是先進行系統配置設計或系統架構設計，形成系統設計報告。再進行詳細設計包括細化對象設計、數據庫設計、輸入設計、輸出設計、模塊處理過程設計等具體內容，最后再編寫詳細設計文檔。上一頁返回6.1系統設計概述(6)．業(yè)務邏輯處理設計對系統中每一業(yè)務事6.2軟件體系架構隨著系統復雜度的增加，系統分解的說明就變得相當關鍵。一旦開始進行開發(fā)，就很難修改或者糾正一個不好的分解，因為這樣大多數子系統的接口就必須改動。為了認識到這個問題的重要性，出現了軟件體系結構的概念。軟件體系結構包括系統分解、全局控制流、錯誤處理策略和子系統間的通信協議。本節(jié)介紹一些典型的不同的體系結構，并簡要介紹不同軟件體系結構的設計思路。具有代表性的軟件體系結構包括倉庫體系結構、MVC體系結構、客戶/服務器體系結構、B/S結構、對等體系結構和管道過濾器結構等。下一頁返回6.2軟件體系架構隨著系統復雜度的增加，系統分解的說明就變得6.2軟件體系架構6.2.1倉庫體系結構(RepositoryArchitecture)在倉庫體系結構(如圖6-1所示)中，子系統通過一個稱為中心倉庫的單一數據結構訪問并修改數據。子系統相對獨立而且只通過中心數據結構相互作用?；蛘咄ㄟ^中心倉庫(例如數據中的觸發(fā)器調用外設)或者通過子系統(例如，通過倉庫的鎖來實現控制流的獨立和同步)來命令控制流。每個子系統只依賴于倉庫中心數據結構。而倉庫并不清楚其他子系統。對于像工資系統、學籍管理系統和銀行系統這樣的數據庫管理系統來說，倉庫體系結構是比較典型的。以數據為中心易于處理子系統間的并發(fā)和完整性問題。倉庫子系上一頁下一頁返回6.2軟件體系架構6.2.1倉庫體系結構(Repositor6.2軟件體系架構

統可以實現全局控制流。用戶可以調用其中的每個界面，倉庫體系結構也適用于處理任務不斷改變的復雜的應用系統。但是倉庫子系統的主要缺點是子系統與倉庫之間耦合度很高，對倉庫數據結構的修改必然會影響到子系統。6.6.2模型／視圖／控制器體系結構（ModelViewControl--MVCArchitecture）在模型／視圖／控制器(MVC)體系結構(見圖6-2)中，子系統分為三種不同的類型：模型子系統負責維護系統的數據結構和數據信息；視圖子系統負責把系統數據信息顯示給用上一頁下一頁返回6.2軟件體系架構 統可以實現全局控制流。用戶可以調用其中的6.2軟件體系架構

戶；控制器子系統負責管理與用戶交互的順序。模型子系統發(fā)展成完全不依賴于任何視圖或控制器子系統。它們狀態(tài)的變化通過訂閱／通知(subscription／notification)協議傳輸給視圖子系統。MVC體系結構是倉庫體系結構的特例，模型實現了中心數據結構，控制對象指揮著控制流。這種體系結構經常用于WEB服務器系統設計?？刂破魇占瘉碜杂脩舻妮斎氩l(fā)消息給模型。模型保持中心數據結構。視圖顯示模型，每當模型發(fā)生變化時得到通知(通過簽署／通知協議)。MVC體系結構將交互式應用程序分為三個區(qū)域：輸入、處理和輸出。模型組件封裝了內核數據和功能。模型獨立于特定輸出表示法或輸入方式。上一頁下一頁返回6.2軟件體系架構 戶；控制器子系統負責管理與用戶交互的順序6.2軟件體系架構視圖組件子系統向用戶顯示信息。視圖從模型獲得數據?？赡苡心Ｐ偷亩鄠€視圖。每個視圖都有一個相關的控制器組件。控制器接受輸入，通常作為將鼠標移動、鼠標按鈕的活動或鍵盤輸入編碼的事件。事件被翻譯成模型或視圖的服務器請求。用戶僅僅通過控制器與系統交互。模型與視圖和控制器組件的分離將允許同一個模型的多個視圖。如果用戶通過一個視圖的控制器改變了模型，所有依賴于該數據的其他視圖應該反映出這種變化。因此一旦模型的數據發(fā)生了變化，模型要通報所有視圖。視圖反過來從模型恢復新數據并更新所顯示的信息。這種變更-傳播機制相當于訂閱—發(fā)行。上一頁下一頁返回6.2軟件體系架構視圖組件子系統向