什麼是軟體架構？

Jan. 15 20:17~23:14；16 07:21~08:50

 

定義

寫了那麼多篇軟體架構的文章，才發現還沒討論過軟體架構的定義，今天來談一下這個主題。關於軟體架構的定義有很多種說法，這裡參考《Software Architecture in Practice, 3rd》的定義：

The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.（系統的軟體架構是理解系統所需的一組結構，包含軟體元素、這些軟體元素之間的關聯，以及軟體元素與關聯的屬性。）

通常名詞的定義看完之後還不太懂，這裡先抓幾個關鍵字：

• structures
• software elements
• relations
• properties

***

軟體結構

結構（structure）就是依據某種關係（relation）被擺在一起的一組元素（element）。一個軟體系統包含多種結構，無法說某種單一結構就代表這個系統的架構。在書中提到三種重要的架構結構（architectural structure），分別是：

• Module Structure：模組結構；將系統切割成實作單位，作為分配計算責任以及派工單位。例如「資料庫」交給Team A，「商業邏輯」交給Team B，「使用者介面」交給Team C。這是一種靜態的結構關係。
• Component-and-Connector（C&C）Structure：元件-連接器結構；為了達成系統功能，元素在執行期間的行為與互動，component代表行為，connector代表互動。假設系統採用好幾個服務（service）所建置完成，這些服務本身、服務所需要的基礎建設（例如資料庫服務、訊息傳遞服務、認證服務等）以及它們之間的同步與互動關係都屬於元件-連接器結構的範疇。這是一種動態的結構關係，透過這種關係可以設計與評估系統的動態屬性（runtime property），例如performance、security、availability等。
• Allocation Structure：分配結構；描述軟體結構與非軟體結構，例如組織結構、開發團隊、安裝、執行環境的對應關係。例如，模組結構被指派給開發團隊開發，模組結構被安排到檔案結構以便實作、整合與測試。元件被佈署到那些硬體，網路環境的規劃與配置等。

以上是書中的解釋，也許鄉民們還是覺得有點抽象，舉個例子，既然軟體架構包含這三種不同的結構（structure），也就是說如果你是一位軟體架構師，你設計出來的軟體架構應該會包含這三者。如果你是開發人員，你拿到的軟體架構也會包含這三者。聽起來好像是廢話，但卻是有用的廢話：

• 從module structure的角度來看，layer、package、class或是單純的功能模有沒有設計出來？
• 從C&C structure的觀點，component可能實作成service、peer、client、server、filter等執行時間的元素，connection則是軟體元件的互動方—同步或非同步？使用function call、RPC、pipe、socket、RESTful或其他方式？資料如何在軟體元件之間流動？資料同步方式為何—不須同步、透過transaction、two-phase commit、或交易補償？那些元件可以並行執行，那些只可同步執行？系統的結構在執行時間可否改變（例如動態增加服務節點以應付突然增加的使用者需求）？
• Allocation structure描述軟體系統與非軟體結構的關係，例如軟體元件整合與佈署。這個議題常常被軟體架構師所忽略而讓開發人員自行決定，從敏捷開發的角度來看，造成持續整合與持續佈署無法落實或一團混亂。

在一般專案中，軟體架構師應該會提供module structure。因為這是靜態結構，連靜態結構都沒有一定會被開發人員 幹譙 退件。C&C structure可能會被忽略，讓開發人員自行決定，或是只提供重要的C&C structure，例如Web的操作要用非同步的方式，服務與服務之間要用RESTful來溝通，資料全部統一集中儲存在關聯式資料庫中。最後Allocation structure則是更容易被忽略的一環，交由開發人員自行決定。例如，假設開發人員想要導入持續整合與持續佈署，需要清楚知道軟體靜態關係、動態關係以及執行環境之間的對應，才能夠自動化建構甚至佈署軟體系統。如果開發人員跑去告訴架構師：「請給我allocation structure讓我們順利完成自動化持續整合與佈署」，應該沒人會理你。因為架構師可能會認為：「這是開發人員的工作，幹嘛推到我身上哩？」

***

架構是一種抽象

軟體架構描述結構，結構包含了元素（elements，模組或元件的統稱）以及關聯（relation），省略了那些對於理解整個系統沒有幫助的細節。也就是說如果元素內部結構的實作細節對於理解整個系統沒有特別幫助，在軟體架構中就不須要描述。因此軟體架構被視為是系統的抽象描述。

傳統上軟體架構經常用方塊圖與直線來表示，對應到上述的說法方塊圖代表元素，箭頭表示關聯。至於方塊圖裡面的實作細節則不是軟體架構層面所關注的焦點（註：書中認為光有方塊圖與直線不算是軟體架構，還要加上行為描述）。

▼N年前剛出社會看到類似下圖這種「架構圖」，會覺得「這是什麼鬼，靠這種架構圖系統怎麼可能做得出來？」並不知道這種只有方塊與箭頭的架構圖其目的並不是提供實作細節，而是讓團隊成員理解系統的大概念。直到後來回學校念書讀了軟體架構的教科書，才慢慢理解軟體架構圖與實作有著不同層次的差別。

 

 

 

 

 

 

***

架構模式

為了解決不同的問題，軟體架構元素可以有多種不同的組合方式。有些組合方式長久以來被證明在許多領域都很實用，我們將這種特定的架構元素組合方式稱為架構模式（Architectural pattern），例如Layered、MVC、Client-server、Multi-tier、Pipe and Filter、Plug-ins等。一個系統可能且通常會套用一種以上的架構模式，套用架構模式可以讓開發團隊減少從頭開始設計架構的時間。對於架構師而言，套用架構模式設計軟體架構也是現今非常普遍的一種方式。

***

結論

依據《Software Architecture in Practice, 3rd》的觀點，軟體架構是組織的商務目標（抽象、高階需求）與實踐該目標的軟體系統之間的橋樑。軟體架構包含結構（structure）以及結構之間的關係（relation），結構包含靜態的模組，動態的元件-連結器，以及軟體與非軟體之間的配置關係。透過軟體架構開發團隊可以回答為了滿足需求所提出的一連串功能與非功能面的問題。

***

友藏內心獨白：還是很抽象啊XD。