背景：昨天元宵佳節同事聚餐，大家聊起今年的網上訂票系統，譭譽參半呀。從程序員的角度我們是怎麼看這個鐵老大斥資幾千萬的大系統的，這裏我就不說了。要寫的是如果我是這個系統的架構師（呵呵誇口了，如果也許假設是，然而未必不見得，嘿嘿），我會如何設計這個系統。2月我會利用零星的時間，就這個系統演練下系統設計的能力，作爲這個月送給自己的玩具，呵呵，不足之處歡迎大家批評指正踊躍拍磚。
目標：
本系統主要實現對火車車次的查詢、車票預訂功能。
關注在大用戶量集中訪問情況下，比如春運訂票高峯期，系統承載能力。
當然細節方面也要注意系統的易用性、用戶體驗，比如在查詢兩車站間沒有直達車時給出中轉站，輸入車站名簡稱時有提示，管理員可修改預售期、增減車次信息等。
功能：
- 兩站之間的車次查詢
- 具體某車次的查詢
- 進出某車站所有車次的查詢
- 車票預訂（車票預定後，所需的座位被聲明，其餘座位解鎖）
- 乘客取票（首先根據身份證號查詢訂單，然後修改訂單狀態）
- 用戶的註冊和登錄，修改密碼
- 訂單管理（訂單的查詢和撤銷等）
- 後臺管理員系統（編輯列車、車票、預售期等相關信息）
系統設計：
一、分析階段
（1）需求分析
- 業務需求：本系統主要的業務需求包括車次查詢、車票預訂
- 用戶需求（用例圖描述）：
- 行爲需求（用例規約描述）
（2）領域建模
首先按照功能進行模塊化的分離。
然後對分離出來的模塊進行抽象。下面以查詢和預訂模塊爲例：
二、架構設計階段
1. 概念型架構設計
（1）確定關鍵需求
車票預訂是本系統的關鍵需求。
（2）概念性架構設計
步驟一、魯棒性分析
魯棒圖（靜態）：
魯棒順序圖（動態）：
步驟二、 引入架構模式
步驟三、 質量屬性分析
2. 實際架構設計
(1) 邏輯架構
車票預訂的邏輯架構如下：
車票查詢的邏輯架構如下：
票的狀態圖如下：
(2) 開發架構
(3) 運行架構
(4) 物理架構
(5) 數據架構
附加：
- 可增加求購和轉讓信息發佈功能。
- 恰當使用AJAX技術進行信息的異步傳輸。
- 經常查詢的數據要設置緩存。
- 系統可以擴展個make charge的模塊，調用服務商提供的接口，這樣就可以增加信用卡或支付寶支付功能，最好還能提供送票服務。
- 注意半段的車票可以繼續出售問題的設計。
- 注意學生票、軍人票等特殊票種的處理情況。
準備知識：
(1) 邏輯架構
l 思想：
邏輯架構的設計着重考慮功能需求，即系統應向用戶提供什麼服務。
規定了軟件架構由哪些邏輯元素組成，以及這些邏輯元素之間的關係。
邏輯架構的設計往往是從用例分析開始的，然後綜合這些用例分析成果，得到整個軟件系統的邏輯架構。
邏輯架構設計要實現層、子系統、模塊等的劃分決定交互接口和交互機制（交互機制是指不同軟件單元之間交互的手段。交互機制的例子有：方法調用、基於RMI的遠程方法調用、發送消息等。）
l 關注點：功能需求、行爲和職責的劃分，將不同的職責分配給邏輯層、功能模塊、類等不同力度的邏輯單元。
l 工作任務：
Ø 細化功能單元
Ø 發現通用機制（機制Mechanism是模式的實例。機制必須進一步細化才能成爲特定模型中的協作，因此機制是獨特上下文中重複出現的問題的特定解決方案。）
Ø 細化領域模型
Ø 確定子系統接口和交互機制
l 描述方式：
靜態：包圖、類圖、對象圖。
動態：序列圖、協作圖、狀態圖、活動圖。
(2) 開發架構
l 思想：開發架構的設計着重考慮開發期質量屬性，例如可擴展性、可重用性、可移植性、易理解性、易測試性等。
l 關注點：軟件模塊的實際組織方式，具體涉及源程序文件、配置文件、源程序包、編譯及打包後的目標文件、第三方庫文件等。
l 工作任務：
Ø 確定要開發或直接利用的程序包之間的依賴關係
Ø 確定採用的技術
Ø 確定採用的框架等
l 關係：
開發架構和邏輯架構是什麼關係？開發架構和邏輯架構之間存在一定的映射關係：比如邏輯架構中的邏輯層一般會映射到開發架構中的多個程序包；開發架構中的源碼文件可以包含邏輯架構中的一到多個類。
l 描述方式：包圖、類圖、組件圖。
(3) 運行架構
l 思想：運行架構的設計着重考慮運行期質量屬性。
l 關注點：進程、線程、對象等運行時概念，已經相關的併發、同步、通信等問題。
l 工作任務：
Ø 確定引入哪些進程與線程
Ø 確定主動對象、被動對象、以及控制流關係
Ø 處理相關問題：進程線程的創建、銷燬、通信機制、資源爭用等
Ø 協議設計（可選，例如基於TCP/IP協議定義本系統的“應用協議”）
l 關係：
開發架構和運行架構是什麼關係？開發架構偏重程序包在編譯時期的靜態依賴關係，而這些程序運行起來之後會表現爲對象、線程、進程，運行架構比較關注的是這些運行時單元的交互問題。運行架構是在開發架構的基礎上，從宏觀上規劃多條控制流的併發和同步。
l 描述方式：
靜態方面可用包圖、類圖、對象圖
動態方面可用序列圖、協作圖
(4) 物理架構
l 思想：
物理架構的設計着重考慮安裝和部署需求。
規定了軟件架構由哪些物理元素組成，以及這些物理元素之間的關係，以及這些物理元素部署到硬件上的策略。
物理架構反映出軟件系統動態運行時的組織情況。
物理元素就是進程、線程、作爲類的運行時實例的對象等，而進程調度、線程同步、進程或線程通信等則進一步反映物理架構的動態行爲。
架構設計中可能需要專門說明數據是如何產生、存儲、共享、複製的，這時可以利用物理架構，展示軟件系統在運行期間數據是由哪些運行時單元產生、如何產生、數據如何被使用、如何被存儲、哪些數據需要跨網絡複製和共享等方面的設計決策。
軟件系統在計算機中運行期間的併發和交互情況（物理架構設計方案中規定了軟件系統如何使用進程和線程完成期望的併發處理，進程線程這些主動對象會調用哪些被動對象參與處理，交互機制(如消息)爲何等問題，從而爲詳細設計和編程實現提供了工作目標的動態視圖。）
l 關注點：安裝和部署需求。
l 工作任務：
Ø 確定物理配置方案（網絡方案）
Ø 確定如何將目標程序映射到物理節點
l 關係：
物理架構和運行架構是什麼關係？物理架構重視目標程序的靜態位置問題，運行架構關注目標程序的動態執行情況。
l 描述方式：
部署圖、組件圖
(5) 數據架構
l 思想：數據架構的設計着重考慮數據需求。
l 關注點：持久化數據的組織。
l 工作任務：
Ø 持久化數據存儲方案
Ø 數據的傳遞、複製、同步等策略
l 描述方式：
E-R圖和數據流圖
類圖和活動圖（可以用類圖替代E-R圖，用帶對象流的活動圖替代數據流圖）
