1.前言
本文将基于一个火车售票系统，进行用例建模，业务领域建模以及数据建模，最终形成概念原型。
2.需求概述
本系统包含两个子系统，分为用户系统与后台管理系统。
1. 用户系统的主要功能
- 用户注册
- 用户信息维护
- 查找车票
- 购买车票
- 改签及退票
2. 后台管理系统的主要功能
3.用例设计
本系统分为两个角色：普通用户和管理者
普通用户用例图：
管理者用例图：
4.业务类图
在进行UML建模前，我们需要先对业务领域进行详细分析和描述，并对业务相关知识概念进行分类，最后使用UML进行图形化展示。
1. 建模步骤
1）第一步，收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料。
2）第二步，头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系
3）第三步，给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。
4）第四步，将结果用 UML 类图画出来。
2. 业务过程说明
1. 用户注册：
- 功能描述：用户注册个人账号
- 处理流程及要点：用户填写个人基本信息并提交，系统验证用户信息合法性，如果不合法，则返回相应的错误提示信息；否则提示注册成功，向表中插入数据
- 输入：账号，密码，性别，年龄，证件类型，证件号码
- 输出：（1）成功：注册成功 （2） 失败：失败原因
2. 用户登录
- 功能描述：用户登录火车售票平台
- 处理流程及要点：用户输入账号密码并提交，系统进行验证，如果通过则进入主页面；否则登录失败，并返回相应信息
- 输入：账号名，密码
- 输出：（1）成功：登录成功 （2） 失败：失败原因
3. 查票
- 功能描述：普通用户查询车票
- 处理流程及要点：用户输入筛选信息，系统返回满足条件的查找结果
- 输入：起点站，终点站，（可选项：时间，座次，车次）
- 输出：（1）成功：返回查找结果 （2） 失败：返回失败原因
4. 购票
- 功能描述：普通用户购买车票
- 处理流程及要点：用户输入筛选信息进行查票，选择车票购买，系统判断出票条件进行出票，成功出票则生成订单信息
- 输入：车次，座位号
- 输出：（1）成功：车票信息，包括车次，买票人信息，始发站，终点站，时间，座位号 （2） 失败：失败原因
5. 改签、退票
- 功能描述：普通用户改签车票或退票
- 处理流程及要点：用户选择要改签/退票的车票，系统重置该车票的信息及状态
- 输入：车次，座位号，若改签则还需输入改签时间
- 输出：（1）成功：返回车票信息或状态 （2） 失败：返回失败原因
6. 站点信息维护
- 功能描述：管理员用户维护站点信息
- 处理流程及要点：管理员用户维护站点表，主要包括增删改查等操作
- 输入：增删改查相应参数
- 输出：（1）成功：成功信息 （2） 失败：失败原因
7. 列车信息维护
- 功能描述：管理员用户维护列车信息
- 处理流程及要点：管理员用户维护列车表、车厢表、座位表，主要包括增删改查等操作
- 输入：增删改查相应参数
- 输出：（1）成功：成功信息 （2） 失败：失败原因
8. 车次设置
- 功能描述：管理员用户添加车次信息
- 处理流程及要点：管理员用户输入车次信息，系统进行判断和验证，并执行对应业务逻辑
- 输入：列车ID，始末站点，中途站点，各站点区间票价，发车日期和时间
- 输出：（1）成功：该车次信息 （2） 失败：失败原因
3. UML建模
根据以上业务需求描述，并结合面向对象的思想，抽象出类、属性、方法，同时确定概念之间的关系，构建UML类图：
5.数据模型设计
1. 采用关系数据库mysql进行设计
（1）用户表
| 字段名称 |
字段类型 |
字段描述 |
| userId |
int |
主键 |
| account |
varchar |
账号 |
| password |
varchar |
密码 |
| name |
varchar |
姓名 |
| sex |
varchar |
性别 |
| phonenum |
number |
电话号码 |
| certificate_type |
varchar |
证件类型 |
| certificate_num |
number |
证件号码 |
| authority |
varchar |
权限 |
| info |
varchar |
其它信息 |
（2）角色表
| 字段名称 |
字段类型 |
字段描述 |
| roleId |
int |
主键 |
| role_type |
varchar |
角色类型 |
| authority |
varchar |
权限 |
| descr |
varchar |
描述 |
（3） 用户角色关联表
| 字段名称 |
字段类型 |
字段描述 |
| urId |
int |
主键 |
| userId |
int |
用户主键【外键】 |
| roleId |
int |
角色主键【外键】 |
（4） 车次表
| 字段名称 |
字段类型 |
字段描述 |
| trainSequenceId |
int |
主键 |
| trainNum |
number |
车次号 |
| trainId |
int |
列车号 |
| start_station |
varchar |
起点站 |
| end_station |
varchar |
终点站 |
| launch_time |
datetime |
启动时间 |
（5） 列车表
| 字段名称 |
字段类型 |
字段描述 |
| trainId |
int |
主键 |
| trainName |
varchar |
列车名称【外键】 |
| type |
varchar |
列车类型 |
| carriage_num |
int |
车厢数 |
| status |
int |
状态 |
（6） 车厢表
| 字段名称 |
字段类型 |
字段描述 |
| carriageId |
int |
主键 |
| trainId |
int |
列车主键【外键】 |
| carriage_number |
int |
车厢号 |
| carriage_type |
int |
车厢类型 |
| price_coef |
int |
价格系数 |
（7） 座位表
| 字段名称 |
字段类型 |
字段描述 |
| seatId |
int |
座位主键 |
| carriageId |
int |
车厢主键【外键】 |
| trainId |
int |
列车主键【外键】 |
| seat_number |
int |
座位号 |
| bitmap |
int |
座位站点状态位图 |
（8） 站点表
| 字段名称 |
字段类型 |
字段描述 |
| stationId |
int |
站点主键 |
| name |
varchar |
站点名称 |
| descr |
varchar |
站点级别 |
（9） 车次站点表
| 字段名称 |
字段类型 |
字段描述 |
| train_sta_Id |
int |
车次站点主键 |
| trainSequenceId |
int |
车次主键【外键】 |
| station_sequence |
int |
站点序列 |
| arrive_time |
datetime |
到达时间 |
| lanch_time |
datetime |
启动时间 |
（10） 订单表
| 字段名称 |
字段类型 |
字段描述 |
| orderId |
int |
订单主键 |
| userId |
int |
用户主键【外键】 |
| seatId |
int |
座位主键【外键】 |
| order_time |
datetime |
时间 |
| status |
varchar |
订单状态 |
| descr |
varchar |
订单描述 |
（11） 字典表
| 字段名称 |
字段类型 |
字段描述 |
| dictionaryId |
int |
字典表主键 |
| attributes |
varchar |
属性名称 |
| value |
varchar |
属性取值 |
2. 关于设计思路的补充说明
（1） 对于关系型数据库，一般情况下遵循其范式原则，但范式并非越高越好。为了提升查找性能，可以有针对性性地进行反范式设计，例如当查询频率远高于修改频率时，或数据基本不改动时，可适当增加冗余来提高查询效率。此时则需要注意冗余字段的一致性问题。本系统中，在用户表中增加authority冗余字段，从而减少多表查询带来的性能损耗。
（2）对于实体间一对多的设计，可分为以下情况讨论：
- 一对多中的多并非单独实体，且规模较少，如各表中的type类型字段：直接内嵌在实体中，不再单独建立实体表。
- 一对多中的多需要单独的实体，且规模较多，如列车表中的车厢，车厢表中的座位等字段：单独建实体表，并通过外键进行关联。（实际开发中在业务层保证）
- 一对多中的多规模非常庞大时，如用户表中的角色：可将一对多中的‘一’内嵌入‘多’的实体中，本系统由于考虑到后续开发的扩展性问题，并未采用。
（3）一些通用开发经验：
- 实体表的设计中，优先考虑使用内嵌。
- 一个字段无法描述，需要使用实体时，应该单独设计实体表
- 在关系数据库的设计中，考虑范式的同时，应结合具体业务进行必要的反范式设计
- 对于是否进行冗余，判断的主要依据是读写频率
- 多表关联查询时，如果效果不佳，考虑增加索引进行优化
6.概念原型
1. 概念原型的定义方式
概念原型是一种虚拟的、理想化的软件产品形式。其定义用以下公式描述:
概念原型 = 用例 + 数据模型。 其中，用例及数据模型在本文中已详细阐述。
2. 工作过程举例
- 用户注册：用户填写注册信息【用户数据模型：账号，密码，姓名，性别，电话号码，证件号码...】，系统进行校验，并返回相应信息。
- 查票：用户输入或选择筛选条件，系统返回车票信息【车票数据模型：车次号，座位号，起点站，终点站，发车时间，到达时间，票价...】
7.总结
本文参考了软件工程的相关知识，并结合工程实践项目，对软件过程中的需求分析和概念原型设计做了细致阐述。在此过程中，我对系统本身业务的理解也更为深刻，也将有利于后续系统的开发。文中涉及的其它细节，我将会在系统开发的同时进行补充和完善。
