1. 总结
今天主要是对需求进行拆分，以及画UML图。
UML图：显示了一组类、接口、协作以及他们之间的关系，名字必须是类的合理的名字，类里面应该是相关的属性和方法
2. 需求分析结果
需求简述：
用户能在购票系统够顺利买到票。
业务需求分析：
按照使用方分类，分为用户和管理员
用户的核心诉求：查票，购票，退票
管理员的核心诉求：车次配置，售票
详细需求清单：
用户：
- 支持注册，登录功能
- 支持管理自己的账户信息，包括实名（姓名，身份证，手机号）认证信息
- 支持绑定其他人的实名认证（姓名，身份证，手机号）认证信息
- 支持查询自己账户下的实名认证信息
- 可以在app端根据城市信息查询城市之间的车次信息
- 可以看到车次的余票信息
- 可以看车次的起点，终点，经停站，起止时间
- 支持按照规则排序
- 支持刷新车次的余票信息
- 支持手动刷新车次信息
- 支持用户购票操作
- 支持选中多人购买多张票
- 支持在线选座
- 支持选座不满足的情况下，自动分配剩余座位
- 支持使用支付宝进行支付
- 支持支付后锁定占票操作，15分钟未支付自动取消
- 支持取消支付
- 支持改签功能
- 支持退票功能
- 支持根据状态来查询自己的订单信息
- 通知用户购票成功，退票成功，改签成功功能
管理员：
- 支持录入车次信息，包括各种基本信息
- 支持录入车次的经停站信息
- 用户的管理
- 退票审核
- 车费的管理
- 退票的手续费管理
需求规则细化：
- 核心规则问题，在购票系统的购票过程中，存在很经停站，比如一个深圳到北京的列车，途径厦门，上海，天津。实际座位只有1000个，但是能卖的票远不止1000张。 他可以在深圳到厦门之间卖1000短途票，在厦门到上海之间卖1000短途票，在上海和天津之间卖1000张票，在天津和北京卖1000张票。这样加起来其实最终可以买4000张票了。 所以这快就需要考虑卖中途票对余票的影响。
- 改签规则，只能改签当天指定城市之间的车票信息。
