软件系统设计方案-豆瓣电影影评分析系统
一、前言
本文是对工程实践项目基于情感词典的豆瓣电影影评分析系统进行的讨论，主要是通过对设计模式与软件架构的分析，阐述项目的完整设计方案并采用不同的视图来描述软件系统以形成软件系统概念原型。
工程实践项目介绍：豆瓣网作为中国最大最权威的电影评论网站之一，它对电影的评价在人们选择和认知电影的过程中扮演着非常重要的作用。但豆瓣评分往往只关注了用户对电影的评分信息，而忽视了用户的评论信息，使得人们看到的最终评分未必能反映这部电影的真实情况，所以为了帮助浏览者有效的解读影评文本，了解影评中的情感因素，我们对影评进行情感分析并打分，通过对电影评论情感得分与豆瓣原生用户评分进行分析对比，使用户更好地了解电影的整体评价。
二、软件设计方案
我们首先需要确定项目的架构风格和设计模式，有了整体的框架后后面的工作才好进行。
其中对于架构风格来说，常见的有三层架构、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数据库
四、系统概念原型的核心工作机制
每个视图都是从不同的角度对软件架构进行描述和建模，比如从功能的角度、从代码的角度、从运行时结构的角度、从目录文件的角度，或者是从项目团队组织结构的角度。软件架构代表了软件系统的整体设计结构，它应该是所有这些视图的集合。但我们不会将不同角度的视图整合起来，因为不便于阅读和更新，不过我们会有意识地将不同角度的视图之间的映射关系和重叠部分了然于胸，从而深刻理解软件架构内在的一致性和完整性，这就是系统概念原型。
整个概念模型的工作过程为：对于用户来说，我们从系统中选择自己想要了解的电影，系统根据用户选择的电影评论进行分析，得到对于评论信息的情感得分并给出建议信息，最后能和原系统自带评分进行比较并得出差异，进一步可以通过可视化方法实现更加清晰地认识。
