軟體架構（software architecture）

軟體架構（software architecture）是一系列相關的抽象模式，用於指導大型軟體系統各個方面的設計。軟體架構是一個系統的草圖。軟體架構描述的物件是直接構成系統的抽象元件。各個元件之間的連線則明確和相對細緻地描述元件之間的通訊。在實現階段，這些抽象元件被細化為實際的元件，比如具體某個類或者物件。在面向物件領域中，元件之間的連線通常用介面_（電腦科學）來實現。

軟體體系結構是構建計算機軟體實踐的基礎。與建築師設定建築專案的設計原則和目標，作為繪圖員畫圖的基礎一樣，一個軟體架構師或者系統架構師陳述軟體構架以作為滿足不同客戶需求的實際系統設計方案的基礎。從和目的、主題、材料和結構的聯絡上來說，軟體架構可以和建築物的架構相比擬。一個軟體架構師需要有廣泛的軟體理論知識和相應的經驗來實施和管理軟體產品的高階設計。軟體架構師定義和設計軟體的模組化，模組之間的互動，使用者介面風格，對外介面方法，創新的設計特性，以及高層事物的物件操作、邏輯和流程。

架構是在元件，彼此間和與環境間的關係，引導設計發展原則中體現的系統的基本結構。

軟體體系結構是構建計算機軟體實踐的基礎。與建築師設定建築專案的設計原則和目標，作為繪圖員畫圖的基礎一樣，一個軟體架構師或者系統架構師陳述軟體構架以作為滿足不同客戶需求的實際系統設計方案的基礎。

軟體構架是一個容易理解的概念，多數工程師（尤其是經驗不多的工程師）會從直覺上來認識它，但要給出精確的定義很困難。特別是，很難明確地區分設計和構架：構架屬於設計的一方面，它集中於某些具體的特徵。

軟體架構是指在一定的設計原則基礎上，從不同角度對組成系統的各部分進行搭配和安排，形成系統的多個結構而組成架構，它包括該系統的各個元件，元件的外部可見屬性及元件之間的相互關係。元件的外部可見屬性是指其他元件對該元件所做的假設。

在“軟體構架簡介”中，David GArlan和 Mary Shaw認為軟體構架是有關如下問題的設計層次：“在計算的演算法和資料結構之外，設計並確定系統整體結構成為了新的問題。結構問題包括總體組織結構和全域性控制結構；通訊、同步和資料訪問的協議；設計元素的功能分配；物理分佈；設計元素的組成；定標與效能；備選設計的選擇。”

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

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

從和目的、主題、材料和結構的聯絡上來說，軟體架構可以和建築物的架構相比擬。一個軟體架構師需要有廣泛的軟體理論知識和相應的經驗來實施和管理軟體產品的高階設計。軟體架構師定義和設計軟體的模組化，模組之間的互動，使用者介面風格，對外介面方法，創新的設計特性，以及高層事物的物件操作、邏輯和流程。

一般而言，軟體系統的架構（ArchitECture）有兩個要素：

1.它是一個軟體系統從整體到部分的最高層次的劃分。

2.一個系統通常是由元件組成的，而這些元件如何形成、相互之間如何發生作用，則是關於這個系統本身結構的重要資訊。

詳細地說，就是要包括架構元件（Architecture Component）、聯結器（Connector）、任務流（TASk-flow）。所謂架構元素，也就是組成系統的核心"磚瓦"，而聯結器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結果，任務流則描述系統如何使用這些元件和聯結器完成某一項需求。

建造一個系統所作出的最高層次的、以後難以更改的，商業的和技術的決定。

在建造一個系統之前會有很多的重要決定需要事先作出，而一旦系統開始進行詳細設計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關係統設計成敗的最重要決定，必須經過非常慎重的研究和考察。

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

1.邏輯架構

軟體系統中元件之間的關係，比如使用者介面，資料庫，外部系統介面，商業邏輯元件，等等。

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

2.物理架構

軟體元件是怎樣放到硬體上的。

比如下面這張物理架構圖，圖中所有的元件都是物理裝置，包括網路分流器、代理伺服器、WEB伺服器、應用伺服器、報表伺服器、整合伺服器、儲存伺服器、主機等等。

3.系統架構

系統的非功能性特徵，如可擴充套件性、可靠性、強壯性、靈活性、效能等。

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

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

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

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

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

我們決定以多種構架檢視來表示軟體構架。每種構架檢視針對於開發流程中的涉眾（例如終端使用者、設計人員、管理人員、系統工程師、維護人員等）所關注的特定方面。

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

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

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

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

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

4.程序檢視：包括所涉及任務（程序和執行緒）的描述，它們的互動和配置，以及將設計物件和類向任務的分配情況。只有在系統具有很高程度的並行時，才需要該檢視。在 Rational Unified Process 中，它是設計模型的子集。

5.部署檢視：包括對最典型的平臺配置的各種物理節點的描述以及將任務（來自程序檢視）向物理節點分配的情況。只有在分散式系統中才需要該檢視。它是部署模型的一個子集。構架檢視記錄在軟體構架文件中。您可以構建其他檢視來表達需要特別關注的不同方面：使用者介面檢視、安全檢視、資料檢視等等。對於簡單系統，可以省略 4+1 檢視模型中的一些檢視。

早在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理論。

正如同軟體本身有其要達到的目標一樣，架構設計要達到的目標是什麼呢？一般而言，軟體架構設計要達到如下的目標：

1.可靠性（Reliable）。軟體系統對於使用者的商業經營和管理來說極為重要，因此軟體系統必須非常可靠。

2.安全性（Secure）。軟體系統所承擔的交易的商業價值極高，系統的安全性非常重要。

3.可擴充套件性（SCAlable）。軟體必須能夠在使用者的使用率、使用者的數目增加很快的情況下，保持合理的效能。只有這樣，才能適應使用者的市場擴充套件得可能性。

4.可定製化（CuSTomizable）。同樣的一套軟體，可以根據客戶群的不同和市場需求的變化進行調整。

5.可擴充套件性（Extensible）。在新技術出現的時候，一個軟體系統應當允許匯入新技術，從而對現有系統進行功能和效能的擴充套件。

6.可維護性（MAIntainable）。軟體系統的維護包括兩方面，一是排除現有的錯誤，二是將新的軟體需求反映到現有系統中去。一個易於維護系統可以有效地降低技術支援的花費。

7.客戶體驗（Customer Experience）。軟體系統必須易於使用。

8.市場時機（Time to Market）。軟體使用者要面臨同業競爭，軟體提供商也要面臨同業競爭。以最快的速度爭奪市場先機非常重要。

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

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

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

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

構架模式是解決複雜構架問題的現成形式。構架框架或構架基礎設施（中介軟體）是可以在其上構建某種構架的構件集。許多主要的構架困難應在框架或基礎設施中進行解決，而且通常針對於特定的領域：命令和控制、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 中設計指南文件的一部分）中。樣式在構架的可理解性與完整性方面起著主要的作用。

邏輯檢視：類圖、狀態機和物件圖。程序檢視：類圖與物件圖（包括任務 - 程序與執行緒）。實施檢視：構件圖。部署檢視：配置圖。

架構描述語言(ADL)用於描述軟體的體系架構。已有多種架構描述語言，如Wright (由卡內基梅隆大學開發)，Acme (由卡內基梅隆大學開發)，C2 (由UCI開發)， Darwin (由倫敦帝國學院開發)。ADL的基本構成包括元件、聯結器和配置。

構架

構架檢視的圖形描述稱為構架設計圖。對於以上描述的各種檢視，設計圖由以下統一建模語言圖組成 [UML99]：

1.邏輯檢視：類圖、狀態機和物件圖。

2.程序檢視：類圖與物件圖（包括任務 - 程序與執行緒）。

3.實施檢視：構件圖。

4.部署檢視：配置圖。

5.用例檢視：用例圖描述用例、主角和普通設計類；順序圖描述設計物件及其協作關係。

構架設計流程

在 Rational Unified Process 中，構架主要是分析設計工作流程的結果。當專案再次進行此工作流程時，構架將在一次又一次迭代中不斷演化、改進、精煉。由於每次迭代都包括整合和測試，所以在交付產品時，構架就相當強壯了。構架是精化階段各次迭代的重點，構架的基線通常會在此階段結束時確定。

架構師

軟體設計師中有一些技術水平較高、經驗較為豐富的人，他們需要承擔軟體系統的架構設計，也就是需要設計系統的元件如何劃分、元件之間如何發生相互作用，以及系統中邏輯的、物理的、系統的重要決定的作出。

這樣的人就是所謂的架構師（Architect）。在很多公司中，架構師不是一個專門的和正式的職務。通常在一個開發小組中，最有經驗的程式設計師會負責一些架構方面的工作。在一個部門中，最有經驗的專案經理會負責一些架構方面的工作。

但是，越來越多的公司體會到架構工作的重要性，並且在不同的組織層次上設定專門的架構師位置，由他們負責不同層次上的邏輯架構、物理架構、系統架構的設計、配置、維護等工作。

軟體架構是對軟體系統執行時元素的抽象，軟體系統可能有很多層抽象，或由多重業務流程所組成，每層抽象或每個業務流程都有自己的軟體架構。

軟體架構是平衡的藝術。