23 四月, 2007 16:34
漫談高鐵訂票系統的結構分析—觀念篇
由 Kenming Wang 發表於 [ 軟體思維與觀點 , 高階系統分析與設計 , 實作(程式)層次的設計觀點 ](12434) 閱讀, (0) 引用, (10) 回應 ,
推文( 0 )
我在網路上看了諸多評論「高鐵訂票系統」重複訂位相關問題的文章與討論串，大部分的 IT 人，謾罵聲不斷，認為該檢討承包系統開發的廠商；也有一小部份人提出自己的看法與建議的解決方案。這非常好，系統的不穩定性造成民眾的不便，本來就該有人監督，廠商也應該虛心接受眾多人所給予的建議。個人並不打算批判，以擔任軟體架構顧問的角度來看此事件時，先找出根本的問題是什麼，然後再提出具體的解決方案。我打算分兩篇文章論述，一篇為觀念篇；另一為實作篇。觀念部分，希望能就系統的結構性來探討；實作部分則會提出整個系統分析設計的過程與實作碼的產出，同時也打算模擬數千至數萬人同時訂票的情境與意外的處理，應該是盡量會接近原廠商所使用的平台(J2EE Solution)。當然，個人更是歡迎，若有機會，原廠商可以找我們過去聊聊，我們絕對很樂意效勞，也願意更進一步說明我們所診斷出來的問題，並且提供開出的處方為何。
一般看待高鐵訂票系統之所以出問題，原因有二：
- 經營者的看法與實際使用有落差：
持這種觀點的人，主要是著眼在經營者提出利用「飛機訂票系統」的觀念來實做高鐵的訂位，實際上並不恰當，飛機的訂位主要是預定「航班」，而實際的劃位則必須在各自的機場櫃臺進行Check-in，這與高鐵的座位預售，明顯有相當大的差距。 - 實做平台的考量上，未考慮到分散式交易：
這種看法大多是資訊專業人員的看法，也就是說，由於未考慮到各售票單位(包括櫃臺以及售票機)對於某一個已訂位的位置的交易，造成在同一時間內，多個售票單位可以販售同一個位置的現象，這主要是屬於「Transaction Lock」的問題。
事實上，這兩個問題都是存在的，然而，這卻不是造成高鐵訂票系統出問題的「主要原因」！ 無論是持哪種看法，其實都是「見樹不見林」，忽略了整體軟體設計最重要的核心 - 「軟體結構」的問題。
先從第一個觀點說起：
使用者需求本來就是會不斷地變動，然而，身為軟體設計人員，在開始進行系統分析設計時，本來就應該要想到「使用者需求」是「暫時」的，然而，重點應該是在於軟體結構本身，能不能夠充分地配合使用者需求的變動而有所彈性；因此，把系統出問題怪罪到使用者需求的變動，是軟體設計人員的「墮落」！
從上述的例子來說，使用者雖然在一開始就提出了不正確的需求，但是，當管理者在上線前一、兩個月就發現了這個「重複訂位」的問題，軟體設計人員卻沒有辦法在這段期間內修復這個問題，這很明顯地，並非是單純的「需求變動」而已，勢必是整體的軟體結構發生了大問題，造成了「地基不穩」，以致於「挖東牆補西牆」，永遠沒有辦法確實解決這個問題。
再從第二個觀點來看：
Transaction 的問題，其實是資訊系統管理面「最基本」的問題，套用前述的觀點，怎麼有可能在一、兩個月前發現這個問題，卻拖了一、兩個月都沒有辦法解決，這也很明顯地，勢必是在結構上出了嚴重的問題，以致於根本沒有辦法對症下藥。
那麼，軟體結構究竟是出了什麼問題呢？ 以下，我們就上述兩個現象分別來說明：
第一個現象主要是軟體的整體結構不夠穩定，而且缺乏彈性，因此，當使用者的「企業規則」(Business Rule)有所變動時，系統沒有辦法快速因應。
這很明顯地，是設計人員在設計系統時，並沒有針對企業的應用系統結構進行良好的分析，致使在捕捉系統的「本質性物件(Essential Object)」時，出了大問題。本質性物件沒有辦法捕捉好，自然而然對於整體系統的未來彈性，就很容易出嚴重的問題。什麼叫「本質性物件」呢？ 其實就是無論企業的作業流程(Process Flow)或是企業的使用者需求(User Requirement)如何變動，但是其基本的結構都不會輕易改變的那些重要概念(Essential Concept)，就是所謂的本質性物件。
我們以高鐵訂票系統為例，其本質性物件其實非常單純，我們以 UML 標準的 類別圖(ClassDiagram)來表達：
（點擊圖片鏈接看原圖）圖、高鐵訂購系統的核心結構
從這張圖中，其實就可以看出個端倪：
左下角的兩個物件：Seat 與 班次，主要是由高鐵人員自行維護的相關基本資料，然而，所有的重點應該在於「訂票交易」與「訂票Demand」這兩個物件上。
從訂票交易來說，其只要能夠提供起站及下車站給「訂票Demand」的物件，不管究竟是像飛機的依班次決定是否有空位；或是像現在高鐵實際營運的依特定座位決定是否有空位，其實，該訂票Demand物件只要回答「可不可以訂位」就可以了！
至於其實做的相關細節，應該都被隱藏在「Specific 班次」以及「SpecificSeat」兩個子型態(SubType)的物件中。
這樣設計的結構最大的好處是：
當我們發現未來高鐵的軟硬體設施真的如同飛機一樣，可以讓乘客先行訂位，之後才在各自搭乘的櫃臺進行「Check-in」以確認其真實的位置，此時，我們只要再重新「Plug-in」「Specific 班次」的物件到高鐵的訂票系統中就可以了！
至於第二個問題，則是整體 IT 結構規劃的問題。也就是說，由於沒有對整體的系統結構作一個有效的區分，而導致 系統面 與實際 問題領域(ProblemDomain) 面糾纏不清，大幅增加了整體應用系統的複雜度與管理成本。這個部分的問題，其實可以用 "Boundary-Control-Entity" 的 分析層次的設計框架 來予以解決。關於實作的相關設計議題，我們留待實作篇再來討論。
台鐵火車售票系統也適用嗎
看了那麼多關於他們系統問題的分析，包括iThome自己的報導，終於覺得看到比較像是真的的說法了...
期待大大的實作篇