帶你讀《軟體架構理論與實踐》之二：軟體架構的概念

點選檢視第一章 點選檢視第三章

第2章　

軟體架構的概念

雖然軟體架構已經在軟體工程領域中有着廣泛的應用，但迄今為止還沒有一個被大家所公認的定義。但從目前存在的100多個軟體架構定義來看，大體上可以分成決策派定義、組成派定義和其他定義三大類。本章簡要介紹這些定義，并簡要讨論這些定義的優勢和不足。

2.1　引言

軟體架構的定義似乎從此概念一出現就存在比較大的争論。研究人員一般認為：軟體架構就是一個系統的草圖。軟體架構描述的對象是直接構成系統的抽象元件。各個元件之間的連接配接則明确和相對細緻地描述元件之間的通信。在實作階段，這些抽象元件被細化為實際的元件，比如，在面向對象領域中，元件就是具體某個類或者對象，而元件之間的連接配接通常用接口來實作。與建築師設定建築項目的設計原則和目标作為繪圖員畫圖的基礎一樣，一個軟體架構師或者系統架構師把對軟體架構的陳述作為滿足不同客戶需求的實際系統設計方案的基礎。業界人士雖然也認同研究人員對軟體架構概念的描述，但鑒于現實系統，特别是遇到的現實問題，很多時候很難用某個軟體架構定義來進行系統、全面、準确的刻畫，解決遇到的問題時也很難達到滿意的程度，導緻業界人士面對五花八門的軟體架構定義時經常感到困惑，甚至刻意回避一些學術界認為比較好的做法。

在國内很多軟體企業中，從事軟體架構工作的人缺少系統的專業訓練，雖然很多人是從程式設計人員、工程師的隊伍中發展起來的，具有良好的軟體系統開發經驗和解決實際問題的能力，但是缺少很好的問題抽象能力，是以他（她）們談論的軟體架構往往與真正的架構師、研究人員心目中的軟體架構不一樣，他（她）們非常注重細節問題，而這些細節問題往往使得軟體架構師，特别是研究人員比較困惑。而在研究人員的心目中，軟體架構隻是軟體系統的一個比較高層次的抽象，也可以說是軟體系統的骨架，這個骨架可支撐軟體系統穩定、可靠、安全和高品質地運作。如果某一天這個骨架出現問題，軟體系統就可能變得不穩定、不可靠、不安全，甚至不能有效運作了。是以，研究人員花費大量的人力、物力和财力研究軟體架構如何模組化、描述、驗證和确認等，也研究出了大量的軟體架構模組化方法、軟體架構描述語言（ADL），以及各種軟體架構度量、評估、分析、測試、驗證的方法和工具。但是這些成果對業界人士來說，很多都是紙上談兵、難以落地，研究人員在業界很難找到認同感。究其原因，很多研究人員并沒有多少工程實踐經驗，甚至沒有從工程實踐出發來提煉問題，是以給出的軟體架構定義太過學術化，在此基礎上上獲得的研究成果勢必與實際需求存在比較大的差異，也很難在工程實踐中推廣使用。

綜上，由于學術界和工業界的聯系不緊密，甚至脫節，導緻它們對軟體架構的認識不一緻，進而使得軟體架構至今很難有一個統一的定義，甚至是一個近似統一的定義。本章首先選擇一些典型的軟體架構定義進行闡述，然後在此基礎上結合筆者的了解，對軟體架構的定義給出一個架構性描述。

正如Martin Fowler所言：軟體業的人樂于做這樣的事情—找一些詞彙，并将它們引申到大量微妙而又互相沖突的含義中。其中最大的受害者就是“架構”這個詞，很多人都試圖給它下定義，而這些定義本身卻很難統一。軟體架構的定義駁雜多端，其中影響較大的定義派别是組成派和決策派：前者關注軟體本身，将軟體架構看作元件和互動的集合；後者關注軟體架構中的實體（人），将軟體架構視為一系列重要設計決策的集合。軟體架構興起初期，研究者對于軟體架構的定義大都傾向組成派的觀點，但随着軟體架構的應用和發展，組成派觀點的一些缺陷逐漸顯露出來，由于軟體開發者隻注重軟體本身，特别是元件本身，開發過程中經常會出現違背原始設計的現象，導緻軟體成品不能完全滿足需求，軟體架構形成之後的評價和演化也面臨困難。在這樣的條件下，決策派的觀點引起了重視，即以人的決策為描述對象，從設計決策的角度來指導軟體開發。然而決策派觀點也有其不足之處，即對設計決策的優化程度要求很高，修改代價大。

2.2　組成派的主要定義

組成派定義的主要依據是軟體架構主要反映系統由哪些部分組成，以及這些部分是如何組成的，強調軟體系統的整體結構和配置。這裡介紹幾種有代表性的組成派定義。

1992年Dewayne和Alexander給出了軟體架構最早的定義之一[1]，他們認為軟體是由架構元素（element）、架構形式（form）和架構原理（rationale）組成的集合，也就是，軟體架構={元素，組成，原理}，其中元素是指具有一定形式的結構化元素，包括處理元素（processing element）、資料元素（data element）和連接配接元素（connecting element）。處理元素負責對資料進行加工，資料元素是被加工的資訊，連接配接元素把架構的不同部分組合連接配接起來。架構組成由權重的屬性（weighted property）和關系（weighted relationship）構成，其中權重是指下列兩種情況之一：①屬性或關系的重要性；②在多個候選項之間選擇的必要性，因為某些候選項相比其他的可能更受青睐。屬性用來限制架構元素的選擇，關系用來限制架構元素的放置（placement）。架構原理是軟體架構的基礎理論部分，用于指導在定義架構時面臨的多種選擇。架構原理指導如何準确捕獲架構風格、架構元素和架構形式的選擇動機。在建構軟體架構時，架構原了解釋了基本的哲學和美學思想，對架構師有很好的啟發作用。

1993年David和Mary定義的軟體架構包括元件（component）、連接配接件（connector）和限制（constraint）三大要素[2]，認為軟體架構是軟體設計過程的層次之一，該層次超越計算過程中的算法設計和資料結構設計。元件可以是一組代碼，也可以是獨立的程式；連接配接件可以是過程調用、管道和消息等，用于表示元件之間的互相關系；限制一般為元件連接配接時的條件。

1994年Jones認為軟體架構是元件以及元件之間互動規則的集合[3]。

1994年波音公司（The Boeing Company）和DSG（Defense and Space Group）給出了一個CFRP模型[4]：軟體系統由一組元素（element）構成。這組元素分成處理元素和資料元素。每個元素有一個接口（interface），一組元素的互連（connection）構成系統的拓撲結構。元素互連的語義包括靜态互連語義（如資料元素的互連）、描述動态連接配接的資訊轉換協定（如過程調用、管道等）。

1995年Hayes認為軟體架構是一個抽象的系統規範，主要包括由其行為和接口來描述的功能元件以及元件之間的互相連接配接關系[5]。

1995年David和Dewayne認為軟體架構即一個程式或系統各元件的結構、它們之間的互相關系以及進行設計的原則和随時間演化的指導方針等[6]。該定義與系統的整體結構定義沒有太大的差別，更加抽象，就是一種哲學思想而已。

1995年Cristina等人認為一個軟體架構包括軟體系統的元件、互聯和限制的集合，系統需求說明的集合，以及說明元件的基本原理等[7]。

1997年Bass等人認為一個程式或計算機系統的軟體架構包括軟體元件、軟體元件外部的可見特性及其互相關系[8]。其中，軟體元件外部的可見特性是指軟體元件提供的服務、性能、錯誤處理、共享資源使用等。

2003年Fowler在《Patterns of Enterprise Application Architecture》中對軟體架構的定義如下[9]：在較高的層次上将系統分解，其中的決策穩定不變，同一系統的架構可以多種多樣，架構上的主要内容會影響整個系統的生命周期，架構歸結為所有重要之物。

2004年張友生在《軟體體系結構》一書中将軟體架構定義為[10]：為軟體系統提供了一個結構、行為和屬性的進階抽象，由構成系統的元素的描述、這些元素的互相作用、指導元素內建的模式以及這些模式的限制組成。軟體架構不僅指定了系統的組織結構和拓撲結構，而且顯示了系統需求和構成系統的元素之間的對應關系，并提供了一些設計決策的基本原理。

2011年ISO/IEC/IEEE标準中[11]定義軟體架構為某一系統的基本組織結構，其内容包括軟體元件、元件間的聯系、元件與其環境間的聯系，以及指導上述内容設計與演化的原理。

2.3　決策派的主要定義

決策派定義的主要依據是軟體架構設計是軟體設計的一部分，軟體設計實際上是開發人員意志和決策在軟體開發過程中的展現，軟體架構更是高層上司和架構師意志和決策的展現，強調的是設計決策，是以更加注重架構風格和模式的選擇。這裡介紹幾種代表性的決策派定義。

1999年Booch等人認為軟體架構是一系列重要決策的集合[12]，這些決策與以下内容有關：軟體系統的組織；選擇組成系統的結構元素和它們之間的接口，以及當這些元素互相協作時所展現的行為；如何組合這些元素，使它們逐漸合成為更大的子系統；用于指導這個系統組織的架構風格。

2005年Jansen等人認為軟體架構是架構層次上所有設計決策的集合體[13]，這些設計決策與以下内容有關：架構改造的影響、原理、設計準則、設計限制以及附加需求。架構改造指的是對軟體架構進行增加、删除和移動等操作，原理即說明為什麼要對軟體架構進行這樣的修改，設計準則說明在設計中哪些操作可以做，設計限制則說明設計中哪些操作不可以做，附加需求是指做出一個設計決策後可能會産生的一些新需求。

2006年Kruchten等人[14]将軟體架構簡單地定義為“設計決策+設計”，這裡的設計指的是設計決策的推理過程。

2.4　其他定義

業界還存在一些軟體架構的其他定義，它們從獨特的角度诠釋了軟體架構。

一些資深軟體架構師根據他們的從業經曆，也給出了軟體架構的描述性定義[15]。比較有代表性的如下：Vivek Khare認為軟體架構是設計和建構軟體應用的科學和藝術，這些軟體應用滿足生命周期中使用者的各種需求；Aakash Ahmad則認為軟體架構是包含設計、演化、元件配置群組件互連關系的高層抽象結構；Andreas Rausch認為軟體架構是一個針對軟體改變的架構[15]；而Muthu Rajagopal則認為軟體架構是能夠有效組合在一起的軟體和硬體元件的集合，這些元件組合後能滿足預期需求。

2.5　參考定義架構

以上讨論的各種軟體架構定義之是以同時存在，是因為人們還很難利用某個架構定義架構來統一它們。根本原因在于：軟體架構與軟體系統的應用領域有很大的關聯，不同應用領域的軟體架構師在強調軟體架構共性的同時也熱衷于強調個性化。是以出現有些架構定義難以了解，有些架構定義太過簡單抽象的情況。例如，Jones的定義相對比較抽象，也比較片面，沒有明确指出如何進行軟體系統的整體配置，以及軟體與外部環境的互動機制，而波音公司和DSG的定義又比較複雜，難以了解等。但是，不同應用領域的軟體架構也是有共性的，特别是不同應用領域的相同類型的軟體系統（如人事管理系統、考勤系統等）。站在一個更高的抽象程度，軟體架構應該有統一的定義，或者存在某個參考定義架構。例如，Dewayne和Alexander的定義提倡的處理元素、資料元素和連接配接元素的思想，以及架構組成思想、架構原理思想，為後續的各種軟體架構定義奠定了很好的基礎，而且在很多其他定義中得到保持。David和Mary的定義給出了軟體架構定義的3C（Component、Connector和Constraint）模型，明确了軟體架構的核心組成内容，現在很多人都稱之為軟體架構的核心模型。

筆者基于國内外普遍認可的看法推薦如下參考定義架構[16]，如圖2-1所示。也就是說，軟體架構一般由五種元素構成，即元件（component）、連接配接件（connector）、配置（configuration）、端口（port）和角色（role）。

元件：具有某種功能的可重用的軟體子產品單元，表示了系統中主要的計算單元和資料存儲。元件有兩種，即組合元件和原子元件。組合元件由其他組合元件和原子元件連接配接而成。

連接配接件：表示了元件之間的互動，簡單的連接配接件有管道（pipe）、過程調用（procedure-call）、事件廣播（event broadcast）等。複雜的連接配接件有用戶端–伺服器（client-server）通信協定、資料庫和應用之間的SQL連接配接等。

配置：表示了元件和連接配接件的拓撲邏輯和限制。

端口：元件作為一個封裝的實體，隻能通過接口與外部互動，元件的接口由一組端口組成，每個端口表示了元件和外部環境的交彙點。通過不同的端口類型，一個元件可以提供多重接口。端口可以很簡單，如過程調用；也可以很複雜，如通信協定。

角色：連接配接件作為模組化軟體架構的主要實體，同樣也有接口，連接配接件的接口由一組角色組成，連接配接件的每個角色定義了該連接配接件表示的互動的參與者。二進制連接配接件有兩個角色，如RPC的角色為caller 和callee，管道的角色是reading 和writing，消息傳遞的角色是sender 和receiver等。有的連接配接件有多于兩個的角色，如事件廣播有一個事件釋出者角色和任意多個事件接收者角色。

2.6　本章小結

本章主要介紹了軟體架構的兩個代表性定義派别：組成派和決策派。其中組成派定義關注的是軟體架構的組成部分有哪些，以及這些部分是如何組成的，強調軟體系統的整體結構和配置；決策派定義強調的是設計決策，認為設計實際上是開發人員意志和決策在軟體開發過程中的展現，軟體架構更是高層上司和架構師意志和決策的展現，是以更加注重架構風格和模式的選擇。

思考題

2.1　軟體架構組成派定義和決策派定義的本質差別是什麼？

2.2　軟體架構的本質是什麼？軟體架構這些定義之間有無共同點？若有，則共同點是什麼？若無，則原因是什麼？

2.3　軟體架構與軟體系統所處的應用領域有關，談談你對這個問題的了解。

參考文獻

[ 1 ]　D E Perry, A L Wolf. Foundations for the Study of Software Architecture[J]. ACM SIGSOFT Software Engineering Notes, 1992, 17(4): 40-52.

[ 2 ]　D Garlan, M Shaw. An introduction to software architecture[M]. Advances in software engineering and knowledge engineering, 1993: 1-39.

[ 3 ]　A K Jones. The Maturing of Software Architecture[C]. Proceedings of the Software Engineering Symposium. Software Engineering Institute, Pittsburgh, 1994.

[ 4 ]　R E Creps, M A Simos. STARS conceptual framework for reuse processes[R]. STARS Program Technical Report, 1994.

[ 5 ]　B Hayes-Roth, K Pfleger, P Lalanda, et al. A domain-specific software architecture for adaptive intelligent systems[J]. IEEE Transactions on Software Engineering, 1995, 21(4): 288-301.

[ 6 ]　D Garlan, D Perry. Introduction to the Special Issue on Software Architecture[C]. IEEE PRESS, 1995.

[ 7 ]　C Gacek, A Abd-Allah, B Clark, et al. On the Definition of Software System Architecture[C]. Proceedings of the First International Workshop on Architectures for Software Systems, 1995: 85-94.

[ 8 ]　L Bass, P Clements, R Kazman. Software Architecture in Practice[R]. DAPNIA, 1998.

[ 9 ]　M Fowler. Patterns of enterprise application architecture[M]. Addison-Wesley Professional, 2003.

[10]　張友生. 軟體體系結構[M]. 北京：清華大學出版社, 2004.

[11]　ISO/IEC/IEEE 42010[R/OL].

http://en.wikipedia.org/wiki/ISO/IEC_42010.

[12]　G Booch, J Rumbaugh, I Jacobson. The Unified Modeling Language User Guide [M]. 2nd ed. Addison Wesley, 1999.

[13]　A Jansen, J Bosch. Software Architecture as a Set of Architectural Design Decisions[C]. Proceedings of the 5th Working IEEE/IFIP Conference on Software Architeture. IEEE, 2005: 109-120.

[14]　P Kruchten, P Lago, H V Vliet. Building up and reasoning about architectural knowledge[C]. Proceedings of the International Conference on the Quality of Software Architectures. Springer, Berlin, Heidelberg, 2006: 43-58.

[15]　Community Software Architecture Definitions[EB/OL].

http://www.sei.cmu.edu/architecture/start/community.cfm,

2018.

[16]　付燕. 軟體體系結構實用教程[M]. 西安：西安電子科技大學出版社, 2009.