台灣最大程式設計社群網站
線上人數
1666
 
會員總數:245141
討論主題:189045
歡迎您免費加入會員
討論區列表 >> 專欄文章 >> 漫談高鐵訂票系統的結構分析—觀念篇
[]  
[我要回覆]
回應主題 加入我的關注話題 檢舉此篇討論 將提問者加入個人黑名單
漫談高鐵訂票系統的結構分析—觀念篇
價值 : 0 QP  點閱數:1681 回應數:0

樓主

Kenming
初學者
20 53
874 3
發送站內信

我在網路上看了諸多評論「高鐵訂票系統」重複訂位相關問題的文章與討論串,大部分的 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 班次」以及「SpecificlSeat」兩個子型態(SubType)的物件中。

這樣設計的結構最大的好處是:
當我們發現未來高鐵的軟硬體設施真的如同飛機一樣,可以讓乘客先行訂位,之後才在各自搭乘的櫃臺進行「Check-in」以確認其真實的位置,此時,我們只要再重新「Plug-in」「Specific 班次」的物件到高鐵的訂票系統中就可以了!

至於第二個問題,則是整體 IT 結構規劃的問題。也就是說,由於沒有對整體的系統結構作一個有效的區分,而導致 系統面 與實際 問題領域(ProblemDomain) 面糾纏不清,大幅增加了整體應用系統的複雜度與管理成本。這個部分的問題,其實可以用 "Boundary-Control-Entity" 的 分析層次的設計框架 來予以解決。關於實作的相關設計議題,我們留待實作篇再來討論。

=$∼寸心千里∼$=
= blog: http://www.kenming.idv.tw/
= 軟體課程訊息與論壇: http://www.hsdc.com.tw/

搜尋相關Tags的文章: [ hsdc ] , [ 高鐵 ] , [ 物件導向 ] , [ 訂位系統 ] , [ object ] , [ 軟體工程 ] ,
本篇文章發表於2007-04-23 16:43
== 簽名檔 ==
= 寸心千里=
= blog: http://www.kenming.idv.tw/
= 軟體課程訊息 http://www.hsdc.com.tw/
別忘捐VP感謝幫助你的人 新手會員瞧一瞧
目前尚無任何回覆
   

回覆
如要回應,請先登入.