上完孟宁老师的高软课程，要求我们对自己的工程实践项目进行需求分析和概念原型设计，具体要求为针对自己的工程实践项目，进行用例建模和业务领域建模，以及数据建模，最终形成概念原型。刚听到这个作业，再去看看自己的工程实践项目----基于情感词典和机器学习的影评数据分析，感觉完全没有思路，准确的说，是自己在做这个工程实践项目的时候从来没有想过用例建模这些事，更不用说去设计概念原型，我之前的想法是作为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+可视化，而变成了一个能够按照需求去实现的一个大数据文本分析的系统。