我們小組的課題是實現12306後端，這是乙個比較難的課題。但是又已經有了乙個現成的軟體可以參考，於是我們小組就通過研究12306前端來得到我們要實現的相關功能。
需要說明的是我們準備實現的12306後端與現在的12306有所不同。最大的區別就是我們並不去考慮這個系統與鐵道部或者車站的互動。也就是說我們系統的參與者就只有後端和使用者，當然前端作為使用者的**被認為是使用者。
通過對12306前端的研究我們的到了如下的需求描述：
使用者可以註冊賬號，使用賬號密碼登入12306軟體
使用者可以檢視自己的購票歷史，包括未出行的和歷史訂單，但是一段時間後歷史訂單會被清空。通過使用者還可以檢視自己未支付的訂單，正在候補的訂單。
使用者可以通過選擇起始站點、目的站點、時間和購票型別（高鐵和學生票）這些資訊來查詢車次已經餘票
不僅可以查詢餘票，使用者還可以通過出發地起+目的地+時間查詢相關的車次但是不顯示餘票、通過車次+時間查詢該車次經過的車站和到達的時間、通過車站+時間查詢當天在車站停留的車次
使用者查詢餘票之後可以選擇還有餘票的車次，選擇車位和乘車人然後支付票價進行購票
使用者通過選擇沒有餘票的車次來進行候補票
使用者通過檢視自己已購買的車票進行退票或者改簽操作
這樣分析我們只能得到使用者這一參與者的一些用例，但是我們還不能一下得出系統內部的用例，這需要在進一步研究系統的實現後才能得到。
為了方便分析和分工，我們小組把一些功能相似的需求，或者資料大致相似，或者可能是流量比較大的需求進行了劃分。劃分為下面四組：
個人資訊，包括了歷史記錄、登入、註冊、實名驗證
查詢車次，包括通過出發地起+目的地+時間查詢相關的車次但是不顯示餘票、通過車次+時間查詢該車次經過的車站和到達的時間、通過車站+時間查詢當天在車站停留的車次
查詢餘票，購票、改簽
候補、退票、支付
當然這並不是什麼嚴謹的劃分，這只是為了方便研究而進行的劃分，這樣劃分之後我們小組的成員可以比較獨立的進行研究，有疑問的也可以相互討論。如果不同分組之間的需求關聯比較大也可以在分析完之後進行磨合
我在小組中主要研究的是候補、退票和支付。所以下面我就只對這三個功能進行分析
1.是否是用例？
候補是不是乙個用例，首先候補肯定是乙個業務過程，由使用者出發，終止於使用者（候補訊息最終發給使用者），為參與者完成了進行買票候補的業務。同樣的退票也有著相似的說法，退票也是乙個用例。
但是支付且有點不同，支付功能是乙個中間功能，這個功能並不是獨立存在的，只有別的功能才能觸發支付功能。單獨把支付拿出來說，似乎支付並沒有為參與者完成有用的業務過程。使用者支付完了，花了錢但是使用者的到了什麼？所以支付功能必須和別的功能一起才能說是乙個有用的功能，這樣的話支付就應該被看作是乙個包含用例進行分析。
2.高層用例
對於退票來說，參與者可能會有所不同，因為不單單是使用者可以退票。由於不考慮跟鐵道部的互動我們也不用考慮由於車次取消引起的退票。但是負責分析改簽功能的隊友告訴我，改簽就是重新購票在退舊票，也就是說參與者可以是使用者或者改簽服務。那麼退票的開始就應該是使用者選擇退票或者改簽服務發出退票請求。對於支付功能，如同上面所說的支付是乙個包含用例，它的參與者包含了使用者和其他用例，那麼他的開始就應該是使用者觸發了別的需要用到支付的用例。
3.用例圖
4.擴充套件用例
候補
退票
支付
這一部分我將通過業務領域建模來得到每個功能需要用到的類。收集資料這一步主要還是通過研究12306手機客戶端和閱讀相關論進行，這裡就不進行介紹。後面的步驟通過候補、退票和支付三個功能進行舉例，其他功能也類似。
使用者選擇對應的發車資訊並支付相應的金額後系統將會為使用者辦理候補業務
發車資訊包括了車次、日期、始發站和目的站
車次是一輛火車的編號，應該有車型號、始發站、目的站和停靠車站資訊。其中車型號是一類車的總稱，包含了車輛的具體資訊，如最高時速，是高鐵還是動車還是普通火車，給出一等車廂有幾個編號分別是什麼，每個車廂有幾排幾列，同時也有二等車廂資訊。普通火車還要有硬座車廂、硬臥和軟臥車廂。
候補成功後將成功資訊傳送給使用者，使用者兌現候補後系統就可以出票給使用者
使用者憑藉車票可以去對應的車站乘坐對應的車次到達目的地
使用者給系統提供車票資訊，系統將為使用者退票
車票資訊包括了車次、發車時間、始發站、目的站、座位資訊
座位資訊包含了座位型別和座位號
其他功能需要用到支付功能的時候可以向支付功能提供乙個金額，支付功能將會建立乙個訂單，並將部分訂單資訊傳送給使用者，使用者在規定的時間內完成就完成支付，完成支付後返回原功能繼續進行
訂單包含了訂單編號、支付編號、金額、建立時間、訂單狀態以及其他支付提供商要求的資訊
通過上述**，然後再經過是否能獨立存在的判斷後得到類圖
這個類圖並不是完全體,因為還要根據mvc進行劃分,還要引入快取模組,再劃分出service層。由於購票的複雜性，我們還要引入乙個完全獨立的票務關聯系統。但是作為原型設計應該差不多了。下面每張表中都包含了id,created_at,delete_at,create_by,modified_at,modified_by,delete_by欄位，這裡不再重複
概念原型設計就是乙個抽象的過程，我們通過對現實事物和其工作過程觀察，不管是用例也好還是業務領域都是先用人類的語言進行描述，然後對描述中進行提取分析，形成我們需要的軟體功能的實質、類和類之間的關係。
需求分析和概念原型 以火車售票系統為例
本文主要在學習高階軟體工程課的基礎上，對工程實踐的題目進行分析，將課本上的知識運用到實際的工程專案中。我的工程實踐題目是 設計乙個類似12306售票系統 首先我要對我的題目進行需求分析。需求就是使用者期望的軟體行為的表述，需求分析就是在獲取需求的基礎上進一步對軟體設計的物件或試題的狀態 特徵和行為進...
後台開發也要快速原型
專案快上線了，再出現這種錯誤會讓大家都很沒有信心。昨天，程式中出線了乙個低階的bug。原因 0，自己對線上 生產系統的開發沒有經驗，後台開發的很多東西不熟 1，一直以來，專案需求不甚明確，大家在摸著石頭過河，前進過程中完善需求 2，自己負責的部分邏輯較為複雜，整個系統缺乏測試 其中最後一條問題最嚴重...
JS 原型的某些概念
prototype 建構函式擁有乙個物件，稱為建構函式的原型屬性，可以通過 建構函式prototype進行訪問。proto 建構函式所創造出的例項物件，可通過該屬性訪問原型物件。constructor 是原型下的乙個屬性，構造器。可認為是原型下的乙個方法，指向建構函式本身。原型繼承 例項物件繼承自原...