工业互联网工程实践需求分析
前言
本文将用软件工程的方法对我的工程实践项目进行需求分析。主要涉及需求分析，用途建模，业务领域建模数据建模并最终以此形成概念原型。
系统简介
本课题是关于工业物联网设备监控与管理系统服务端的设计与开发。该系统是一个集分级用户管理，设备情况监控，设备控制与数据转发于一体的多边平台。各级用户拥有不同权限，可以对所属的不同设备进行监控或操作。可以做到对设备情况进行远程诊断，远程重启等操作，减维修人员到现场的次数，大大减少人力成本，方便设备管理。
需求分析
介绍
需求就是对用户期望的软件行为的表述，获取需求就是需求分析师通过关注用户的期望和需要，从而获得用户期望的软件行为，然后对其进行表述的工作。需求分析是在获取需求的基础上进一步对软件涉及的对象或实体的状态、特征和行为进行准确描述或建模的工作。
系统需求分析
系统用户
该系统主要面向对象为大型工业企业，总共分为5级用户。A级为全国总厂，B级为总经销商，C级为次级经销商，D级为工厂管理员，E级为值班人员。各级用户可以查看管理自已拥有的设备以及所属的下级用户的设备，而不能看到其他人的设备情况。经销商可以对自己下属的设备进行远程重启等操作。
5级用户：
E级用户（值班员）在经过登陆过后拥有以下功能：
- 更新自己的个人信息和密码
- 设备查看（可以模糊查询设备，设备位置，设备类型，只能查看属于自己工厂的设备）
- 异常提醒（当温度或其他数据出现异常会提醒用户）
- 问题上报（设备损坏可以向上级用户报告，问题严重程度可以分级）
D级用户（具体某个工厂）：
- 修改个人信息和密码
- 增、删、改、查自己的下属人员（值班员）
- 设备添加（属于自己的设备开启时，设置其基本信息并纳入系统管理）
- 设备删除（将不用的设备从系统管理中剔除）
- 设备查看（是否使用，工作状态，模糊查询）
- 设备信息修改（设备名，位置等）
- 问题上报（D级解决不了的，给C级）
B,C级用户（某个地区，省级的管理员，管理各个厂，总经销商和分经销商 ）
-
修改个人信息
-
添加删除查找自己下属的用户
-
分配设备给下级用户（将属于自己的设备分配给下级用户）
-
查看自己所有设备的状态（已分配，未分配，损坏，模糊查询）
-
查看下属用户的设备状况
-
问题上报（B,C级解决不了的，给A级）
A级用户（厂家的总管理员）：
- 修改个人信息
- 添加删除查找各级用户
- 添加，删除设备，
- 分配设备（将本工厂未分配的设备，分配给下属的B级用户）
- 查看未分配设备（模糊查询，设备位置，类型）
- 查看所有设备的状况
- 问题查看和解决
设备合法性验证
用户只允许使用总厂或者上级用户分配的设备，如果使用其他设备，系统将无法识别，也无法将其数据录入数据库。用户也无法从拥有的设备表中找到该设备。
权限分配
各用户只能操作、查看自己和自己下属用户设备的状态。总体将用户分为5级，各级用户可创建相应的下属的用户，E级用户（值班员）只能由D级用户（厂家）创建。
用例建模
用例简介
用例（Use Case）的核心概念中首先它是一个业务过程（business process），经过逻辑整理抽象出来的一个业务过程，这是用例的实质。什么是业务过程？在待开发软件所处的业务领域内完成特定业务任务（business task）的一系列活动就是业务过程。
接下来我们具体看看用例的几个基本要素：
- 一个用例应该由业务领域内的某个参与者（Actor）所触发。
- 用例必须能为特定的参与者完成一个特定的业务任务。
- 一个用例必须终止于某个特定参与者，也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。
用例建模的基本步骤
- 从需求表述中找出用例，往往是动名词短语表示的抽象用例；
- 描述用例开始和结束的状态，用TUCBW和TUCEW表示的高层用例；
- 对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；
- 进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。
其中第一步到第三步是计划阶段，第四步是增量实现阶段。
系统用例
值班员用例：
厂家用例：
经销商用例：
顶级用户：
业务领域建模
介绍
业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知。因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知。
开发团队获取业务领域知识的过程一般包括收集业务领域相关信息、执行团队头脑风暴、对业务领域相关的知识概念进行分类，最后用UML类图将业务领域知识图形化展示。
基本步骤
- 收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；
- 头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；
- 给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系
- 将结果用 UML 类图画出来。
系统类图
数据建模
根据前面的的内容，本系统将大概有4张数据表分别为：
- 用户表：用来存放用户数据
- 执行器表：用来存放执行器数据
- 网关表：用来存放网关数据
- 状态数据表：用来存放执行器状态
用户表：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | int | 用户id，用来唯一标识用户 |
| name | varchar | 用户名，用来登录 |
| password | char | 密码 |
| grade | int | 用户等级 |
| parent_id | int | 用户的上级 |
| info | text | 用户信息 |
| create_time | timestamp | 用户创建时间 |
执行器表：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | int | 执行器在数据库的唯一标识 |
| Pid | char | 执行器的出厂id |
| name | varchar | 执行器的名称 |
| pos | varchar | 执行器所在位置 |
| type | int | 执行器的类型 |
| gateway | char | 网关的mac地址 |
| user_id | int | 所属用户的id |
| create_time | timestamp | 执行器使用的开始时间 |
| info | text | 执行器的相关信息 |
| ip | char | 执行器所在的ip地址 |
| status | int | 执行器的状态（启用，运行中等） |
网关表：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | int | 网关的唯一标识 |
| parent_id | int | 所属用户的id |
| mac | char | 网关的mac地址 |
执行器状态表：
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | int | 状态数据的唯一标识 |
| fid | char | 设备出厂id和网关mac地址的合并 |
| data | varchar | 数据内容 |
| time | timestamp | 接收时间 |
概念原型
概念是人对能代表某种或发展过程的特点及意义气形成的思维结论，而概念原型是一种虚拟的、理想化的软件产品形式。
通过以上用例和数据模型我们已经得到本系统的概念原型了，其工作过程如下：
用户在登录后，系统会对用户的等级进行鉴定，对不同用户提供不同的功能。这些用户会根据等级不同能够对不同的设备进行查看数据远程重启等不同操作。
参考资料：https://gitee.com/mengning997/se/blob/master/ppt/从需求分析到软件设计.pptx
