需求规格说明书(版本1.0) - sekaiiiii/BUCTCS1703SECD GitHub Wiki

博物馆应用系统需求规格

1. 导言

1.1 目的

  • 本文旨在说明博物馆应用系统各子模块的功能需求和非功能需求,重点描述了博物馆应用系统各子系统的设计需求,将作为对该系统在概要设计阶段的设计输入
  • 本文档的预期读者是:
    • 设计人员
    • 开发人员
    • 项目管理人员
    • 测试人员
    • 用户

1.2 缩写说明

  • UML:Unified Modeling Language
  • Scrapy
    • Scrapy 是用 Python 实现的一个为了爬取网站数据、提取结构性数据而编写的应用框架。
    • Scrapy 常应用在包括数据挖掘,信息处理或存储历史数据等一系列的程序中。
    • 通常我们可以很简单的通过 Scrapy 框架实现一个爬虫,抓取指定网站的内容或图片。
  • sklearn
    • Scikit-learn(也称为sklearn)是Python编程语言的免费软件机器学习库。它具有各种分类、回归和聚类算法,包括支持向量机、随机林、梯度提升、k-均值和DBSCAN,旨在与 Python 数值和科学库NumPy和SciPy进行互操作。

1.3 术语定义

  • 爬虫
    • 网络爬虫(又称为网页蜘蛛,网络机器人,在FOAF社区中间,更经常的称为网页追逐者),是一种按照一定的规则,自动地抓取万维网信息的程序或者脚本。另外一些不常使用的名字还有蚂蚁、自动索引、模拟程序或者蠕虫。
  • 机器学习
    • 机器学习是一门多领域交叉学科,涉及概率论、统计学、逼近论、凸分析、算法复杂度理论等多门学科。专门研究计算机怎样模拟或实现人类的学习行为,以获取新的知识或技能,重新组织已有的知识结构使之不断改善自身的性能。
  • 文本分析
    • 文本分析是对文本进行解析,以便从中提取机器可读的事实。文本分析的目的是用自由文本内容创建结构化数据。这个过程可以看作是将一堆非结构化、异构的文档分割成易于管理和解释的数据块。

1.4 参考资料


2. 博物馆网站数据采集子系统需求规格

2.1 子系统来源和背景

本项目是博物馆网站信息采集系统,由于博物馆网站众多,本产品致力于智能高效的搜集网站信息,删除不必要的信息,并保留关键信息,减少查询博物馆的工作量。 其他小组成员通过编辑筛选条件可以找出所需博物馆的信息,并且排除多余的垃圾信息,实现查找、阅读的高效与便捷。

2.2 子系统目标

本产品用于快速采集博物馆网站信息,能够筛选有用的消息如开馆时间、展品信息、展览信息、教育活动信息、学术研究信息等,产品有筛选准确快速的优势、导入数据库查询定位快速准确、持续更新信息。通过产品说明介绍,能快速掌握使用方法,使用简单方便,仅需要掌握电脑基本操作。

2.3 子系统功能简介

  1. 数据爬取:爬取全国一级博物馆(130家左右)的网站信息,包括博物馆基本的介绍、参观信息(开放时间等)、展览信息、教育活动、经典藏品信息、学术研究信息等,对于展览信息可以定时更新。
  2. 数据加工:对于爬取的信息进行过滤和加工,抽取需要的内容。例如:对于展览页面,要得到展览主题、展览时间、展览地点、展览介绍等信息。
  3. 数据导入:采用合适的方式保存抽取的数据,能够导入到数据库中。
  4. 数据更新:支持数据的持续更新。例如:根据情况,每天或每周爬取一次新的数据,更新原有数据。

2.4 用户特征

  • 其他小组开发成员:用爬取来的信息进行其他功能构建小组成员

2.4 功能需求

  • 博物馆网站数据采集子系统的整体功能用例图见图1。 整体功能用例图

  • 用例图的简要描述见表1、表2

  • 表1 Actor一览表

Actor 可选操作
管理员 登录系统,查看信息表,更新信息表,更新信息表,保存信息,退出系统。
  • 表2 用例一览表
用例中文名称 简要用例描述
登录 管理员输入账号密码登录系统
查看 管理员选择查看已有信息表
更新 管理员选择更新信息表
退出 管理员选择退出系统
添加 当信息表为空时,管理员向表中添加数据
修改 管理员用新加工后的数据替换信息表中的数据
保存 管理员保存信息表

2.5 性能需求

  • 系统对管理员请求的最大响应时间是10秒钟,在此时间内将响应结果显示在屏幕上;
  • 系统的加载时间不大于5秒钟;
  • 系统支持的客户端人数为10人。

2.6 质量需求

  • 可用性:系统可以使用,每天更新1次;
  • 可扩展性:系统可增加新的功能,所需时间不超过2天;
  • 安全性:系统不会影响计算机其他软件的使用;
  • 可靠性:系统运行过程中,不会发生内存泄漏和进程死锁,系统无故障运行时间达到500小时以上,如果在运行过程中发生错误,系统一般不会回到发生错误前的状态;
  • 可维护性:从系统运行过程中查找、修复错误的时间预期不超过1天
  • 易操作性:对所有博物馆的信息页面布局采用的模板不超过3个,管理员能轻松地对数据进行更新。

2.7 系统运行网络环境

  • 本系统运用于小组成员内部的数据交流,通过网络进行数据传输,在建立的数据库中进行筛选,通过专用接口传输到app中,展示出来。

2.8 实现约束

  • 系统的实现约束:
    • 操作系统: Window10、Linux
    • 开发平台: Python
    • 数据库: Sql server、MySQL

3. 博物馆新闻采集分析子系统需求规格

3.1 项目目标

  1. 开发一款博物馆新闻分析子系统,为其他子系统提供前提。
  2. 系统具有良好的运行效率,能够实时采集博物馆相关新闻。
  3. 系统具有检测垃圾新闻的能力,保证所采集新闻的品质。
  4. 系统应有良好的可扩充性,可以容易的加入其它子系统的应用。
  5. 平台的设计具有一定的超前性,灵活性,能够适应未来可能的变化。
  6. 通过这个项目可以锻炼队伍,提高团队的开发能力和项目管理能力。
  7. 同时组员们获得系统的软件工程项目训练。

3.2 应用环境

3.2.1 系统运行硬件环境

  • 服务器
    • 配置信息
      • 操作系统
        • Ubuntu Server 18.04 1 LTS 64位
      • CPU
        • 1核
      • 内存
        • 2GB
      • 带宽
        • 1Mbps
  • 客户机:普通PC

3.2.2 系统运行软件环境

  • 操作系统
    • Win10/Macos/Linux
  • 数据库
    • MySQL 或其他数据库操作软件
  • 浏览器
    • Microsoft Edge/Google Chrome

3.3 角色Actor定义

  • 用户
    • 用户指的是整个系统的用户,用户可以根据指定的某一家博物馆,获取该博物馆的指定时间的新闻,并进行加工分析,得到该博物馆指定时间内的主要新闻,正面新闻和负面新闻。
  • 数据库
    • 数据库是一个与系统产生交互的外部系统,这个Actor负责系统的数据查询、增加、删除和修改等操作。在该子系统中,我们将爬取到的数据进行数据处理,数据分析,数据定制服务,将处理后的数据放入数据库中。

3.4 系统主Use Case图

3.5 功能简介

用户登录博物馆应用平台系统,根据其他子系统实现的界面,查看从主要的新闻网站上获取博物馆相关的新闻信息。用户可以在客户端指定时间范围,选定新闻的发布时间、新闻的标题、新闻的内容、新闻涉及的博物馆等,系统还会根据正面新闻和负面新闻进行分类反馈给用户。用户还可以选择数据定制服务,可以指定获取某一家博物馆的指定时间内的主要新闻,正面新闻和负面新闻。

博物馆新闻分析子系统的功能主要包括数据获取、数据加工、数据分析、数据定制服务。

博物馆新闻分析子系统的功能描述如下:


F-C-1:数据获取 爬取主要的新闻网站中的博物馆相关新闻。可以支持爬取指定时间范围内的新闻,如1年内的新闻,半年内的新闻等。


F-C-2:数据加工 子系统对于爬取的信息进行过滤和加工,抽取需要的内容。例如,抽取新闻的发布时间、新闻的标题、新闻的内容、新闻涉及的博物馆等。


F-C-3:数据分析 对于加工好的新闻,分析是正面新闻还是负面信息。


F-C-4:数据定制服务 可以根据指定的某一家博物馆及用户的指令,获取该博物馆的指定时间的新闻,并进行加工分析,得到该博物馆指定时间内的主要新闻,正面新闻和负面新闻。


3.6 功能详细描述

3.6.1 数据获取

  • 用例描述:子系统对新闻数据进行爬取
  • 执行者:子系统
  • 前置条件:用户登陆并进入系统
  • 后置条件:子系统对爬取的信息进行加工
  • 基本路径:
    • 用户登入到此系统内,根据其他子系统提供的接口,查看自己所需的新闻。

3.6.2 数据加工

  • 用例描述:对爬取的信息进行加工
  • 执行者:博物馆新闻分析子系统
  • 前置条件:子系统已经对数据爬取完成
  • 后置条件:信息加工好后,系统对信息进行分析
  • 基本路径:
    • 对爬取的信息进行过滤和加工
    • 从初步加工的信息中抽取所需的内容

3.6.3 数据分析

  • 用例描述:对加工好的新闻,分析是否是正面信息
  • 执行者:博物馆新闻分析子系统
  • 前置条件:对爬取的信息已加工完成
  • 后置条件:分析结束后,用户可获得所需新闻
  • 基本路径:
    • 采用已有的可直接调用的服务和代码实现
    • 分析是正面新闻还是负面新闻

3.6.4 数据定制服务

  • 用例描述:根据用户需求对指定的博物馆,获取该博物馆指定时间的新闻,并进行加工和分析
  • 执行者:用户
  • 前置条件:用户已选择指定的博物馆和时间
  • 后置条件:用户指定博物馆和时间后,获得相应的新闻信息
  • 基本路径:
    • 指定某一个博物馆,指定获该博物馆新闻的时间
    • 得到该博物馆指定时间内的主要新闻,正面新闻和负面新闻。

4. 博物馆导览子系统需求规格

4.1 子系统应用背景分析

博物馆当前对于展品导览的需求归纳如下:
导览信息的需求:参观者希望每个展品可以多些知识的介绍, 其中包括展品的年代、 发现时间、出土过程、所含有的经历等。
导览信息形式的需求:在博物馆,参观者不仅希望有文字方式的介绍,图片或视频的形式更能够突出展品的相关特性。同时,为了减缓参观者的压力,信息以声音的形式传递将会更好。

4.2 子系统要达到的目标

  1. 在提供的信息准确丰富的同时,也要让使用者能方便快捷的使用本系统,让管理者能简单有效的管理更新信息。
  2. 系统具有良好的运行效率
  3. 系统有良好的可扩充性
  4. 平台的设计具有一定的超前性

4.3 运行环境

本系统无论客户端的使用者还是管理端的管理者都可以通过网络登录到本系统中,使用者通过网络查询相关信息,管理者通过网络发布相关信息。

  • 系统硬件要求: 安卓6.0及以上

4.4 角色定义

  • 使用者:使用者是指在客户端使用本系统查询相关信息,使用导览等相关功能的人员。
  • 管理者:管理者是指在管理端执行上传、更新、修正信息,以及对本系统进行维护升级等相关功能的人员。(实质是指后台管理子系统的角色定义)

4.5 实现功能

4.5.1 地图浏览

此部分使用高德地图sdk(https://lbs.amap.com/),通过**okhttp**请求拉取服务器提供的**博物馆经纬度**查询api来显示在地图上组件,调用设备的获取位置函数来取得定位,通过设置点击时间来显示服务器获取的信息。

预计需要服务器的接口列表(尽可能详细)

接口名称 获取结构示例
博物馆经纬度 (112.25,46.45)
博物馆近期展览 json格式的新闻
博物馆讲解音频 音频格式

4.5.2 基础信息浏览

使用自定义的适配器显示博物馆的基本信息、展览信息、藏品信息等

接口名称 获取结构示例
博物馆名称 兵马桶5A级风景区
博物馆地点 西安市xxxxxx
博物馆级别 5A
开放时间 周一——周五,9:00-17:00
藏品信息 一个json数组,用于套娃的请求

4.5.3 音频播放

使用设备自带的播放器调用麦克风播放,从服务器拉流播放完整音频本地播放,可显示当前博物馆的所有导览,也可按内容进行筛选

4.5.4 上传讲解

将文件上传到服务器,需要服务器提供此服务,需要内容提供器寻找文件

4.5.5 用户信息

用户可以注册登录该系统,设置用户名、密码等个人信息,需要服务器提供此服务

接口名称 获取结构示例
用户名 abc
密码 123456

4.6 页面说明

4.6.1 主界面

主题突出,栏目、菜单设置布局合理,传递的信息简单易懂,让人一目了然的同时信息务必准确、及时。文字准确,语句通顺;专用术语规范,行文格式统一规范。

4.6.2 其他页面

主题突出,站点定义、术语和行文格式统一、规范、明确,栏目、菜单设置和布局合理,传递的信息准确、及时。内容丰富,文字准确,语句通顺;专用术语规范,行文格式统一规范

4.7 程序合并要求

4.7.1 函数命名规范

数名使用下划线分割小写字母的方式命名: 设备名_操作名()

操作名一般采用:谓语(此时设备名作为宾语或者标明操作所属的模块)或者

谓语+宾语/表语(此时设备名作为主语或者标明操作所属的模块) 等形式,如:

tic_init()

adc_is_busy()

uart_tx_char()

中断函数的命名直接使用 设备名_isr() 的形式命名,如:

timer2_isr()

4.7.2 布局规范

简洁整齐,简单易懂

4.7.3 代码规范

原则一:代码应该简洁易懂,逻辑清晰 因为软件是需要人来维护的。这个人在未来很可能不是你。所以首先是为人编写程序,其次才是计算机:不要过分追求技巧,降低程序的可读性。简洁的代码可以让bug无处藏身。要写出明显没有bug的代码,而不是没有明显bug的代码。

原则二:面向变化编程,而不是面向需求编程。 需求是暂时的,只有变化才是永恒的。本次迭代不能仅仅为了当前的需求,写出扩展性强,易修改的程序才是负责任的做法,对自己负责,对公司负责。

原则三:先保证程序的正确性,防止过度工程 过度工程(over-engineering):在正确可用的代码写出之前就过度地考虑扩展,重用的问题,使得工程过度复杂。

4.8 性能需求

4.8.1 响应时间需求

无论是客户端和管理端,当用户登录,进行任何操作的时候,系统应该及时的进行反应,反应的时间在5秒以内。系统应能监测出各种非正常情况,如与设备的通信中断,无法连接数据库服务器等,避免出现长时间等待甚至无响应。

4.8.2 可靠性需求

系统应保证7X24内不当机,保证多人可以同时在客户端登录,系统正常运行,正确提示相关内容。

4.8.3 可扩展性需求

系统设计要求能够体现扩展性要求,以适应将来功能扩展的需求。

4.8.4 系统安全性需求

系统有严格的权限管理功能,各功能模块需有相应的权限方能进入。系统需能够防止各类误操作可能造成的数据丢失,破坏。防止用户非法获取网页以及内容。

4.9 产品提交

提交产品为:
a)应用系统软件包
b)数据库初始数据
c)需求说明规格文档


5. 博物馆信息服务子系统需求规格

5.1 项目目标

  • 系统能够提供友好的用户界面,使操作人员的工作量最大限度的减少
  • 系统具有良好的运行效率,提升用户体验感
  • 系统应有良好的可扩充性,可以容易的加入其它子系统的应用。
  • 通过这个项目可以锻炼队伍,提高团队的开发能力和项目管理能力

5.2 运行环境

本系统无论客户端的使用者还是管理端的管理者都可以通过网络登录到本系统中,使用者通过网络查询相关信息,管理者通过网络发布相关信息。

  • 系统硬件要求: 安卓6.0及以上

5.3 功能规格

采用面向对象分析作为主要的系统建模方法,使用UML进行建模。

Use Case描述的是“actor”(用户、外部系统以及系统处理)是如何与系统交互来完成工作的。Use Case模型提供了一个非常重要的方式来界定系统边界以及定义系统功能,同时,该模型将来可以派生出动态对象模型。

设计Use-case时,我们遵循下列步骤:

  • 第一步,识别出系统的“actor”。Actor可以是用户、外部系统,甚至是外部处理,通过某种途径与系统交互。重要的是着重从系统外部执行者的角度来描述系统需要提供哪些功能,并指明这些功能的执行者(Actor)是谁。尽可能地确保所有Actor都被完全识别出来。
  • 第二步,描述主要的Use Case。可以采取不断地问自己“这个Actor究竟想通过系统做什么?”来准确地描述Use Case。
  • 第三步,重新审视每个Use Case,为它们下个详尽的定义。

5.4 角色定义

  • 用户:用户是指在这个博物馆信息服务子系统中通过客户端浏览博物馆信息的人员,这个Actor主要参与客户端的数据浏览、数据查询、用户反馈和查看博物馆数据分析等功能。

5.5 系统主Use Case图

子系统的主UseCase图

5.6 功能说明

使用者进入客户端可以看到博物馆列表,详细的博物馆参观信息,馆藏精品,博物馆音频介绍,周边博物馆及博物馆相关新闻展览等场馆详情几项。搜索界面有排名列表,按照展览次数、参观人次及用户评分有不同的排序。当使用者正在博物馆参观时,可使用地图浏览进行辅助参观(四组部分),参观某个博物馆之前,也可以通过场馆详情中的评价一栏,查看其他用户对该博物馆的评价与打分,参观完毕后,也可以自行对该博物馆做出评价。它的活动图如下图所示:

活动图 客户端的主要功能包括:

  • 数据浏览:浏览各博物馆的介绍、参观信息、展览、教育活动、藏品、新闻等。采用列表方式或地图方式查看各博物馆。
  • 数据查询:按照博物馆、展览或藏品名称等进行数据查询。
  • 用户反馈:支持用户评论,支持用户按展览、服务、环境三个方面对一个博物馆进行打分。
  • 查看博物馆数据分析结果:按展览次数、用户评分等指标查看博物馆排名列表 它的用例图如下图所示:

客户端的功能用例图

5.6.1 数据浏览

数据浏览功能是子系统的主要功能,为用户提供浏览各博物馆的介绍、参观信息、展览、教育活动、藏品、新闻等功能,方面用户全面了解博物馆信息。

用例描述: 数据浏览

执行者: 用户

前置条件: 用户选择博物馆后,进入其首页的场馆详情页面

后置条件: 用户浏览完可以选择去博物馆实地参观或在评论区发表评论

基本路径:

a) 查看某博物馆首页

b) 点击“场馆简介”按钮查看博物馆简介

c) 点击“场馆详情”按钮查看博物馆的参观信息、展览、教育活动、新闻

d) 点击“藏品介绍”按钮查看博物馆藏品介绍

5.6.2 数据分析结果查看

数据分析结果查看为用户提供浏览博物馆按各种指标进行排名的列表的功能。

用例描述: 查看博物馆排名列表

执行者: 用户

前置条件: 用户处于客户端首页

后置条件: 用户通过查看博物馆排名,选择自己感兴趣的博物馆进一步了解

基本路径:

a) 点击左上角按钮进入博物馆排名列表查看界面

b) 点击博物馆排名界面的排名指标按钮,选择按展览次数或用户打分等指标查看博物馆排名列表

5.6.3 数据查询

数据查询功能可以让用户快速准确地找到自己想了解的博物馆、展览或藏品信息。

用例描述: 数据查询

执行者: 用户

前置条件: 用户处于客户端首页

后置条件: 数据查询后,用户可以浏览自己想要查询的博物馆、展览或藏品的详细信息

基本路径:

a) 点击博物馆首页的搜索框进入搜索界面

b) 点击搜索界面的搜索指标按钮,选择按博物馆、展览或藏品进行查询

c) 用户查看查询结果

5.6.4 用户反馈

用户评价和打分可供用户对博物馆发表自己的看法与评价,也给未参观过某博物馆的用户提供参考的价值,具体描述如下:

用例描述: 评价打分

执行者: 用户

前置条件: 用户已登录系统并进入某博物馆首页的场馆详情页面

后置条件: 在评价处留在使用者的评论与打分

基本路径:

a) 从博物馆首页的场馆详情按钮进入,选择评价

b) 可查看其他用户的评价,并点击“我要评价”按钮进入评价打分界面,可对参观博物馆进行评价。


6. 后台管理子系统需求规格

6.1 子系统来源以及背景

该子系统是博物馆应用系统的后台管理子系统,由于博物馆应用系统是一个集论坛+资料库性质的系统,存在大量用户以及数据需要管理。为了维护良好的网络环境,使得应用程序质量得到保证,故采用管理员管理的方式。该子系统主要是面向管理员,其作用是为管理员提供管理工具,并提高管理效率。

6.2 子系统要达到的目标

  1. 系统能够提供友好的用户界面,使操作人员的工作量最大限度的减少
  2. 系统具有良好的运行效率,能够得到提高生产率的不敌
  3. 系统应该具有良好的可扩充性,可以容易的加入其他系统的应用。
  4. 平台的设计具有与一定的超前性,灵活性,能够适应企业生产配置的变化。
  5. 通过这个子系统能够锻炼子系统成员,提高团队的开发能力和项目管理能力。

6.3 子系统整体结构

根据用户需求陈述,可以确定本子系统分为客户端和服务端以及数据库部分

  • 客户端主要是提供给管理员使用的应用程序,管理员可以通过页面实现例如用户管理、讲解审核、数据管理、数据库备份等功能。
  • 服务端主要是提供子系统客户端实现业务功能相关的接口
  • 数据库主要是存放大量数据的地方,数据直接与服务端进行交互,通过服务端提供的接口向客户端开放数据库操作的功能。

后台管理子系统整体结构图

6.5 子系统客户端功能规格

6.5.1 角色定义

  • 管理员:管理用户指的是管理的用户,管理端用户能实现用户管理、讲解审核、数据管理等功能
  • 超级管理员(Root):具有管理用户的功能,此外还能负责数据备份和恢复等功能
  • Use Case图 后台管理客户端子系统Use Case图

6.5.2 客户端活动图

后台管理子系统客户端活动图

6.5.3 功能描述

6.5.3.1 登录验证
  • 用例描述:用户发起登录验证登录后台管理子系统
  • 执行者: 所有人
  • 前置条件:无
  • 后置条件:无
  • 基本路径:
    1. 用户通过地址访问获取到登录页面
    2. 用户输入账户以及密码并提交
    3. 客户端发起请求,等待服务端返回信息
    4. 客户端对其根据返回结果进行响应
6.5.3.2 用户管理
  • 用例描述:用户要进行用户管理相关操作
  • 执行者:管理员以及超级管理员
  • 前置条件: 用户已经登录
  • 后置条件: 无
  • 基本路径
    1. 用户在功能选择页面选择用户管理页面
    2. 进入用户管理页面选择相关操作,输入相关信息
    3. 客户端发起请求,等待服务端返回信息
    4. 客户端根据其返回结果进行响应
6.5.3.3 讲解审核
  • 用例描述:用户要进行讲解审核操作
  • 执行者: 管理员以及超级管理员
  • 前置条件: 用户已经登录
  • 后置条件: 无
  • 基本路径
    1. 用户在功能选择页面选择讲解审核页面
    2. 进入讲解审核页面选择相关操作,输入相关信息
    3. 客户端发起请求,等待服务端返回信息
    4. 客户端根据其返回结果进行响应
6.5.3.4 数据管理
  • 用例描述:用户要进行数据管理相关操作
  • 执行者:管理员以及超级管理员
  • 前置条件: 用户已经登录
  • 后置条件: 无
  • 基本路径
    1. 用户在功能选择页面选择数据管理页面
    2. 进入数据管理页面选择相关操作,输入相关信息
    3. 客户端发起请求,等待服务端返回信息
    4. 客户端根据其返回结果进行响应
6.5.3.5 数据备份以及恢复
  • 用例描述:用户要进行数据备份以及恢复相关操作
  • 执行者:超级管理员
  • 前置条件: 用户已经登录
  • 后置条件: 无
  • 基本路径
    1. 用户在功能选择数据备份以及恢复页面
    2. 进入数据备份以及恢复页面选择相关操作,输入相关信息
    3. 客户端发起请求,等待服务端返回信息
    4. 客户端根据其返回结果进行响应
6.5.3.6 退出
  • 用例描述:用户退出登录状态
  • 执行者:管理员以及超级管理员
  • 前置条件: 用户已经登录
  • 后置条件: 无
  • 基本路径
    1. 用户在功能选择退出功能。
    2. 客户端发起请求,等待服务端返回信息
    3. 客户端根据其返回结果进行响应

6.7 子系统服务端功能规格

6.7.1 服务端主要功能职责

  1. 提供相关功能的接口
    • 接口设计规范具体在设计文档中阐述
  2. 管理数据存放的各种数据库
    • 管理存放结构化数据的Mysql数据库
    • 管理二进制文件的相关数据
  3. 数据备份数据恢复功能

6.7.2 服务端应用环境

  • 硬件环境
    • CPU:>= 1核
    • 内存: >= 512Mb
  • 网络环境
    • 拥有公网IP
    • 带宽: >= 1Mbps
  • 软件环境
    • 操作系统:Linux系统
    • Chrome V8引擎(Nodejs的运行环境)
    • Mysql服务器
    • shell

6.8 子系统数据库功能规格

6.8.1 数据库主要功能职责

  1. 存放大量的结构化数据
  2. 提供高效的数据操作功能(例如使用SQL语句进行查询)

6.9 产品提交

  • 提交方式:网盘上传
  • 应用系统软件包
    • 后台管理客户端程序源代码
    • 服务端程序源代码
    • 初始化数据库的源代码
  • 数据库初始化数据
  • 系统开发过程文档
  • 系统使用维护说明文档
  • 提供一个供使用以及测试的应用程序
⚠️ **GitHub.com Fallback** ⚠️