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輸入，以便更准確地預測統一標簽。該組件被賦予一個門機制，以明確地將前一個詞的特征集成到當前預測中，旨在保持多詞意見目標中的情感一致性。
為了提供更高質量的邊界信息，運行經驗組件遵循“意見目標和意見詞總是同時出現”的觀察，執行另一個輔助二進制分類任務來確定當前詞是否是目標詞。情感一致性組件和增強目標詞檢測組件采用了軟最大解碼層的標簽序列預測，觀察到邊界標簽可以為統一標簽預測提供重要線索。