軟件架構對于復雜實時系統的開發已日益變得更加重要。在這個新的系列中，了解為什么以及應該如何編寫軟件架構文檔說明。您將了解 為任何中大型軟件開發項目編寫文檔說明的五個不同視圖或方面。這是本系列中的第一篇文章，其中將介紹軟件架構和文檔說明的重要性。您還將概略了解將在后續 文章中介紹的體系結構視圖。

引言

軟件架構是一門學科，開始于 20 世紀 70 年代。面對不斷增加的復雜性和開發復雜實時系統的壓力，作為主流系統工程和軟件開發的基本構造，軟件架構應運而生。

與任何其他久經考驗的學科一樣，軟件架構在誕生之初也面臨許多挑戰。軟件架構表示系統的結構和行為方面。在早期為軟件架構編寫文檔說明時，所使用的文本和 圖解表達常常不足或者不夠精確。所需的是某種一致并得到充分理解的偽（或元）語言，以便將對軟件架構進行表示和編寫文檔說明的不同方式統一起來。在學術研 究的推動下，在用于開發有效軟件架構文檔說明的最佳實踐和指導原則方面，工程和計算機科學領域已取得了長足的發展。

在本系列中，您將了解如何編寫軟件架構文檔說明。了解編寫文檔說明的不同方面：系統上下文、體系結構概述、功能體系結構、操作體系結構和體系結構決策。

在這第一篇文章中，了解軟件架構是什么，以及為該學科的不同方面編寫文檔說明的重要性。

回頁首

軟件架構

不同的研究人員已解釋了軟件架構是什么，并且他們對有關如何最好地表示軟件系統的體系結構具有不同的觀點。其中沒有哪一種解釋是錯誤的；每種解釋都具有自己的價值。Bass L 等人抓住了軟件架構的本質：

“程序或計算系統的軟件架構是該系統的結構，包括軟件組件、那些組件的外部可見的屬性，以及那些組件之間的關系” 。

此定義重點關注由粗粒度的構造（軟件組件）所構成的體系結構，可以將這些構造看作是體系結構的構建塊。每個軟件組件或體系結構構建塊具有某些外部可見的屬 性，這是它向其他體系結構構建塊公開的屬性。軟件組件的內部設計和實現細節不是系統的其他部分所關心的內容，系統的其他部分只是將某個特定組件視為一個黑 盒。該黑盒具有某些所公開的屬性，其他軟件組件可以使用這些屬性來共同實現業務或 IT 目標。軟件架構在恰當的粒度級別標識體系結構構建塊。軟件架構還標識那些構建塊如何彼此相關，并進行文檔記錄。

與軟件工程相關的體系結構涉及到將單個系統分解或劃分為一組可迭代地、漸進地和獨立地構造的部分。各個部分彼此具有顯式的關系。當組合在一起時，各個部分就形成了系統、企業或應用程序的體系結構。

關于體系結構與設計之間的區別，存在一些混淆。正如 Clements P 等人 所指出的，所有體系結構都是設計，但不是所有設計都是體系結構。需要綁定以使系統滿足其功能性和非功能性需求和目標的設計本質上是體系結構。體系結構將體 系結構構建塊視為黑盒，而設計則處理體系結構構建塊的配置、自定義和內部工作。體系結構將軟件組件與其外部屬性綁定在一起。設計通常要比體系結構松散得 多，因為它允許以更多的方式遵守組件的外部屬性。設計還考慮用于實現組件內部細節的各種方法。

軟件架構可以遞歸地使用。請考慮一個屬于某個系統的軟件架構組成部分的軟件組件 (C1)。軟件架構師將該組件及其應該公開的屬性、功能和非功能特性及其與其他軟件組件的關系交給系統設計人員。設計人員在分析軟件組件 C1 之后，決定將該組件分解為更細粒度的組件（C11、C12 和 C13），其中每個組件提供可重用的功能，這些功能將用于實現 C1 的要求屬性。設計人員詳細設計了 C11、C12、C13 及其接口。

此時，對設計人員來說，C11、C12 和 C13 是體系結構構造（或組件）；其中每個構造具有顯式定義的外部接口。對設計人員來說，C11、C12 和 C13 是軟件組件 C1 的體系結構，并且這些構造需要進一步的改進和設計，以處理它們的內部實現。通過將大型、復雜的系統劃分為小型的構成部分并集中于每個部分，可以遞歸地使用 體系結構。

體系結構使用共同滿足行為和質量目標的體系結構構建塊將系統綁定在一起。參與者必須能夠理解體系結構。因此必須為體系結構編寫足夠的文檔說明，下一個部分將對此進行討論。

回頁首

編寫體系結構文檔說明的重要性

參與者：體系結構的下游設計和實現用戶。為體系結構的定義、維護和增強功能進行投資的人。

向參與者傳達您正在構建的系統藍圖的關鍵是為系統體系結構編寫文檔說明。軟件架構通過不同的視圖進行表示——功能、操作、決策等等。沒有任何單一視圖能夠表示整個體系結構。并非所有視圖都需要表示特定企業或問題領域的系統體系結構。架構師將確定足以表示所需軟件架構范疇的視圖集。

通過編寫不同視圖的文檔說明并捕獲每個部分的開發，您可以向開發團隊和業務及 IT 參與者傳達有關該不斷發展的系統的信息。軟件架構具有一組其預期要滿足的業務和工程目標。體系結構的文檔說明可以向參與者傳達這些目標將如何實現。

為體系結構的各個方面編寫文檔說明，有助于架構師彌補用白板描述解決方案（使用框線圖方法）與以對下游設計和實現團隊有意義的方式表示解決方案之間眾所周知的差距。體系結構的框線圖留下了大量有待解釋的空間。需要揭示的細節通常隱藏并令人混淆地固守在那些框線背后。

文檔說明還可以促進創建切合實際并且可以系統開發（例如遵循標準模板）的體系結構構件。作為一門學科，軟件架構是非常成熟的。您可以利用最佳實踐和指導原 則來為每種視圖創建標準模板，以表示體系結構的某個部分或范疇。模板可以為架構師提供有關需要實際產生什么結果的訓練。并且模板還可以幫助架構師執行強化 訓練——超越框線圖技術。模板以更具體的術語定義體系結構，因此可直接追溯到解決方案預期要滿足的業務和 IT 目標。

由于復雜性，典型的系統開發活動可能要花 18 個月左右的時間。人員縮減在設計和開發團隊是司空見慣的事情，從而導致瘋狂尋找恰當的替換人員。新的團隊成員通常阻礙進度，因為他們必須經歷一個學習過程才能成為高效的參與者。具有良好文檔說明構件的軟件架構可以提供：

• 對新團隊成員進行有關解決方案需求教育的完美平臺。
• 有關解決方案如何滿足業務和工程目標的說明。
• 特定于問題領域的各種解決方案體系結構視圖。
• 對個人將處理的視圖的重點關注。

請考慮一個名為“體系結構決策”的假想構件（后續部分還將對此進行討論）。此構件確定要解決的問題，并評估備選機制以解決該問題。此構件對為什么選擇某種備選機制而不選擇其他機制提供了論證。

所 確定的問題涉及到訪問大型機 IBM DB2® 表的機制。對兩種備選機制進行了評估：使用 IBM MQSeries®，或者使用 NEON Shadow Direct 適配器（一種供應商適配器）。盡管 MQSeries 具備相關功能并且花費較少，但是后者要穩定得多，并且在制定決策時，后者具有一定的優勢。現在設想原架構師在一年后離開了該項目，新的架構師粉墨登場。新 的架構師質問該團隊為什么不使用 IBM MQSeries 來訪問大型機 DB2 表。該團隊很快返回到體系結構決策構件，并指出了做出該選擇的原因。由于 IBM MQSeries 已在過去一年中經測試證明與另一個解決方案不相上下，并且由于其價格較低，于是對該決策進行了重新審視并做出更改以反映更新后的解決方案。

這個示例說明了為什么對系統軟件架構的各個方面編寫文檔說明，是教育新團隊成員和在最少的停機情況下幫助他們入門所必需的。

回頁首

體系結構的不同視圖

您已經了解到可以通過不同的視圖來表示體系結構，每種視圖集中于該體系結構的特定方面或范疇。正如 Bass L 等人 所指出的，視圖 是由系統參與者編寫和讀取的體系結構元素或構造以及它們之間關系的內聚集合。

體系結構的功能 視圖描述各個體系結構構建塊、構建塊之間的關系，以及如何將它們分配到體系結構中的不同層。操作 視圖（也稱為技術視圖）描述各個基礎結構和中間件軟件組件，這些組件為將要部署的功能體系結構組件提供運行時平臺。對應用程序架構師而言，功能視圖具有第一位的重要性。對基礎結構架構師而言，操作視圖是要重點關注的視圖。

這兩種視圖采用不同的方法解決相同的問題，兩種視圖都需要從概念體系結構推進到物理實現。視圖用于強調特定的體系結構范疇，同時有意地抑制其他范疇。

自從 20 世紀 90 年代以來，已經存在許多不同的視圖集。Perry 和 Wolf 提出，關于構建具有多種視圖的體系結構（包括軟件架構），存在一些非常有趣的要點。發表軟件架構的 4 + 1 視圖的 Kruchten 認為存在五種視圖，這些視圖組合起來可以表示軟件架構。下面將描述前四種視圖。

第五種視圖更多的是一種 Litmus Test 視圖。它采用一組在體系結構上非常重要的用例（業務場景），并說明如何將四種視圖的每一種視圖中的體系結構元素集與針對那些元素的體系結構約束和決策結合起來，用于實現那些用例。

由 Soni 等人 在 Applied Software Architecture 中發表的另一種視圖由四種構成軟件架構的主要視圖組成：

軟件架構出版物中描述了許多其他視圖，但是介紹所有這些視圖超出了本文的范圍。對軟件架構的不同視圖進行仔細分析后表明，不同的研究結果之間存在大量的相似性。我們擁有一個最常用于表示系統軟件架構的最優視圖集合。

下一個部分將提供一些構件的概述，建議將這些構件用作可在軟件開發生命周期的體系結構階段生成的體系結構文檔的最小集。

回頁首

文檔說明對象

可以對軟件架構的許多不同視圖或方面做文檔說明。對于任何中大型軟件開發項目，建議您至少為以下體系結構構件集編寫文檔說明：

系統上下文

系統上下文對表示為黑盒的整個系統如何與外部實體（系統和最終用戶）交互做文檔說明。它還定義系統與外部實體之間的信息和控制流。

系統上下文用于對系統所在的操作環境進行澄清、確認和編寫文檔說明。外部系統的性質、其接口以及信息和控制流對體系結構中的技術構件的下游規范有幫助。

體系結構概述

體系結構概述通過簡單的圖示表示形式說明體系結構中的主要概念元素和關系。您可以產生包括企業視圖和 IT 系統視圖的體系結構概述關系圖。概述幫助表示組織所需要的業務和 IT 功能。

體系結構概述還提供了簡要圖表，功能和操作體系結構中將對這些圖表做進一步的詳述和文檔說明。并且體系結構概述還描述了企業在 IT 系統方面的戰略方向。

功能體系結構

功能體系結構構件也稱為組件體系結構或模型，用于說明如何將體系結構分解為提供軟件組件邏輯分組的 IT 子系統。

功能體系結構從以下方面描述 IT 系統的結構：IT 系統的軟件組件的職責、接口、靜態關系和協作來交付組件所需功能的方式。此構件在各個細化階段中迭代地進行開發。

操作體系結構

操作體系結構構件表示計算機系統的網絡，這些系統支持解決方案的某些性能、可伸縮性和容錯等需求。此構件還運行中間件、系統軟件和應用程序軟件組件。

此構件在各個細化階段中迭代地進行開發。

體系結構決策

體系結構決策構件提供了對所有在體系結構上相關的決策編寫文檔說明的單一位置。決策通常涉及到但不限于：

• 系統的結構。
• 標識中間件組件以支持集成需求。
• 將功能分配到每個體系結構組件（體系結構構建塊）。
• 將體系結構構建塊分配到體系結構中的各個層。
• 遵守標準。
• 選擇技術以實現特定的體系結構構建塊或功能組件。

對任何視為在體系結構上與滿足業務和工程目標相關的決策編寫文檔說明。文檔說明通常包括：

• 問題的確定。
• 各種解決方案的評估，包括優點和缺點。
• 選定的解決方案，包括足夠的論證和其他將對下游設計和實現有幫助的相關詳細信息。

本系列的其余部分將討論如何對軟件架構中的這五個構件編寫文檔說明。

回頁首

結束語

軟件架構已經存在 30 多年了。過去幾十年已見證了軟件工程方面的大量工作。軟件架構師在設計滿足企業的業務、工程和 IT 目標的解決方案中起著中流砥柱的作用。為軟件架構編寫文檔說明是極其重要的。您可以使用文檔說明，就某個正在發展的系統與參與者進行交流。文檔說明對于使 新的團隊成員迅速投入工作也是非常有用的，因為新的團隊成員可以在實現解決方案時使用體系結構透視圖作為上下文和邊界前提。

關于什么在性質上是體系結構，什么在性質上不是體系結構，以及應該對系統的哪些方面做文檔說明，一直存在大量的混淆。體系結構模板定義并標準化每種類型的構件中的內容，支持采用一致的方法來對軟件架構編寫文檔說明。

在本文中，您了解了作為一門學科的軟件架構，并了解了對體系結構的基本元素編寫文檔說明的重要性。您還閱讀了建議作為文檔說明最小集的體系結構構件的概述。請繼續關注本系列的其他文章，它們將詳述如何使用一組指導原則，以及如何對每個構件編寫文檔說明。