對這文章發表回應
發表限制: 非會員 可以發表
發表者： 冷日 發表時間： 2008/3/14 9:04:44
| 先從觀點看架構 |
| 筆者首先以「觀點（Viewpoint）」一詞來解釋架構。要能具軟體架構的整體與協調性，最起碼要能有三個觀點： 1.需求面的觀點 2.結構面的觀點 3.實作面的觀點 ● 需求面的觀點： 需求（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）等，是否有違背原先所承諾客戶的結構設計。 |