一、前言
本系统是一个基于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