對這文章發表回應
發表限制: 非會員 可以發表
發表者： 冷日 發表時間： 2008/3/19 7:54:58
| 軟體設計美學之道第4回──要美麗先調體質 |
| 「架構」一詞意味著什麼呢？這個看似學術的名詞，其實在我們的日常生活中也常會聽到的，例如，文章架構、組織架構、發展架構，它在形容事物的一種風格、組織方式或著決策方向。 在這裏我們要談的是軟體架構，顧名思義它也是指軟體的一種風格、組織方式或著決策方向，不過這樣的解釋可能不好理解，畢竟軟體本身是一個複雜的創意。軟體架構的重要，就如同每個人的體質，從身體的最深處，一層一層的影響到外表的美麗。 軟體架構雜亂，專案失敗風險高 我曾經歷過一個經典且傳統的軟體專案，那是一個旅遊網站，旅客可以在網站上透過聰明的航程規畫精靈即時地比較機票的價格，然後直接訂機票並且線上付款，流程中幾乎不用和旅行社的票務人員交涉，除此之外，在那個網站上也可以查到各式旅行資訊。 和大部份的軟體專案一樣，在這個案子裏有一位野心勃勃的老闆，另外，我們有一些極熱心但是擁有類比腦（完全不懂電腦）的旅遊專家──就是票務小姐及票務經理，然後我們需要和信用卡系統及一個世界級，但是穩定度及整合介面是古蹟級的票務系統介接，最後還有一群從沒搭過飛機，但視加班為進補的程式開發人員，我們要做的系統包含了旅客會直接使用的訂票網、票務小姐管理票務的後臺系統、跨平臺介接的即時訂票系統及線上付款系統等等。 這個專案包含了許多不同的「角色」及「需求」。角色有旅客、老闆、票務人員及軟體開發人員等等。他們都有各自己的需求，例如，旅客希望票價便宜並且系統使用安全、方便及穩定、老闆希望以最少的成本及時間就能上線、票務小姐希望系統能減輕她們後臺票務的工作量、行銷業務希望什麼功能都有、開發人員希望系統設計彈性或者使用熟悉的技術來開發。 於是乎，開發人員為了符合大家的需求或者某個特殊活動的需要，開始了一夜夜悲壯的軟體開發戰役。而在系統尚未穩定之時，沒想到老闆竟想要複製「成功」經驗，開始建立兩岸三地的作戰堡壘，因此系統也由小恐龍漸漸地變成了究極大怪獸。 「使用介面風格不一致、訂票系統容易斷線、訂票回應速度太慢……」，一連串的問題陸續出現，然而最終沒有人真正了解問題的來源或者可以解釋細節。這個沒有人能控制的大怪獸終於帶來了最後的審判日──失敗的軟體專案。這個專案失敗的原因很複雜，包括了使用者接受度、商業模式（Business Model）、政治因素、專案管理控制等等，當然有很大的一部分原因是：它擁有一個雜亂的軟體架構及一個無法控制的系統。 軟體系統的最高指導原則 所謂的軟體架構，簡單的來說，就是定義一個軟體系統未來發展的「最高指導原則」，就像憲法一樣，在未來的發展中不可抵觸，例如，系統該分成哪些模組、要用哪些技術、元件間的溝通介面是什麼、元件間的互動行為要用哪些Pattern。 這些最高的原則當然是由各種需求或者開發團隊的能力分組所引導出來的，例如，分成三層，並分給三個不同能力的小組來完成，或者使用訊息中介軟體介接外部系統，縮短使用者的等待時間並增加系統的穩定度及可靠度等等。這些最高指導原則訂定了整個軟體系統發展的大方向，也等於限制住系統技術發展的最大範圍，進而防止系統開發走向錯誤的方向，並且讓開發人員有一個技術的依歸，可以踏實地完成系統開發。當然，憲法是可以修的，只不過必須經過正式的修憲會議而已，軟體架構也是一樣，不然在偏離架構範疇下所開發出來的軟體，最後還是很可能會誤入歧途而失敗。 在《Software Architecture in Practice》一書中，作者Bass、 Clements、Kazman對於軟體架構以比較學術的方式來解釋：「軟體架構是一種系統的結構，「包含」並「定義」了許多軟體元件及其間的組織方式和互動行為」。換句話來說，軟體架構有許多軟體元件、一個以上的結構以及它們之間的各種關係。除此之外，架構還包含了非功能面的條件，像是QoS（Quality of Service）或是SLR（Service Level Requirement），它包含可用性（Availability）、可信賴（Reliability）、可擴充（Scalability）和安全性（Security）等等。 上述這個定義也暗示著任何一個軟體系統都有軟體架構，只不過和系統本身的好壞無關。對於一個軟體系統來說，架構並沒有絕對的好與壞，只有適不適合而已。例如，一個時間緊迫並且規模小的網站系統，就沒有必要一定要用MVC的架構來開發，它也可以很簡單的利用Layer的觀念並且配合資料封裝技術來實作。建立軟體架構的關鍵在於能夠提供軟體系統未來實用而穩固的發展基礎，這是很重要的一點，因此架構不應由錯誤嘗試中得到，它應該是經過認真的設計及規劃出來的，而架構文件則是架構設計後所該留下的重要結果，也是未來開發的依據。清楚的架構設計有利於開發過程的「溝通」、系統的「演化」以及未來產品線開發的「再利用」。 平衡軟體專案元素，建立扎實軟體架構 通常一個軟體系統，打從娘胎開始就會不斷地受到各種需求的影響，但同時滿足所有的需求是不容易的，因為有許多的需求是相互抵觸或者是有隱含的意義。軟體的「開發過程」就是在協調及滿足這些需求，而過程中，如果沒有好好地規畫軟體設計的發展策略，軟體系統很容易會變成多頭馬車，進而演變出疊床架屋的架構，充滿隨時倒塌的危險。 架構師的責任就在於利用自己的經驗來「平衡」專案相關人員需求、開發團隊技術能力、技術環境及成本等元素，進而建立出扎實的軟體架構。雖然我們都知道軟體的本質是「恆變的需求」，但是在我們擁抱改變的信念下，還是不可能從咖啡機中煮出紅酒來的。 「軟體架構」就像是一個人的體質，它會影響軟體系統未來的生老病死，因此在開發軟體系統前，請先好好的調理它。 《作者簡介》葉政達 艾群科技研發中心技術經理，中原大學電子工程研究所碩士。 曾任職於網際商擎科技、台聯電訊研發工程師等職，專精於OOAD、軟體架構設計、Pattern、J2EE、J2SE、行動運算應用；通過SCEA、SCWCD、SCJP等認證。曾參與電子商務系統、航空即時訂票系統、SNMP網路管理產品開發、亞太電信QMA Image Solution、Sandio Mobile Sync產品設計開發等專案規畫建置。 |