架構:計算機術語-中文百科頻道

簡介

軟件架構各個組件之間的連接則明确和相對細緻地描述組件之間的通訊。在實現階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在面向對象領域中，組件之間的連接通常用接口(計算機科學)來實現。

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

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

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

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

從和目的、主題、材料和結構的聯系上來說，軟件架構可以和建築物的架構相比拟。一個軟件架構師需要有廣泛的軟件理論知識和相應的經驗來事實和管理軟件産品的高級設計。軟件架構師定義和設計軟件的模塊化，模塊之間的交互，用戶界面風格，對外接口方法，創新的設計特性，以及高層事物的對象操作、邏輯和流程。

是一般而言，軟件系統的架構（Architecture）有兩個要素：

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

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

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

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

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

曆史

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

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

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

下面的照片顯示了中美洲古代瑪雅建築，Chichen-Itza大金字塔，九個巨大的石級堆壘而上，九十一級台階（象征着四季的天數）奪路而出，塔頂的神殿聳入雲天。所有的數字都如日曆般嚴謹，風格雄渾。難以想象這是石器時代的建築物。

圖1、位于墨西哥Chichen-Itza（在瑪雅語中chi意為嘴chen意為井）的古瑪雅建築。（攝影：作者）

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

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

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

架構的目标

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

可靠性（Reliable）。軟件系統對于用戶的商業經營和管理來說極為重要，因此軟件系統必須非常可靠。

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

可擴展性（Scalable）。軟件必須能夠在用戶的使用率、用戶的數目增加很快的情況下，保持合理的性能。隻有這樣，才能适應用戶的市場擴展得可能性。

可定制化（Customizable）。同樣的一套軟件，可以根據客戶群的不同和市場需求的變化進行調整。

可伸縮（Extensible）。在新技術出現的時候，一個軟件系統應當允許導入新技術，從而對現有系統進行功能和性能的擴展

可維護性（Maintainable）。軟件系統的維護包括兩方面，一是排除現有的錯誤，二是将新的軟件需求反映到現有系統中去。一個易于維護的系統可以有效地降低技術支持的花費

客戶體驗（CustomerExperience）。軟件系統必須易于使用。

市場時機（TimetoMarket）。軟件用戶要面臨同業競争，軟件提供商也要面臨同業競争。以最快的速度争奪市場先機非常重要。

架構的種類

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

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

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

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

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

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

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

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

構架描述

為了讨論和分析軟件構架，必須首先定義構架表示方式，即描述構架重要方面的方式。在RationalUnifiedProcess中，軟件構架文檔記錄有這種描述。

構架視圖

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

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

典型的構架視圖集

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

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

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

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

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

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

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

軟件架構

簡介

（softwarearchitecture）是一系列相關的抽象模式，用于指導大型軟件系統各個方面的設計。軟件架構是一個系統的草圖。軟件架構描述的對象是直接構成系統的抽象組件。各個組件之間的連接則明确和相對細緻地描述組件之間的通訊。在實現階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在面向對象領域中，組件之間的連接通常用接口(計算機科學)來實現。軟件體系結構是構建計算機軟件實踐的基礎。與建築師設定建築項目的設計原則和目标，作為繪圖員畫圖的基礎一樣，一個軟件架構師或者系統架構師陳述軟件構架以作為滿足不同客戶需求的實際系統設計方案的基礎。

在“軟件構架簡介”中，DavidGarlan和MaryShaw認為軟件構架是有關如下問題的設計層次：“在計算的算法和數據結構之外，設計并确定系統整體結構成為了新的問題。結構問題包括總體組織結構和全局控制結構；通信、同步和數據訪問的協議；設計元素的功能分配；物理分布；設計元素的組成；定标與性能；備選設計的選擇。”【GS93】但構架不僅是結構；IEEEWorkingGrouponArchitecture把其定義為“系統在其環境中的最高層概念”【IEEE98】。構架還包括“符合”系統完整性、經濟約束條件、審美需求和樣式。它并不僅注重對内部的考慮，而且還在系統的用戶環境和開發環境中對系統進行整體考慮，即同時注重對外部的考慮。

構架重點

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

模型的結構，即組織模式，例如分層。

基本元素，即關鍵用例、主類、常用機制等，它們與模型中的各元素相對。

幾個關鍵場景，它們表示了整個系統的主要控制流程。

記錄模塊度、可選特征、産品線狀況的服務。

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

系統演進，即進入下一個開發周期。

在産品線環境下複用構架或構架的一部分。

評估補充質量，例如性能、可用性、可移植性和安全性。

向團隊或分包商分配開發工作。

決定是否包括市售構件。

插入範圍更廣的系統。

構架模式

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

構架模式示例

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

軟件構架是一個容易理解的概念，多數工程師（尤其是經驗不多的工程師）會從直覺上來??難明确地區分設計和構架：構架屬于設計的一方面，它集中于某些具體的特征。

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

為闡明其含義，下面将詳述其中的兩個；完整說明請參見【BUS96】。

模式以下列廣泛使用的形式來表示：

模式名

環境

問題

影響，描述應考慮的不同問題方面

解決方案

基本原理

結果環境

示例

模式名

層

環境

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

問題

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

影響

系統的某些部分應當是可替換的

構件中的變化不應波動

相似的責任應歸為一組

構件大小--複雜構件可能要進行分解

解決辦法

将系統分成構件組，并使構件組形成層疊結構。使上層隻使用下層（決不使用上層）提供的服務。盡量不使用非緊鄰下層提供的服務（不跳層使用服務，除非中間層隻添加通過構件）。

示例

1.通用層

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

2.業務系統層

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

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

模式名

環境

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

問題

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

影響

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

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

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

解決辦法

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

示例：

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

構架風格

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