一、前言
本系統是一個基於Python實現的一個大數據分析系統，主要實現的功能是對豆瓣網站上面的電影評論進行分析，並給出最后的參考分數。目前市場上的電影評論等軟件的評分機制雖然已經較為成熟，但是針對於小部分的評論而言，存在着一定的誤導性和反差性，很容易讓觀影者因為評論而對影片本身造成誤解，所以針對這個需求痛點，我們設計了這樣的一個基於評論數據的電影分析系統，能夠綜合在網站上獲取到的一些評論數據，分為訓練樣本和預測樣本，利用機器學習的方法來對訓練樣本進行訓練，並完成對基礎詞典的擴充，從而達到對最后的預測樣本評論數據進行分析的目的。
系統基於情感詞典和機器學習的方法來進行數據的處理和分析，利用Django框架來進行系統整體的開發。由於該項目暫時處於構思設計階段，所以本文結合高級軟件工程課程上面所學到的知識以及目前的開發進度，來對該系統進行系統概念原型的分析和設計。
二、軟件架構風格
系統整體采用Django的框架來進行前后端的開發，Python 下有 Flask、Django、Tornado 等許多款不同可供選擇的 Web 框架,其中 Django框架是主流框架中最有代表性的一位，它最早是被用於開發管理勞倫斯集團下的一些以新聞內容為主網站的內容管理系統軟件。Django 創造了許多成功的網站和應用，使用該框架可以使 Web 開發能夠以最小的代價構建 Web 應用並且使其維護變的方便。同時 Django能為頻繁進行編程的模塊提供了快速的解決方案。
Django是基於MVC的架構進行開發的，MVC即為Model-View-Controller（模型-視圖-控制器），各部分含義如下： Model（模型）代表一個存取數據的對象及其數據模型； View（視圖）代表模型包含的數據的表達方式，一般表達為可視化的界面接口；Controller（控制器）作用於模型和視圖上，控制數據流向模型對象，並在數據變化時更新視圖。控制器可以使視圖與模型分離開解耦合。最簡單的MVC原理圖可表示如下：
其中包含的動作流程有：控制器創建模型； 控制器創建一個或多個視圖，並將它們與模型相關聯； 控制器負責改變模型的狀態； 當模型的狀態發生改變時，模型會通知與之相關的視圖進行更新。這是目前大型系統開發較為主流的一個過程，最直接的優點就是視圖層和業務層分離，這樣就允許更改視圖層代碼而不用重新編譯模型和控制器代碼，同樣，一個應用的業務流程或者業務規則的改變只需要改動MVC的模型層即可。因為模型與控制器和視圖相分離，所以很容易改變應用程序的數據層和業務規則，還有重用性高、部署快、可維護性高等優點。在具體的Django開發中，對應的MVC應用可表示如下：
這個圖中，我們可以很清晰的看出基本符合MVC模式的特點，同時Django的體量較小，對於輕量級的系統開發和部署，具有很好的效果，不僅可以最大程度的提升開發速度，同時也可以很方便進行測試和維護。
由於采用的是Django的框架來進行前后端的開發，所以，本系統采用的是B/S(Browser/Server)架構，即瀏覽器/服務器架構，是在C/S（Client/Service，客戶機/服務器）模式的基礎上發展起來的一種體系結構，在開發Web應用時有明顯的技術優勢。針對本系統而言，可以使得系統的擴展較為容易且不需要安裝專門的軟件，使用也較為方便。
三、軟件架構的描述
軟件架構模型是通過一組關鍵視圖來描述的，同一個軟件架構，由於選取的視角（Perspective）和抽象層次不同可以得到不同的視圖，這樣一組關鍵視圖搭配起來可以完整地描述一個邏輯自洽的軟件架構模型。一般來說，我們常用的幾種視圖有分解視圖、依賴視圖、執行視圖、實現視圖和工作任務分配視圖。下面我們來進行具體的分析：
1.分解視圖：
分解視圖也是描述軟件架構模型的關鍵視圖，一般分解視圖呈現為較為明晰的分解結構（breakdown structure）特點。簡單的說也就是將系統的功能進行分解，形成幾個小的部分，然后這些小部分又包含各自所要處理的業務，我們所要做的就是對這些具體業務的設計和開發。本系統中，即分解為數據獲取端、數據處理端、結果顯示端三個大模塊，然后在各個模塊內部細分為一些小的功能類，這樣使得系統的結構較為清晰，同時也能看清楚各層次之間的聯系，使得開發更加系統化。
2.依賴視圖：
依賴視圖展現了軟件模塊之間的依賴關系。比如一個軟件模塊A調用了另一個軟件模塊B，那么我們說軟件模塊A直接依賴軟件模塊B。如果一個軟件模塊依賴另一個軟件模塊產生的數據，那么這兩個軟件模塊也具有一定的依賴關系。本系統中，三大模塊之間均存在數據的傳遞和調用，所以產生如下的依賴視圖：
即數據處理端依賴於數據獲取端從影評網站上爬取的數據來進行具體的數據分析，並給出最終生成的結果傳遞給結果顯示端；而結果顯示端也依賴於數據處理端傳遞來的數據來進行頁面的數據渲染。
3.執行視圖：
執行視圖展示了系統運行時的時序結構特點，比如流程圖、時序圖等。執行視圖中的每一個執行實體，一般稱為組件（Component），都是不同於其他組件的執行實體。執行實體可以最終分解到軟件的基本元素和軟件的基本結構，因而與軟件代碼具有比較直接的映射關系。在設計與實現過程中，我們一般將執行視圖轉換為偽代碼之后，再進一步轉換為實現代碼。根據系統的各部分的功能實現，我們畫出系統的整體流程圖如下：
可見，上圖中基本概括了系統的執行時序和整體的動作，作為偏算法類的項目，所以具體的分析處理模塊未明確列出，但是對於數據的傳遞路徑以及結果的回調等，均有了一個簡單的執行順序。
4.實現視圖：
實現視圖是描述軟件架構與源文件之間的映射關系。比如軟件架構的靜態結構以包圖或設計類圖的方式來描述，但是這些包和類都是在哪些目錄的哪些源文件中具體實現的呢？一般我們通過目錄和源文件的命名來對應軟件架構中的包、類等靜態結構單元，這樣典型的實現視圖就可以由軟件項目的源文件目錄樹來呈現。
上圖即為系統源代碼的目錄文件結構，從上往下依次為css文件，圖片文件和js文件，其中分別對應着樣式、圖片和網頁動作等；下面的包即為模板包，內含各個具體的前端頁面，即相當於MVC中的V即視圖模塊，能將數據進行具體的展示；再下一個文件夾為Django框架中的處理相關的文件，內含默認初始化文件、測試文件、默認設置文件、url路徑文件、邏輯實現文件以及部署文件,url.py和views.py兩個文件的功能即相當於MVC中的controller的作用，其中具體的數據分析模型和取數據的模塊嵌入在views.py當中；再往下即為數據庫和全局管理文件。
實現視圖有助於我們在海量源代碼文件中找到具體的某個軟件單元的實現，因為會使得具體的實現代碼的層次更加清晰，對源代碼的某個模塊的定位也會更加精准。實現視圖與軟件架構的靜態結構之間映射關系越是對應的一致性高，越有利於軟件的維護，因此實現視圖是一種非常關鍵的架構視圖。
5.工作分配視圖:
工作分配視圖將系統分解成可獨立完成的工作任務，以便分配給各項目團隊和成員。工作分配視圖有利於跟蹤不同項目團隊和成員的工作任務的進度，也有利於在個項目團隊和成員之間合理地分配和調整項目資源，甚至在項目計划階段工作分配視圖對於進度規划、項目評估和經費預算都能起到有益的作用。由於本系統的模塊區分較為明顯，即為數據獲取、數據處理、結果展示三大模塊，所以組內的三名成員分工也較為明確：
| 數據獲取和清洗 | 成員A |
| 數據處理和分析 | 成員B |
| 結果可視化和系統維護 | 成員C |
同時，針對本系統開發的進度安排，小組進度計划如下表所示：
商標即為整體規划，整個系統大概7個月的時間完成，包括系統的源代碼和伴隨的說明文檔以及開發文檔等。
四、設計模式
設計模式的本質是面向對象設計原則的實際運用總結出的經驗模型。正確使用設計模式具有以下優點：
• 可以提高程序員的思維能力、編程能力和設計能力。
• 使程序設計更加標准化、代碼編制更加工程化，使軟件開發效率大大提高，從而縮短軟件的開發周期。
• 使設計的代碼可重用性高、可讀性強、可靠性高、靈活性好、可維護性強。
在本系統中，我們組要是使用的組合模式，結合系統中的業務類圖，下面來進行簡要的分析：
針對以上的業務類圖，即可以看出用戶選擇觀看的電影，系統即根據選擇的電影的評論生成分數和建議，最終反饋給用戶，而在實際應用中，系統的主要工作過程也是對電影的評論的分析，並最終給出系統生成的分數和建議。 從圖中，我們可以看出在實現改功能的過程中使用了組合模式，可以使電影的評論動態的添加到電影本身當中來，因為我們的結果是和電影直接綁定的，也就是說單個的評論不能直接影響到最終的結果，這樣的好處即簡化了分析時的復雜性，根據一部電影即可調出全部的評論，然后進行最終的評分和結果展示，極大的簡化了開發的流程。
五、數據庫設計
根據第三部分的業務類圖，可以看出來系統涉及的主要數據模型即為四個大的存儲表，即為用戶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存儲到評論之中，在系統實現時，直接查詢數據庫中的評論即可，較為方便，同時也可以不導致數據冗余（一部電影對應的評論可能很多）。
六、系統開發環境和技術選型
本系統擬采用結構化方法來進行開發，將系統實現的主要功能進行分解，各模塊分別進行開發和維護，是的最終的結果利於實現和維護；本系統基於64位Windows10系統進行開發，開發環境Python3.6、Django2.0.1以及Tensorflow2.0，編譯器為JetBrains Pycharm 2019.3.3，獲取數據即為Python爬蟲技術。
由於系統的數據集最終分為訓練樣本和預測樣本，所以針對訓練樣本的作用，既作為訓練的基礎數據集，同時在結果顯示出來之后，又做為一個最直接的測試樣本，即可直接通過訓練樣本來進行初步測試，整合好了詞典之后，再利用預測樣本的結果作為最終的測試結果。
七、概念原型的核心工作機制
經過上述的分析，可以總結出概念原型的工作機制，簡而言之就是用戶在系統中選擇自己想看的電影，系統根據用戶選擇的電影從數據庫中找到對應的評論，進而對這些評論進行分析，給出最后分析的電影評分和建議，供用戶觀影之前的參考；我們開發小組也會對該系統進行不斷地測試和維護，當系統的評分模型出現較大的誤差時，我們便會從數據和算法模型入手，去做數據清洗工作或者算法的改進工作，提高評分的准確率。
八、總結
經過本次的對軟件系統的結構特點和架構風格的分析，我對自己的工程實踐的開發又有了一些新的思路和認識，尤其是利用各種視圖來進行軟件系統概念原型的描述時，會讓我們更加深入的去分析我們這個系統的目標是什么、我們怎么實現這個目標，尤其是算法類的項目，我們要達到的精度以及完整度才是我們應該追求的，而不僅僅是說為了去分析而分析。經過兩次的概念原型的建模和分析，我對軟件工程的方法也有了一定的深入了解，現在也會慢慢的思考這些方法的目的和優點所在，知其然也要知其所以然，在以后的需求分析和原型設計中，也要時刻想着利用這些常用的方法去進行分析和設計。
參考資料：
https://www.cnblogs.com/leehz/p/14076336.html