需求分析和概念原型—基于深度学习的交通预测项目
0. 项目概述
本人的工程实践项目为基于深度学习算法的交通流量预测，是算法研究的科研向课题。
考虑到研究的前提是能够给用户带来价值，那么开发出来的算法最终会落地应用。
假定这么一个场景：甲方为交通管理部门，要求我们做出一套交通数据管理的可视化软件，提供路况（传感器数据）监控，拥堵预测和远程更新公告牌的功能。
我们在获得用户对软件的期待和要求的行为后，就可以进行需求分析了：我们将对软件涉及的对象/实体的状态、特征和行为进行准确描述，进行建模。
参考资料：从需求分析到软件设计.pptx
1. 用例建模
用例（Use Case）是一个业务过程（business process），是在待开发软件所处的业务领域内完成特定业务任务（business task）的一系列活动。
具体来讲，一个用例由用户A发起，要完成A要求的一个特定任务，在这个任务完成时A要知道。
用例从抽象到具体有三个抽象等级：抽象用例(这个任务的名称) /高层用例（任务的开始与结束）/扩展用例（两列表格，描述任务全程具体的交互过程）
- 第一步，从需求表述中找出用例，往往是动名词短语表示的抽象用例：
交通管理人员要能够查询各路段传感器的历史数据和实时数据，能够查看某路段的拥堵状况预测，并能够控制 电子公告牌提示道路的信息和分流的建议；
总结一下其中的动名词短语，抽象用例可以是：传感器数据查询 / 拥堵预测查看 / 控制公告牌
以表格的形式呈现，抽象用例大致是这样：
| System | 交通数据可视化系统 |
| Actor | 交通管理人员 |
| Use Case 1 | 交通传感器数据查询 |
| Use Case 2 | 拥堵预测信息查询 |
| Use Case 3 | 电子公告牌控制 |
- 第二步，描述用例开始和结束的状态，用TUCBW (The use case begins with) 和TUCEW (The use case ends with) 表示的高层用例：
根据上一步的抽象用例，可以写出具体一些的高层用例：
| TUCBW | TUCEW | |
| UC1 | 用户输入传感器位置和时间 | 传感器数据显示 |
| UC2 | 用户点击拥堵信息更新 | 路网数据显示 |
| UC3 | 用户输入公告牌位置，输入显示信息 | 公告牌成功显示信息 |
- 第三步，用例图如下：
2. 业务领域建模
业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知。因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知。
开发团队获取业务领域知识的过程一般包括收集业务领域相关信息、执行团队头脑风暴、对业务领域相关的知识概念进行分类，最后用UML类图将业务领域知识图形化展示。
由于环境限制，那我们自行头脑风暴，分析业务领域相关的知识概念，大致可以整出这么些内容来：
- 可以独立存在的名词大约由这几种：用户 / 传感器 / 路网 / 公告牌。这些名词都是独立的个体，均可是class类。而这些类上的操作可以有这些：
| 类名 | 属性 | 方法 | 描述 |
| 用户 | ID, 权限等 | 查询传感器，查询路网，更新公告牌 | 操作的主体 |
| 传感器 | ID, 坐标等 | 获得某时刻的平均速度等路况信息 | 用于采集和保存路况信息 |
| 路网 | 路网图 | 更新路网，查询传感器，计算拥堵数据 | 预测传感器构成的路网拥堵信息 |
| 公告牌 | ID, 坐标等 | 更新公告牌显示信息 | 显示用户发布的信息，引导交通 |
- 画出的UML类图如下所示：
3. 数据建模
根据业务领域建模和硬件设备的客观要求，我们可以设计下列数据表：
- 用户表：
| 字段名 | 字段描述 | 数据类型 | 长度 |
| USER_ID | 用户ID | BIGINT | 16 |
| PASSWORD | 用户密码 | VARCHAR | 32 |
| LIMIT | 用户权限 | VARCHAR | 8 |
- 传感器表：
| 字段名 | 字段描述 | 数据类型 | 长度 |
| SENSOR_ID | 传感器ID | BIGINT | 16 |
| LATITUDE | 维度 | FLOAT | 8 |
| LONGITUDE | 经度 | FLOAT | 8 |
| DIRECTION | 方向 | VARCHAR | 8 |
| ROAD_ID | 道路ID | BIGINT | 16 |
- 路况记录表：
| 字段名 | 字段描述 | 数据类型 | 长度 |
| SENSOR_ID | 传感器ID | BIGINT | 16 |
| TIMESTAMP | 时间戳 | TIMESTAMP | 4 |
| AVG_SPEED | 5分钟内的平均速度 | INT | 4 |
| AVG_OCCUPY | 5分钟内的平均车道占用率 | INT | 4 |
| TOTAL_FLOW | 5分钟内的平均速度 | INT | 4 |
- 公告牌表：
| 字段名 | 字段描述 | 数据类型 | 长度 |
| BILLBOARD_ID | 公告牌ID | BIGINT | 16 |
| LATITUDE | 纬度 | FLOAT | 8 |
| LONGITUDE | 经度 | FLOAT | 8 |
| ROAD_ID | 道路ID | BIGINT | 16 |
4. 概念原型
概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论。概念原型是一种虚拟的、理想化的软件产品形式。
如同那句有名的“程序 = 数据结构 + 算法”，概念原型可以看作用例+数据模型：
由前文的用例和数据模型建模，我们可以总结出这样的概念原型：
- 用户想要查询传感器在某时刻的记录：在操作界面输入传感器的位置和想要查看的时间，系统会返回传感器在某个时刻的数据到操作界面；用户想要查看最新的路网拥堵数据：在操作界面点击更新，系统会使用基于深度学习算法构建的模型，根据传感器的历史数据更新路网的拥堵预测信息，将路网信息返回到操作界面；用户想要在某个路段的某个电子公告牌上显示输入的信息：在操作界面输入公告牌的位置和想要显示的内容，系统会将数据发送至对应的电子公告牌，在操作界面显示发送成功。
5. 总结
本文根据工程实践的内容虚构了一个相关的应用项目，并对这个项目做了需求分析。一方面学习了需求分析的完整流程，另一方面从更加实际的角度审视了本人的工程实践项目。由于本人并没有实际的工程项目经验，本文的内容多是个人的理解，所以无论是您发现本文出现了概念理解偏差，或是不切实际的内容，希望大家能够进行批评指正，谢谢！
