基于列车售票系统的需求分析与概念原型
一、前言
本篇博客基于工程实践项目（设计一个类似12306的售票系统）进行用例建模和业务领域建模，以及数据建模，最终形成概念原型。
二、需求分析
用户需求分析：
1、用户注册、登录：用户可以注册账号，并用账号信息登录售票系统已进行其他操作。
2、用户信息维护：用户可以修改账号的基本信息。
3、查询车票：用户可以选择出发站和目的站以及日期，查询车次以及对应的余票等信息。
4、购买车票：用户在查询到车票信息后，可选择仍有余票的车次进行买票。
5、候补：当用户想购买的车次没有足够的余票时，用户可以选择候补下单并支付票款，如果之后有满足用户需求的车票，则自动完成购买，超过候补期限仍没有车票则退款给用户。
6、查询订单：用户可查询已购买的车票、未支付的车票、以及候补订单。也可以根据自己的身份信息查询到所有本人车票。
7、退票：用户行程有变时可将已购买的车票进行退票。
8、改签：用户行程有变时可以进行改签以更换目的地。
三、用例建模
（一）什么是用例？
用例的核心概念中首先它是一个业务过程，经过逻辑整理抽象出来的一个业务过程，这是用例的实质。什么事业务过程？在待开发软件所处的业务领域内完成特定业务任务的一系列活动就是业务过程。
（二）用例建模的基本步骤
第一步，从需求表述中找出用例，往往是动名词短语表示的抽象用例；
第二步，描述用例开始和结束的状态，用TUCBW和TUCEW表示的高层用例；
第三步，对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；
第四步，进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。
（三）根据项目进行用例建模
主要功能
用户注册
用户登录
个人信息维护
根据站点、日期查询车票
查询已买车票
购买车票
改签
退票
候补
用例图
四、业务领域建模
（一）业务领域建模基本介绍
业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知。因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知。
（二）业务领域建模基本步骤
第一步，收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；
第二步，头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；
第三步，给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系；
第四步，将结果用 UML 类图画出来。
（三）根据项目进行业务领域建模
用户：id、用户名、密码、证件类型、证件号码、姓名、性别、出生年月、手机号、邮箱、地址
乘车人：id、姓名、证件类型、证件号码、旅客类型（成人、学生等）
用户_乘车人：id、乘车人id、用户id
列车：id、车次号、列车类型id、始发站id、终点站id、经停站、发车时间、到达时间
列车类型：id、列车类型
车厢：id、车厢类型、座位数
列车_车厢：id、列车id、车厢id、车厢编号
车站：id、车站名称
列车_车站：id、车站id、列车id、到达时间、发车时间
车票：id、列车id、出发站id、目的站id、发车时间、车厢id、座位号、乘车人id、车票状态
订单（Order）：id、用户id、车票id、金额、创建时间、支付时间、订单状态
UML类图
四、数据模型
根据前面的需求分析、用例建模、业务领域建模，得出以下数据库表。
用户表
| 字段名 | 字段类型 | 字段描述 |
| id | int | 用户id |
| username | varchar | 用户名 |
| password | varchar | 密码 |
| name | varchar | 姓名 |
| sex | varchar | 性别 |
| birthday | datetime | 出生日期 |
| telephone | varchar | 手机号 |
| varchar | 邮箱 | |
| address | varchar | 地址 |
| identification_type | varchar | 证件类型 |
| identification_number | varchar | 证件号 |
乘车人表
| 字段名 | 字段类型 | 字段描述 |
| id | int | 乘车人id |
| name | varchar | 乘车人姓名 |
| identification_type | varchar | 证件类型 |
| identification_number | varchar | 证件号码 |
| passenger_type | varchar | 乘客类型（成人、学生等） |
用户_乘车人表
| 字段名 | 字段类型 | 字段描述 |
| id | int | 用户_乘车人表id |
| passengerid | int | 乘车人id |
| userid | int | 用户id |
列车表
| 字段名 | 字段类型 | 字段描述 |
| id | int | 列车id |
| traintypeid | int | 列车类型id |
| trainNumber | int | 列车编号 |
| start_stationid | int | 始发站id |
| dest_stationid | int | 终点站id |
| starttime | datetime | 发车时间 |
| arrivetime | datetime | 到达时间 |
列车类型表
| 字段名 | 字段类型 | 字段描述 |
| id | int | 列车类型表id |
| trainType | string | 列车类型（动车、火车等） |
车厢表
| 字段名 | 字段类型 | 字段描述 |
| id | int | 车厢id |
| carriageType | varchar | 车厢类型 |
| seatnumber | int | 座位数量 |
列车_车厢表
| 字段名 | 字段类型 | 字段描述 |
| id | int | 列车_车厢表id |
| trainid | int | 列车id |
| carriageid | int | 车厢id |
| carriagenumber | int | 车厢编号，用于表示该车厢是列车的几号车厢 |
车站表
| 字段名 | 字段类型 | 字段描述 |
| id | int | 车站id |
| stationname | varchar | 车站名称 |
列车_车站表
| 字段名 | 字段类型 | 字段描述 |
| id | int | 列车_车站表id |
| stationid | int | 车站id |
| trainid | int | 列车id |
| arrivetime | datetime | 列车到达时间 |
| starttime | datetime | 列车发车时间 |
车票表
| 字段名 | 字段类型 | 字段描述 |
| id | int | 车票id |
| trainid | int | 该车票对应的列车id |
| start_stationid | int | 车票出发站id |
| dest_stationid | int | 车票目的站id |
| starttime | datetime | 开车时间 |
| carriageid | int | 车厢id |
| seat | int | 座位号 |
| passengerid | int | 乘车人id |
| ticketstatus | varchar | 车票状态 |
订单表
| 字段名 | 字段类型 | 字段描述 |
| id | int | 订单id |
| userid | int | 创建该订单的用户id |
| ticketid | int | 订单购买的车票id |
| amountmoney | float | 订单金额 |
| createtime | datetime | 创建时间 |
| paytime | datetime | 支付时间 |
| orderstatus | varchar | 订单状态（未支付、已支付..） |
五、概念原型
概念原型的定义
在理解概念原型之前，我们首先要理解概念的定义——即人对能代表某种事物或发展过程的特点及意义所形成的思维结论。因此我们可以得出概念原型的定义，其是一种虚拟的、理想化的软件产品形式，更加直观的来说，概念原型等于数据模型加上用例。
概念原型工作过程举例
用户注册：用户填写基本信息，提交给系统，系统校验数据，返回给用户相应信息。
购票：用户选择车次，将乘车人、座位类型等信息提交给系统，系统进行出票，将车票信息或出票失败信息返回给用户。
六、总结
本文对工程实践项目（设计一个12306售票系统），进行了用例建模、业务领域建模和数据模型，最终形成概念原型。在此过程中对项目有了更深的理解，对项目开发流程有了更宏观的理解。
