高新企業為了生存，因此他們所依靠的軟件必須能提供其所需的功能；所需的高質量；所承諾的可用性，和可接受的價格。這篇文章的主題就是關于可以影響這些屬性的軟件架構。

我所關注的是“強軟件系統”，在 IEEE 中定義如下：

一個軟件集成系統就是軟件對于設計，構建，配置和整個系統的發展具有深入影響的系統 [ 來自 IEEE 1471 ， " 架構的定義 " 部分 ]

在本文中，“架構”與“軟件架構”是相同的含義。雖然這篇文章關注于軟件集成系統，但是應該注意，軟件集成系統仍然需要硬件來運行，并且諸如可靠性和性能等品質是通過軟硬件的結合實現的。所以解決方案中的硬件部分不能被忽略。文中后面將更詳細的討論這部分內容。

定義的架構

我們對于“架構”的定義沒有缺陷。甚至存在支持定義集的網站。 ¹ 文中的定義來自 IEEE 標準 1472000 ， IEEE 對強軟件系統的架構描述的推薦實踐，參見 IEEE 1471 。 ² 定義如下，其中重要部分用粗體字表示。

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

這些標準還定義了以下相關概念：

系統 是為實現某個（些）特殊作用的組件的集合。專用系統包括個人應用，傳統概念上的系統，子系統，系統中的系統，產品線，產品系列，整個企業和其他利益集團。一個系統是為了實現一個或多個任務而存在。 [IEEE 1471]

環境 決定了開發，操作，策略和其他影響系統的設置和條件。 [IEEE 1471]

任務 是指系統為了實現對對象設置的使用或操作。 [IEEE 1471]

涉眾 是對于系統有利益關系或關注的個人，團隊或組織。 [IEEE 1471]

正如我們所見，“組件”貫穿于這些定義。正如有意留下一個模糊的概念來解釋，大部分架構定義沒有提到“組件”， IEEE 1471 也不例外。組件也許是邏輯上的或物理存在的，技術上獨立的或特定的，規模大的或規模小的。由于文章的原因，我使用了 UML 2.0 規范的組件定義；并且我相當寬松的使用這個概念來包含各種所遇到的架構成分，包括了對象，技術組件（例如 Enterprise JavaBean ），服務，程序模塊，遺留系統，包應用程序等。這些是 UML 2.0 中對“組件”的定義：

[ 組件 ] 是包括內容的系統模型部分，且它的顯示是可替換的。組件定義了所需接口的行為。例如，組件類似類型 (type) ，它與所需接口行為一致。（包括靜態和動態語義） ³

這里的定義包括了多種不同的概念，文中后面將有更詳細的介紹。雖然工業界對于“架構”的概念沒有普遍的共識，但是有必要考慮一些其他的定義使得他們可以被遵照。參照一下下面的定義，重點處我已經用粗體表示。

架構 是對軟件系統組織，結構部分和系統包含接口的選擇，集合部分的特定行為，較大子系統部分的構成和架構風格的重大決定的設置。 [Kruchten]⁴

系統或計算系統的軟件架構是包含軟件部分，外部可見特性部分，和他們之間的關系的系統的結構。 [Bass et al.]⁵

[ 架構 ] 是系統的組織結構和相關行為。架構可被重復分解為通過接口，互聯部分的關系和結合部相互作用的部分。通過接口相互作用的部分包括類，組件和子系統。 [UML 1.5]⁶

軟件架構或系統由組成系統的結構的相互作用和軟件結構的重要設計決定組成。設計決定應成功實現所期望支持的質量。設計決定為系統開發，支持和維護提供概念上的基礎。 [McGovern]⁷

雖然在某些方面定義有些區別，但我們可以看到大部分是相同的。例如，大部分定義都指出一個架構關注于結構和行為，僅關注于重要決定，可以與架構風格一致，受涉眾和環境的影響，體現基于原因的決定。所有這些方面，都在下面提到。

一個架構定義結構

如果你要求人們為你描述“架構”，十分之九的人都會參照結構來解釋。這在關于構建或其他土木工程結構（例如橋梁）中非常常見。雖然這些條目中的其他屬性（例如行為，目的適當性和美學觀念）也存在，但是結構的屬性是最熟悉的和最經常被提到的。

我們對你會讓某人來描述一下他所工作的軟件系統架構一點也不會感到奇怪，他們將會給你展示一份系統結構方面的圖表——無論這些內容是否是架構層，組件，或是分布結點。事實上，結構是架構的基礎屬性。架構會以各種形式展示他們自己，且大部分架構的定義是非常模糊的。一個結構組件可能是一個子系統，進程，庫，數據庫，計算結點，饋贈系統，按需產品等等。

許多架構的定義不但承認了他們自己的結構元素，而且還有結構元素的組成，關系（任何連接部分都需支持這樣的關系），接口。這些部件都以不同方式被提供。例如，連接段可以是套接字，同步的或異步的，與某個協議相關等。

圖 1 提供了結構元素的例子。這幅圖顯示了包含展示順序進程系統的結構部分的 UML 類圖。我們看到有三個類—— OrderEntry ， CustomerManagement ，和 AccountManagement 。 OrderEntry 類與 CustomerManagement 和 AccountManagement 類相連。

圖 1 ： UML 類圖顯示了結構元素

一個架構定義行為

與定義結構元素一樣，架構定義了這些結構元素的相互作用。這些作用可以實現所期望的系統行為。圖 2 展示了允許系統支持在順序進程系統中的次序定義的 UML 順序圖。在這里我們能看到五個交互作用。第一， Sales Clerk 使用 OrderEntry 類創建了一個順序。 OrderEntry 使得客戶得到使用 CustomerManagement 類的細節。然后 OrderEntry 使用 AccountManagement 類創建一個次序，用次序條目構建順序。

圖 2 ： UML 是序列圖顯示了行為元素

圖 2 與圖 1 相連，因為我們能從圖 2 中的關于交互作用的定義得到圖 1 中的相關內容。例如， OrderEntry 事例在被執行中要依靠 CustomerManagement 事例，正如在圖 2 中所示的一樣。這種依賴就如 OrderEntry 和 CustomerManagement 間通信所反映的依賴關系一樣。

一個架構關注于重要元素

當一個架構定義了結構和行為，它不會在意所有的結構和行為的定義。它只在意那些被認為是重要的元素。重要的元素是那些有持久影響的，例如結構部分的主要部分，與核心行為相關的元素，和對諸如可靠性和可測量性等重要品質相關的元素。總的來說，架構不關心這些元素的細節。架構的重要性還可以以經濟的重要性來表達，因為某些元素的主要驅動者是創建的成本和變更的成本。

由于架構僅關注于重要元素，它給我們提供了在考慮中的系統的一個特殊透視圖——與架構最相關的透視圖。 ⁸ 在這種含義下，一個架構是一個系統的抽象，可以幫助架構師管理復雜性。

我們僅僅應注意重要元素的設置不是靜態的。作為一個需要被提煉，確定風險，可執行的軟件構建和經驗總結的結果，重要元素的設置可能會改變。但是，面對改變的架構的穩定性是好的架構，好的可執行架構進程，好的架構師的標志。如果架構需要根據變化不斷做出調整，那么這不是一個好的標志。但是，如果架構相對穩定，那么相反的也對。

一個架構可以平衡涉眾需求

架構是為了實現涉眾的需要而創造的。但是，一般來說不可能滿足所有的需求。例如，涉眾可能會問特定的時間框的功能，但是這兩方面（功能和時間框）是互斥的。或者為了滿足時間表而減少范圍或者所有的功能可以擴展時間框實現。類似的，不同的涉眾之間可能有相互沖突的需求，所以應滿足適當的平衡性。所以作折中是構建進程的主要方面，且妥協是架構的重要屬性。

僅僅提供一個任務的例子，考慮如下涉眾群各自的所需：

l???????? 最終用戶關心直覺，正確的行為，性能，可靠性，可用性，有效性和安全性。

l???????? 系統管理員關注直覺行為，管理和輔助監測。

l???????? 業務人員關注有競爭力的特性，市場的時效性，對于其他產品的定位和開銷。

l???????? 客戶關注開銷，穩定性和計劃性。

l???????? 開發者關注清晰的需求和簡單而一致的設計方法。

l???????? 項目經理關注追蹤項目，計劃，資源的生產使用和預算的可預見性。

l???????? 維護人員關注易理解性，一致性，和文檔化的設計方法，與易修改性。

正如表中可看到的，對于架構師的另一個挑戰是涉眾群不僅僅關注系統所提供的需求功能。他們所關注的在實際中是不起作用的，因為在系統中他們不發生作用。（例如，關于成本和計劃的關注）但是這些關注體現了系統質量或局限。非功能需求經常是架構師所關注的最重要的需求。

一個架構基于基本原理體現決策

一個架構的重要部分不僅僅是最終結果，架構本身，而是他為什么是如此的原因。因此，確信你已把使用這個架構和原因文檔化就非常重要了。

這個信息與許多涉眾都有關系，尤其是那些維護系統的人。這些信息對需要參考設計理由的架構師來說非常有價值，因為他們可以省去不必要的步驟。例如，當需要重復架構和架構師重新審視所做的決定時，這些信息非常有用。

一個架構可以符合一個架構樣式

大部分的架構來源于有相似關注的共享系統。這些相似性可被描述成某種特殊模式的架構風格，雖然經常是復雜和組合模式（由許多模式共同作用）。一種架構風格展示一個經驗法典，并且有利于架構師重復使用類似經驗。架構風格的例子包括分布式的風格，管道和過濾器風格，數據中心風格，基于規則的風格等。一個系統可以包含多于一個架構風格。 Shaw 和 Garlan 的描述如下：

[ 架構風格 ] 按照結構組織的模式定義了系統。更具體的，架構風格定義了組件和連接型的語法，和連接的方法。 ⁹

在 UML 中的定義 :

[ 模式 ] 是對于普遍問題的普遍解決方案。 ¹⁰

除了重復經驗，由于一種風格以文檔的形式保存了使用它的理由和它的結構與行為，所以架構風格的應用使類似架構師的工作變得容易起來。

一個架構被其環境所影響

系統貯存于環境中，且環境影響架構。這就是有時所提到的“環境中的架構”。基本上，環境決定了系統運行的范圍，這些又決定了架構。影響架構的環境的因素包含架構所支持的商務環境，系統涉眾群，內部技術限制（例如需要符合組織標準），和外部技術限制（例如對外部系統的接口或遵守外部規則的標準）。

相反的，如在 Bass, Clements, 和 Kazman 所描述的， ¹¹ 架構可能還影響它的環境。不但是從技術前景的架構創新改變了環境 -- 例如它可能對擁有組織的可重復使用價值有貢獻——架構的創新可能在技術方面改變環境。

當提到軟件集成系統，有一個必須被提到的關于環境的特殊部分。為了軟件的有用性，它必須執行。為了執行，軟件運行在硬件之上。所以最終系統是軟硬件的結合，與諸如可靠性和性能等完美結合的實現。軟件不能在單獨的硬件條件下實現這些功能。

IEEE 標準 12207-1995 ， IEEE 信息技術標準 －－ 軟件生命周期過程，定義了與之前 IEEE1471 不同的系統（關注于軟件集成系統），但與在系統工程方面定義的相同：

[ 系統 ] 是包含了一個或多個進程，硬件，軟件，工具與可以滿足需求的人的集合。 [IEEE 12207]¹²

Systems Engineering (RUP SE) 的 Rational Unified Process 配置包含一個類似的定義。

[ 系統 ] 是提供為企業執行商業目的或任務的服務資源。系統組件包括硬件，軟件，數據和工作人員 ¹³ 。

在系統工程方面，根據軟件，硬件和人的使用定義事務。例如，如果性能為重，那么可能決定某一個系統元素的硬件實現，而不是軟件或人。另一個例子是為了給客戶提供可用系統，所以要給客戶提供接口。更復雜的情況需要通過軟硬件和人的結合實現系統功能。

我們非常有趣的注意到系統工程特別關注于對待軟件和硬件，因此避免把硬件和軟件相比作為第二級，或是執行軟件的載體，或是反過來。

一個架構影響團隊結構

架構定義了一組連貫的相關元素。例如，順序進程系統架構可能已定義了一組次序入口，計數管理，客戶管理，實現，外部系統集成，持續性和安全性。

每一組都會要求不同的技術。因此，一旦被定義好，統一軟件開發小組結構就非常有意義了。但是，情況經常是最初的小組結構影響了構架，而不是相反情況。因為結果通常都是一個不太理想的架構。“康威規律” 規定“如果你有 4 個編譯小組，那你會有 4 路編譯器”。 實際上，我們經常會無意識地創建架構，以反映創建架構的組織。

但是，完全從實際出發，事實上這種有點理想的觀點經常是不實際的，因為當前小組結構和技術都有實際可能的限制，并且架構師必須考慮在內。

一個架構呈現在每一個系統中

每個系統都有一個架構，即使這個架構沒有被文檔化，或者如果系統非常簡單且包含單一元素。對架構文檔化很有價值。文檔化的架構比沒有的考慮的更周全——因此也更有效，所以根據架構的進程可以更細致的考慮。

相反地，如果架構沒有文檔化，那么很困難來證明滿足了諸如可維護性，最佳適應性等的需求。似乎大部分現今存在的無文檔的架構都有些隨意性而不是目的性。

一個架構擁有一個特定的范圍

有許許多多種架構，最著名的是與建筑和其他工程相關的。甚至在軟件工程領域，我們經常會遇到不同形式的架構。例如，除了軟件構架的概念，我們會遇到諸如企業架構，系統架構，組織架構，信息架構，硬件架構，應用架構，基礎設施架構等。你會見到其他類型的，每種類型都定義了一個架構的具體范圍。

不幸的是，產業界沒有相互形式間的協定，所以導致了對同一形式的不同意思。但是，從圖 3 中可以推斷出這些形式的范圍。當你們在考慮和討論下面這張圖的時候，你肯定會發現很多你不同意的元素或是在你們的組織中不同的使用方法。但是重要的是——這些形式的確存在，卻沒有一致的觀點。

圖 3 ：不同領域的范圍

圖 3 展示的元素有：

l???????? 軟件架構——這篇文章主要的關注點。

l???????? 硬件架構——包括 CPU, 內存，硬盤，周邊設備例如打印機，與連接這些元素的部分。

l???????? 組織架構——是一些關于商業進程，組織結構，規則和職責，與組織核心能力的部分。

l???????? 信息架構——包含組織好的信息結構。

l???????? 軟件架構，硬件架構，組織架構和信息架構是全部系統架構的子結構。

l???????? 企業架構，與系統架構很相似，包括硬件，軟件，人員等。但是，企業架構與商業有很強的聯系，因為它專注于商業對象的聯系，專注于商業敏捷性和組織效率。企業架構可能穿插于公司間。

正像人們期盼的那樣，有相應形式的架構師（例如軟硬件架構師等）和架構（例如，軟硬件架構等）。

總結

這篇文章關注于定義軟件架構的核心特性。但是，仍然有很多未被解答的問題。什么是軟件架構師的角色？架構師最重要的活動是什么？從“建立架構”中能得到什么好處？這些問題將在后續文章中被解答。

注釋

¹ 軟件工程研究所（ SEI ）架構 Web 站點 －－ 架構定義，提供了一個好的例子。參見 http://www.sei.cmu.edu/architecture/definitions.html

² IEEE Computer Society ，強軟件系統的架構描述的 IEEE 推薦實踐： IEEE 標準 1472000 ， 2000 。

³ 對象管理組織， UML 2.0 結構規格說明：文檔號 03-09-15 。 2003 年九月。

⁴ Philippe Kruchten ， Rational 統一過程：介紹，第三版。 Addison-Wesley Professional 2003 。

⁵ Len Bass ， Paul Clements 和 Rick Kazman ，軟件架構實踐，第二版。 Addison Wesley 2003 。

⁶ 對象管理組織， OMG 統一建模語言規格 1.5 版，文檔號 03-03-01 。 2003 年三月。

⁷ James McGovern 等，企業架構的實踐指南。 Prentice Hall 2004

⁸ 一個在本系列的后續文章中所涵蓋的角色。

⁹ Mary Shaw 和 David Garlan ，軟件架構 -- 關于一個正在形成的學科的觀察。 Prentice Hall 1996 ，

¹⁰ Grady Booch ， James Rumbaugh 和 Ivar Jacobson ，統一建模語言用戶指南。 Addison Wesley 1999 。

¹¹ Bass 等，前面引用的書。

¹² IEEE Computer Society ， IEEE 信息技術標準 －－軟件生命周期過程。 IEEE 標準 12207-1995 。

¹³ Murray Cantor ，“系統工程的 Rational 統一過程”。 The Rational Edge ， 2003 年八月。 http://download.boulder.ibm.com/ibmdl/pub/software/dw/rationaledge/aug03/f_rupse_mc.pdf

?