軟件架構:指導軟件系統各個方面的設計-中文百科頻道

曆史

早在1960年代，諸如E·W·戴克斯特拉就已經涉及軟件架構這個概念了。自1990年代以來，部分由于在 Rational Software Corporation 和Microsoft内部的相關活動，軟件架構這個概念開始越來越流行起來。

卡内基梅隆大學和加州大學埃爾文分校在這個領域作了很多研究。卡内基·梅隆大學的Mary Shaw和David Garlan于1996年寫了一本叫做 Software Architecture perspective on an emerging DIscipline的書，提出了軟件架構中的很多概念，例如軟件組件、連接器、風格等等。加州大學埃爾文分校的軟件研究院所做的工作則主要集中于架構風格、架構描述語言以及動态架構。

計算機軟件的曆史開始于五十年代，曆史非常短暫，而相比之下建築工程則從石器時代就開始了，人類在幾千年的建築設計實踐中積累了大量的經驗和教訓。建築設計基本上包含兩點，一是建築風格，二是建築模式。獨特的建築風格和恰當選擇的建築模式，可以使得一個建築獨一無二。

軟件與人類的關系是架構師必須面對的核心問題，也是自從軟件進入曆史舞台之後就出現的問題。與此類似地，自從有了建築以來，建築與人類的關系就一直是建築設計師必須面對的核心問題。英國首相丘吉爾說，我們構造建築物，然後建築物構造我們（We shape our buildings, and afterwaRDS our buildings shape us）。英國下議院的會議廳較狹窄，無法使所有的下議院議員面向同一個方向入座，而必須分成兩側入座。丘吉爾認為，議員們入座的時候自然會選擇與自己政見相同的人同時入座，而這就是英國政黨制的起源。Party這個詞的原意就是"方"、"面"。政黨起源的關鍵就是建築物對人的影響。

在軟件設計界曾經有很多人認為功能是最為重要的，形式必須服從功能。與此類似地，在建築學界，現代主義建築流派的開創人之一Louis Sullivan也認為形式應當服從于功能（FORMs follows function）。

幾乎所有的軟件設計理念都可以在浩如煙海的建築學曆史中找到更為遙遠的曆史回響。最為著名的，當然就是模式理論和XP理論。

架構的種類

根據我們關注的角度不同，可以将架構分成三種：

·邏輯架構。軟件系統中元件之間的關系，比如用戶界面，數據庫，外部系統接口，商業邏輯元件，等等。

比如下面就是筆者親身經曆過的一個軟件系統的邏輯架構圖

圖2、一個邏輯架構的例子

從上面這張圖中可以看出，此系統被劃分成三個邏輯層次，即表象層次，商業層次和數據持久層次。每一個層次都含有多個邏輯元件。比如WEB服務器層次中有HTML服務元件、Session服務元件、安全服務元件、系統管理元件等。

·物理架構。軟件元件是怎樣放到硬件上的。

比如下面這張物理架構圖描述了一個分布于北京和上海的分布式系統的物理架構，圖中所有的元件都是物理設備，包括網絡分流器、代理服務器、WEB服務器、應用服務器、報表服務器、整合服務器、存儲服務器、主機等等。

·系統架構。系統的非功能性特征，如可擴展性、可靠性、強壯性、靈活性、性能等。

系統架構的設計要求架構師具備軟件和硬件的功能和性能的過硬知識，這一工作無疑是架構設計工作中最為困難的工作。

此外，從每一個角度上看，都可以看到架構的兩要素：元件劃分和設計決定。

首先，一個軟件系統中的元件首先是邏輯元件。這些邏輯元件如何放到硬件上，以及這些元件如何為整個系統的可擴展性、可靠性、強壯性、靈活性、性能等做出貢獻，是非常重要的信息。

其次，進行軟件設計需要做出的決定中，必然會包括邏輯結構、物理結構，以及它們如何影響到系統的所有非功能性特征。這些決定中會有很多是一旦作出，就很難更改的。

根據作者的經驗，一個基于數據庫的系統架構，有多少個數據表，就會有多少頁的架構設計文檔。比如一個中等的數據庫應用系統通常含有一百個左右的數據表，這樣的一個系統設計通常需要有一百頁左右的架構設計文檔。

視圖

我們決定以多種構架視圖來表示軟件構架。每種構架視圖針對于開發流程中的涉衆（例如最終用戶、設計人員、管理人員、系統工程師、維護人員等）所關注的特定方面。

構架視圖顯示了軟件構架如何分解為構件，以及構件如何由連接器連接來産生有用的形式 [PW92]，由此記錄主要的結構設計決策。這些設計決策必須基于需求以及功能、補充和其他方面的約束。而這些決策又會在較低層次上為需求和将來的設計決策施加進一步的約束。

構架由許多不同的構架視圖來表示，這些視圖本質上是以圖形方式來摘要說明“在構架方面具有重要意義”的模型元素。在 Rational Unified Process 中，您将從一個典型的視圖集開始，該視圖集稱為“4+1 視圖模型”[KRU95]。它包括：

用例視圖：包括用例和場景，這些用例和場景包括在構架方面具有重要意義的行為、類或技術風險。它是用例模型的子集。

邏輯視圖：包括最重要的設計類、從這些設計類到包和子系統的組織形式，以及從這些包和子系統到層的組織形式。它還包括一些用例實現。它是設計模型的子集。

實施視圖：包括實施模型及其從模塊到包和層的組織形式的概覽。同時還描述了将邏輯視圖中的包和類向實施視圖中的包和模塊分配的情況。它是實施模型的子集。

進程視圖：包括所涉及任務（進程和線程）的描述，它們的交互和配置，以及将設計對象和類向任務的分配情況。隻有在系統具有很高程度的并行時，才需要該視圖。在 Rational Unified Process 中，它是設計模型的子集。

配置視圖：包括對最典型的平台配置的各種物理節點的描述以及将任務（來自進程視圖）向物理節點分配的情況。隻有在分布式系統中才需要該視圖。它是部署模型的一個子集。構架視圖記錄在軟件構架文檔中。

您可以構建其他視圖來表達需要特别關注的不同方面：用戶界面視圖、安全視圖、數據視圖等等。對于簡單系統，可以省略 4+1 視圖模型中的一些視圖。

重點

雖然以上視圖可以表示系統的整體設計，但構架隻同以下幾個具體方面相關：

模型的結構，即組織模式，例如分層。基本元素，即關鍵用例、主類、常用機制等，它們與模型中的各元素相對。幾個關鍵場景，它們表示了整個系統的主要控制流程。記錄模塊度、可選特征、産品線狀況的服務。

構架視圖在本質上是整體設計的抽象或簡化，它們通過舍棄具體細節來突出重要的特征。在考慮以下方面時，這些特征非常重要。

系統演進，即進入下一個開發周期。在産品線環境下複用構架或構架的一部分。評估補充質量，例如性能、可用性、可移植性和安全性。向團隊或分包商分配開發工作。決定是否包括市售構件。插入範圍更廣的系統。

形式

構架模式

構架模式是解決複雜構架問題的現成形式。構架框架或構架基礎設施（中間件）是可以在其上構建某種構架的構件集。許多主要的構架困難應在框架或基礎設施中進行解決，而且通常針對于特定的領域：命令和控制、MIS、控制系統等等。

模式示例

[BUS96] 根據構架模式最适用的系統的特征将其分類，其中一個類别處理更普遍的結構問題。下表顯示了 [BUS96] 中所提供的類别和這些類别所包含的模式。

類别模式結構層管道和過濾器黑闆分布式系統代理交互系統模型-視圖-控制器表示-抽象-控制自适應系統反射微核

在“軟件構架簡介”中，David Garlan 和 Mary Shaw 認為軟件構架是有關如下問題的設計層次：“在計算的算法和數據結構之外，設計并确定系統整體結構成為了新的問題。結構問題包括總體組織結構和全局控制結構；通信、同步和數據訪問的協議；設計元素的功能分配；物理分布；設計元素的組成；定标與性能；備選設計的選擇。”[GS93]

但構架不僅是結構；IEEE Working Group on Architecture 把其定義為“系統在其環境中的最高層概念”[IEEE98]。構架還包括“符合”系統完整性、經濟約束條件、審美需求和樣式。它并不僅注重對内部的考慮，而且還在系統的用戶環境和開發環境中對系統進行整體考慮，即同時注重對外部的考慮。

在 Rational Unified Process 中，軟件系統的構架（在某一給定點）是指系統重要構件的組織或結構，這些重要構件通過接口與不斷減小的構件與接口所組成的構件進行交互。

為闡明其含義，下面将詳述其中的兩個；完整說明請參見 [BUS96]。模式以下列廣泛使用的形式來表示：

模式名環境問題影響，描述應考慮的不同問題方面解決方案基本原理結果環境示例模式名層

環境需要進行結構分解的大系統。

問題必須處理不同抽象層次的問題的系統。例如：硬件控制問題、常見服務問題和針對于不同領域的問題。最好不要編寫垂直構件來處理所有抽象層次的問題。否則要在不同的構件中多次處理相同的問題（可能會不一緻）。

影響

系統的某些部分應當是可替換的構件中的變化不應波動相似的責任應歸為一組構件大小 -- 複雜構件可能要進行分解解決辦法将系統分成構件組，并使構件組形成層疊結構。使上層隻使用下層（決不使用上層）提供的服務。盡量不使用非緊鄰下層提供的服務（不跳層使用服務，除非中間層隻添加通過構件）。

示例：

1. 通用層

嚴格的分層構架規定設計元素（類、構件、包、子系統）隻能使用下層提供的服務，服務可以包括事件處理、錯誤處理、數據庫訪問等等。相對于記錄在底層的原始操作系統級調用，它包括更明顯的機制。

2. 業務系統層

上圖顯示了另一個分層示例，其中有垂直特定應用層、水平層和基礎設施層。注意：此處的目标是采用非常短的業務“煙囪”并實現各種應用程序間的通用性。否則，就可能有多個人解決同一問題，從而導緻潛在的分歧。

有關該模式的深入讨論，請參見指南：分層。

模式名黑闆

環境沒有解決問題的确定方法（算法）或方法不可行的領域。例如 AI 系統、語音識别和監視系統。

問題多個問題解決顧問（知識顧問）必須通過協作來解決他們無法單獨解決的問題。各顧問的工作結果必須可以供所有其他顧問訪問，使他們可以評估自己是否可以參與解決方案的查找并發布其工作結果。

影響

知識顧問參與解決問題的順序不是确定的，這可能取決于問題解決策略

不同顧問的輸入（結果或部分解決方案）可能有不同的表示方式

各顧問并不直接知道對方的存在，但可以評估對方發布的工作

解決辦法多名知識顧問都可訪問一個稱為“黑闆”的共享數據庫。黑闆提供監測和更新其内容的接口。控制模塊/對象激活遵循某種策略的顧問。激活後，顧問查看黑闆，以确定它是否能參與解決問題。如果顧問決定它可以參與，控制對象就可以允許顧問将其部分（或最終）解決方案放置于黑闆上。

示例：

以上顯示了使用 UML 建模的結構或靜态視圖。它将成為參數化協作的一部分，然後會綁定到實參上對模式進行實例化。

構架風格軟件構架（或僅是構架視圖）可以具有名為構架風格的屬性，該屬性減少了可選的形式，并使構架具有一定程度的一緻性。樣式可以通過一組模式或通過選擇特定構件或連接器作為基本構件來定義。對給定系統，某些樣式可作為構架描述的一部分記錄在構架風格指南（Rational Unified Process 中設計指南文檔的一部分）中。樣式在構架的可理解性與完整性方面起着主要的作用。

邏輯視圖：類圖、狀态機和對象圖。進程視圖：類圖與對象圖（包括任務 - 進程與線程）。實施視圖：構件圖。部署視圖：配置圖。

技巧

1. 單一的目标：Amundsen唯一的目标就是以最快的速度抵達目标，而Scott則要兼顧科學研究。

對于Scott來說，科學研究這個使命甚至優于資源與人員配備。而Amundsen的所有目的都是赢得比賽，還有平安歸來。

想比之下Scott的雙重目标存在很多矛盾。不錯，那時确實不乏悠久的帆船科學研究曆史（比如達爾文），然而達爾文并不是進行比賽，他們的船很大，同時科學研究隻是附加目标，而環境也遠沒有南極那麼惡劣及荒無人煙。

Fred Wilson在談專注的力量時經常引Steve Jobs為例——“我們專注于打造一個适合所有場景電腦的生産線，然後逐漸關閉其它的生産線”。專注是類似Minimal Viable Products及 time box scheduling産品背後的原動力，Amundsen專注在比賽上，所以一切策略都以這個為目标展開。

2. 使用簡單，已被驗證的技術。比賽中最難以接受的就是Scott的計劃選擇了一組複雜且未經驗證的運輸技術。

Amundsen的計劃是簡單的，他們選用狗拉雪橇；而在那時，狗拉雪橇的這個技術無疑是得到論證的，因此奇怪的應該是不選用狗的人。

然而在早先的旅行中Scott對狗有着非常不好的體驗，所以他并未選用這個運輸途徑。取而代之的是，Scott選用了motor-sledge，這是機動雪橇的早期版本。在那個時候，這還是個試驗中的技術，最終3架motor-sledge都在途中損壞。然而當下的問題不是讨論他們為什麼有那麼差的體驗，而土著人民卻非常善于用狗，而是缺乏對事物的詳細了解并往下定論。

小馬的任務是搬運補給，但是很小的蹄子讓其不能勝任工作，因為它很容易受到潮濕和冰凍的侵害。9匹小馬在旅行開始時就失去了作用，然而馬和motor-sledge的補給隻能儲存在船上。對比而言，狗無疑更适應戰場，它們可以吃南極洲捕獲的企鵝和海豹肉。

使用人力拉沉重的雪橇，本來隻作為應急，但是馬和motor-sledge的缺失讓這個方案執行了3/4的旅途。而雪橇還在不停變重，因為沿途他們不得不收集一些岩石以作科學研究。這樣，問題就在于他們根本沒有足夠的食物以支撐整個過程。他們并不清楚，一天吃4000卡路裡的他們卻需要消耗6000到10000卡路裡的能量。

3. 定制、測試、重複。Amundsen的計劃很周密，不留任何漏洞。當他發現設備達不到需求時，會自己動手，他親自做了防風鏡、滑雪闆、犬繩及肉幹。這種自力更生正是開發者需要具備的品質：

所有Amundsen的工具都出自自己的工坊，并經過一次又一次的提煉。Amundsen在制造工具時使用了兩個信條：第一，遠甚于批量生産的設備；第二，參與制造，可以确保設備在比賽中的表現。

4. 冷靜且無情的。捕獲焦點，必須具備認知重點的能力，隻做必要的事情。

Walter Sullivan在The South Pole Fifty Years After使用另一個方式完美的闡述了這個道理：

登月通過一連串的火箭完成，而在這個過程中這些火箭被逐一抛棄；那個挪威人使用了同樣的策略，在旅途中不斷抛棄虛弱的動物，并且作為其它動物和人的食物。

5. 靈活的。Amundsen原計劃是去北極，但是在聽說兩個美國人已經抵達北極後，果斷的将目标轉向了南極，以獲取世界第一這個獎勵。

6. 從實際出發。Scott使用人拉雪橇不僅僅是為了運輸，更加入了一種浪漫主義風格。Scott日記的背後甚至反射出Wagner的身影：

在我的記憶中，沒有任何與狗有關的探險可以達到這樣的高度——人們直面險阻，并用自己的雙手達到目的……無可否認的是，在這種情況下，征服才是更高貴、更華麗的勝利。

7. 技巧讓一切都變得不同。Amundsen招募了多個經驗老道的滑雪人并組成團隊，相比，Scott的隊伍無疑都是一些門外漢，并未針對需求進行訓練。

8. 選擇正确的團隊。Scott的團隊有許多來自英國的紳士，而Amundsen則選擇了一些具有戶外經驗并有不同技能的工匠。

9. 錯誤的疊加。Scott的團隊注定無法赢得比賽，然而他們的死亡卻是由一系列的錯誤疊加引起。天氣比預期的更冷，這樣導緻他們返程時在預定時間并未到達下一個補給點，補給點存放了食物、燃料及其他物資。當Scott、Wilson和Bowers三人死亡時，離下一個補給點僅11英裡遠。馬、motor-sledge及一個錯誤的補給點判斷，讓下一個補給點離他們遙遙無期。悲劇的鑄成絕不因一個錯誤，而是由一系列錯誤疊加形成。

10. 後見之明。在事情開始時沒有什麼是清晰可見的，然而在結果産生時一切都已塵埃落定。Scott在開始時做了他認為最合适的決策，而其它人也同意他的觀點。每一個項目也是如此，沒有人會愚蠢到從開始就放棄；然而通往成功的路徑總是很少，并且沿途充滿了太多的岔路。所以我們有必要去吸取一些成功的經驗，多了解一些最佳實踐。

憶往昔，不難發現成功的團隊總是具備一些共同的特性：規模小、良好的引導、專注、高技巧及具備豐富的經驗，同時他們還有着健壯的計劃、豐富的資源以及強大的戰場适應能力。