上完孟寧老師的高軟課程，要求我們對自己的工程實踐項目進行需求分析和概念原型設計，具體要求為針對自己的工程實踐項目，進行用例建模和業務領域建模，以及數據建模，最終形成概念原型。剛聽到這個作業，再去看看自己的工程實踐項目----基於情感詞典和機器學習的影評數據分析，感覺完全沒有思路，准確的說，是自己在做這個工程實踐項目的時候從來沒有想過用例建模這些事，更不用說去設計概念原型，我之前的想法是作為NLP類別的項目，重點在於算法的設計以及模型精度的改善這些方面，至於使用者的行為或者里面具體涉及的數據模型倒不是很重要；但直到某天，在高軟課程微信學習群里面看到某個同學說的一句話“如果一個深度學習算法沒有落地場景的話，這個算法又有什么意義呢”，雖然是句玩笑話，但是過后想了想，也確實是有道理的。各種機器學習算法的設計，最終落地都是給人使用，都是利用內部的數據轉換學習出來的結果，如果完全忽略建模和需求分析這些，算法的設計將變得毫無意義，畢竟軟件開發和算法設計的規范還是很重要的。所以，我整理了一下我的工程實踐材料，寫出以下需求分析和概念原型設計文檔。（參考孟寧老師課件：從需求分析到軟件設計）
一、基本需求說明
整理需求的兩類基本方法為原型化方法（Prototyping）和建模的方法（Modeling）。原型化方法可以很好地整理出用戶接口方式（UI，User Interface），比如界面布局和交互操作過程。建模的方法可以快速給出有關事件發生順序或活動同步約束的問題，能夠在邏輯上形成模型來整頓繁雜的需求細節。對於建模的方法，具體包括用例建模、業務領域建模和業務數據建模，利用這些模型即可較為直觀的反映出軟件系統設計的業務流程和模塊功能，能讓我們對整個系統一目了然。
針對自己的工程實踐項目-----基於情感詞典和機器學習的影評數據分析，是一個基於Python實現的一個大數據分析系統，主要實現的功能是對豆瓣網站上面的電影評論進行分析，並給出最后的參考分數。目前市場上的電影評論等軟件的評分機制雖然已經較為成熟，但是針對於小部分的評論而言，存在着一定的誤導性和反差性，很容易讓觀影者因為評論而對影片本身造成誤解，所以針對這個需求痛點，我們設計了這樣的一個基於評論數據的電影分析系統，能夠綜合在網站上獲取到的一些評論數據，分為訓練樣本和預測樣本，利用機器學習的方法來對訓練樣本進行訓練，並完成對基礎詞典的擴充，從而達到對最后的預測樣本評論數據進行分析的目的。以上說明即為基本的需求，下面針對本系統進行具體的建模和原型設計。
二、用例圖
用例（Use Case）的核心概念中首先它是一個業務過程（business process），經過邏輯整理抽象出來的一個業務過程，這是用例的實質。業務過程就是在待開發軟件所處的業務領域內完成特定業務任務（business task）的一系列活動。用例的幾個基本要素如下：
針對本系統而言，主要的參與者即有兩類，即為使用者User和管理員Admin，具體業務任務和參與者的角色如下用例圖所示：
具體的業務流程即為用戶注冊然后的登錄到本系統中，然后選擇具體相關看到電影，通過選擇這個電影可以查看系統根據影評給出的分數和評分建議；而管理員端主要完成的是對評論的數據的接收以及模型的維護和更新，通過查看模型給出的結果確定是否需要進行模型的改進等，同時也可以在系統數據庫中查看系統用戶的數據。
三、業務類圖
業務領域建模是開發團隊用於獲取業務領域知識的過程。因為軟件工程師往往需要工作在不同的業務領域或者不同項目中，他們需要業務領域知識來開發軟件系統。軟件工程師往往來自不同的專業背景，這可能會影響他們對業務領域的認知。因此業務領域建模有助於開發團隊獲取業務領域知識形成統一的業務認知。開發團隊獲取業務領域知識的過程一般包括收集業務領域相關信息、執行團隊頭腦風暴、對業務領域相關的知識概念進行分類，最后用UML類圖將業務領域知識圖形化展示。
業務領域建模的基本步驟如下：
這四個步驟中，第一個就是整個系統的需求總結和調研，頭腦風暴就是團隊成員聚在一起執行頭腦風暴從收集的應用業務領域的信息中按規則識別業務領域相關的概念，並分別列出，即相當於提取出需求的關鍵詞；第三步即為核心步驟，經過頭腦風暴按照識別規則將業務領域內的信息提取出來之后，我們需要進一步對這些信息進行面向對象分析，將其歸類為類、屬性，以及類之間的關系，簡而言之也就是關鍵詞之間的關系和特征整理。針對自己的工程實踐項目，可以畫出如下業務類圖：
針對以上的業務類圖，即可以看出用戶選擇觀看的電影，系統即根據選擇的電影的評論生成分數和建議，最終反饋給用戶，而在實際應用中，系統的主要工作過程也是對電影的評論的分析，並最終給出系統生成的分數和建議。
四、數據模型
根據第三部分的業務類圖，可以看出來系統涉及的主要數據模型即為四個大的存儲表，即為用戶User表，電影Film表和comment表以及用戶選擇電影后生成的U_Select_F表，具體的表結構和描述如下表格所示：
User表
| Field | Type | Null | Key | Comment |
| uid | int | — | PRI | 用戶id |
| name | varchar(20) | — | — | 用戶姓名 |
| sex | varchar(5) | — | — | 用戶性別 |
Film表
| Field | Type | Null | Key | Comment |
| fid | int | — | PRI | 電影id |
| fname | varchar(20) | — | — | 電影名稱 |
comment表
| Field | Type | Null | Key | Comment |
| cid | int | — | PRI | 評論id |
| fid | int | — | FRI | 電影id |
| value | varchar(50) | — | — | 評論內容 |
U_Select_F表
| Field | Type | Null | Key | Comment |
| ufid | int | — | PRI | 事務id |
| uid | int | — | FRI | 用戶id |
| fid | int | — | FRI | 電影id |
| score | double | — | — | 評論得出的分數 |
| advice | varchar(20) | — | — | 評論給出的建議 |
上述的四個表結構以及表中的數據均存在與關系型數據庫中，由於電影這個實體類在代碼設計時會直接包含該電影所屬的評論，所以在實現的過程中也是直接利用外建的方式將電影的id存儲到評論之中，在系統實現時，直接查詢數據庫中的評論即可，較為方便，同時也可以不導致數據冗余（一部電影對應的評論可能很多）。
五、概念原型
進行完上述的用例建模，業務流程建模和數據模型之后，接下來就進行概念原型的設計。概念是人對能代表某種事物或發展過程的特點及意義所形成的思維結論。概念原型是一種虛擬的、理想化的軟件產品形式。對概念原型不是很清楚時，可以類比我們比較熟悉的：
程序=算法+數據結構
這是一個很經典的論斷，而對比概念模型，我們也可以總結為：
概念原型=用例+數據模型
所以，針對以上幾個部分的建模，這里的概念原型就很清晰了。簡而言之就是用戶在系統中選擇自己想看的電影，系統根據用戶選擇的電影從數據庫中找到對應的評論，進而對這些評論進行分析，給出最后分析的電影評分和建議，供用戶觀影之前的參考；而系統的管理員（其實就是我們開發小組）也會對該系統進行不斷地測試和維護，當系統的評分模型出現較大的誤差時，我們便會從數據和算法模型入手，去做數據清洗工作或者算法的改進工作，提高評分的准確率。
六、總結
至此系統建模和原型設計總結完畢。對於我們這個NLP類別的工程時間項目，可能確實重點工作還是在數據獲取和算法設計這兩個方面上，但是當我們自習剖析系統的需求所在以及系統的用例所在，就會發現不管什么項目，都有用例和數據模型來進行構建，即使用例對項目本身的意義不大，但是當我們真正總結出來所需要的用例以及數據模型的時候，系統的結構會變得更加清晰。在概念原型的指導下，工程實踐項目也不再是完全的爬蟲+tensorflow+可視化，而變成了一個能夠按照需求去實現的一個大數據文本分析的系統。