需求分析和概念原型——以火车售票系统为例
本文主要在学习高级软件工程课的基础上，对工程实践的题目进行分析，将课本上的知识运用到实际的工程项目中。
我的工程实践题目是“设计一个类似12306售票系统“，首先我要对我的题目进行需求分析。
一、需求分析
1.1 需求分析概述
需求就是用户期望的软件行为的表述，需求分析就是在获取需求的基础上进一步对软件设计的对象或试题的状态、特征和行为进行准确描述或建模的工作。
我们的系统主要服务于两类人群：用户和管理员。
1.2 用户需求分析
1、注册账户：用户第一次进入系统需要提交注册请求并完善账户信息。
2、登录账户：用户通过核验账户及密码可以登录系统。
3、查询车票：用户通过指定出发地、目的地和时间查询可购买的车票，并可以通过对出发时间段、有无余票、指定同城不同火车站等信息对车票进行筛选。
4、购买车票：通过查询页面，用户可以选择购买指定车次、指定座位的车票。
5、退改车票：用户可以对已经购买的车票进行退票、改签等操作。
6、候补下单：对于当前无票的车次，用户可以选择候补下单，当预定的车次有车票时，优先发放给候补人员。
1.3 管理员需求分析
1、增删车型：管理员可以做到增加、删除车型的座位定价、列车车厢数、车厢座位数。
2、增删站点：管理员可以做到增加、删除站点。
3、增删车次：管理员可以做到增加、删除车次的出发时间、到达时间、出发地点、到达地点、途径站点。
二、用例建模
2.1 用例建模概述
用例：用例的核心概念中首先它是一个业务过程，经过逻辑整理抽象出来的业务过程，这是用例的实质。业务过程就是在待开发软件所处的业务领域内完成特定业务任务。
准确提取用例的基本方法：
1、从需求中寻找业务领域相关的动名词和动名词短语，比如做什么事、什么事情必须被完成，或者执行某任务等；
2、验证这些业务领域相关的动名词和动名词短语到底是不是用例。验证业务领域相关的动名词或动名词短语是不是用例的标准是满足四个必要条件：
- 必要条件一：它是不是一个业务过程？
- 必要条件二：它是不是由某个参与者触发开始？
- 必要条件三：它是不是显式地或隐式地终止于某个参与者？
- 必要条件四：它是不是为某个参与者完成了有用的业务工作？
如果以上四个必要条件都满足的话，那么该业务领域相关的动名词或动名词短语就是一个用例。
3、在需求中识别出参与者、系统或子系统。
- 参与者会触发某个用例开始，用例也会显式地或隐式地终止于某个参与者；
- 用例会属于系统或子系统。
2.2 用户用例建模
2.3 管理员用户建模
三、业务类图建模
3.1 业务类图概述
业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知。因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知。
开发团队获取业务领域知识的过程一般包括收集业务领域相关信息、执行团队头脑风暴、对业务领域相关的知识概念进行分类，最后用UML类图将业务领域知识图形化展示。
业务领域建模的基本步骤：
1、收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；
2、头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；
3、给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。
4、将结果用 UML 类图画出来。
3.2业务类图建模
通过我们对需求的分析和用例建模，得到了如下的类和属性：
1、用户：用户名、密码、姓名、昵称、身份证号、手机、权限信息、会员信息
2、车次：车次编号、车次号、列车编号、起点、终点、开车时间、到达时间
3、列车：列车编号、列车类型、车厢数量、列车状态
4、车厢：车厢编号、列车编号、车厢号、车厢类型、车厢座位数、车厢价格系数
5、座位：座位编号、车厢编号、列车编号、座位号、座位使用区间状态图
6、站点：站点编号、站点名称、车次编号、列车到站时间、列车出发时间
7、订单：订单编号、订单时间、订单联系人、订单座位号、订单状态
3.3 项目的UML图
四、数据模型建模
通过对上述的分析，我们提取出各个类的数据之间的关系，得到如下的数据模型：
1、用户表：
| 变量名称 | 变量类型 | 备注 |
| id | varchar | 账户名 |
| password | varchar | 密码 |
| name | varchar | 姓名 |
| nickname | varchar | 昵称 |
| credential_type | varchar | 证件类型 |
| credential_number | varchar | 证件号 |
| telephone | varchar | 手机号 |
| member | varchar | 会员信息 |
2、车次表：
| 变量名称 | 变量类型 | 备注 |
| train_id | int | 车次编号 |
| train_number | varchar | 车次号 |
| train_identification | varchar | 列车编号 |
| begin_place | varchar | 起点 |
| end_place | varchar | 终点 |
| begin_time | datetime | 开车时间 |
| end_time | datetime | 到达时间 |
3、列车表：
| 变量名称 | 变量类型 | 备注 |
| train_identification | varchar | 列车编号 |
| train_type | varchar | 列车类型 |
| carriage_sum | varchar | 车厢数量 |
| carriage_type | varchar | 列车状态 |
4、车厢表：
| 变量名称 | 变量类型 | 备注 |
| carriage_id | varchar | 车厢编号 |
| train_identification | varchar | 列车编号 |
| carriage_number | int | 车厢号 |
| carriage_type | varchar | 车厢类型 |
| seat_number | int | 车厢座位数 |
| seat_price | double | 车厢座位价格系数 |
5、座位表：
| 变量名称 | 变量类型 | 备注 |
| seat_id | varchar | 座位编号 |
| carriage_id | varchar | 车厢编号 |
| train_identification | varchar | 列车编号 |
| seat_number | varchar | 座位号 |
| seat_use | varchar | 座位使用情况 |
6、站点表：
| 变量名称 | 变量类型 | 备注 |
| station_id | varchar | 站点编号 |
| station_name | varchar | 站点名称 |
| train_id | varchar | 车次编号 |
| begin_time | datetime | 列车到站时间 |
| end_time | datetime | 列车出发时间 |
7、订单表：
| 变量名称 | 变量类型 | 备注 |
| order_id | varchar | 订单编号 |
| order_time | varchar | 订单时间 |
| order_person | varchar | 订单联系人 |
| seat_id | varchar | 订单座位号 |
| order_status | varchar | 订单状态 |
五、概念原型
5.1 概念原型概述
概念是人对能代表某种事物或者发展过程的特点及其意义所形成的思维结论，概念原型是一种虚拟化的、理想化的软件产品形式。
所以，概念原型=用例+数据模型。
5.2 概念原型实例
用户可以通过系统注册自己的账户，然后登录自己的账户，完善个人信息。在系统首页选择出发城市、到达城市和日期，然后在筛选出的车次中选择一个具体的车次，选择座位，然后系统生成订单，用户支付订单。用户可以通过订单页面选择改签或退票。
管理员可以登录系统，增加或删除某天的车次、某种车型，还可以增加和删除某个具体的站点及站点信息。