網頁設計的系統體系結構設計

1、在系統設計中怎樣寫系統體系結構的設計？

簡單來說，就是：畫圖，全方位的剖析系統，設計類。其中要畫出用例圖版，狀態圖，時序圖，類圖權。下面就我做過的一個「大富翁」游戲的體系結構設計為例。

用例圖：

時序圖：

類圖：

把用戶對系統的需求劃分成系統的一個個功能模塊並設計好類，就可以進行開發了。

2、什麼階段要做體系結構設計

一般在方案階段就會確定結構體系，因為這個關系造價，且比重很大。初步設計階段基本就有確定的大致體系（牆柱布置等），施工圖階段做詳細的配筋等.

3、基於體系結構的設計方法的特點是什麼

基於體系結構的開發模型是以軟體體系結構為核心，以基於構件的開發方法為基礎。然後採用迭代增量方式進行分析和設計，將功能設計空間映射到結構設計空間，再由結構設計空間映射到系統設計空間的過程。該開發模型把軟體生命周期分為軟體定義、需求分析和定義、體系結構設計、軟體系統設計和軟體實現5個階段. 在基於體系結構的開發過程中，首先是基於體系結構的需求獲取和分析，將軟體體系結構的概念引入到需求空間，從而為分析階段到設計階段的過渡提供更好的支持。在需求分析結果的基礎上，進行體系結構的設計。考慮系統的總體結構及系統的構成元素，根據構成元素的語法和語義在已確定的構件庫中尋找匹配的構件。當不存在符合要求的構件時，則根據具體情況組裝合成新構件或者購買新構件或者根據需要開發新構件而得到滿足需求的構件。在經過語法和語義檢查後，將這些構件通過膠合代碼組裝到一起實現整個軟體系統。在實踐中，整個開發過程呈現多次迭代性。在傳統的軟體生命周期中，軟體需求分析和定義完成後緊接的是軟體系統的設計和實現。在這種傳統的開發方法中，如果軟體需求不斷變化，最終軟體產品可能與初始原型相差很大。而基於體系結構的開發模型有嚴格的理論基礎和工程原則，是以體系結構為核心。體系結構為軟體需求與軟體設計之間架起了一座橋梁，解決了軟體系統從需求到實現的平緩過渡，提高了軟體分析設計的質量和效率。基於體系結構的開發模型的優點是通過對體系結構的設計，使得軟體系統結構框架更清晰，有利於系統的設計、開發和維護，並且軟體復用從代碼級的復用提升到構件和體系結構級的復用。基於體系結構的開發模型和基於構件的開發模型都是在體系結構的基礎上進行構件的組裝而得到軟體系統，前者主要關注運行級構件及其之間的互操作性，提供了一種自底向上且基於預先定製好的構件來構造應用系統的途徑；後者局限在構件的規范上，缺少系統化的指導開發過程的方法學。基於體系結構的開發方法從系統的總體結構入手，將一個系統的體系結構顯示化，以在高抽象層次處理諸如全局組織和控制結構、功能到計算元素的分配、計算元素間的高層交互等設計問題。

4、系統總體結構設計

（一）系統設計思路

地下水系統三維可視化軟體是一個龐大的軟體系統，涉及到了一系列的軟體開發技術和地下水系統概化與表示方案，在系統設計上要充分考慮現有的資料庫基礎，以提高對地下水系統的可視性與可操作性為目標，總體設計思路如下：

（1）地下水系統三維可視化軟體運行的基礎是地下水資源資料庫系統，系統運行的所有原始數據均來源於地下水資源資料庫，二者之間需要實現緊密的有機結合。

（2）地下水系統三維可視化軟體運行的核心數據是地下水系統的三維結構數據，它以資料庫的形式存儲。本系統的各個子系統均是圍繞該資料庫進行操作。

（3）地下水系統三維可視化軟體按功能的不同劃分為幾個子系統或稱為組件，這些組件可根據需要集成到不同的系統中，其本身可以集成為一個完整的可視化軟體系統。

（4）地下水系統三維可視化軟體所處理的數據對象鎖定為含水層系統，從面到體體現為含水層界面和含水層/隔水層本身，具有空間查詢和管理功能，並對這些面和體可進行數據查詢操作。

（5）地下水流體的可視化依據含水層系統動態生成，其數據基礎是地下水的動態觀測數據。

（6）為體現地下水系統三維可視化軟體的獨立性，研製開發相關原始性數據的資料庫管理軟體，作為獨立的組件集成到整個可視化軟體中。

（二）系統結構與組織

地下水系統三維可視化軟體採用組件方式處理，按照研究內容給出的劃分方案，共包括8個軟體組件和一個網路服務體系，作為一個集成結構，這些組件之間的關系如圖4-1所示。整個系統可以劃分為四個組成部分，分別具有相對獨立的軟體功能，但又相互聯系、互相依託。

圖4-1 地下水系統三維可視化軟體的結構與組織

1.地下水系統基礎資料庫管理子系統

實現對地下水系統三維結構基礎水文地質數據信息的管理，原則上採用大型資料庫作為數據存儲，利用數據引擎進行開發。

2.地下水系統三維模型生成編輯工具子系統

地下水三維系統生成輔助編輯工具能夠為用戶提供一個進行地下水三維系統動態生成和編輯的工作環境，並為地下水數值模擬提供單元剖分功能以及水文地質參數的空間配准。

3.地下水三維系統可視化系統

利用生成的三維水文地質模型數據信息，系統可提供多種形式的地下水系統三維可視化顯示，並可將這些成果用於輸出。

4.地下水三維系統的網路服務體系

三維可視化服務的對象是含水層結構，可基於含水層結構提供多種形式的WEB服務，通過用戶的請求而取得可視化結果。

（三）系統組件與關聯

地下水系統三維可視化軟體的四個子系統又可以劃分為8個程序組件和一個網路服務體系，實現地下水系統三維結構的生成、維護和服務過程。

系統包括的8個組件為單機模式，服務於水文地質專業技術人員，實現地下水系統三維結構的生成和顯示，為開展地下水資源評價工作提供一種有效的工作環境。具體組件如下：

（1）地下水系統基礎數據管理組件（組件1）；

（2）地下水系統基礎數據預處理組件（組件2）；

（3）地下水系統三維模型生成編輯環境組件（組件3）；

（4）地下水系統三維空間剖分組件（組件4）；

（5）地下水系統空間面可視化飛行組件（組件5）；

（6）地下水系統三維結構可視化組件（組件6）；

（7）地下水流體運移動態模擬組件（組件7）；

（8）地下水流場動態模擬組件（組件8）。

網路服務體系是基於INTERNET提供的社會化服務，提供地下水系統三維結構的各種顯示服務，並可根據用戶的需要提供真實的三維結構數據服務。

5、系統邏輯結構設計

塔里木河流域生態環境動態監測系統是一個以資料庫為核心，以生態環境監測和保護為目的的綜合應用系統。整個系統採用C/S與B/S混合結構的管理信息系統運行模式，這種運行模式將C/S和B/S模式融為一體，不僅發揮了C/S模式事務處理能力強的特點，而且充分利用B/S模式網路易擴性和分布式的優勢，滿足系統對不同層次用戶的要求(廖志英，董安邦，2002)。系統由多個功能子系統組成，各子系統限於實現內容、實現方法和所需外設、運行地點的不同，分別採用了C/S或B/S的體系結構和運行模式，運行模式有基於特定功能區域的，有基於專業處室的，還有面向所有處室全體員工進行信息發布的。

在這種體系結構和運行模式下，進行基於各子系統功能模塊緊密關系的集成是不可行的。因此，本系統總體結構採用:以數據集成為中心，以各子系統間數據流動關系為紐帶，把整個系統集成為基於子系統間數據關系緊密、物理結構鬆散的塔里木河流域生態環境動態監測系統。系統的邏輯結構如圖3－2所示。

系統採集的各類歷史以及實時數據通過大型資料庫平台進行統一管理;ArcSDE作為空間數據引擎在GIS平台與資料庫系統之間建立了聯結的橋梁，實現了空間數據的關系型方式存儲;採用ENVIIDL和ArcObjects組件進行開發的應用系統運行於ENVI和ArcGIS/ArcEngine基礎平台上實現各類數據的提取、編輯、入庫、查詢以及分析等，該部分主要採用C/S結構開發模式;採用VB及.net等高級語言直接開發的信息發布、瀏覽應用系統則運行於ArcIMS軟體之上，為廣大的Intranet或Internet用戶提供基本的瀏覽、查詢、統計功能，該部分主要採用B/S結構開發模式。

圖3－2 系統邏輯結構示意圖

6、電子商務系統總體結構設計的主要內容與方法是什麼

電子商務系統的總體結構設計是在系統體系結構的基礎上，針對企業電子商務的目標，界定系統的外部邊界和介面，刻畫系統的內部成及其相互關系，明確目標系統的各個組成部分、各個組成部分的作用及其相互關系。
系統總體結構設計包括如下內容：
1．確定系統的外部介面
通過分析，將電子商務系統與其外部環境區分開來，從而使總體設計有一個明確的范圍。系統與其外部環境的介麵包括以下方面：
（1）與企業合作夥伴之間的介面；
（2）與企業內部既有信息系統的介面；
（3）與交易相關的公共信息基礎設施之間的介面；
（4）其他介面，如企業與政府或其他機構之間的介面。
2．確定系統的組成結構
系統組成結構主要說明目標系統內部的組成部分，以及系統內部與外部環境的相互關系。

方法：
隨著Internet技術的發展，人們的日常生活已經離不開網路。未來社會人們的生活和工作將越來越依賴於數字技術的發展，越來越數字化、網路化、電子化、虛擬化。電子商務也隨著網路的發展日益和人們的生活貼近。本設計嘗試用ASP在網路上架構一個動態的電子商務網站，以使每一位顧客不用出門在家裡就能夠通過上網來輕松購物。在本設計中，我主要完成了後台功能的實現，實現了登錄功能，圖書管理，圖書分類管理，訂單管理，用戶管理等功能。
本文中所做的主要工作如下：
(1)簡單介紹了電子商務，分析了電子商務的現狀；
(2)介紹了IIS+ASP系統的一般原理；
(3)闡述整個系統的系統結構及工作原理；分析了系統實現中的特殊性、難點和重點；
(4)分析並解決實現中的若干技術問題；

附：

方案設計主要依靠設計者的經驗，作出技術和結構的選擇，並以有組織的文檔反映，作為與客戶交流論證方案，交付系統開發人員實施的依據，方案設計的基礎是業務環境說明書。業務環境說明書重新組織系統需求，給出解決方案的業務運作方式。在系統需求相對簡單時不一定需要，如果系統需求較為復雜時，以文字和圖表的方式系統地說明業務環境可以使系統需求更加清楚，業務環境說明書可以採用三種文檔結構。
* 業務流程圖：業務流程圖描述企業的業務在新系統中如何運作，說明新系統的業務運作模式如何解決客戶的要求，指出客戶的業務流程因為新系統的應用而作出那些更改。業務流程圖是一種直觀的工具，向客戶解釋新系統的作用，徵求使用者的配合與支持，能提高新系統的實際效能。
* 操作規程說明：相對於業務流程圖這種較高層概括的文檔，普通用戶可能更需要一份詳細的操作規程說明，以便更好地理解系統的功能與使用。操作規程說明以易被最終用戶理解的詞語描述，避免使用過分專業的詞語。操作規程說明仍屬於高層設計文檔，不是最終的操作步驟說明。操作規程說明規定了系統活動的框架，
* 處理流程圖 ： 細化操作規程中描述的活動，由事件和處理流組成。事件是活動開始的條件，處理是活動中的具體工作。處理流程圖的描述層次接近詳細設計。以客戶在網上購貨為例，最後一步是確認付款，操作規程說明只需簡單地說明：「客戶檢查付款額後確認」，處理流程圖的說明比較詳細，激發活動的事件是客戶按下「付額」按鈕，處理是付款總額從資料庫中統計出來，顯示在瀏覽器上，最後由客戶按「確認」按鈕確認。

當前普遍採用對象技術描述復雜的應用結構，電子商務系統一般用Java,EJB,CORBA等對象技術實現，在系統設計階段，編制業務環境書時採用面向對象分析和設計方法可以提高實施階段的效率。業務環境說明書中的設計文檔完成後，召開第二次項目會議，在會上以圖表的形式向客戶和項目開發人員介紹系統設計的概貌。著重與客戶討論兩個問題，檢查系統設計是否滿足客戶需求：

系統設計在多大程度上解決了用戶的需求？是否准確地實現了客戶的期望，既沒有過分簡單化，也沒有過分復雜化。

系統設計的功能范圍是否包含了用戶提出的所有需求？
應用開發人員參加項目會議，可以更好地了解客戶的業務環境與方案設計的總體結構，與客戶和系統設計者直接交談，減少溝通的誤差，提高效率。

IBM為電子商務系統定義了一套完整的電子商務應用框架，基於三層次體系結構集成企業核心系統與互聯網服務，多層次結構使企業內部應用系統無需作重大更改，通過與互聯網伺服器的連結就可以在互聯網上提供服務，實現電子商務系統的目標。
基於電子商務應用框架的電子商務系統體系結構共有八個主要部分。直接支持應用程序運行的模塊有六個：客戶端、網路連接、互聯網伺服器、應用邏輯、中間連接件、核心數據與應用，其餘兩個模塊安全性和系統管理與這六個模塊都有關聯，系統設計者可相對獨立地設計安全性體系和系統管理體系，在應用程序運行支持模塊的實現中加入相應的技術與處理。安全性和系統管理的效率是系統的整體性效果，應用系統運行的每一個環節都能影響系統總體的安全性和可管理性。

7、什麼是系統架構設計?

系統架構的主要任務是界定系統級的功能與非功能要求、規劃要設計的整體版系統的特權征、規劃並設計實現系統級的各項要求的手段，同時利用各種學科技術完成子系統的結構構建。

在系統架構中，由於對軟體越來越深入的依賴，軟體架構的任務也體現出重要的作用。而且系統架構與軟體架構是緊密聯系和相互依賴的。

8、簡述信息系統體系結構設計的任務

1.問題定義

9、電子商務系統總體結構設計的主要內容與方法是什麼？

電子商務系統的總體結構設計是在系統體系結構的基礎上，針對企業電子商務的目標，界定系統的外部邊界和介面，刻畫系統的內部成及其相互關系，明確目標系統的各個組成部分、各個組成部分的作用及其相互關系。
系統總體結構設計包括如下內容：
1．確定系統的外部介面
通過分析，將電子商務系統與其外部環境區分開來，從而使總體設計有一個明確的范圍。系統與其外部環境的介麵包括以下方面：
（1）與企業合作夥伴之間的介面；
（2）與企業內部既有信息系統的介面；
（3）與交易相關的公共信息基礎設施之間的介面；
（4）其他介面，如企業與政府或其他機構之間的介面。
2．確定系統的組成結構
系統組成結構主要說明目標系統內部的組成部分，以及系統內部與外部環境的相互關系。

方法：
隨著Internet技術的發展，人們的日常生活已經離不開網路。未來社會人們的生活和工作將越來越依賴於數字技術的發展，越來越數字化、網路化、電子化、虛擬化。電子商務也隨著網路的發展日益和人們的生活貼近。本設計嘗試用ASP在網路上架構一個動態的電子商務網站，以使每一位顧客不用出門在家裡就能夠通過上網來輕松購物。在本設計中，我主要完成了後台功能的實現，實現了登錄功能，圖書管理，圖書分類管理，訂單管理，用戶管理等功能。
本文中所做的主要工作如下：
(1)簡單介紹了電子商務，分析了電子商務的現狀；
(2)介紹了IIS+ASP系統的一般原理；
(3)闡述整個系統的系統結構及工作原理；分析了系統實現中的特殊性、難點和重點；
(4)分析並解決實現中的若干技術問題；

附：

方案設計主要依靠設計者的經驗，作出技術和結構的選擇，並以有組織的文檔反映，作為與客戶交流論證方案，交付系統開發人員實施的依據，方案設計的基礎是業務環境說明書。業務環境說明書重新組織系統需求，給出解決方案的業務運作方式。在系統需求相對簡單時不一定需要，如果系統需求較為復雜時，以文字和圖表的方式系統地說明業務環境可以使系統需求更加清楚，業務環境說明書可以採用三種文檔結構。
* 業務流程圖：業務流程圖描述企業的業務在新系統中如何運作，說明新系統的業務運作模式如何解決客戶的要求，指出客戶的業務流程因為新系統的應用而作出那些更改。業務流程圖是一種直觀的工具，向客戶解釋新系統的作用，徵求使用者的配合與支持，能提高新系統的實際效能。
* 操作規程說明：相對於業務流程圖這種較高層概括的文檔，普通用戶可能更需要一份詳細的操作規程說明，以便更好地理解系統的功能與使用。操作規程說明以易被最終用戶理解的詞語描述，避免使用過分專業的詞語。操作規程說明仍屬於高層設計文檔，不是最終的操作步驟說明。操作規程說明規定了系統活動的框架，
* 處理流程圖 ： 細化操作規程中描述的活動，由事件和處理流組成。事件是活動開始的條件，處理是活動中的具體工作。處理流程圖的描述層次接近詳細設計。以客戶在網上購貨為例，最後一步是確認付款，操作規程說明只需簡單地說明：「客戶檢查付款額後確認」，處理流程圖的說明比較詳細，激發活動的事件是客戶按下「付額」按鈕，處理是付款總額從資料庫中統計出來，顯示在瀏覽器上，最後由客戶按「確認」按鈕確認。

當前普遍採用對象技術描述復雜的應用結構，電子商務系統一般用Java,EJB,CORBA等對象技術實現，在系統設計階段，編制業務環境書時採用面向對象分析和設計方法可以提高實施階段的效率。業務環境說明書中的設計文檔完成後，召開第二次項目會議，在會上以圖表的形式向客戶和項目開發人員介紹系統設計的概貌。著重與客戶討論兩個問題，檢查系統設計是否滿足客戶需求：

系統設計在多大程度上解決了用戶的需求？是否准確地實現了客戶的期望，既沒有過分簡單化，也沒有過分復雜化。

系統設計的功能范圍是否包含了用戶提出的所有需求？
應用開發人員參加項目會議，可以更好地了解客戶的業務環境與方案設計的總體結構，與客戶和系統設計者直接交談，減少溝通的誤差，提高效率。

IBM為電子商務系統定義了一套完整的電子商務應用框架，基於三層次體系結構集成企業核心系統與互聯網服務，多層次結構使企業內部應用系統無需作重大更改，通過與互聯網伺服器的連結就可以在互聯網上提供服務，實現電子商務系統的目標。
基於電子商務應用框架的電子商務系統體系結構共有八個主要部分。直接支持應用程序運行的模塊有六個：客戶端、網路連接、互聯網伺服器、應用邏輯、中間連接件、核心數據與應用，其餘兩個模塊安全性和系統管理與這六個模塊都有關聯，系統設計者可相對獨立地設計安全性體系和系統管理體系，在應用程序運行支持模塊的實現中加入相應的技術與處理。安全性和系統管理的效率是系統的整體性效果，應用系統運行的每一個環節都能影響系統總體的安全性和可管理性。

10、　系統結構設計

一、用戶需求分析

全面深入地了解掌握用戶需求是作出一個優良的系統設計的關鍵，也是系統生命力的保證。在需求分析階段，系統設計者應當完全確定用戶的工作范圍與流程。據此，確定系統的全部數據及相應處理，繪出系統數據流圖，從而產生整個評價系統的邏輯模型。

針對地質災害災情評估的特點，可以歸納為五個方面的需求，即：①數據維護；②物理系統（孕災環境危險性）分析；③社會經濟系統（承災區易損性）分析；④風險分析；⑤防治效益評價。

二、設計需求

1.地質災害系統自組織體系

地質災害系統作為一個開放的自組織體系，在內外界持續干擾的作用下，該體系形成漲落，從而體系狀態發生質變，形成一種更加穩定有序的結構。地質災害系統是由孕災環境、致災因子與承災體共同組成的地球表層變異系統。災情則是這一體系漲落作用的產物。

2.系統硬軟體環境的選擇

（1）各種與IBM兼容的PC機（需帶有80387浮點運算器），1兆以上內存，100兆以上硬碟，VGA以上彩色圖形顯示器（卡）。

（2）輸入、輸出設備，包括解析度為0.1×0.1（mm）、帶有國際標准數據交換格式的掃描儀（便於弧段跟蹤、數據矢量化處理和數據格式轉換），CALCOMP、HP系列或與之兼容的數字化儀和繪圖儀。

（3）軟體環境

系統採用美國環境系統研究所（ESRI）研製的PC版ARC/INFO（V3.4-PLUS）系統為基礎軟體。該系統是兩個系統的結合，即描述地圖特徵和拓撲關系的ARC系統和記錄屬性數據的關系型數據管理INFO系統。這種混和數據模型兼顧了空間數據和非空間數據兩種不同性質的數據特點，便於有效地管理這兩種基本的空間數據：描述空間坐標的點、線、面特徵和拓撲結構數據以及這些特性的屬性數據。

3.資料庫的組織結構

計算機作業較之於手工作業，在其精確度、可靠性方面具有很大的優越性。但這一切基於一個先決條件，那便是數據源的准確性。地質災害風險評價系統涉及到的數據源較復雜，既包括自然物理數據，又包含社會經濟發展數據。根據這些數據特點分為：屬性庫、圖形庫和圖像庫三類資料庫。通過分析評價區內各災種成災特點、社會經濟構成，收集各類數據源的數據，評價其精確度、可靠性、可利用性及相互關系，確定入庫的數據項，並給出各數據項的詳細定義，編輯數據詞典。在各相關資料庫之間建立公共特徵碼欄位，將有助於提高數據的檢索查詢效率。根據系統的基本要求和地質災害的基本規律，系統資料庫組織如下：

圖9-1　GDRES資料庫組織圖

4.系統總體設計

地質災害災情評估系統是一類專業性的地理信息系統。其總體結構可作如下劃分（圖9-2）：

系統運行時，用戶在應用子系統中工作，由應用子系統調用系統功能模塊從而完成對系統數據的處理。

用戶應用子系統是系統的用戶界面。此層的缺失或劃分不當，系統的用戶友好性無從談起。一般而言，應用子系統對應於用戶某一需求的共同作業，此層面的設計與劃分一定要從用戶需求出發，面向地質災害災情評估的實際工作程序，以系統數據流圖為基礎進行。

圖9-2　系統總體設計圖

應用子系統建立在對系統功能模塊的調用基礎之上。系統功能模塊可由支撐軟體直接提供。許多支撐軟體雖然功能強大，但一般都是從通用性入手考慮，具體到某一類專業應用系統，開發者仍具有一定工作量的二次開發任務，需要對系統功能模塊進行擴充以滿足特定需求。這類功能擴充定義又來源於上層應用子系統的操作分解，從中抽象出多個子系統中共同的操作，在此基礎上開發擴充功能模塊滿足應用子系統的操作並優化系統整體結構。

5.GDRES結構

（1）系統組織結構的設計　從實用性入手，系統組織結構必須面向實際工作內容。為此，我們結合DBMS和GIS設計的概念和原理，將系統分為如下圖所示的三個層次的七個子系統：①孕災區災害分布分析；②孕災區危險程度分析；③承災區受損范圍分析；④承災區價值易損性分析；⑤災害發生概率分析；⑥災害強度分析；⑦災害風險分析。災害強度是綜合考慮孕災區危險性強度及承災區價值易損性的結果，災害風險分析則建立在對中間層兩因素的綜合分析之上。

圖9-3　GDRES組織結構圖

（2）系統功能結構設計　我們以屬性資料庫、空間資料庫為基礎，設計出面向災害風險分析的用戶應用子系統。各應用子系統都具有以下功能模塊，其中包括屬性資料庫維護、空間資料庫維護、數據檢索查詢、統計查詢、矩陣判斷、空間分析模塊。所有模塊以GIS、DMBS類軟體支撐並根據面向任務擴展產生。模塊處理結果用文本、報表及圖件三種方式輸出，為地質災害的管理和防治提供決策依據。

系統功能結構圖如下：

圖9-4　GDRES功能結構圖