概念: 軟體架構
軟體架構代表系統的結構,由軟體元件、這些元件的公開內容及元件之間的關係組成。
關係
主要說明

簡介

軟體架構是一種簡單的概念,大多數工程師都可以直覺地理解,尤其是稍有經驗的工程師,但很難準確定義。尤其,很難清楚界定設計和架構的差別 - 架構是一種特別關切某些特性的設計。

An Introduction to Software Architecture 一書中,David Garlan 和 Mary Shaw 認為軟體架構是一種在關切議題上的設計層次:「超越運算的演算法和資料結構;隨著新的問題浮現來設計和指定整體系統結構。結構性問題包括整個組織和全體控制結構;通訊協定、同步化及資料存取;指派功能給設計元素;實體分佈;設計元件的組合;調整和效能;設計替代方案的抉擇。」[GAR93]

但架構不只是有結構;IEEE 架構工作小組將「架構」定義為 「系統在環境中的最高階概念」[IEP1471]。另外也涉及「符合」系統完整性、經濟條件的限制、審美觀點及風格。不限於內在關注,也以使用者環境和開發環境的整體角度來考量系統 - 外內關注。

在 RUP 中,軟體系統的架構(在特定時點)是指系統中透過介面互動的重要元件所形成的組織或結構,元件由許多更小的元件和介面構成。

架構說明

在談論和推論軟體架構之前,您必須先定義架構表示法,也就是一種描述重要架構層面的方法。在 RUP 中,以軟體架構文件來提供這項說明。

架構觀點

我們選擇以多個架構觀點來表示軟體架構。每一個架構觀點解決一部份特定議題、關係人在開發流程中關心的議題:使用者、設計師、管理人員、系統工程師、維護人員等。

這些觀點擷取主要的結構性設計決策,指出軟體架構如何拆解為元件,以及元件如何由連接器串連起來形成有用的格式 [PW92]。這些設計選項必須取決於功能和增補需求及其他限制。但這些選項反過來會限制更低層次的需求和未來的設計決策。

一套典型架構觀點

架構有許多不同的架構觀點,這些觀點在本質上就是模型的「重大架構性」元素的摘要闡述。在 RUP 中,一開始從一套典型的觀點下手,稱為「4+1 觀點模型」[KRU95]。包括:

  • 使用案例觀點此觀點包含使用案例和情境,內含在架構上重要的行為、類別或技術風險。此觀點是使用案例模型的一部份。
  • 邏輯觀點,此觀點包含最重要的設計類別及其形成的套件子系統,以及這些套件和子系統形成的。也包含一些使用案例實現化。屬於設計模型的一部份。
  • 實作觀點此觀點以形成套件和層的模組,提供實作模型及其組織的概觀。也描述套件和類別(來自「邏輯觀點」)如何對映至「實作觀點」的套件和模組。此觀點是實作模型的一部份。
  • 流程觀點,此觀點包含相關作業(流程和執行緒)的說明、互動和配置,以及從設計物件和類別至作業的對映。高度並行性系統才需要用到這項觀點。在 RUP 中,此觀點是設計模型的一部份。
  • 部署觀點,此觀點包含最常見的平台配置中各種實體節點的說明,以及作業(來自「流程觀點」)至實體節點的對映。分散式系統才需要用到此觀點。此觀點是部署模型的一部份。

軟體架構文件中詳細說明架構觀點。您可以構想其他觀點來表達不同的特殊議題:使用者介面觀點、機密保護觀點、資料觀點等,諸如此類。在簡單的系統中,您可以省略 4+1 觀點模型的部份觀點。

架構焦點

雖然上述觀點可代表系統的整體設計,但架構本身只著重在一些特殊的層面:

  • 模型的結構 - 組織型樣,例如分層
  • 必要元素 - 重要使用案例、主要類別、一般機制等,相對於模型中所有的元素。
  • 一些關鍵情境,顯示整個系統的主要控制流程。
  • 服務,探索模組性、選用功能、產品線範疇。

在本質上,架構觀點是整個設計的抽象或簡化,不考慮細節,更明確指出重要的特性。在做以下的推理時,這些特性很重要:

  • 系統演進 - 進入下一個開發週期。
  • 架構或其一部份在產品線的重複使用性。
  • 增補品質的評估,例如效能、可用性、可攜性及安全性。
  • 對於團隊或轉包商的開發工作分配。
  • 採用現成元件的決策。
  • 納入更大的系統中。

架構型樣

架構型樣 是現成的格式,可解決一再出現的架構問題。架構框架架構基礎建設(中介軟體)是可供建置特定架構的一組元件。許多主要架構性難題都應該在架構或基礎建設中解決,通常以特定領域為目標:指令和控制、MIS、控制系統等。

架構型樣的範例

[BUS96] 依據系統最適用的架構型樣,以系統的特性將架構型樣分組,其中以一個種類來處理較普通的結構性議題。下表顯示 [BUS96] 中提出的種類及其包含的型樣。

種類 型樣
結構 分層
管道和過濾器
黑板
分散式系統 代理程式
互動式系統 模型觀點控制器
呈現抽象控制
調適性系統 反射
微核心

這裡詳細討論其中兩種,以釐清這些觀念;如需完整的論述,請參閱 [BUS96]。型樣採下列常用的格式來表達:

  • 型樣名稱
  • 環境
  • 問題
    • 論點,描述應該考量的不同問題層面
  • 解決方案
    • 理論根據
    • 形成的環境
    • 範例
型樣名稱

分層

環境

需要分解的大型系統。

問題

必須以不同抽象程度來處理問題的一個系統。 例如:硬體控制問題、一般服務問題及特殊領域問題。撰寫垂直元件來處理所有層次的問題是相當不理想的作法。相同的問題將會重複在不同的元件中處理(可能不一致)。

論點

  • 系統組件可更換
  • 元件的變更不該引起連鎖衝擊。
  • 相似的責任應該歸成一類。
  • 元件的大小 - 可能必須拆解複合元件.
解決方案

將系統設計成許多群元件,形成彼此重疊的分層結構。上層只使用下層的服務(絕不會用到上層)。儘量不要使用直屬下層以外的其他服務(不要跳層,除非中間的層只是加入透通元件而已)。

範例:

1. 通用層

圖解說明詳見下文。

嚴格的分層式構造顯示設計元素(類別、套件、子系統)只使用直屬下層的服務。服務包括事件處理、錯誤處理、資料庫存取等,諸如此類。相對於低層提供的原始作業系統層次呼叫,愈上層的機制愈具體可見。

2. 商業系統層

圖解說明詳見下文。

上圖顯示另一個分層範例,其中有垂直的特定應用程式層及水平的基礎架構層。請注意,目標是儘量減少「多頭馬車」的情況,善用應用程式之間的共通性。 否則,將有許多人重複解決相同的問題,還可能各以不同的手法解決。

關於此型樣的詳細討論,請參閱準則:分層

型樣名稱

黑板

環境

有一個領域沒有已知或可行的明確(演算)方法可解決問題。例如 AI 系統、語音辨識及監控系統。

問題

必須由多個問題解決代理程式(知識代理程式)共同合作,才能解決任何單一代理程式所無法獨立解決的問題。每個代理程式必須彼此分享工作成果,以評估是否能夠提出解決方案,展現工作的成果。

論點

  • 知識代理程式在解決問題時沒有一定的順序,可能隨問題解決策略而定。

  • 不同代理程式提出的成果(結果或部份解決方案)可能有不同的表示法。

  • 代理程式無法直接得知彼此的情況,但可以評估彼此貢獻的成果。

解決方案

許多「知識代理程式」(KnowledgeAgent) 可存取一個共用的資料儲存庫,稱為「黑板」(Blackboard)。黑板提供一個視察和更新內容的介面。控制 (Control) 模組/物件會根據某些策略來啟動代理程式。在啟動之後,代理程式緊接著會視察黑板,瞭解在問題解決上是否能有所貢獻。如果代理程式認為可以提出貢獻,控制物件可讓代理程式將部份(或最終)解決方案公佈在黑板上。

範例:

圖解說明詳見下文。

圖中顯示以 UML 塑造的結構性或靜態觀點。這是參數化合作的一部份,最後會連結至實際參數來導出型樣的實例。

架構樣式

軟體架構(或只是架構觀點)可能有一個稱為架構樣式的屬性,此屬性可縮減可供選擇的格式數量,並在架構上施以某種程度的統一性。 樣式可能由一組型樣來定義,或由特定的元件或連接器來定義,形成基本的建置區塊。在特定的系統中,架構樣式手冊的架構說明中可擷取到一些樣式 - 透過 RUP 的專案特定準則工作成果來提供。在架構的理解性和完整性上,樣式扮演重要的角色。

架構藍圖

架構觀點的圖形表達方式稱為架構藍圖。就上述各種觀點而言,藍圖由下列「統一建模語言」圖解組成 [UML01]:

建構流程

在 RUP 中,架構是分析與設計工作流程的主要成果。隨著專案重新執行此工作流程,經過反覆推敲,架構會逐步趨向精煉和優美。由於每一次反覆都會整合和測試,等到交付產品時,架構已相當健全。此架構是詳述階段的反覆重點,等到結束時,通常也就底定架構。