列车售票后台概念原型
简介
我们小组的课题是实现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字段，这里不再重复
总结
概念原型设计就是一个抽象的过程，我们通过对现实事物和其工作过程观察，不管是用例也好还是业务领域都是先用人类的语言进行描述，然后对描述中进行提取分析，形成我们需要的软件功能的实质、类和类之间的关系。
