1.整体设计方案
传统的基于目标的情感分析涉及目标情感提取和目标情感分类。但是现有的大部分工作通常都是单独研究这两个子任务中的一个，阻碍了它们的实际应用。如传统的基于目标的情感分析旨在检测句子中明确提到的意见目标，并预测意见目标上的情感极性。这种方法，是将这个任务分为两个子任务，即目标情感提取和目标情感分类。例如，在“新电脑比旧电脑好的多”这句话中，用户提到了两个意见目标，即“新电脑”和“旧电脑”，并对第一个表示积极的情绪，对第二个表示消极的情绪。
第一个子任务，目标情感提取的目的是检测文本中所提到的目标情感，已经被广泛研究。第二子任务，即目标情感分类，它可以预测给定意见目标的情感极性。这个子任务近年来也受到了很多关注。
是以端到端的方式解决基于目标的情感分析这一完整任务，并提出了一种新的应用统一标记方案的统一模型。这种框架包括两个堆叠的递归神经网络:上层预测统一的标签，以产生基于主要目标的情感分析的最终输出结果；下层执行辅助目标边界预测，旨在引导上层网络提高主要任务的性能。为了探索任务间的依赖性，使用了模拟从目标边界到目标情感极性的约束转换。还通过一个门机制来保持目标中的情感一致性，该机制对当前单词和前一个单词的特征之间的关系进行建模。
在两个堆叠的带有LSTM单元的RNN之上，我们的框架设计了三个关键组件，用标注详细描述，以探索TBSA任务中的三个重要直觉。具体来说，上标签用于完成TBSA任务并预测作为输出的统一标签，而下标签用于辅助任务并预测目标提及的边界标签。来自第一时间点的边界预测用于指导第一时间点对完整任务的统一标签进行更好的预测。
出来这个模型，我们还尝试了传统的DNN，textCNN等方案。
2. 软件架构风格与策略
软件架构既要考虑满足数量众多的各种系统功能需求， 也需要完成诸如系统的易用性、系统的可维护性等非功能性的设计目标， 还要遵从各种行业标准和政策法规。 不过并不是每一个项目我们都需要从头开始进行完全创新性的设计，更多的是通过研究借鉴优秀的设计方案，来逐步改进我们的设计。换句话说，大多数的设计工作都是通过复用（Reuse）相似项目的解决方案，或者采用一些优秀设计方案的方法，这让看起来非常有挑战性的软件架构设计工作变得有例可循。但是，软件架构又是至关重要的：
（１） 软件架构模型有助于项目成员从整体上理解整个系统
（２） 给复用提供了一个高层视图，既可以辅助决定从其他系统中复用设计或组件，也给我们构建的软件架构模型未来的复用提供了更多可能性
（３） 软件架构模型为整个项目的构建过程提供了一个蓝图，贯穿于整个项目的生命周期
（４） 软件架构模型有助于理清系统演化的内在逻辑、有助于跟踪分析软件架构上的依赖关系、有助于项目管理决策和项目风险管理等
系统采用MVC架构，MVC包括模型层（Model）、视图层（View）、控制器层（Controller）
Model代表一个存取数据的对象及其数据模型。
View代表模型包含的数据的表达方式，一般表达为可视化的界面接口。
Controller作用于模型和视图上，控制数据流向模型对象，并在数据变化时更新视图。控制器可以使视图与模型分离开解耦合。
3.接口API
用户接口API的设计
| 接口名称 | 参数列表 | 返回 | 注释 |
| userRegister | name,password,tel,email | true/false | 用户注册 |
| userLogin | name,password | userid/false | 用户登录 |
| userLogout | name,password | true/false | 用户注销 |
| userPredict | userid,content | userid,content,resultlist | 用户预测 |
| userAsk | userid,content | userid,answer | 用户询问 |
| userLoad | userid,filename | true/false | 用户下载结果 |
| userDownload | userid | content | 用户上传 |
管理员接口API的设计
| 接口名称 | 参数列表 | 返回 | 注释 |
| adminRegister | name,password | true/false | 管理员登录 |
| adminData | dataLists | null | 数据管理 |
| adminModel | modelLists | null | 模型管理 |
4.视图设计
分解视图
依赖视图
依赖视图展现了软件模块之间的依赖关系。比如一个软件模块A调用了另一个软件模块B，那么我们说软件模块A直接依赖软件模块B。如果一个软件模块依赖另一个软件模块产生的数据，那么这两个软件模块也具有一定的依赖关系。依赖视图在项目计划中有比较典型的应用。比如它能帮助我们找到没有依赖关系的软件模块或子系统，以便独立开发和测试，同时进一步根据依赖关系确定开发和测试软件模块的先后次序。依赖视图在项目的变更和维护中也很有价值，比如它能有效帮助我们理清一个软件模块的变更对其他软件模块带来影响范围。
执行视图（流程图展示）
用户登录注册流程图
用户分析情感流程图
管理员分析情感流程图
工作分配视图
5.源代码目录文件结构
|-- senti_analysis 主要对传入的文本进行分析处理 ||-- Model.py 数据库模型以及相关操作，负责和数据库交互，进行数据处理 ||-- urls.py URL配置表文件，主要是将URL映射到应用程序上 ||-- view.py 保存响应各种请求的函数或者类 ||-- routes 路由配置 |--train_model 主要复杂模型的训练 ||--... 与第一个模块结构类似 |--user 用户相关的业务处理 ||--... 与第一个模块结构类似 |--administrator 管理员相关的业务处理 ||--... 与第一个模块结构类似 |--templates 存放html静态模板的 |--static 放css和js这些静态文件 |-- utils 常用工具 |--manage.py 自动创建，它是django的任务管理命令行工具
6.数据库设计
User：
| 字段 | 类型 | 注释 |
| 用户ID | int | 唯一确定用户身份 |
| 用户密码 | string | 可用于登录 |
User Manage：
| 字段 | 类型 | 注释 |
| 用户ID | int | 唯一确定用户身份 |
| 用户昵称 | string | 用户可修改的昵称 |
| 用户密码 | string | 可用于登录 |
| 用户手机号 | int | 实名制需要 |
| 用户邮箱 | string | 联系用户邮箱 |
| 用户状态 | string | 在线/离线等 |
| 提交微博内容编号 | int | 唯一确定 |
| 提交咨询编号 | int | 唯一确定 |
Model Manage：
| 字段 | 类型 | 注释 |
| 模型编号 | int | 用于表示不同种模型 |
Administrator：
| 字段 | 类型 | 注释 |
| 管理员ID | int | 唯一确定管理员身份 |
| 管理员昵称 | string | 管理员可修改的昵称 |
| 管理员密码 | string | 管理员登录密码 |
7.软件系统运行环境和技术选型
本系统应用多种深度学习模型对输入的文本进行情感分析，为了使系统的运行逻辑更加清晰，因此采取了前后端分离的方式对其进行更高效的处理。后端的搭建采用Pycharm使用Django框架进行开发，该框架具有强大的后台管理模块和方便的ORM操作模块，前端部分采用HTML、CSS、JavaScript等技术实现用户界面的开发，对于后期在训练数据上可能会存在不足可能会通过scrapy框架来进行获取。
该系统的运行环境如及相关技术如下所示：
（1）开发主要使用语言及相关技术：Python，Django框架，相关的深度学习模型pytorch，HTML、CSS、JavaScript。
（2）系统后台数据库：MySQL数据库。
（3）数据库可视化管理工具：SQLyogEnt。
（4）开发软件：Pycharm。
（5）浏览器：Google Chrome（谷歌浏览器）/ Firefox（火狐浏览器）/ IE浏览器。
8.系统概念原型的核心工作机制
本项目的概念原型是：
管理员爬取大量数据作为训练数据，并尝试选择不同种模型进行分析比较，从中选择最佳模型，并在需要时对客户信息进行管理，并回答客户的问题。
而用户则通过注册、登录等操作进入系统，使用训练好的模型，得到情感分析的结果。如果有问题可向管理员提问。
本项目侧重于算法方面，重要创新是：
采取了双层LSTM结构与参考了著名的gate机制进行边界截取。又采用了三个关键组件，分别是边界引导组件、情感一致性组件和增强目标词检测组件。
边界引导组件组件利用辅助任务提供的边界信息来指导LSTM输入，以便更准确地预测统一标签。该组件被赋予一个门机制，以明确地将前一个词的特征集成到当前预测中，旨在保持多词意见目标中的情感一致性。
为了提供更高质量的边界信息，运行经验组件遵循“意见目标和意见词总是同时出现”的观察，执行另一个辅助二进制分类任务来确定当前词是否是目标词。情感一致性组件和增强目标词检测组件采用了软最大解码层的标签序列预测，观察到边界标签可以为统一标签预测提供重要线索。