一、前言
本文是對工程實踐項目基於情感詞典的豆瓣電影影評分析系統進行的討論，主要是通過對設計模式與軟件架構的分析，闡述項目的完整設計方案並采用不同的視圖來描述軟件系統以形成軟件系統概念原型。
工程實踐項目介紹：豆瓣網作為中國最大最權威的電影評論網站之一，它對電影的評價在人們選擇和認知電影的過程中扮演着非常重要的作用。但豆瓣評分往往只關注了用戶對電影的評分信息，而忽視了用戶的評論信息，使得人們看到的最終評分未必能反映這部電影的真實情況，所以為了幫助瀏覽者有效的解讀影評文本，了解影評中的情感因素，我們對影評進行情感分析並打分，通過對電影評論情感得分與豆瓣原生用戶評分進行分析對比，使用戶更好地了解電影的整體評價。
二、軟件設計方案
我們首先需要確定項目的架構風格和設計模式，有了整體的框架后后面的工作才好進行。
其中對於架構風格來說，常見的有三層架構、MVC架構、MVVM架構等。軟件架構的設計要考慮滿足數量眾多的各種系統功能需求，也需要完成諸如系統的易用性、系統的可維護性等非功能性的設計目標，還要遵從各種行業標准和政策發揮。軟件架構模型是通過一組關鍵視圖來描述的，同一個軟件架構，由於選取的視角不同可以得到不同的視圖，這樣一組關鍵視圖搭配起來可以完整地描述一個邏輯自洽的軟件架構模型。一般來說，我們常用的幾種視圖有分解視圖、依賴視圖、泛化視圖、執行視圖、實現視圖、部署視圖和工作任務分配視圖。架構風格主要有P2P、管道-過濾器、發布-訂閱、客戶-服務、CRUD、層次化。
對於設計模式來說，若根據設計模式可以完成的任務類型來划分的話，可以分為創建型模式、結構型模式和行為型模式3種類型的設計模式。常用的設計方案有單例模式、原型模式、建造者模式、享元模式、策略模式、命令模式、模板方法模式等。雖然設計模式很多，但是我們還是要遵循以下原則，即開閉原則（OCP）、Liskov替換原則（LSP）、依賴倒置原則（DDIP）、單一職責原則（SRP）、迪米特原則（LoD）、合成復用原則（CRP）。
1、軟件架構風格
我們的項目整體采用Django框架進行開發。Python下有多種不同的web框架，Django是其中最具代表性的一位，相較於其他的框架優勢在於：大而全，框架本身集成了ORM、模型綁定、模板引擎、緩存、Session等功能。
Django是基於MVC架構進行開發的，MVC是眾所周知的模式，即：將應用程序分解成三個組成部分：model（模型）、view（視圖）、controller（控制器）。其中：M--管理應用程序的狀態（通常存儲到數據庫中），並約束改變狀態的行為（或者叫做業務規則）；V--負責把數據格式化后呈現給用戶；C--接受外部用戶的操作，根據操作訪問模型獲取數據，並調用視圖顯示這些數據。控制器是將模型和視圖隔離，並成為二者之間的聯系紐帶。最簡單的MVC原理圖如下所示：
MVC設計思想體現了系統邏輯處理與網站視圖展示的分離，允許在不修改模型層和控制層等后端數據處理代碼的情況下，想要達到改變數據展示的目的，僅需要對視圖層代碼的修改。同樣，對模型層修改后，只要數據返回格式正確，視圖層仍然能正確展示結果，大大降低了代碼的耦合度且易於維護。
2、軟件系統概念原型視圖
上文中也提到了，軟件架構模型是通過一組關鍵視圖來描述的，同一個軟件架構，由於采用不同的視角可以得到不同的視圖，不同的視圖搭配起來可以完整地描述一個軟件架構模型。下面我們將對上面提到的部分視圖進行展示和分析。
（1）、分解視圖
分解是構建軟件架構模型的關鍵步驟，分解視圖也是描述軟件架構模型的關鍵視圖，一般分解視圖呈現為較為明晰的分解結構特點。分解視圖用軟件模塊勾划出系統結構，往往會通過不同抽象層級的軟件模塊形成層次化的結構。簡單的說就是將系統的功能分解成幾個部分，每個部分又包含各自需要處理的業務。下圖是本項目的分解視圖：
（2）、依賴視圖
依賴視圖展現了軟件模塊之間的依賴關系。比如一個軟件模塊A調用了另一個軟件模塊B，那么我們說軟件模塊A直接依賴軟件模塊B，如果一個軟件模塊依賴另一個軟件模塊產生的數據，那么這兩個軟件模塊也具有一定的依賴關系。在我們的工程實踐項目中，數據獲取、數據處理和可視化顯示存在着互相的傳遞和調用，其依賴視圖如下所示：
（3）、執行視圖
執行視圖展示了系統運行時的時序結構特點，比如流程圖、時序圖等。執行視圖中的每一個執行實體，一般稱為組件，都是不同於其他組件的執行實體。如果有相同或相似的執行實體那么就把它們合並成一個。在設計與實現過程中，我們一般將執行視圖轉化為偽代碼之后，再進一步轉化為實現代碼。本次工程項目的實現流程圖如下:
（4）、實現視圖
實現視圖是描述軟件架構與源文件之間的映射關系，比如軟件架構的靜態結構以包圖或設計類圖的方式來描述，但是這些包和類都是在哪寫目錄的哪些源文件中具體實現的呢？一般我們通過目錄和源文件的命名來對應軟件架構中的包、類等靜態結構單元，這樣典型的實現視圖就可以有軟件項目的源文件目錄樹來呈現。實現視圖與軟件架構的靜態結構之間映射關系越是對應的一致性越高，越有利於軟件的維護，因此實現視圖時一種非常關鍵的架構視圖。以下為我們的工程實踐項目的實現視圖：
（5）、工作分配視圖
工作分配視圖將系統分解成可獨立完成的工作任務，以便分配給各項目團隊和成員。工作分配視圖有利於跟蹤不同項目團隊和成員的工作任務的進度，也有利於在個項目團隊和成員之間合理得分配和調整項目資源，甚至在項目計划階段工作分配視圖對於進度規划、項目評估和經費預算都能起到有益的作用。本工程實踐項目對應的工作分配視圖如下圖所示：
3、設計模式
設計模式是軟件設計中常見問題的典型解決方案。每個模式就像一張藍圖，你可以通過對其進行定制來解決代碼中的特定設計問題。正確的使用設計模式可以提高程序員的思維能力，編程能力和設計能力；也使得程序設計更加標准化、代碼編制更加工程化，使得軟件開發效率大大增強；使得設計的代碼可重用性強、可讀性強、可靠性高、靈活性好。
本次我們的工程實踐項目使用的是組合模式，結合對業務類圖的分析，可以知道：
用戶通過選擇自己喜歡看的電影，系統會根據選擇的電影的短評進行分析給出評分和建議，最終反饋給用戶。
4、數據庫設計
系統涉及的主要數據模型為以下四大存儲表，即為用戶表、影評系統表、影評信息表、電影生成信息表。表結構以及表中的數據均存放在關系型數據庫中，由於電影這個實體類在代碼設計時會直接包含所附屬的評論，所有在實現的過程中也是直接利用外建的方式將電影的id存儲到評論之中，在系統實現時直接查詢數據庫中的評論即可。表結構如下所示：
| 字段名 | 字段類型 | 描述 |
| uid | int | 用戶id |
| name | string | 用戶姓名 |
| 字段名 | 字段類型 | 描述 |
| fid | int | 電影id |
| fname | string | 電影名 |
| comment | string | 電影評論 |
| 字段名 | 字段類型 | 描述 |
| cid | int | 評論id |
| fid | int | 電影id |
| value | string | 評論內容 |
| 字段名 | 字段類型 | 描述 |
| uid | int | 用戶id |
| fid | int | 電影id |
| ufid | int | 事務id |
| score | double | 評論得分 |
| advice | string | 評論建議 |
三、系統開發環境和技術選型
本系統采用結構化方法來進行開發，將系統實現的功能分解，各模塊分別開發和維護，易於實現且維護。
基於64位win10系統開發，開發環境為Pyhon3.6、Django2.0.1、Tensorflow2.0
編譯器為JetBrains Pycharm2019.3.3，通過爬蟲技術獲取需要的數據，數據存放在mysql數據庫
四、系統概念原型的核心工作機制
每個視圖都是從不同的角度對軟件架構進行描述和建模，比如從功能的角度、從代碼的角度、從運行時結構的角度、從目錄文件的角度，或者是從項目團隊組織結構的角度。軟件架構代表了軟件系統的整體設計結構，它應該是所有這些視圖的集合。但我們不會將不同角度的視圖整合起來，因為不便於閱讀和更新，不過我們會有意識地將不同角度的視圖之間的映射關系和重疊部分了然於胸，從而深刻理解軟件架構內在的一致性和完整性，這就是系統概念原型。
整個概念模型的工作過程為：對於用戶來說，我們從系統中選擇自己想要了解的電影，系統根據用戶選擇的電影評論進行分析，得到對於評論信息的情感得分並給出建議信息，最后能和原系統自帶評分進行比較並得出差異，進一步可以通過可視化方法實現更加清晰地認識。