1、一. 軟件體系結構(架構) 軟件體系結構的定義通常，軟件體系結構通常被稱為架構，指可以預制和可重構的軟件框架結構。架 構尚處在發展期，對于其定義，學術界尚未形成一個統一的意見，而不同角度的 視點也會造成軟件體系結構的不同理解。比如，ansi/ieee 610. 12-1990軟件工 程標準詞匯對于體系結構定義是“體系架構是以構件、構件之間的關系、構件與 環境之間的關系為內容的某一系統的基本組織結構以及知道上述內容設計與演 化的原理(principle) v ；而garlan & shaw模型的基本思想是：軟件體系結構 二構件(component),連接件(connector),約束(c

2、onstrain)。對于軟 件項目的開發來說，一個清晰的軟件體系結構是首要的。傳統的軟件開 發過程可以劃分為從概念到實現的若干個階段，包括問題定義、需求分析、軟件 設計、軟件實現及軟件測試等。軟件體系結構的建立就位于需求分析之后，軟 件設計之前。在建立軟件體系結構時系統設計師主要從結構的角度對整個系統進 行分析，選擇恰當的構件(component) 構件間的相互作用以及它們的約束， 最后形成一個系統框架(fzmework)以滿足用戶的需求，為軟件設計奠定基礎。 軟件體系結構風格軟件體系結構設計的一個核心問題是能否使用重復的體系結構模式，即能否達到 結構級的軟件重用。也就是說，能否在不同的軟件體

3、系中，使用同一體系結構。 基于這個目的，學者們開始研究和實踐軟件體系結構的風格問題。軟件體系結構風格(software architecture style)是描述某一特定應用領域 系統組織方式的慣用模式。它反映了領域中眾多系統所有的結構和語義特性，并 指導如何將各個模塊和子系統有效地組織成一個完整的系統。對軟件體系結構 風格的研究和實踐促進了對設計的復用，一些經過實踐證明的解決方案也可以可 靠地用于解決新的問題。體系結構風格的不變部分使不同的系統可以共享一個 實現代碼。只要系統是使用常用的、規范的方法來組織，就可使別的設計者很容 易地理解系統結構。garlan和shaw對通用體系結構風格進行

4、如下分類：(1) 數據流風格：批處理序列、管道/過濾器等；(2) 調用/返冋風格：主程序/子程序、面向對象風格、層次結構等。(3) 獨立構件風格：進程通訊、事件系統等；(4) 虛擬機風格：解釋器、基于規則的系統等；(5) 倉庫風格：數據庫系統、超文本系統、黑板系統等。近年來，出現了許多新的體系結構風格，例如客戶/服務器(client /server) 結構、瀏覽器/服務器(browser/server)結構、正交(orthogonal)結構、三 層c/s結構等。軟件體系結構的建模研究研究軟件體系結構的首要問題是如何表示軟件體系結構，即如何對軟件體系結構 建模。根據建模的側重點的不同，可以將軟件

5、體系結構的模型分為5種：結構模 型、框架模型、動態模型、過程模型和功能模型。其中，最常用的是結構模型和 動態模型。研究熱點當前本系結構仍是一個非常新的研究領域，其概念還相當模糊。但軟件體系結 構作為軟件工程領域屮的一個組成部分，已經取得了長足的發展，受到大多數軟 件系統設計和研究人員的重視。軟件體系結構目前較活躍的研究方向包括：(1)軟件體系結構形式基礎的研究;(2)針對軟件體系結構描述中特有的問題研究新的專門的高級語言；(3)建立 用于度量和評價軟件體系結構的模型和方法；(4)建立面向專門領域的軟件體 系結構范型庫。(5)把軟件體系結構從冃前的直覺和經驗狀態過渡到理論。二. 模式模 式(pa

6、ttern)的概念最早由建筑大師christopher alexander于二十世紀七 十年代提出，應用于建筑領域，八十年代中期由ward cunningham 11 kent beck 將其思想引入到軟件領域，christopher alexander將模式分為三個部分：(1) 周境(context,也可以稱著上下文)，指模式在何種狀況下發生作用；(2) 動機(system of forces)，意指問題或預期的目標;(3) 解決方案(solution)，指平衡各動機或解決所闡述問題的一個構造或配置 (configuration)。他提出，模式是表示周境、動機、解決方案三個方面關系的一個規則

7、，每個模 式描述了一個在某種周境下不斷重復發生的問題，以及該問題解決方案的核心所 在，模式 即是一個事物(thing)又是一個過程(process),不僅描述該事物本 身，而且提出了通過怎樣的過程來產生該事物。這一定義已被軟件界廣為接受。 軟件模式的應用對軟件開發產生了重大的作用，主要表現在：(1)軟件模式是人們在長期的設計軟件、管理組織軟件開發等實踐中大量經驗 的提煉和抽彖，是復用軟件設計方法、過程管理經驗的有力工具。模式類似于拳 擊屮的組合拳，它提供了一系列軟件開發屮的思維套路。如，通過模式的使用， 有利于在復雜的系統屮產生簡潔、精巧的設計。(2)軟件模式為我們提供了一套簡潔通用的設計、管

8、理、組織方面的詞匯，同吋 模式也為我們提供了一個描述抽象事物的規范標準，可大大促進軟件開發過程中 人與人之間的交流，而軟件開發中的交流是至關重要的，“軟件項目失敗的原 因最終都可追溯到信息沒有及時準確地傳遞到應該接收它的人”。三. 架構和模式的關系架構(architecture)和模式(pattern)在當前的軟件開發中經常地被提及，這兩 個術語非常容易混淆，而且學術界也沒有一個非常統一的定義。架構和模式應該是一個屬于相互涵蓋的過程，但是總體來說architecture更加 關注的是所謂的high-level design,而模式關注的重點在于通過經驗提取的“準則或指導方案”在設計中的應用，因

9、此在不同層面考慮問題的時候就形成了 不同問題域上的pattern。模式的目標是，把共通問題中的不變部分和變化部分 分離出來。不變的部分，就構成了模式，因此，模式是一個經驗提取的“準則”， 并且在一次一次的實踐屮得到驗證，在不同的層次有不同的模式，小到語言實 現(如singleton)大到架構。在不同的層面上，模式提供不同層面的指導。根據 處理問題的粒度不同，從高到低，模式分為3個層次：(1)架構模式(architectural pattern) > 設計模式(design pattern) > 實現模 式(implementation pattern).架構模式是模式中的最高層次，

10、描述軟件系統里 的基本的結構組織或綱要，通常提供一組事先定義好的子系統，指定它們的責任, 并給出把它們 組織在一起的法則和指南。比如，用戶和文件系統安全策略模型， n-層結構，組件對彖服務等，我們熟知的mvc結構也屬于架構模式的層次。一個 架構模式常常可以分解成很多個設計模式的聯合使用。（2）設計模式是模式屮的第二層次，用來處理程序設計屮反復出現的問題。例如，設計模式一可復用面向對象軟件的基礎一書屮總結的23個基本設計模 式factory pat tern, observer patt ern 等。（3）實現模式是最低也是最具體的層次，處理具體到編程語言的問題。比如， 類名，變量名，函數名的命名規則；異常處理的規則等等。相 對于系統分析或者設計模式來說，體系結構從更高的層而去考慮問題，所以 關注的問題就體現在“不變”因素上，比如系統部署中，更加關心應用程序的分 層分級設計，而在這個基礎之上提出的部署方案，才是架構考慮的重點。體系 結構關心應用程序模式，更加體現在通過技術去解決這些業務差異帶來的影響， 關心是否是分布式應用程序，關心系統分層是如何設計，也關心性能和安全， 因此在這樣的情況之下，會考慮集群，負載平衡，故障遷移等等一系列技術。 總之，希望通過定義的方式來區分架構和模式是不太可能的，因為本來就是交 互交叉和提供服務的，它實際上是架構模式，而不是設計模式。在大部