微博情感分析——需求分析和概念原型
前言
所做的工程实践为基于深度学习，对微博内容进行情感分析，得出博文的情感倾向如何（积极/消极/中立/愤怒等等情感）。本项目偏向研究型，下面对项目进行相应的需求分析与概念原型等分析。
一、需求分析
（1）什么是需求分析
需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。
（2）本项目的需求分析
探寻人所思所想是一个有价值的研究方向。例如当今生活压力增大，常常有人想不开甚至走向极端，如能了解其内心所想，及时对其干预治疗，相信会挽救不少生命。
而微博是年轻人表达自己想法观点的重要场所，其内容很大程度上反应了一个人内心的情感。因此本项目，微博情感分析系统，就有了很大研究价值。
二、用例建模
1、用例概念
用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
2.Actor概念
参与者是业务领域内的参与者或者业务实体。参与者不是待开发软件系统的一部分，但参与者需要和待开发软件系统交互。参与者常常是人，比如客户，但也可以是一个外部的硬件或软件，甚至是待开发软件系统内部的一个组件，比如内部计时器可以触发某个业务过程。某个参与者触发某个用例为相应的参与者完成一个业务任务。
3.用例的三个抽象层次
抽象用例。只要用一个干什么、做什么或完成什么业务任务的动名词短语，就可以非常精简地指明一个用例；
高层用例。需要给用例的范围划定一个边界，也就是用例在什么时候什么地方开始，以及在什么时候什么地方结束；
扩展用例。需要将参与者和待开发软件系统为了完成用例所规定的业务任务的交互过程一步一步详细地描述出来，一般我们使用一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来。
4.判断是否为用例的四个条件
必要条件一：它是不是一个业务过程？
必要条件二：它是不是由某个参与者触发开始？
必要条件三：它是不是显式地或隐式地终止于某个参与者？
必要条件四：它是不是为某个参与者完成了有用的业务工作？
5.本项目的用例分析
a）管理员抓取训练模型所需的大量训练数据，并选择多种模型进行训练，选择合适的模型。
b）客户可使用本系统进行微博内容的情感分析。如果没注册可在系统注册，并进行登录、注销账号等操作。
c）客户登录账号后提交微博内容，使用本系统所提供的模型进行情感分析，并得到系统所预测的情感倾向。
d）如客户有问题，可咨询客服并得到答复。
（1）用例分析
System：微博情感分析系统——客户使用子系统
Actor：客户
Use Case：
UC1：注册账号；
UC2：登录账号；
UC3：注销账号；
UC4：输入微博内容；
UC5：咨询客服；
System：微博情感分析系统——管理员服务子系统
Actor：管理员
Use Case：
UC6：抓取训练数据；
UC7：训练模型；
UC8：选择模型；
UC9：生成情感分析结果；
UC10：客户账号管理；
UC11：客户咨询反馈；
（2）高层用例分析
| 用例开始 | 用例结束 | |
| UC1：注册账号 | 客户创建账号与密码 | 系统返回注册成功与否 |
| UC2：登录账号 | 客户输入账号与密码 | 系统返回登录成功与否 |
| UC3：注销账号 | 客户输入需要注销的账号与密码 | 系统返回注销成功与否 |
| UC4：输入微博内容 | 客户输入需要进行情感分析的微博内容 | 系统返回情感倾向分析结果 |
| UC5：咨询客服 | 客户输入咨询内容 | 系统返回回答内容 |
| UC6：抓取训练数据 | 管理员输入爬取微博内容范围 | 系统返回爬取内容 |
| UC7：训练模型 | 管理员输入爬取内容作为训练集 | 系统返回训练结果 |
| UC8：选择模型 | 管理员选择不同模型 | 系统进行调整后返回更改成功 |
| UC9：生成情感分析结果 | 管理员输入客户提交的微博内容 | 系统返回情感倾向分析结果 |
| UC10：客户账号管理 | 管理员对客户账号进行管理 | 系统返回管理结果 |
| UC11：客户咨询反馈 | 管理员对客户问题进行回答 | 系统提示回答成功 |
（3）微博情感分析系统用例图
三、业务领域建模
（1）业务领域建模的概念
业务对象模型（也叫领域模型 domain model）是描述业务用例实现的对象模型。它是对业务角色和业务实体之间应该如何联系和协作以执行业务的一种抽象。业务对象模型从业务角色内部的观点定义了业用例。该模型为产生预期效果确定了业务人员以及他们处理和使用的对象（“业务类和对象”）之间应该具有的静态和动态关系。它注重业务中承担的角色及其当前职责。这些模型类的对象组合在一起可以执行所有的业务用例 。
（2）业务领域建模的过程
收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。将结果用 UML 类图画出来。
（3）微博情感分析系统的业务领域建模
整个系统有四个类：User类是客户使用，可以用来输入微博内容进行情感分析，也可就问题咨询客服；User Manage类负责对客户各种信息进行管理，并对客户的注册、登录、注销等操作进行服务；Model Manage类是对情感分析系统模型的管理；Administrator类是系统管理员类。
四、数据建模
User：
| 字段 | 类型 | 注释 |
| 用户ID | int | 唯一确定用户身份 |
| 用户密码 | string | 可用于登录 |
User Manage：
| 字段 | 类型 | 注释 |
| 用户ID | int | 唯一确定用户身份 |
| 用户昵称 | string | 用户可修改的昵称 |
| 用户密码 | string | 可用于登录 |
| 用户手机号 | int | 实名制需要 |
| 用户邮箱 | string | 联系用户邮箱 |
| 用户状态 | string | 在线/离线等 |
| 提交微博内容编号 | int | 唯一确定 |
| 提交咨询编号 | int | 唯一确定 |
Model Manage：
| 字段 | 类型 | 注释 |
| 模型编号 | int | 用于表示不同种模型 |
Administrator：
| 字段 | 类型 | 注释 |
| 管理员ID | int | 唯一确定管理员身份 |
| 管理员昵称 | string | 管理员可修改的昵称 |
| 管理员密码 | string | 管理员登录密码 |
五、概念原型
概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论。概念原型是一种虚拟的、理想化的软件产品形式。
本项目的概念原型是：管理员爬取大量数据作为训练数据，并尝试选择不同种模型进行分析比较，从中选择最佳模型，并在需要时对客户信息进行管理，并回答客户的问题。
而用户则通过注册、登录等操作进入系统，使用训练好的模型，得到情感分析的结果。如果有问题可向管理员提问。
六、总结
通过本课程的学习，我在理论上学到了很多有用于实践的知识，对项目的整个架构有了更为深入的理解。
参考：https://gitee.com/mengning997/se/blob/master/README.md#%E4%BB%A3%E7%A0%81%E4%B8%AD%E7%9A%84%E8%BD%AF%E4%BB%B6%E5%B7%A5%E7%A8%8B
