结合火车售票系统理解需求分析和概念原型

本文主要基于高级软件工程课程所学内容，结合我的工程实践题目——12306系统设计，进行用例建模、业务领域建模以及数据建模，最终形成概念原型。目的在于从中体会软件工程中需求分析和概念原型设计的过程。

题目简介

题目基本要求

• 参考12306站点进行售票系统建模设计，尽可能接近覆盖真实线上系统，实现的功能有但不限于:

  • 用户信息注册
  • 查询余票: 根据时间，车次，站点区间，座次(一等座，二等座，硬卧，硬座…)查询余票
  • 售票: 支持一次购买同一车次的多张车票(多人)，支持订单30分钟内锁定，超时释放。支付接口可以mock。
  • 退票: 支持一个用户账户下的批量退票
  • 改签: 同一用户一张车票只能改签一次

• 所有读写接口延迟要求 <= 500ms

• 单机支持到500qps的并发请求

本项目只包含针对客户端app的部分，不包含后台管理系统。

用例分析

什么是用例？

用例的核心概念中首先它是一个业务过程，用例的实质是经过逻辑整理抽象出来的一个业务过程。业务过程就是在待开发软件所处的业务领域内完成特定业务任务的一系列活动。对于一个用例，一定要满足以下几个条件：

• 由业务领域内的某个参与者所触发。
• 能为特定的参与者完成一个特定的业务任务。
• 终止于某个特定参与者，也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。

这里的参与者是指业务领域内的参与者或者业务实体。参与者可以是一个人，也可以是一个组件或外部设备。

如何获取用例？

用例包含三个抽象层级：抽象用例，高层用例和扩展用例。抽象用例只需要说明要完成什么样的任务，高层用例需要说明用例的开始和结束，给用例划定边界。扩展用例要详细描述参与者和用例交互的具体过程。所以，获取用例的过程应该是从简单到复杂逐步进行的。

首先从需求中找到抽象用例。再用TUCBW和TUCEW来描述的用例的边界，得到高层用例。对用例进行分类，画出用例图。最后详细分析参与者和用例的交互步骤，得到扩展用例。

购票系统用例分析

因为本系统不包含后台管理的部分，所以系统的主要参与者是12306系统客户端用户。对于用户，系统的主要功能包括：注册/登录，查询车次信息，购票，改签，退票。用户可以分为已注册用户和游客。从宏观上看，主要用例如下。

上面的用例图展示了购票系统和用户系统两大模块为用户提供的功能。用例图可以继续细化，加入用例之间的关联关系。

业务领域建模

业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知。因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知。

开发团队获取业务领域知识的过程一般包括收集业务领域相关信息、执行团队头脑风暴、对业务领域相关的知识概念进行分类，最后用UML类图将业务领域知识图形化展示。

根据课上所学内容，我理解的业务领域建模步骤如下：

1. 收集信息
2. 列出业务领域概念及其属性，分析出概念之间的关系
3. 将业务领域概念定义成类，通过类的属性和关系描述概念的属性和关系
4. 绘制UML类图

购票系统业务领域建模

由于12306系统较为复杂，这里只针对我所负责的用户与购票模块进行分析。

业务领域概念分析

根据业务领域建模步骤，首先需要分析购票系统中有哪些业务概念。

1. 未注册用户需要注册，注册时需要提供姓名、证件号码、手机号码等信息。
2. 用户可以登录，登录后可以通过购票系统购买车票。
3. 用户可以添加或修改常用联系人信息，可以为联系人购买车票。
4. 每个车次经过若干个站点。
5. 车票包含车次信息、起点和终点等信息。

从上面的分析中可以提出一些名词如用户，车次，车票，联系人以及用户和联系人信息。接下来将这些信息归类为类、属性以及类之间的关系。

• 用户是一个名词，可以独立存在，因此用户是一个类。
• 用户注册时提供的姓名、证件号码等信息是名词，但不可以独立存在，因此不是类，而是作为用户的属性。
• 与用户类似，联系人是一个类。联系人的信息是联系人的属性。
• 车次是一个名词，可以独立存在，因此车次是一个类。
• 站点是一个名词，可以独立存在，因此站点是一个类。
• 同理，车票也是一个类。
• 经过是一个及物动词，表示车次和站点之间的关系。
• 购买是一个及物动词，表示用户和车票之间的关系。

以上就是分析出的类及类之间的关系。接下来根据这些信息绘制UML类图。

UML 类图

数据模型设计

考虑到性能因素，车票相关的具有高并发量的数据都采用NoSQL内存数据库进行存储。在传统关系型数据库中，主要存储：用户信息，静态的车次、站点信息，订单信息和出票信息。部分会频繁读取且很少更新的信息进行了反范式化处理，对这些字段冗余存储。

用户

属性名	类型	注释
id	int	用户ID
username	varchar	用户名
password	varchar	密码
name	varchar	姓名
id_type	int	证件类型
id_number	int	证件号码
sex	int	性别
email	varchar	Email
passenger_type	int	乘客类型（成人/学生）
register_time	datetime	注册时间

联系人

属性名	类型	注释
id	int	联系人信息ID
user_id	int	用户ID
contact_name	int	联系人姓名
contact_number	varchar	联系人电话
contact_id_type	int	联系人证件类型
contact_id_number	varchar	联系人证件号码
contact_passenger_type	int	联系人乘客类型

车次

属性名	类型	注释
id	int	车次ID
name	varchar	车次名称
train_type	int	车次类型(K/D/G)
starting_station_id	int	起点站ID
terminal_station_id	int	终点站ID
starting_station_name	int	起点站名称
terminal_station_name	int	终点站名称
starting_time	datetime	车次出发时间
terminal_time	datetime	车次到达时间

站点

属性名	类型	注释
id	int	站点ID
name	varchar	站点名称
city	varchar	城市名称

车次区间

属性名	类型	注释
id	int	区间ID
train_id	int	车次ID
station_id	int	站点ID
order	int	站点顺序

订单

属性名	类型	注释
id	int	订单ID
user_id	int	订单创建者ID
train_id	int	车次ID
train_date	date	车次出发日期
starting_station_id	int	出发站ID
terminal_station_id	int	到达站ID
price	int	总金额（分）
is_paid	int	是否已支付
paid_time	datetime	支付时间
created_at	datetime	创建时间

订单详情

属性名	类型	注释
id	int	订单详情ID
order_id	int	订单ID
passenger_name	int	乘客姓名
passenger_id_type	int	乘客证件类型
passenger_id_number	varchar	乘客身份证号
passenger_type	int	乘客类型
seat_type	int	座位类型
carriage_number	int	车厢号
seat_number	int	座位号（排）
seat_location	char	座位位置（ABCDEF)

车票信息

属性名	类型	注释
id	int	车票ID
train_id	int	车次ID
starting_station_name	varchar	出发站名称
terminal_station_name	varchar	到达站名称
starting_time	datetime	出发日期时间
seat_type	int	座位类型
carriage_number	int	车厢号
seat_number	int	座位号（排）

概念原型

概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论。概念原型是一种虚拟的、理想化的软件产品形式。一般来说，概念原型=用例+数据模型。

本例中的用例主要包括了针对未注册用户的用例和注册用户的用例。用例包括与用户信息相关的用例如注册、登录。和与车票相关的如购买车票。未注册用户在注册后成为已注册用户，已注册用户在登录后可以使用购票系统，查询并购买车票。购买成功后产生订单，生成车票。数据模型上文已经定义。

总结

本文结合一个类似12306的购票系统软件，对其部分功能模块，按用例分析、业务领域建模、数据模型设计等步骤进行分析设计，体会了一个软件从需求分析到概念原型的整体流程。

参考资料

1. 从需求分析到软件设计.pptx