軟體架構是一種簡單的概念,大多數工程師都可以直覺地理解,尤其是稍有經驗的工程師,但很難準確定義。尤其,很難清楚界定設計和架構的差別 - 架構是一種特別關切某些特性的設計。
在 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 中,架構是分析與設計工作流程的主要成果。隨著專案重新執行此工作流程,經過反覆推敲,架構會逐步趨向精煉和優美。由於每一次反覆都會整合和測試,等到交付產品時,架構已相當健全。此架構是詳述階段的反覆重點,等到結束時,通常也就底定架構。
|