像學寫文章一樣，在學會字、詞、句之後，就應上升到段落，就應追求文章的“佈局謀篇”，這就是架構。通俗地講，軟體架構設計就是軟體系統的“佈局謀篇”。

    人們在軟體工程實踐中，逐步認識到了軟體架構的重要性，從而開闢了一個嶄新的研究領域。軟體架構的研究內容主要涉及軟體架構描述、軟體架構設計、軟體架構風格、軟體架構評價和軟體架構的形成方法等。

    軟體設計人員學習軟體架構知識旨在站在較高的層面上整體地解決好軟體的設計、複用、質量和維護等方面的實際問題。

   1 軟體架構概述 

    軟體架構是軟體抽象發展到一定階段的產物，從程式設計的角度，可以清晰地看到軟體抽象層次和表達工具的發展歷史。

• 20 世紀 60 年代是子程式的年代：出現了原始的軟體架構，即子程式，並以程式間的呼叫為連線關係。

• 20 世紀 70 年代是模組化的年代：出現了資料流分析、實體—關係圖（E-R 圖）、資訊隱藏等工具和方法，軟體的抽象層次發展到了模組級。

• 20 世紀 80 年代是面向物件的年代：基於模組化的程式語言進一步發展成面向物件的語言，繼承性地增加了一種新元素之間的連線關係。

• 20 世紀 90 年代是框架的年代：標準的基於物件的架構以框架的形式出現了。如電子資料表、文件、圖形影象、音訊剪輯等可互換的黑箱物件，可以相互嵌入。

• 當前（最近 10 年來）：中介軟體和 IT 架構作為標準平臺出現，用可購買可複用的元素來構建系統，同時，基於架構的開發方法和理論不斷成熟。

1  軟體架構的定義 

    軟體架構仍在不斷髮展中，還沒有形成一個統一的、公認的定義，這裡僅舉出幾個較權威的定義。

    定義 1：軟體或計算機系統的軟體架構是該系統的一個（或多個）結構，而結構由軟體元素、元素的外部可見屬性及它們之間的關係組成。

    定義 2：軟體架構為軟體系統提供了一個結構、行為和屬性的高階抽象，由構成系統的元素的描述、這些元素的相互作用、指導元素整合的模式及這些模式的約束組成。

    定義 3：軟體架構是指一個系統的基礎組織，它具體體現在：系統的構件，構件之間、構件與環境之間的關係，以及指導其設計和演化的原則上。（IEEE1471- 2000）

   前兩個定義都是按“元素—結構—架構”這一抽象層次來描述的，它們的基本意義相同，其中定義 1 較通俗，因此，本章採用這一定義。該定義中的“軟體元素”是指比“構件”更一般的抽象，元素的“外部可見屬性”是指其他元素對該元素所做的假設，如它所提供的服務、效能特徵等。

    為了更好地理解軟體架構的定義，特作如下說明：

    （1）架構是對系統的抽象，它通過描述元素、元素的外部可見屬性及元素之間的關係來反映這種抽象。因此，僅與內部具體實現有關的細節是不屬於架構的，即定義強調元素的“外部可見”屬性。

    （2）架構由多個結構組成，結構是從功能角度來描述元素之間的關係的，具體的結構傳達了架構某方面的資訊，但是個別結構一般不能代表大型軟體架構。

    （3）任何軟體都存在架構，但不一定有對該架構的具體表述文件。即架構可以獨立於架構的描述而存在。如文件已過時，則該文件不能反映架構。

    （4）元素及其行為的集合構成架構的內容。體現系統由哪些元素組成，這些元素各有哪些功能（外部可見），以及這些元素間如何連線與互動。即在兩個方面進行抽象：在靜態方面，關注系統的大粒度（巨集觀）總體結構（如分層）；在動態方面，關注系統內關鍵行為的共同特徵。

    （5）架構具有“基礎”性：它通常涉及解決各類關鍵的重複問題的通用方案（複用性），以及系統設計中影響深遠（架構敏感）的各項重要決策（一旦貫徹，更改的代價昂貴）。

    （6）架構隱含有“決策”，即架構是由架構設計師根據關鍵的功能和非功能性需求（質量屬性及專案相關的約束）進行設計與決策的結果。不同的架構設計師設計出來的架構是不一樣的，為避免架構設計師考慮不周，重大決策應經過評審。特別是架構設計師自身的水平是一種約束，不斷學習和積累經驗才是擺脫這種約束走向自由王國的必經之路。

    在設計軟體架構時也必須考慮硬體特性和網路特性，因此，軟體架構與系統架構二者間的區別其實不大。但是，在大多情況下，架構設計師在軟體方面的選擇性較之硬體方面，其自由度大得多。因此，使用“軟體架構”這一術語，也表明了一個觀點：架構設計師通常將架構的重點放在軟體部分。

    將軟體架構置於商業背景中進行觀察，可以發現軟體架構對企業非常重要。

    （1）影響架構的因素。軟體系統的專案干係人（客戶、使用者、專案經理、程式設計師、測試人員、市場人員等）對軟體系統有不同的要求開發組織（專案組）有不同的人員知識結構、架構設計師的素質與經驗、當前的技術環境等方面都是影響架構的因素。

這些因素通過功能性需求、非功能性需求、約束條件及相互衝突的要求，影響架構設計師的決策，從而影響架構。

    （2）架構對上述諸因素具有反作用，例如，影響開發組織的結構。架構描述了系統的大粒度（巨集觀）總體結構，因此可以按架構進行分工，將專案組為幾個工作組，從而使開發有序；影響開發組織的目標，即成功的架構為開發組織提供了新的商機，這歸功於：系統的示範性、架構的可複用性及團隊開發經驗的提升，同時，成功的系統將影響客戶對下一個系統的要求等。這種反饋機制構成了架構的商業週期。

2 軟體架構的重要性 

    從技術角度看，軟體架構的重要性表現為如下幾方面。

    （1）專案關係人之間交流的平臺。軟體系統的專案關係人分別關注系統的不同特性，而這些特性都由架構所決定，因此，架構提供了一個共同語言（公共的參考點），專案關係人以此作為彼此理解、協商、達成共識或相互溝通的基礎。架構分析既依賴於又促進了這個層次上的交流。

    （2）早期設計決策。從軟體生命週期來看，軟體架構是所開發系統的最早設計決策的體現，主要表現為：

• 架構明確了對系統實現的約束條件：架構是架構設計師對系統實現的各方面進行權衡的結果，是總體設計的體現，因此，在具體實現時必須按架構的設計進行。

• 架構影響著系統的質量屬性：要保證系統的高質量，具有完美的架構是必要的（雖然不充分）。

• 架構可以用來預測系統的質量，例如，可以根據經驗對該架構的質量（如效能）作定性的判斷。

• 架構為維護的決策提供根據。在架構層次上能為日後的更改決策提供推理、判斷的依據。一個富有生命力的架構，應該是在最有可能更改的地方有所考慮（架構的柔性），使其在此點最容易進行更改。

• 架構有助於原型開發。可以按架構構造一個骨架系統（原型），例如，在早期實現一個可執行的特例，確定潛在的效能問題。

• 藉助於架構進行成本與進度的估計。

    （3）在較高層面上實現軟體複用。軟體架構作為系統的抽象模型，可以在多個系統間傳遞（複用），特別是比較容易地應用到具有相似質量屬性和功能需求的系統中。產品線通常共享一個架構。產品線的架構是開發組織的核心資產之一，利用架構及其範例進行多系統的開發，在開發時間、成本、生產率和產品質量方面具有極大的回報。基於架構的開發強調對各元素的組合或裝配。系統開發還可以使用其他組織開發的元素，例如購買商業構件。

    （4）架構對開發的指導與規範意義不容忽略。架構作為系統的總體設計，它指導後續的詳細設計和編碼。架構使基於模板的開發成為可能，有利於開發的規範化和一致性，減少開發與維護成本。架構可以作為培訓的基礎，有利於培養開發團隊和培訓相關人員。

   從軟體開發過程來看，如果採用傳統的軟體開發模型（生命週期模型），則軟體架構的建立應位於概要設計之前，需求分析之後。

    基於架構的軟體開發模型則明確地把整個軟體過程劃分為架構需求、設計、文件化、評審（評估）、實現、演化等 6 個子過程。本章各節將分別對這些子過程進行討論。

3 架構的模型

    軟體架構作為一個有機的整體，可以分解成多個側面來認識，每個側面強調它的不同方面的特徵，從而使架構設計師能整體地把握它的重點。我們可以將軟體架構歸納成 5 種模型：結構模型、框架模型、動態模型、過程模型和功能模型。最常用的是結構模型和動態模型。

    （1）結構模型。這是一個最直觀、最普遍的建模方法。這種方法以架構的構件、連線件和其他概念來刻畫結構，併力圖通過結構來反映系統的重要語義內容，包括系統的配置、約束、隱含的假設條件、風格、性質。研究結構模型的核心是架構描述語言。

    （2）框架模型。框架模型與結構模型類似，但它不太側重描述結構的細節而更側重於整體的結構。框架模型主要以一些特殊的問題為目標建立只針對和適應該問題的結構。

    （3）動態模型。動態模型是對結構或框架模型的補充，研究系統“大顆粒”的行為性質。例如，描述系統的重新配置或演化。動態可能指系統總體結構的配置、建立或拆除通訊通道或計算的過程。

    （4）過程模型。過程模型研究構造系統的步驟和過程。因而結構是遵循某些過程指令碼的結果。

    （5）功能模型。該模型認為架構由一組功能構件按層次組成，且下層向上層提供服務。它可以看作是一種特殊的框架模型。

    這 5 種模型各有所長，也許將 5 種模型有機地統一在一起，形成一個完整的模型來刻畫軟體架構更合適。即將軟體架構視為這些模型的統一體，通過這些模型的表述（文件）來完整反映軟體架構。例如，Kruchten 在 1995 年提出了一個“4+1”的檢視模型。“4+1” 檢視模型從 5 個不同的視角包括邏輯檢視、程序檢視、物理檢視、開發檢視和場景檢視來描述軟體架構。每一個檢視只關心繫統的一個側面，5 個檢視結合在一起才能反映系統的軟體架構的全部內容。“4+1”檢視模型如圖 9-1 所示。

    （1）邏輯檢視：主要支援系統的功能需求，即系統提供給終端使用者的服務。在邏輯檢視中，系統分解成一系列的功能抽象，這些抽象主要來自問題領域。這種分解不但可以用來進行功能分析，而且可用作標識在整個系統的各個不同部分的通用機制和設計元素。在面向物件技術中，通過抽象、封裝和繼承，可以用物件模型來代表邏輯檢視，用類圖來描述邏輯檢視。邏輯檢視中使用的風格為面向物件的風格，邏輯檢視設計中要注意的主要問題是要保持一個單一的、內聚的物件模型貫穿整個系統。

    （2）開發檢視：也稱為模組檢視，主要側重於軟體模組的組織和管理。軟體可通過程式庫或子系統進行組織，這樣，對於一個軟體系統，就可以由不同的人進行開發。開發檢視要考慮軟體內部的需求，如軟體開發的容易性、軟體的重用和軟體的通用性，要充分考慮由於具體開發工具的不同而帶來的侷限性。開發檢視通過系統輸入輸出關係的模型圖和子系統圖來描述。可以在確定了軟體包含的所有元素之後描述完整的開發角度，也可以在確定每個元素之前，列出開發檢視原則。

    （3）程序檢視：側重於系統的執行特性，主要關注一些非功能性的需求，例如系統的效能和可用性。程序檢視強調併發性、分佈性、系統整合性和容錯能力，以及邏輯檢視中的主要抽象的程序結構。它也定義邏輯檢視中的各個類的操作具體是在哪一個執行緒中被執行的。程序檢視可以描述成多層抽象，每個級別分別關注不同的方面。

    （4）物理檢視：主要考慮如何把軟體對映到硬體上，它通常要考慮到解決系統拓撲結構、系統安裝、通訊等問題。當軟體運行於不同的節點上時，各檢視中的構件都直接或間接地對應於系統的不同節點上。因此，從軟體到節點的對映要有較高的靈活性，當環境改變時，對系統其他檢視的影響最小。

    （5）場景：可以看作是那些重要系統活動的抽象，它使四個檢視有機地聯絡起來，從某種意義上說，場景是最重要的需求抽象。在開發架構時，它可以幫助設計者找到架構的構件和它們之間的作用關係。同時，也可以用場景來分析一個特定的檢視，或描述不同檢視構件間是如何相互作用的。場景可以用文字表示，也可以用圖形表示。

    希賽教育專家提示：邏輯檢視和開發檢視描述系統的靜態結構，而程序檢視和物理檢視描述系統的動態結構。對於不同的軟體系統來說，側重的角度也有所不同。例如，對於管理資訊系統來說，比較側重於從邏輯檢視和開發檢視來描述系統，而對於實時控制系統來說，則比較注重於從程序檢視和物理檢視來描述系統。