對這文章發表回應
發表限制: 非會員 可以發表
發表者： 冷日 發表時間： 2008/3/19 7:55:34
| 軟體設計美學之道第5回──塑造軟體架構的美感 |
| 我們都知道，蓋房子都會有一個挖地基，打地基的步驟，而且依據房子的類型及用途，地基的工程以及結構的材料也會有所不同，這些都是經過建築師專業而仔細的設計及計算才得知的，為的是房子未來的安全及使用需求，甚至是施工過程的安全及順暢度等等。 軟體建造的道理，其實是一樣的，大家也都希望不僅開工順利，最後也驗收順利，最好是在保固期內，什麼事都不會發生。 建立軟體架構的目的，就在於提供系統一個穩固而堅實的發展基礎，而其具體的產出，就是一份軟體架構書以及依照架構書這個最高設計原則所建構出來的原型（Prototype）。這樣就可以讓後續加入的工程團隊遵循架構設計所表達的美感，並照著原型的建造工法，來繼續大部份尚未完成的工程。 當你決定使用以架構為中心的開發方式時，這兩個產出是連接架構設計階段及實作階段最重要的東西。當然，軟體架構的設計不是一、兩篇文章就可以解釋清楚的，本文僅將一些比較重要的概念及經驗提出來，希望能給初入門的讀者有個概括的認識。 所有的故事，都是從需求開始 任何一個軟體專案的開始，都是為了滿足某些特定的需求，這是一句廢話，但也是一句非常重要的話，因為當我們在塑造軟體架構的時候，顯性的需求或其所帶來的隱性特質，都可能是影響日後系統成功的關鍵。顯性的需求是客戶最直接的期望，他可以明確的告訴你說，他需要在某個畫面上加一個按鈕，讓使用者可以簡單的按下按鈕，就輕鬆地訂到機票並且自動地完成付款，但是客戶可能不會清楚使用者在按下這顆按鈕時，不希望等待時間超過10秒鐘，他更不會知道從按下按鈕，到系統完成所有的工作，是經過幾萬行的程式並和幾個外部系統連線後才會有的結果。而一百或者一千個使用者的規模，對於軟體架構以及開發成本，又有著截然不同的設計，往往客戶和開發人員的期待落差，就此產生。因此，影響軟體專案成敗的地方，大部份不是顯性的需求，而是隱藏在那背後的邪惡靈魂。 透視需求，找到架構觀點 不知道各位有沒有做過健康檢查？當你在健檢中心做檢查時，通常會有好多的關卡，而您會像過關斬將般地面對一站一站不同的儀器及醫生，每一站所檢查的內容都不一樣，例如骨科醫生看到的，是你的骨質狀況；腸胃科看的是你的腸胃健康，他們唯一做的同一件事，就是在檢查同一個你。 人類是一個完美而複雜的系統，人體的複雜當然不是只有我們看的到的外表，這是我們都能了解的事實，而軟體系統也是一樣。以UP（Unified Process）這個軟體開發方法論為例，它有幾種架構觀點（views）；使用案例觀點、邏輯觀點、執行觀點、部署觀點、實作觀點等等。這些軟體的觀點，就像是不同科的醫生對人所看到的不同觀點一樣，都是在描述同一個軟體系統。 設計架構的工作，其實就像醫生角色伴演的遊戲，你要伴演各科別的醫生，透視軟體系統，從外在功能面上的需求，找出隱含在各種觀點背後的需求，然後再像建築師，設計出滿足這些需求的架構。 顯性的需求通常所描述的是「使用案例」（Use-Case），這是以使用者的觀點來看系統的外觀長相，看的到的東西都是屬於功能性的需求，例如，會員管理、票價查詢、訂票等等。 在這些顯性需求背後所含的隱性特質，就是所謂的SLR（Service Level Requirement），其中包含了可靠性（availability）、可修改性（modifiability）、效能（performance）、安全（security）、可測試性（testability）、可使用性（usability）等等，而滿足這些從使用案例觀點所發覺出來的SLR，就是「邏輯觀點」以及其他的架構觀點的責任了。 滿足需求再描述設計 在滿足SLR及設計架構觀點的過程中，我比較建議從「邏輯觀點」開始，因為它是在描述軟體實作時所需的設計概念。在這個觀點裏，會有較高層次的設計元件，包括Package、Subsystem、Interface等等，它會直接影響到執行觀點以及實作觀點的設計，當然，部署觀點也是一樣。只不過通常部署觀點會有需多客戶本身的限制，例如，客戶需要用掉之前的機器庫存或者預算限制等等，因此在專案開始前，這個部份有時是被限制住的。其實這些架構觀點都會因為某些需求而互相影響，端看架構師的智慧及經驗來取捨。 對於這些架構觀點詳細的說明或舉例，因為篇幅的關係，建議各位去讀讀UP相關書籍及Craig Larman所著的《Applying UML and Patterns》一書，大家會有更清楚的了解。 「凡走過，必留下痕跡」，以上所說的種種觀點，如果沒有記錄下來，架構的設計也就沒有意義了，一般來說，我們會將這些設計內容一一地寫到所謂的SAD（Software Architecture Document）－軟體架構書裏，這是系統未來開發的最高指導原則。而為了系統後續的開發順利，在SAD完成後，我們還必須分析並找出架構設計裏面的指標因子，例如風險較高的技術、連接子系統的關鍵、影響程式撰寫風格的部份等等，然後進行細部設計及實作這些指標因子，使成為所謂的Prototype。接下來，開發團隊的大部份成員就可以遵循著SAD及Prototype的腳步，比較穩健而安全的開發下去。 用Pattern的美感來表達軟體架構 Pattern是一個很重要的軟體設計技術，從定義中我們可以知道它是在一個特定背景下，已被命名而且為了解決某個特定問題的解決方案，而Architectural Pattern更是針對架構性的問題所發展出來的，例如在POSA1所提的，Layers、Broker、MVC等等。現在世面上所流行的技術或Open Source Framework，像是RMI、Struts等等，都是基於上述的Architectural Pattern所發展出來，當然，在做架構設計時，reuse這些技術框架也是省時方便的策略。 一般的軟體技術，如OO的基本原則，或者系統分析設計方法並不一定能真正地解決特定的SLR，因此這些已驗證過的Pattern可以做為設計軟體架構時，滿足特定隱性需求最佳的架構單位，除了利用Pattern來建構一個穩固的軟體架構之外，其利於溝通的特性讓你容易地將你的設計記錄在SAD裏並讓後續的開發團隊易於了解。讓自己的「創意」經由「溝通」而能確實實現，我想是這是每個軟體人的希望吧。 對於這些架構觀點詳細的說明或舉例，建議各位去讀讀UP相關書籍及Craig Larman所著的《Applying UML and Patterns》一書，大家會有更清楚的了解。 《作者簡介》葉政達 艾群科技研發中心技術經理，中原大學電子工程研究所碩士。曾任職於網際商擎科技、台聯電訊研發工程師等職，專精於OOAD、軟體架構設計、Pattern、J2EE、J2SE、行動運算應用；通過SCEA、SCWCD、SCJP等認證。曾參與電子商務系統、航空即時訂票系統、SNMP網路管理產品開發、亞太電信QMA Image Solution、Sandio Mobile Sync產品設計開發等專案規畫建置。 |