基于智能信息搜集和数据分析系统的需求分析与概念原型
前言
本文是在学习完《高级软件工程》中《从需求分析到软件设计》这一章节后完成的，具体分析的案例是我在学校的工程实践项目————基于Python的智能信息搜集和数据分析系统设计及实现，希望通过本篇博客的总结，能让我对自己的工程实践项目有一个更深地理解，并为以后的项目实践打下基础。
一、项目介绍
我的工程实践项目是基于Python的智能信息搜集和数据分析系统设计及实现，该系统主要实现三大功能：第一是对新闻或者商品数据信息的爬取；第二是完成对爬取到的数据进行数据分析；第三是对数据进行展示，即可视化。我主要负责的是数据的爬取，虽然只是负责了其中一部分功能，但不影响我对整个系统的全局进行分析。
二、基本需求说明
整理需求的两类基本方法为原型化方法（Prototyping）和建模的方法（Modeling）。原型化方法可以很好地整理出用户接口方式（UI，User Interface），比如界面布局和交互操作过程。建模的方法可以快速给出有关事件发生顺序或活动同步约束的问题，能够在逻辑上形成模型来整顿繁杂的需求细节。对于建模的方法，具体包括用例建模、业务领域建模和业务数据建模，利用这些模型即可较为直观的反映出软件系统设计的业务流程和模块功能，能让我们对整个系统一目了然。
我本次的工程实践项目——基于Python的智能信息搜集和数据分析系统，是一个基于Python实现的一个爬虫与数据分析项目，该系统爬取对象主要是新浪财经（爬取原油等商品信息）、卓创资讯（橡胶等大宗商品信息），实现该系统的主要目的是帮助企业或者有需求的个人用户搜集大宗商品的数据信息，他们可以通过我们的信息搜集系统获取目标数据，系统同时能够利用数据分析技术自动地分析商品价格趋势、货量等信息，再利用可视化技术将得出来的信息结论展示给用户，以达到数据搜集到数据分类分析再到挖掘规律这样一个过程，实现这样一个系统能够帮助企业或者个人用户节省大量的人力物力，让用户专注于更加重要的决策等事务。
三、用例图
用例的核心概念中首先它是一个业务过程，经过逻辑整理抽象出来的一个业务过程，这是用例的实质。什么是业务过程？在待开发软件所处的业务领域内完成特定业务任务的一系列活动就是业务过程。
用例主要有三大基本要素：
第一个，一个用例应该由业务领域的某个参与者（Actor）所触发，这个参与者可以是用户，也可以是管理员等角色。
第二个，用例必须能为特定的参与者完成一个特定的业务任务，该业务任务也可以理解为功能，功能必须能为特定参与者服务。
第三个，一个用例必须终止于某个特定参与者，也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。
掌握用例的三大基本要素后，对于用例建模总共定义了四大步骤，第一步是从需求表述中找出用例，往往是动名词短语表示的抽象用例；第二部描述用例开始和结束状态；第三步对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；第四步进一步分析用例参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。
对于我们实现的信息搜集与数据分析系统，参与者主要是管理员Admin和个人用户User，管理员主要是在后台对数据信息进行操作，个人用户能够在客户端获取自己想要获取的信息，具体的业务任务和参与者角色如下用例图所示：
由上图可知，普通用户User登录本系统中，能够根据自己的需要查询大宗商品，并且能够获取商品的详细信息，比如商品价格、供应商、记录时间等信息，除此之外还能够查询历史信息，查询完这些信息后，系统还能为用户提供数据分析，对未来商品价格以及库存趋势进行预测；管理员在后台完成对数据的爬取与更新，并且就爬取到的信息进行数据分析与建模，同时也能够查看系统用户数据。
四、业务类图
业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知。因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知。
开发团队获取业务领域知识的过程一般包括收集业务领域相关信息、执行团队头脑风暴、对业务领域相关的知识概念进行分类，最后用UML类图将业务领域知识图形化展示。
在我的工程实践项目中，用户为需要获取大宗商品信息的企业用户，他们需要从系统中获取商品数据以及对应的预测信息，而管理员负责数据的爬取与分析，这些类包含的属性主要有以下：
用户：用户id（id）、姓名（name）、密码（password）、性别（gender）、头像（portrait）
大宗商品：商品id（id）、商品名称（name）、商品类型（type）、价格类别（price_type）、价格（price）、供应商（provider）、日期（date）
管理员：管理员id（id）、姓名（name）、密码（password）、头像（portrait）
于是有如下UML图
针对以上的业务类图，用户User可以选择自己想要查询的大宗商品Commondity，用户不仅能够查看商品的详情信息，还能够观看历史记录以及该商品相应的数据分析；管理员主要任务是更新数据以及对数据进行分析。
五、数据模型
针对以上业务类图，我们可以得出以下数据模型：
1、User表
| 名称 | 数据类型 | 备注 |
|---|---|---|
| id | int | 用户id，主键 |
| name | string | 用户姓名 |
| password | string | 用户密码 |
| gender | string | 用户性别 |
| potrait | string | 用户头像 |
| 2、Admin表 | ||
| 名称 | 数据类型 | 备注 |
| ---- | ---- | ---- |
| id | int | 管理员id，主键 |
| name | string | 管理员姓名 |
| password | string | 管理员密码 |
| potrait | string | 管理员头像 |
| 3、Commodity表 | ||
| 名称 | 数据类型 | 备注 |
| ---- | ---- | ---- |
| id | int | 商品id，主键 |
| name | string | 商品名称 |
| price_type | string | 价格类型，例如元/千克 |
| price | float | 商品价格 |
| provider | string | 供应商 |
| date | datetime | 记录日期 |
| 4、User_select_Commodity表 | ||
| 名称 | 数据类型 | 备注 |
| ---- | ---- | ---- |
| id | int | 主键 |
| uid | int | 用户id |
| cid | int | 商品id |
| 其中User表主要存储使用该系统的用户的信息；Admin表存储管理员信息；Commodity表存储大宗商品的数据，其中该数据是随着时间而增加的； |
六、概念原型
概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论。概念原型是一种虚拟的、理想化的软件产品形式。我们不难得出：概念原型=用例+数据模型
所以，针对以上几个部分的建模，这里的概念原型就很清晰了。简而言之就是用户在系统中选择自己查询的大宗商品，系统根据用户选择的商品从数据库中找到对应的数据信息，并且向用户进行展示，同时系统还会提供相应的数据分析；而系统的管理员也会对该系统的数据不断更新和分析，以确保用户能够获取更具有时效性的信息。
七、总结
我在学习完《从需求分析到软件设计》这部分章节后，对于一个软件系统的需求以及用例信息的提取有了一个清楚的认知，未来不论是在课程设计项目还是在工作中为客户设计产品，通过设计用例图以及业务类图，能够帮助自己更好地理解业务逻辑，同时团队的交流也能够更加顺畅，毫无疑问，这些方法都是作为计算机专业学生的我们所必须要掌握的技能，总而言之，通过这门课程算是给我打开了一个全新的世界，在学校里不仅要能够解决学术问题，还要能够灵活地解决实际的工程问题。
