前言
所做的工程實踐為基於深度學習，對微博內容進行情感分析，得出博文的情感傾向如何（積極/消極/中立/憤怒等等情感）。本項目偏向研究型，下面對項目進行相應的需求分析與概念原型等分析。
一、需求分析
（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