什麼是軟件架構？

 

Peter Eeles, 高級 IT 架構師, IBM

2006 年 4 月 15 日

本文來自於 Rational Edge：這篇關於軟件架構的較新規則的介紹，是一個關於“架構”的四篇系列文章的的第一篇。作者以定義規則的關鍵術語開始，繼續探索設計出色的架構對於架構所部署的環境所起的作用。

我們毫不懷疑世界正變得越來越依靠軟件。軟件是諸如無處不在的手機，和複雜的空中控制系統的核心元素。事實上，如果沒有軟件，例如eBay 和 Amazon等我們理所當然認爲是創新的企業將不可能存在。甚至那些金融業，零售業和公共部門等傳統行業也相當的依賴於軟件。在當今的時代，某種程度上，我們很難發現一個企業完全與軟件不相關。

高新企業爲了生存，因此他們所依靠的軟件必須能提供其所需的功能；所需的高質量；所承諾的可用性，和可接受的價格。

這篇文章的主題就是關於可以影響這些屬性的軟件架構。我所關注的是“強軟件系統”，在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間通信所反映的依賴關係一樣。

一個架構關注於重要元素

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

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

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

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

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

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

• 最終用戶關心直覺，正確的行爲，性能，可靠性，可用性，有效性和安全性。
• 系統管理員關注直覺行爲，管理和輔助監測。
• 業務人員關注有競爭力的特性，市場的時效性，對於其他產品的定位和開銷。
• 客戶關注開銷，穩定性和計劃性。
• 開發者關注清晰的需求和簡單而一致的設計方法。
• 項目經理關注追蹤項目，計劃，資源的生產使用和預算的可預見性。
• 維護人員關注易理解性，一致性，和文檔化的設計方法，與易修改性。

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

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

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

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

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

大部分的架構來源於有相似關注的共享系統。這些相似性可被描述成某種特殊模式的架構風格，雖然經常是複雜和組合模式（由許多模式共同作用）。一種架構風格展示一個經驗法典，並且有利於架構師重複使用類似經驗。架構風格的例子包括分佈式的風格，管道和過濾器風格，數據中心風格，基於規則的風格等。一個系統可以包含多於一個架構風格。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展示的元素有：

• 軟件架構——這篇文章主要的關注點。
• 硬件架構——包括CPU, 內存，硬盤，周邊設備例如打印機，與連接這些元素的部分。
• 組織架構——是一些關於商業進程，組織結構，規則和職責，與組織核心能力的部分。
• 信息架構——包含組織好的信息結構。
• 軟件架構，硬件架構，組織架構和信息架構是全部系統架構的子結構。
• 企業架構，與系統架構很相似，包括硬件，軟件，人員等。但是，企業架構與商業有很強的聯繫，因爲它專注於商業對象的聯繫，專注於商業敏捷性和組織效率。企業架構可能穿插於公司間。

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

現在我們已瀏覽過這些定義了，但還有很多未回答的問題。企業架構與系統架構間有什麼不同？一個企業是一個系統？信息架構與數據集成軟件應用中的數據架構是一樣的？不幸的是，沒有對這些問題的一致的答案。

對現在來說，你會意識到這些不同，但是產業界不存在對這些內容的一致定義。因此，對你的建議只是選擇那些與你的組成相似的形式並且合適的定義他們。至少你會獲得某些一致性，並減少錯誤傳達的可能。

總結

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

感謝

這篇文章的內容來源於一本即將出版的新書，暫時叫做“軟件架構建立過程”。最後，我衷心的感謝對內容提出寶貴意見的人們，他們是Grady Booch，Dave Braines，Alan Brown，Mark Dickson，Holger Heuss，Kelli Houston，Luan Doan-Minh，Philippe Kruchten，Nick Rozanski，Dave Williams，和Eoin Woods。

註釋

¹ 軟件工程研究所（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