從觀點來解釋架構 — Kenming 看架構 <1>

前言:

架構(Architecture)一詞,非常之難解釋。

若真要一言以蔽之,那麼,可以說,”架構” 是一種整體觀,需要保持從各角度看待架構時,仍有一致性與調和的觀點。

對 ”架構” 要能有充分的理解與認識,至少要能確實瞭解與體會下列幾個與架構至為關鍵的意涵與術語,包括了:整體、觀點(View),包括巨(Macro)觀與微(Micro)觀、焦點(Focus)、層次(Layer)、廣度(Boundary)。

擔任軟體架構師(Software Architect)必備的素養,即在於:觀照整體的能力。

經常我在輔導許多軟體公司的專案開發與教育訓練時,發現到與開發團隊對 “架構” 一詞的認知與定義大不相同。我發現到,大部分的 IT 技術開發人員,所表達出來的架構,是比較偏向於實體層次如 .NET, J2EE 的 IT 技術層次。不是不對,而是 IT 實體層次僅是架構的觀點之一,並不足以代表整體的架構觀。

我想試著利用以上述幾個術語來解釋 “架構”。畢竟,架構的設計,牽涉到相關於設計中系統的議題與範圍太廣了,包括:團隊開發的共識、開發流程(Development Process)的制訂,分工與外包(Outsourcing)控管、系統的彈性、延展(Scalibility)與維護性等。

金剛經有云:「凡所有相,皆屬虛妄,見諸相非相,即見如來」。

“相”,是被具化、可以看得到的形,如同軟體模型,是被具化的產出(Artifact),也就是 “相”。而 “如來”,是不著相的,架構即為如來,所以架構也可以說是一種空、無。

問題來了,既然不著相,你又如何知道何為正道,何為如來?
佛教禪宗有個「以指標月」的譬喻:對於一個從不來不知月亮為何物的人,在蒼茫的星空中,不知那一個叫做月亮,這時候就需要一個認識月亮的人,用手指著月亮說:「那就是月亮」。

同樣的道理,你又能如何瞭解甚至來驗證架構(如來)的正確性呢?
有經驗的架構師(Architect),以各種不同的角度(以上所涵蓋的幾個術語),建構各類型的軟體模型,來看待並解釋「架構」。如同「以指標月」一般,對架構有深一層體會的架構師,會以導師(Mentor)的角色,利用各種工具來具化產出,以引導軟體設計師認識「架構」。

所以,UML, 程式碼等只是個標示工具,真正的「架構」是要靠自己去體會的。

觀點(Viewpoint)

我想首先以 “觀點(Viewpoint)” 一詞來解釋架構。

要能具軟體架構的整體與協調性,最起碼要能有三個觀點:

ˇ 需求面的觀點
ˇ 結構面的觀點
ˇ 實做面的觀點

● 需求面的觀點:
需求(Requirement),代表著的是系統外部的觀點,也就是從 “Actor” 的角度來看待系統,系統所該提供的功能(Function)。

我會建立使用案例模型(Use Case Model),來代表需求面的觀點,每一個使用案例,即代表系統所該履行的功能。

使用案例模型的建立,我會視系統規模的廣度,來決定是否建立企業使用案例(Business Use Case Model)模型與系統使用案例模型(System Use Case Model)。

不以使用案例模型來代表需求面的觀點,未嘗不可。例如,利用如 XP(Extreme Programming) 的使用者陳述(User Story)來紀錄系統的功能點(Functional Point),當然可以更形簡化需求面的陳述。只是,我個人是偏好於利用視覺化來建立各種觀點的模型,感覺會更有助於對整體系統的瞭解。尤其是,我經常以 “套件圖(Package)”,表達在使用案例圖內,子系統與子系統之間範圍的界定與溝通。

範例-企業使用案例圖
圖、範例-企業使用案例圖(縮略圖,點擊圖片鏈接看原圖)

範例-系統使用案例圖
圖、範例-系統使用案例圖(縮略圖,點擊圖片鏈接看原圖)

● 結構(Structure)面的觀點:
系統的結構設計,可以說才是決定系統的彈性、延展、效能、穩定等主要成敗因素。

國內軟體專案的開發,絕大部分並不重視系統的結構設計。主因在於專案開發時程偏短線的不合理、軟體人員對結構設計未能俱足抽象與實務並重的技能,以及內部的結構是客戶所看不到,並且短期無法能感受到的。專案開發因重視短線立即性的效果,所以反而以功能需求面、使用者介面(UI)為主要的開發重點。

這如同購買房子一樣,一開始因為樣品屋美輪美奐的室內佈置(UI),以及附贈許多的家具、生活用品(功能),卻忽視掉房屋的結構設計。短期感受不到問題,住久後才逐漸顯現出如漏水、海砂屋甚至因鋼架的偷工減料而導致強烈地震一來即崩垮的慘劇。

軟體的結構模型,至少有兩個主要的產出:類別(Class)設計圖與循序(Sequence)圖。

類別圖表達的是系統的內部靜態結構;循序圖表達的是系統內部元素(稱之為物件比較理想)之間,為完成某一交付的任務(系統功能),物件之間互動合作的動態行為。

傳統的軟體結構分析與設計,會以為主要的工作是建立資料庫的 E-R(Entity-Relationship) 模型。這該算是靜態結構設計的一種退化解,雖然 E-R 圖是以問題領域(Problem Domain) 的術語作為分解的依據,這與類別圖設計的分解思維是一致的。不過最主要的問題,仍在於 E-R 圖的分解元素沒有自主性的行為(Behavior)能力,把行為抽離出來而分散至 Form Script, Web Page, Stored-procedure …, 甚至亂分一番,隨便實做某個物件,把演算邏輯 “塞” 進去就號稱為物件導向設計。

行為的分散,造成系統彈性與維護的困難性,是注重以 E-R 資料模型為結構設計主體的問題點。類別圖(Class Diagram),回歸至本質面,把資料與行為有效歸納至所該承擔的物件上。類別圖的設計最困難與謹慎之處,即在於如何有效分派責任(Responsibility Assign)至物件上。

結構的設計,若以層次(Layer)之分,又分為高階抽象的領域模型,與細部、平台面相依的軟體規格模型。層次的問題,我會以另外一個主題:從層次來解釋架構時,來討論之。

越是高階、抽象的結構模型,會比較偏向於 “本質面”,當越能抽至最接近本質面的那一層,結構越為穩定。越接近本質面的那一層,其呈象反而越是簡單(Simple),但是,要能呈現出簡單,本身卻不簡單,是最為難之分析、設計的。

理由是,結構設計師需要非常高度的抽象理解能力。抽象能力的培養,講究悟性,左、右腦需能平衡協調,絕非純左腦邏輯的分析,也無法利用所謂的方法論(Methodology),以所謂的 “規則” 來套用。這是 “純(Pure)” 軟體設計的修練,起碼要花上 5~10 年以上(最保守的估計),培養個人的反思與創意思考能力,來鍛鍊對軟體設計的基本功夫。

範例-高階類別圖
圖、範例-高階類別圖(縮略圖,點擊圖片鏈接看原圖)

範例-高階循序圖
圖、範例-高階循序圖(縮略圖,點擊圖片鏈接看原圖)

● 實做面的觀點:
程式碼(Source Code) 是實做最主要的產出,也可以說是最直接、有效的產出。因為,無論你的設計圖作得多棒,卻很難以工具來驗證、測試其正確性。但是,程式碼,經過語法檢查、編譯後,能不能執行,馬上就可以知道,並且可以透過各種的測試機制,來測試包括功能、效能、容錯(Fault Tolerance) ...等各類的測試項目。

從實做面的觀點,我個人一直大力主張要能針對系統功能作測試自動化,而不要僅流於紙張上的測試案例。功能絕對會善變,功能一變,測試程式碼就必須得跟著改變,否則無法通過自動化的測試。

這非常重要,因為會直接影響到 “驗收” 這一環節。這裡我太認同 XP 其中之一的實務;測試先行(Test First)。由客戶撰寫測試的情節(Scenario)與提供測試相關的數據;開發團隊負責撰寫測試程式碼。

使用者接受度測試(UAT, User Acceptance Test),是可以透過撰寫功能測試程式碼來達到自動化的測試,不過,卻無法測試程式碼的結構內涵。

結構的測試,更是一個重要的議題。有太多的軟體開發單位,是先寫程式碼,再反轉回(Reverse)設計圖,把設計圖當文件(Document)交差了事。這很危險,脆弱的結構,是導致系統複雜難以維護,以及無法應變的主因。

我會利用如 Together, EA(Enterprise Architect) 等 UML 工具,幫程式碼照 “X” 光,檢驗其脈絡。反轉程式碼,呈現視覺化的模型後,最重要的是檢查元素的相依性(Dependence),從巨觀包括子系統、模組,至微觀包括套件(Package)、元件(Component)等,是否有違背原先所承諾客戶的結構設計。

範例-利用 Borland Together 檢視套件與類別的相依性關係
圖、範例-利用 Borland Together 檢視套件與類別的相依性關係(縮略圖,點擊圖片鏈接看原圖)

補充— RUP 的 4+1 觀點(View)

以上三個觀點應該算是最簡化的了,是我認為最起碼該具備的,才有可能從不同角度,仍能以一致、整體性,來看待架構。此外,這裡再補充,RUP 對架構的解釋,它以是所謂的 “4+1 View” 來說明架構。

RUP(Rational Unified Process) 的開發模式,係以架構為中心(Architecture-Centric)的流程,當組織或團隊對架構的呈現方式已經取得共識,認為它符合手上的問題後,下一個議題就是學會架構設計的流程與規劃(Architectural Design Process)。

RUP 利用從五個架構觀點的方式,來簡化對架構的描述(或稱之為抽象化)。每一個觀點,會涵蓋了與之相關特殊的考量點,而忽略跟該觀點無關的東西。對每一個觀點,需要清楚找出:

  • 觀點 – 我們希望專注的考量點和關係人。
  • 觀點中所捕捉並呈現的元素和它們之間的關係。
  • 建立觀點元素與其它觀點元素之間的關係。
  • 建立觀點的最佳流程。

如下圖,RUP 所建議五個觀點方式。而其中,係以使用案例(Use Case)的觀點來驅動(Drive)其它四個觀點,所以,又稱之為 4+1 架構觀點的模型。

RUP 4+1 架構觀點的模型(摘錄自 Philippe Kruchten “The 4+1 View Architecture”)
圖、RUP 4+1 架構觀點的模型(摘錄自 Philippe Kruchten “The 4+1 View Architecture”)
(縮略圖,點擊圖片鏈接看原圖)

● 邏輯觀點(Logical View)
此架構觀點專注在系統的功能性需求(Functional Requirement),也就是說,系統該為終端使用者(End-User)做到的事。
邏輯觀點是設計模型(Design Model)的抽象概念,用來找出在分析與設計階段時的類別(Class)、子系統(Sub System)、主要套件(Package)。
例子包括訂購、訂購細項、顧客、產品和產品型錄等套件。

● 實做觀點(Implementation View)
此架構觀點利用套件與階層(Layer)或組態管理(Configurement Management)來描述開發環境中靜態軟體的模組(Module)、原始碼(Source Code)、資料檔、元件(Component)、可執行(Executable)碼和其它工作成果等組織。
它專注再容易開發、軟體資產管理、可再利用性(Reuse)、外包和客製化元件等議題上。
例子包括訂購子系統的原始程式碼。

● 程序觀點(Process View)
此架構專點專注在執行期間(Runtime),系統的並行性(Concurrency),包括工作(Task)、執行緒(Thread)或程序(Process)、交易(Transaction)、安全性(Security)以及資源(包括資料庫連線與物件個體數)管理等範疇。
程序的觀點,會視專案規模的大小,而有不同的應對與處理方式。
例子包括訂購系統如何處理超過同時上線客戶的人數超過 5000 人,仍能包持系統的穩定度與效能(如3秒內完成訂購的交易)的處理。

● 配置觀點(Deployment View)
此架構觀點展現不同的可執行(Executable)和其它執行時期(Runtime)元件,如何把它們配置(Deploy)在基本平台或運算的節點(Node)上。
此一觀點,會處理配置、安裝和效能等議題。
例子包括在 Windows 2000 上,安裝了 IIS 以及 .NET Framework、MTS(Microsooft Transaction Service)等應用伺服器,然後在其內配置了訂購系統,並連接另一台同為 Windows 2000 系統、安裝了 SQL Server 2000 的資料庫系統。

透過 “以使用案例為驅動” 的架構觀點,更能清楚瞭解在每一個流程的核心工作流程,其主要的設計模型產出與產出之間的關係。參考如下圖。

”流過” 各種模型的使用案例(摘錄 “The Rational Unified Process An Introduction 2nd))
圖、”流過” 各種模型的使用案例(摘錄 “The Rational Unified Process An Introduction 2nd))
(縮略圖,點擊圖片鏈接看原圖)

文章導覽

   

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *