【正文】 圖 片 商 店網(wǎng) 絡客 戶 1 客 戶 2 客 戶 3 客 戶 4 客戶機 服務器 ? 一個采用客戶機 服務器模式的系統(tǒng)是由一個服務集合和相關的服務器以及訪問和使用這些服務的客戶機組織起來的。因此實際的控制器或者它的實現(xiàn)可以在知識源中，也可以在黑板中，獨立的模塊中或者在它們的組合中。知識源不斷修改黑板中的數(shù)據(jù)，直到問題得解。黑板體系結構的示意圖如圖 611所示。在不同的系統(tǒng)中，知識庫和外部構件集合之間的交互方式存在很大的差異。到底激活哪個工具要視對數(shù)據(jù)的分析結果而定。雖然從邏輯上講將集中式容器分布到不同的機器上是可能的，但這樣做會引起數(shù)據(jù)冗余和不一致性的問題。然而，組件一定要圍繞一個約定好了的容器數(shù)據(jù)模型運行。該圖顯示了一個包含不同工具來支持模型驅動開發(fā)的 IDE系統(tǒng)。 知識庫（容器） ? 大多數(shù)使用大量數(shù)據(jù)的系統(tǒng)都是圍繞共享數(shù)據(jù)庫或容器來組織的。 表 64 容器模式 圖 69 以數(shù)據(jù)為中心的體系結構 數(shù) 據(jù) 存 儲（ 中 心 存 儲 庫 或 黑 板 ）客 戶 軟 件 客 戶 軟 件客 戶 軟 件客 戶 軟 件客 戶 軟 件客 戶 軟 件客 戶 軟 件 客 戶 軟 件 知識庫（容器） ? 數(shù)據(jù)存儲（如文件或數(shù)據(jù)庫）駐留在這種體系結構的中心，其他構件會經(jīng)常訪問該數(shù)據(jù)存儲，并對存儲中的數(shù)據(jù)進行更新、增加、刪除或者修改。另外，定義一個合適的抽象層次可能會非常困難。這使得定義標準層接口成為可能，在此接口上可建立不同實現(xiàn)。第二，它支持擴展。這個系統(tǒng)有 5層，最底層是各個圖書館中獨立的數(shù)據(jù)庫。最上層提供用戶界面設施。 分層系統(tǒng) ? 圖 67是一個分為 4層的體系結構的例子。這個體系結構還是可改變的和可移植的。較低層定義較低層的交互，最底層通常通過硬件連接來定義。（在其他分層系統(tǒng)中，層次可能只是部分透明的。在外層，構件完成建立用戶界面的操作；在內(nèi)層，構件完成建立操作系統(tǒng)接口的操作；中間層提供各種實用工具服務和應用軟件功能。 分層系統(tǒng) ? 分離性和獨立性的概念是體系結構設計的基礎，因為分離性和獨立性使得變更得到局部化。尤其是在系統(tǒng)需要逐步顯示數(shù)據(jù)流變化的過程時，問題會變得更加難以解決，因為增量顯示和過濾器的輸出數(shù)據(jù)差距太大。 管道 過濾器 ? 但是管道 過濾器模式也有缺點。第二，支持功能模塊的重用：任意兩個過濾器只要相互間所傳輸?shù)臄?shù)據(jù)格式上達成一致，就可以連接在一起。 ? 自從計算機被用于自動數(shù)據(jù)處理以來，數(shù)據(jù)流模型的多種形式就被廣泛使用。每個過濾器獨立于其上游和下游的構件而工作，要針對某種形式的數(shù)據(jù)輸入產(chǎn)生某種特定形式的數(shù)據(jù)輸出（到下一個過濾器）。當輸入數(shù)據(jù)經(jīng)過一系列的計算構件和操作構件的變換形成輸出數(shù)據(jù)時，可以應用這種體系結構。 表 62 管道 過濾器模式 圖 64 管道 過濾器模式（數(shù)據(jù)流體系結構） 過 濾 器過 濾 器過 濾 器過 濾 器過 濾 器過 濾 器過 濾 器過 濾 器過 濾 器過 濾 器過 濾 器過 濾 器過 濾 器過 濾 器過 濾 器過 濾 器過 濾 器管 道管 道 和 過 濾 器圖 65 管道 過濾器模式的一個實例 票 據(jù)收 據(jù)提 醒讀 發(fā) 出 的票 據(jù)支 付確 認 支 付發(fā) 出 支 付檢 查 支 付截 止 日 期發(fā) 出 支 付提 醒 管道 過濾器 ? “管道 過濾器”的名字最早出自 Unix系統(tǒng)， Unix系統(tǒng)在鏈接進程時可能會用到“管道”，通過提供符號表示要連接的構件和提供運行時機制來實現(xiàn)管道，這些管道能從一個進程到另一個進程傳遞文本流。 管道 過濾器 ? 管道 過濾器（ Pipes and Filters）體系結構模式（見表 62和圖 64）是一個系統(tǒng)運行時組織的模型，在這個模型中，函數(shù)轉換處理輸入并產(chǎn)生輸出。應用較多的體系結構模式有： MVC（模型 視圖 控制器）、批處理序列、管道 過濾器（數(shù)據(jù)流）、調(diào)用和返回、主程序和子程序、面向對象系統(tǒng)、多級分層、客戶機 服務器、獨立構件、通信進程、事件系統(tǒng)、虛擬機、解釋器、基于規(guī)則系統(tǒng)、數(shù)據(jù)中心系統(tǒng)（知識庫、黑板、容器）、數(shù)據(jù)庫、超文本系統(tǒng)、過程控制。下面的問題有助于更深入地了解體系結構風格： – 控制。 – 開發(fā)結構：該結構定義構件、工作產(chǎn)品以及軟件工程過程中所需的其他信息源。 “ 關系（連接件）包括同步于、優(yōu)先級高于、發(fā)送數(shù)據(jù)到、運行必須有、運行不能有。 – 實現(xiàn)結構： “ 構件可以是包、類、對象、過程函數(shù)方法等所有在不同抽象層上打包的功能 ” 。 基本體系結構 ? 本質上軟件體系結構表示了一種結構，在該結構中，某個實體集（經(jīng)常稱作構件）通過一組已定義的關系（經(jīng)常稱作連接件）進行連接。 風格與模式 ? 與體系結構風格一樣，體系結構模式也對體系結構設計施加一種變換。 風格與模式 ? 為基于計算機的系統(tǒng)構造的軟件也展示了眾多體系結構風格中的一種。建筑師使用體系結構風格作為描述手段，將該房子和其他風格（例如，公寓、別墅等）的房子區(qū)分開來。 風格與模式 ? 因此，一個體系結構風格根據(jù)結構組織模式定義了一個系統(tǒng)族。某些體系結構模式和一些特殊類型的系統(tǒng)相關，比如編譯器的傳統(tǒng)組織結構，國際標準化組織的公共系統(tǒng)連接參考模型和面向對象設計通用模式。 風格與模式 ? 軟件體系結構設計的特點之一，是使用系統(tǒng)組織慣用模式（ idiomatic patterns）。 風格與模式 ? 體系結構模式是復用和通用系統(tǒng)體系結構知識的一種方法。體系結構模式在 20世紀 90年代以“體系結構風格”的名字提出來。這種格式化的模式描述包括模式的名字，一個簡短的描述（伴有一個相關的圖形模型），以及一個這種模式適用的系統(tǒng)類型的例子（可能也伴有一個圖形模型）。類型模塊化使得分布式代碼開發(fā)、測試和重用以及快速系統(tǒng)設計與集成、維護和演化更加便利。 體系結構類型 ? 從體系結構設計的立場看，每一種類型表述了一個特有問題。 體系結構類型 – 科學 ——用于科學研究和應用的系統(tǒng)。 – 醫(yī)療 ——診斷或治療，或者有助于醫(yī)學研究的系統(tǒng)。 – 游戲 ——為個人或群體提供娛樂體驗的系統(tǒng)。 – 內(nèi)容創(chuàng)作 ——用來創(chuàng)建或管理文字或多媒體人造物品的系統(tǒng)。每種風格的結構可以用一組可預測模式進行描述。在體系結構設計環(huán)境中，“類型”隱含了在整個軟件領域中的一個特定類別。 體系結構視圖 ? 大多數(shù)系統(tǒng)是不值得開發(fā)一個詳細的體系結構描述的。 ADL語言的基本要素是組件和連接器，這類語言包含了形成規(guī)范化體系結構所應該使用的規(guī)則和指南。 ? 關于軟件體系結構是否應該使用 UML來描述有不同的看法。體系結構模型描述了這些組件以及它們之間的關聯(lián)。概念視圖是系統(tǒng)的抽象視圖，它可以作為把高層次需求分解為詳細描述的基礎，來幫助工程師在可復用的組件、表現(xiàn)產(chǎn)品線而不是單獨的系統(tǒng)等方面做出決策。 – 4）物理視圖。這種視圖對非功能系統(tǒng)特征的判斷非常有效，比如性能和可用性。顯示了系統(tǒng)中對象和對象類的一些主要抽象。軟件工程師可以在給定的體系結構類型中使用許多種不同的體系結構風格和模式，每個模式描述了一個系統(tǒng)類別，它包含：一組完成系統(tǒng)所需功能的構件；一組使構件間通信、協(xié)調(diào)及合作的連接件；定義如何集成構件以構成系統(tǒng)的約束條件；使設計者能夠理解系統(tǒng)整體特性的語義模型。軟件體系結構與設計 浙江大學城市學院 周蘇 教授 ： 81505050 第 6章 體系結構的模式與結構 第 6章 體系結構的模式與結構 ? 軟件工程中的設計 ? 設計過程 ? 關注點分離 ? 關于設計的概念 ? 設計模型 ? 在工程領域中，基于模式和設計風格的開發(fā)方式使用得非常普遍。系統(tǒng)的性質，比如性能、信息安全性和可用性，都受到所使用體系結構的影響。 體系結構視圖 ? 4種基礎的體系結構視圖是： – 1）邏輯視圖。顯示了在運行時系統(tǒng)是如何組織為一組交互的進程。這種視圖主要用于軟件的管理者和程序員。 體系結構視圖 ? 在使用類似視圖的基礎上還要添加概念視圖。 圖 61 打包機器人控制系統(tǒng)的體系結構 打 包 選 擇系 統(tǒng)打 包 系 統(tǒng) 傳 送 帶 控 制 器手 臂 控 制 器 機 械 爪 控 制 器對 象 識 別系 統(tǒng)視 覺 系 統(tǒng) 體系結構視圖 ? 這個機器人系統(tǒng)能夠對不同類型的對象進行打包，它使用一個視覺子系統(tǒng)來拾取傳送帶上的對象，識別對象類型并選擇正確的打包方式，然后從傳送帶上移下對象、打包，最后將其送到另一個傳送帶上。在設計過程中，當討論系統(tǒng)的不同方面時也可能會形成一些其他的視圖，但是包含各個角度的完全描述是沒有必要的。 體系結構視圖 ? 還可以使用專門的體系結構描述語言（ ADL）來描述系統(tǒng)體系結構。盡管如此，像 UML這種非正式的模型和符號系統(tǒng)是文檔化系統(tǒng)體系結構最普遍使用的方法。 體系結構類型 ? 盡管體系結構設計的基本原則適用于所有類型（也稱為應用領域）的體系結構，但對于需要構建的結構，體系結構類型經(jīng)常規(guī)定特定的體系結構方法。在每種一般風格中，也會運用更多的具體風格，即結構。 – 通信 ——用于數(shù)據(jù)傳輸和數(shù)據(jù)管理、數(shù)據(jù)的用戶連接或者數(shù)據(jù)展示的基礎設施的系統(tǒng)。 體系結構類型 – 金融 ——為轉賬和理財以及其他安全事務提供基礎設施的系統(tǒng)。 – 法律 ——支持法律的系統(tǒng)。 – 平臺 ——位于操作系統(tǒng)之上提供高級服務的系統(tǒng)。 – 實用程序 ——與其他軟件交互作用的系統(tǒng)，可以提供某些有意義的服務。SAI的目標是為算法的分布式實施和容易地將其集成到復雜系統(tǒng)提供通用框架 …… 底層可擴展數(shù)據(jù)模型和混合（共享存儲和信息傳遞）分布式異步并行處理模型允許自然和有效地處理一般數(shù)據(jù)流，并可以使用已有的庫或本地代碼。在許多基于 Web的系統(tǒng)中，這種模式是交互管理的基礎。 圖 62 MVC模式的組成 控 制 器 映 射 用 戶 的 動 作 到 模 型 更 新 操 作 選 擇 視 圖視 圖 繪 制 模 型 請 求 模 型 更 新 發(fā) 送 用 戶 事 件 給 控 制 器視 圖 選 擇用 戶 事 件模 型 封 裝 應 用 狀 態(tài) 通 知 視 圖 狀 態(tài) 已 變 更狀 態(tài) 查 詢變 更 通 知狀 態(tài) 變 更圖 63 采用 MVC模式的 Web應用體系結構 控 制 器 H T T P 請 求 處 理 特 定 于 應 用 的 邏 輯 數(shù) 據(jù) 有 效 性 驗 證視 圖 動 態(tài) 頁 面 生 成 表 單 管 理要 顯 示 的 表 單用 戶 事 件模 型 業(yè) 務 邏 輯 數(shù) 據(jù) 庫刷 新 請 求變 更 通 知更 新 請 求瀏 覽 器 體系結構的風格與模式 ? 作為一種表示、共享和復用軟件系統(tǒng)知識的方法 ——模式的思想，已經(jīng)得到廣泛的應用，例如面向對象設計模式、機構設計模式、可用性模式、交互模式、配置管理模式等。通常，體系結構風格獨立于實際問題，強調(diào)了軟件系統(tǒng)中通用的組織結構，比如管道線，分層系統(tǒng)，客戶機 服務器等等，體系結構風格以這些組織結構定義了一類系統(tǒng)族。體系結構模式還應該包括：這種模式什么時候適用，什么時候不適用，以及這種模式的優(yōu)點和缺點等。 風格與模式 ? 體