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