571
社区成员
发帖
与我相关
我的任务
分享弹幕提取分析项目需求分析
项目综述
弹幕作为视频内容的延伸、以及用户喜好反馈的一部分，有着巨大的挖掘价值，在赛事直播中，各大直播平台产生了大量用户即时发出的弹幕内容，需要对弹幕内容进行分析，以提炼对直播内容的质量反馈，满意度反馈，问题反馈，热点内容挖掘，热点话题发掘，关注点发掘等。其次也需要思考，探索弹幕在实时场景与离线场景的二次应用。
视频弹幕内容的挖掘分析，对于精准把握用户喜好、用户情绪，以及结合弹幕热点因势利导，提升内容社区活跃度等，有着非常重要的意义。
此外，对于弹幕和评论文本，还可以借助文本情感分析，鉴别观众的情感倾向，从而把握观众的整体情绪反应。对于节目突发负面舆情事件，可以提早预警和及时应对。
需求分析
概述
需求分析是软件工程重要的一环，简而言之，就是确定你的项目使用者具体有什么需求，这是在之前项目背景之上再进一步，对象达到了用户的粒度。下面介绍两个名词：
-
需求：对用户期望的软件行为的表述
-
需求分析：确定新系统的目的、范围、定义和功能时所要做的所有工作
对于需求而言，可能是无限的，所以可能出现“五彩斑斓的黑”这样的需求；然而需求的作用对象是项目，需求分析是为了项目服务的。实际情况中往往需求是丰满的，而项目是骨感的，项目只能实现有限的需求，所以在进行需求分析的时候也需要尽可能体现项目的价值、减少工作量。
具体需求
具体需求可分为功能性需求及非功能性需求两种，详细分析如下。
功能性需求
-
数据采集，获取弹幕数据，分词后存储，并生成词云反馈给用户
-
文本情感分析，用户能够得知直播期间弹幕的情感变化
-
舆情反馈，对于相应的实时分析结果，发出提示预警信息以便管理员处理
非功能性需求
-
兼容PC及移动端
-
兼容多个直播平台
-
并发性与实时性，同时监控多个直播平台的同一赛事直播，实时比对数据分析结果
用例建模
概述
需求分析结束后，对该项目进行相应用例建模。在这之前，首先得明确什么是用例、用例的基本要素以及用例建模的步骤。
-
用例的定义
用例的核心概念中首先它是一个业务过程，经过逻辑整理抽象出来的一个业务过程，这是用例的实质。什么是业务过程？在待开发软件所处的业务领域内完成特定业务任务的一系列活动就是业务过程。
-
用例的基本要素
-
一个用例应该由业务领域内的某个参与者所触发；
-
用例必须能为特定的参与者完成一个特定的业务任务；
-
一个用例必须终止于某个特定参与者，也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。
-
-
用例建模的基本步骤
-
从需求表述中找出用例，往往是动名词短语表示的抽象用例；
-
描述用例开始和结束的状态，用TUCBW和TUCEW表示的高层用例；
-
对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；
-
进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例；
-
具体用例建模
用例提取
用例一般是需求中与业务领域相关的动名词和动名词短语，验证业务领域相关的动名词或动名词短语是不是用例的标准是满足四个必要条件：
-
是一个业务过程；
-
是由某个参与者触发开始；
-
是显式地或隐式地终止于某个参与者；
-
是为某个参与者完成了有用的业务工作；
System：弹幕提取分析
Actor：用户
Use Case：
-
UC1：查看弹幕高频词云
-
UC2：查看直播时间内舆情波动
-
UC3：查看弹幕数量热度分布
用例图
根据以上的分析，弹幕提取分析系统的用例图如下图所示。
业务概念模型
基于上面的需求分析以及用例建模，可以继续分析进行业务领域的建模。
概述
业务领域建模是开发团队用于获取业务领域知识的过程。领域模型可以被看作是一个系统的概念模型，用于以可视化的形式描述系统中的各个实体及其之间的关系。领域模型记录了一个系统中的关键概念和词汇表，显示出了系统中的主要实体之间的关系，并确定了它们的重要的方法和属性。因此，对应于用例所描述的动态视图，领域模型提供了一种对整个系统的结构化的视图。领域模型的一个好处是描述并限制了系统边界。
业务领域建模的基本步骤：
-
第一步，收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；
-
第二步，头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；
-
第三步，给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系;
-
第四步，将结果用 UML 类图画出来。
具体业务建模
-
系统业务领域分析
根据以上步骤对文本情感分析系统进行分析，大致可分为三个类：
-
Info：获取弹幕信息数据并保存；
-
Handler：对数据进行处理分析;
-
Show：将数据可视化处理并输出；
-
-
文本情感分析系统类图
数据模型
经过用例、业务建模之后可对项目中所用到的数据进行模型建构，建立数据库表。
概述
数据建模是一种用于定义和分析数据的要求和其需要的相应支持的信息系统的过程，即是对现实世界各类数据的抽象组织，确定数据库需管辖的范围、数据的组织形式等直至转化成现实的数据库。 将经过系统分析后抽象出来的概念模型转化为物理模型后，在工具建立数据库实体以及各实体之间关系的过程。
具体数据建模
数据库中主要存储弹幕及其分词、情感分析之后的处理信息，应有数据库表建模如下：
| 字段名 | 类型 | 备注 |
|---|---|---|
| content | Text | 完整弹幕内容 |
| vec | Text | 分词后的信息 |
| emo | Text | 情感预测后的信息 |
概念原型工作流程
经过用例模型的分析建立以及数据模型的分析建立，概念原型可在此基础上分析得出。
概述
要分析该项目的概念原型，首先得明确什么是概念和概念原型。
概念：概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论。
概念原型：概念原型是一种虚拟的、理想化的软件产品形式。
概念原型 = 用例 + 数据模型
具体概念原型
从上述的用例建模、业务领域建模和数据建模可知，该系统的概念原型是：
从直播网站接口获取弹幕数据后实时进行数据分析处理，并将分词、情感分析后的数据信息存储到数据库中，最后由数据库中的数据生成词云、直播舆情预警等信息，反馈给用户。
设计模式
为满足程序实现中的不同需求，需要采用多种设计模式进行预先的设计。
单例模式
使用单例模式来控制Handler只有一个实例，因为若有多个Handler实例，具有同样功能的管理类同时存在会导致系统功能紊乱，数据的处理流程不明确等问题。如下图所示
适配器模式
对于从网站抓取弹幕的行为，需要使用第三方的websocket接口接入，此时很有可能出现接口与原本的info获取数据类无法兼容，使用Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以在一起工作。如下图所示。
具体架构
如下图所示，本项目实现框架主要划分为：数据接入层、指标计算层、数据服务层。与MVC模型相似，数据接入层处理数据接口，获取数据并保存相应信息，指标计算层对数据进行相应的处理并传入数据服务层，数据服务层将数据展现在web端，体现数据处理结果。
数据接入层：将采集到的站内、站外的评论和弹幕流水日志数据统一接入Info数据采集。
指标计算层：将评论和弹幕流水日志数据按视频vid粒度进行累积滚动，并集中融合至统一的底表中。接着，通过弹幕及评论文本分词、命名实体识别人名提取、新词发现。最后，在Handler中完成弹幕分析统计。
数据服务层：最终在Show()展示的数据中提供弹幕互动相关的评价指标分析，热门弹幕/评论、热门词云以及网络舆情监控分析等数据服务模块。
总结
结合一个学期以来的课程学习，通过对工程实践项目进行相应的需求分析，并对其进行相应的用例建模和业务领域建模，以及数据建模，最终形成概念原型，选定设计模式，设定好初步的软件架构等一系列专业、规范的软件工程开发实践，使我对项目流程的分析和设计实现有了更深的理解。由于项目还在设计阶段，目前的需求分析以及部分流程可能设计的并不完善，仍需在实际项目中不断提高对项目的理解和分析能力。
作者：295，梁钢
...全文
请发表友善的回复…
发表回复
