概要设计文档 - sekaiiiii/BUCTCS1703SECD GitHub Wiki

设计文档

1. 博物馆网站数据采集系统设计文档

1.1 导言

1.1.1 目的

本文档的目的是描述《博物馆网站数据采集系统》项目的详细设计,其主要内容包括:

  • 系统功能简介
  • 系统详细设计简述
  • 各个模块的三层划分
  • 最小模块组件的伪代码

1.1.2 范围

该文档定义了系统的各个模块和模块接口,但未确定单元的具体实现,这部分内容将在实现中确定

1.1.3 缩写说明

  • MVC:Model-View-Control(模式-视图-控制)的缩写,表示一个三层的结构体系

1.1.4 术语定义

Struct:一种框架体系结构

1.1.5 阅读人群

  • 开发人员
  • 项目管理人员
  • 测试人员

1.1.6 参考资料

-《实战struct》 〔美〕Ted Husted 机械工业出版社

1.2 系统设计概述

该系统按照功能划分分为客户端子系统和管理端子系统,根据页面流的设计,管理端系统分为用户管理,数据使用、登录管理三个模块,以下将分小节对各个部分分别进行详细设计

1.3 详细设计概述

本系统采用基于Struct体系结构的设计,即采用MVC的三层设计模式,采用面向对象的Python语言,所以,基本采用面向对象的设计方法。在整个的开发过程中,尽可能采用复用的原则,例如采用标签库,统一数据库的基本操作,统一结果显示等

1.4 网站管理模块的详细设计

网站管理模块主要实现网上数据爬取,数据加工,数据输入和数据更新

1.5 网站管理模块三层模块

视图 控制器 模型

1.5.1视图层

  1. 包括文件种类和数量
  2. 伪码描述和说明

1.5.2控制层

  1. 文件种类和数量
  2. 伪码描述

1.5.3模型层

  1. 文件种类和数量
  2. 伪码描述

1.6 数据使用模块的详细设计

数据使用模块主要实现由其他小组成员使用爬取来的数据

  • 网站管理模块三层模块
视图 控制器 模型

1.6.1 视图层

  1. 包括文件种类和数量
  2. 伪码描述和说明

1.6.2 控制层

  1. 文件种类和数量
  2. 伪码描述

1.6.3 模型层

  1. 文件种类和数量
  2. 伪码描述

1.7 系统流程图

管理者

graph LR
A[数据爬取]--> B[数据加工] 
B[数据加工]-->C[数据存储]

使用者

graph LR
A[数据导出]--> B[数据使用] 

1.8 体系结构

1.8.1 系统的总体结构设计遵循如下原则:

  1. 系统应具有良好的适应性:能适应用户对系统的软件环境、管理内容、模式和界面的要求;
  2. 系统应具有可靠性:采用成熟的技术方法和软件开发平台,以保证在以后的实际应用中安全、可靠;
  3. 系统应具有较好的安全性:应提高完善的安全机制和用户权限限制机制,确保数据的受限访问;
  4. 系统应具有良好的可维护性:系统应易于维护、安装;
  5. 系统应具有良好的可扩展性:系统应适应未来信息化建设的要求,能方便得进行功能扩展,以建立完善的信息集成管理体系。

本系统采用struts体系结构,Struts 是一个基于模型 (Model) -视图 (View) -控制器 (Controller)(MVC) 模式的应用架构的开源框架。

1.8.2 硬件环境

  • 本系统的硬件环境如下:
    • 客户机:普通PC
      • CPU:P4 1.8GHz以上
      • 内存:256MB以上
      • 能够运行IE5.0以上或者Netscape4.0以上版本的机器
      • 分辨率:推荐使用1024*768像素
    • WEB服务器
      • CPU:P4 2.0GHz
      • 内存:1G以上
      • 硬盘:80G以上
      • 网卡:千兆
    • 数据库服务器
      • CPU:P4 2.0GHz
      • 内存:1G以上
      • 硬盘:80G以上

1.8.3软件环境

  • 本系统的的软件环境如下:
    • 操作系统:Unix/Linux/windows2000或以上版本
    • 数据库:SQL Server 2000
    • 开发工具包:JDK Version 1.4.2
    • 开发环境:eclipse-SDK-3.1.2-win32
    • Web服务器:Tomcat
    • 浏览器:IE6.0以上

2. 博物馆新闻采集分析子系统设计文档

2.1导言

2.1.1 目的

该文档的目的是描述网上招聘系统项目的概要设计,其主要内容包括:

  • 系统功能简介
  • 系统结构设计
  • 系统接口设计
  • 数据设计
  • 模块设计
  • 界面设计

本文档的预期的读者是:

  • 开发人员
  • 项目管理人员
  • 测试人员

2.1.2范围

该文档定义了系统的结构和单元接口,但未确定单元的实现方法,这部分内容将在详细设计/实现中确定。

2.1.3 缩写说明

  • UML (Unified Modeling Language)

    UML(统一建模语言)是一种用于指定、可视化、构造和记录软件系统工件的标准语言。

  • Scrapy

    • Scrapy 是用 Python 实现的一个为了爬取网站数据、提取结构性数据而编写的应用框架。
    • Scrapy 常应用在包括数据挖掘,信息处理或存储历史数据等一系列的程序中。
    • 通常我们可以很简单的通过 Scrapy 框架实现一个爬虫,抓取指定网站的内容或图片。
  • sklearn

    Scikit-learn(也称为sklearn)是Python编程语言的免费软件机器学习库。它具有各种分类、回归和聚类算法,包括支持向量机、随机林、梯度提升、k-均值和DBSCAN,旨在与 Python 数值和科学库NumPy和SciPy进行互操作。

2.1.4 术语定义

  • 爬虫

    网络爬虫(又称为网页蜘蛛,网络机器人,在FOAF社区中间,更经常的称为网页追逐者),是一种按照一定的规则,自动地抓取万维网信息的程序或者脚本。另外一些不常使用的名字还有蚂蚁、自动索引、模拟程序或者蠕虫。

  • 机器学习

    机器学习是一门多领域交叉学科,涉及概率论、统计学、逼近论、凸分析、算法复杂度理论等多门学科。专门研究计算机怎样模拟或实现人类的学习行为,以获取新的知识或技能,重新组织已有的知识结构使之不断改善自身的性能。 它是人工智能的核心,是使计算机具有智能的根本途径。

  • 文本分析

    文本分析是对文本进行解析,以便从中提取机器可读的事实。文本分析的目的是用自由文本内容创建结构化数据。这个过程可以看作是将一堆非结构化、异构的文档分割成易于管理和解释的数据块。

2.1.5 参考资料

2.2 系统分析

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

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

2.3 体系结构

系统的总体结构设计遵循如下原则:

  • 系统应具有良好的适应性:能适应用户对系统的软件环境、管理内容、模式和界面的要求;
  • 系统应具有可靠性:采用成熟的技术方法和软件开发平台,以保证在以后的实际应用中安全、可靠;
  • 系统应具有较好的安全性:应提高完善的安全机制和用户权限限制机制,确保数据的受限访问;
  • 系统应具有良好的可维护性:系统应易于维护、安装;
  • 系统应具有良好的可扩展性:系统应适应未来信息化建设的要求,能方便得进行功能扩展,以建立完善的信息集成管理体系。

2.3.1 系统运行硬件环境

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

2.3.2 系统运行软件环境

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

2.4数据模型

本系统的数据模型主要是进行数据库的设计。

2.4.1数据库的概念结构模型设计

概念设计以反映现实世界中的实体、属性和它们之间的关系等的原始数据形式

2.4.2数据库的逻辑结构模型设计

数据库的逻辑设计是将各局部的E-R图进行分解、合并后重新组织起来形成数据库全局逻辑结构,包括所确定的关键字和属性、重新确定的记录结构、所建立的各个数据之间的相互关系。

2.4.3数据库管理物理结构模型设计

信息存储结构的设计在系统的设计中至关重要,要考虑到数据冗余、系统执行效率、信息控制以及维护等方面的要求。信息的管理离不开数据库的支持,我们采用mysql数据库管理系统。 数据库的物理设计主要是对数据在内存中的安排,包括对索引区、缓冲区的设计;对使用的外存设备及外存空间的组织,包括索引区、数据块的组织与划分;设置访问数据的方式方法。

(详见附录数据库结构设计)

2.5模块设计

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

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


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


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


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


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


2.5.1 数据获取

用例描述:子系统对新闻数据进行爬取 执行者:子系统 前置条件:用户登陆并进入系统 后置条件:子系统对爬取的信息进行加工 基本路径:

  • 用户登入到此系统内,根据其他子系统提供的接口,查看自己所需的新闻。

2.5.2 数据加工

用例描述:对爬取的信息进行加工 执行者:博物馆新闻分析子系统 前置条件:子系统已经对数据爬取完成 后置条件:信息加工好后,系统对信息进行分析 基本路径:

  • 对爬取的信息进行过滤和加工
  • 从初步加工的信息中抽取所需的内容

2.5.3 数据分析

用例描述:对加工好的新闻,分析是否是正面信息 执行者:博物馆新闻分析子系统 前置条件:对爬取的信息已加工完成 后置条件:分析结束后,用户可获得所需新闻 基本路径:

  • 采用已有的可直接调用的服务和代码实现
  • 分析是正面新闻还是负面新闻

2.5.4 数据定制服务

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

  • 指定某一个博物馆,指定获该博物馆新闻的时间
  • 得到该博物馆指定时间内的主要新闻,正面新闻和负面新闻。

3. 博物馆信息服务子系统设计文档

3.1 导言

3.1.1 目的

该文档的目的是描述博物馆信息服务子系统的设计,其主要内容包括:

  • 系统功能简介
  • 系统结构设计
  • 系统接口设计
  • 数据设计
  • 模块设计
  • 界面设计

本文档的预期的读者是:

  • 开发人员
  • 项目管理人员
  • 测试人员

3.1.2 范围

该文档定义了系统的结构和单元接口,但未确定单元的实现方法,这部分内容将在后续版本中补充

3.1.3 引用标准

《韩万江软件文档范例》

3.1.4 版本更新信息

修改编号 修改日期 修改后版本 修改位置 修改内容概述 修改人
000 2020.4.17 0.1 全部 初始发布版本 胡以欣

3.2 系统分析

  • 数据浏览:在手机端可以浏览各博物馆的介绍、参观信息、展览、教育活动、藏品、新闻等。可以采用列表方式,或地图方式显示各博物馆。
  • 数据查询:支持数据的查询功能:按照博物馆查询、按照展览查询、按照藏品名称查询。
  • 用户反馈:支持用户评论、打分功能。按照展览、服务、环境三个方面让用户对一个博物馆进行打分。
  • 数据分析:分析博物馆信息以及用户反馈信息,用排名列表和可视化方式显示分析结果:各博物馆按一年举办的展览次数或藏品数目或用户综合评分的排名列表

3.3 界面设计

主要界面设计如下: 界面设计

3.4 设计方案

初步计划如下:

  • 每个页面一个Activity
  • 展览/藏品/要闻/教育的详情页用WebView显示,传url即可
  • 列表页统一采用RecyclerView显示列表,列表考虑采用动态加载的方式,提升性能
  • 和四组有交叉的部分目前决定采用fragment+navigation,两组分开写fragment
  • 数据无法获取前,先采用假数据进行测试

4. 博物馆导览子模块概要设计

4.1导言

4.1.1 目的

该文档的目的是描述博物馆导览子系统的概要设计,其主要内容包括:

  • 系统功能简介
  • 系统结构设计
  • 系统接口设计
  • 数据设计
  • 模块设计
  • 界面设计

本文预期阅读对象是:

  • 项目的开发人员
  • 测试人员
  • 管理人员

4.1.2 范围说明

该文档定义了系统的结构和单元接口,但未确定单元的实现方法。

4.1.3缩写说明

4.1.4 术语定义

4.1.5 引用标准

《需求规格报告格式标准》v1.1

4.1.6 参考资料

《需求规格报告格式标准》v1.1

4.2 系统分析

  • 设计概述 对于客户端的使用会涉及到各种类型的游客人群,凭借android简洁明了的UI和快捷的操作特性,并不要求用户对其特别的熟悉,其可以做到让使用方法简单易懂,操作方法尽量浅显明了,用户能够在短时间内借助简易的说明快速上手。为了提高系统的实用性,要求具有较强的可靠性和较大的吞叶量。 对于服务端的操作人员,由于软件设计的提供给操作人的接口仅仅会涉及到简单的文件新建、修改、复制、删除等操作,因此仅仅需要操作人员熟悉简单的电脑操作即可,不需要专门进行培训。 image-20200417140016516

4.3 界面设计

主要实现登录、选择博物馆、地图浏览、语音介绍以及用户管理等功能。主要界面设计如下:

  • 登录界面
    通过用户名和密码实现用户登录,并判断用户的权限
  • 管理首页
    根据用户的权限,进入首页,并在首页中展示此用户相应可以操作的权限功能。
  • 浏览管理
    包括“博物馆简要介绍”、“查看详细信息”、“查看地图”、“展品介绍”、“语音导航”、等页面。
  • 用户管理
    包括“用户列表”、“用户信息”、“修改用户信息”、“添加用户”和“删除用户” 、“用户权限设置”等页面。

详见附件页面设计.pdf第一版

4.4 体系结构

系统的总体结构设计遵循如下原则:
1)系统应具有良好的适应性:能适应用户对系统的软件环境、管理内容、模式和界面的要求;
2)系统应具有可靠性:采用成熟的技术方法和软件开发平台,以保证在以后的实际应用中安全、可靠;
3)系统应具有较好的安全性:应提高完善的安全机制和用户权限限制机制,确保数据的受限访问;
4)系统应具有良好的可维护性:系统应易于维护、安装;
系统应具有良好的可扩展性:系统应适应未来信息化建设的要求,能方便得进行功能扩展,以建立完善的信息集成管理体系。

4.5 数据模型

本系统的数据模型主要是进行数据库的设计。

4.5.1数据库的概念结构模型设计

概念设计以反映现实世界中的实体、属性和它们之间的关系等的原始数据形式

4.5.2数据库的逻辑结构模型设计

数据库的逻辑设计是将各局部的E-R图进行分解、合并后重新组织起来形成数据库全局逻辑结构,包括所确定的关键字和属性、重新确定的记录结构、所建立的各个数据之间的相互关系。

4.5.3数据库管理物理结构模型设计

信息存储结构的设计在系统的设计中至关重要,要考虑到数据冗余、系统执行效率、信息控制以及维护等方面的要求。信息的管理离不开数据库的支持,我们采用mysql数据库管理系统。 数据库的物理设计主要是对数据在内存中的安排,包括对索引区、缓冲区的设计;对使用的外存设备及外存空间的组织,包括索引区、数据块的组织与划分;设置访问数据的方式方法。需在非系统卷(操作系统所在卷以外的其他卷)上安装 SQL Server 程序及数据库文件。内存是影响Microsoft SQL Server系统性能的一个重要因素,应在Microsoft SQL Server数据库安装后进行内存选项(Memory)设置,最大配置值为2GB。 为了确定SQL Server系统最适宜的内存需求,可以从总的物理内存中减去Windows 2000 server需要的内存(120M)以及其它一些内存需求后综合确定,理想的情况是给SQL Server分配尽可能多的内存,而不产生页面调度。

(详件附录数据库结构设计)

4.6 模块设计

按照功能分解,本系统分为客户端管理系统和管理端系统。 本组只负责客户端系统

4.6.1客户端模块设计

4.6.1.1 表示层设计

客户端运行在公网上,可以显示博物馆列表,使用者可以查看相关博物馆的详细信息,用户评价,当使用者希望浏览某博物馆时,还可以选择语音导航,语音介绍。

根据上述的功能介绍,总结出客户端的页面设计如下

  • 主页面: 客户端的主页面
  • 博物馆列表: 显示一定范围内的博物馆及其简介
  • 博物馆详细信息: 显示某个博物馆的详细信息
  • 个人基本信息: 包含个人账户信息
  • 个人浏览历史: 包含个人浏览历史,可以从里面找出最近浏览
  • 地图信息:包含某个博物馆的具体位置及导航
  • 介绍管理:包含某个博物馆的文字介绍,语音介绍及其他用户的评价
4.6.1.2控制层设计

控制层主要是设计activity组件,activity负责单个事件的流程控制, activity映射决定了activity与其它Service组件之间的关联关系. 客户端的事件主要包括进入博物馆列表、浏览博物馆详细信息,进入博物馆界面,查看展品信息、查看其他用户的评价、地图导航、语音介绍以及所有页面的上级返回动作。

4.6.2登录管理模块设计

登录管理模块负责管理端用户的登录。管理端用户都是通过登录界面进入管理端的,用户输入用户名和密码进入管理界面首页,提供了进入功能面板的接口,并根据用户的权限在首页中列出相应的操作功能。

4.6.2.2控制层设计

非本组范围

4.6.3总结

根据上述的功能介绍,总结出博物馆管理功能的页面设计下

  • 博物馆信息首页: 博物馆管理主页面
  • 展品信息列表 : 显示各种展品的列表
  • 展品详细信息 : 包含展品的背景故事及其介绍
  • 增加展品: 增加展品的页面
  • 增加展品信息: 增加展品信息的页面
  • 增加评价: 增加其他用户对该博物馆的评价

4.7 页面设计

页面列表

注页面级别:0级为主页面,1级为子页面,2级之后以此类推,A级为服务,服务由活动调用,页面也注明调用的服务id

img

0首页

图片待定,可通过搜索搜索博物馆具体信息,可查看博物馆简介及参观须知,可浏览要闻信息/展览信息/教育信息/藏品信息及评价

等级 0

子页面:1,2,3,4,6,7,8,9

1搜索页面

显示搜索结果

等级 1

子页面 无

调用服务 A25

2 博物馆列表

显示所有博物馆,也可切换到地图

等级 1

子页面:26,0(默认显示首页,但首页可通过页面2进入)

3博物馆简介页面

场馆信息-博物馆简介

等级 1

子页面 无

需要实现:见图

4 要闻列表

等级1

子页面 5

5要闻具体信息/展览具体信息/教育具体信息/藏品具体信息/新闻,形式webview

等级 2

子页面 无

6展览列表

等级1

子页面 5

7教育活动列表

等级1

子页面 5

8藏品列表

等级1

子页面 5

藏品介绍

藏品介绍子界面

9游客评价列表

等级1

子页面 10

10游客具体评价/我要评价
11tabbar新闻

等级0,可bar切换,属于主页面

子页面12,13

12搜索页面1

等级1

无子页面

13新闻列表webview

等级2

无子页面

14我的(登陆前/登陆后)

等级 0 ,属于bar切换

子页面 15,16,17,18,19,20,21,22,23

登录-用户

15注册

等级1

子页面无

注册

16登录

等级1

子页面无

登录-游客

17找回密码

等级1

子页面无

忘记密码?

18上传讲解

等级1

子页面无

上传博物馆讲解视频

19查看审核状态

等级1

子页面无

已上传文件

20设置

等级1

子页面无

更多设置

21更改个人信息

等级1

子页面无

更改头像

22服务反馈

等级1

子页面无

意见反馈

23关于
A24:音频讲解服务/广播

完成音频获取和准备工作

A25:搜索服务

完成搜索的数据呈递

26:地图

等级1

子页面无

完成地图的相关要求 地图界面


5. 后台管理子系统设计文档

5.1导言

5.1.1 目的

该文档的目的是描述博物馆导览子系统的概要设计,其主要内容包括:

  • 系统功能简介
  • 系统结构设计
  • 系统接口设计
  • 数据设计
  • 模块设计
  • 界面设计

本文预期阅读对象是:

  • 项目的开发人员
  • 测试人员
  • 管理人员

5.1.2 范围说明

该文档定义了系统的结构和单元接口,但未确定单元的实现方法,这部分内容将在详细设计/实现中确定。

5.1.3缩写说明

5.1.4 术语定义

5.1.5 引用标准

《需求规格报告格式标准》v1.1

5.1.6 参考资料

《需求规格报告格式标准》v1.1

5.2 系统分析

本系统作为博物馆应用程序的管理程序,需要一个仅供管理员访问的页面进行操作。其中大致功能包括以下几大块:

  1. 用户管理:管理后台用户信息、后台管理员日志、手机端用户信息。如增加管理员,修改管理员密码,禁止一个发布过非法评论的手机端用户再次发布评论等。
  2. 讲解审核:审核用户上传的讲解。
  3. 数据管理:管理1-4系统中涉及所有数据,如一个博物馆的基本信息、展览信息、藏品信息、新闻信息、讲解信息、评论等。例如,删除一个用户发布的非法评论信息。
  4. 数据备份和恢复:支持本系统的数据库和服务器端重要文件的备份和恢复。

实现这部分功能的设计包括客户端设计以及后端服务器设计。

  • 客户端 客户端设计图

  • 服务端 服务端设计图

5.3 界面设计

界面设计主要是面向WEB客户端的界面设计

  • 登录界面
    • 提供管理员使用的登录页面,并完成登录验证,根据登录验证成功与否跳转至首页。
  • 首页
    • 登录成功后的主页面,管理员可以在此跳转至其余各个主页面。
  • 数据管理主页面
    • 数据管理主页面,可以跳转至各种数据处理的子页面。
  • 用户管理主页面
    • 可以跳转至用户管理的各种子页面
  • 数据库备份与恢复主页面
    • 可以跳转至数据库备份页面,数据库恢复主页面
  • 讲解审核主页面
    • 可以跳转至讲解审核主页面
  • 数据管理子页面
    • 基本信息页面
      • 提供博物馆信息的增删改查功能
    • 展览信息页面
      • 提供展览信息的增删改查功能
    • 藏品信息页面
      • 提供藏品信息的增删改查功能
    • 新闻信息页面
      • 提供新闻信息的增删改查功能
    • 讲解信息页面
      • 提供讲解信息的增删改查功能
      • 提供跳转至讲解审核页面的功能。
    • 评论页面
      • 提供博物馆评论的增删改查功能
  • 用户管理子页面
    • 后台管理员信息页面
      • 提供后台用户信息的增删改查功能
    • 后台管理员日志
      • 查看后台管理员的工作日志功能
    • 手机端用户信息
      • 提供手机端用户信息增删改查功能
  • 讲解审核主页面
    • 显示讲解列表
    • 可以进入处理讲解审核的页面
  • 讲解审核页面
    • 在该页面可以完成讲解的审核功能
  • 数据备份和恢复主页面
    • 提供完成数据备份和恢复的功能的页面

5.4 体系结构

5.4.1 WEB端体系结构

开发Web应用,要从头设计并开发出一个可靠、稳定的框架不是一件容易的事情,随着Web开发技术的日趋成熟,在web开发领域出现了一些现成的优秀的框架,开发者可以直接使用它们。Vuejs就是一个很好的框架结构。

Vue (读音 /vjuː/,类似于 view) 是一套用于构建用户界面的渐进式框架。与其它大型框架不同的是,Vue 被设计为可以自底向上逐层应用。Vue 的核心库只关注视图层,不仅易于上手,还便于与第三方库或既有项目整合。另一方面,当与现代化的工具链以及各种支持类库结合使用时,Vue 也完全能够为复杂的单页应用提供驱动。

  • 基于VUEJS的MVVM架构 MVVM架构图 MVVM拆开来即为Model-View-ViewModel,有View,ViewModel,Model三部分组成。View层代表的是视图、模版,负责将数据模型转化为UI展现出来。Model层代表的是模型、数据,可以在Model层中定义数据修改和操作的业务逻辑。ViewModel层连接Model和View。 在MVVM的架构下,View层和Model层并没有直接联系,而是通过ViewModel层进行交互。ViewModel层通过双向数据绑定将View层和Model层连接了起来,使得View层和Model层的同步工作完全是自动的。因此开发者只需关注业务逻辑,无需手动操作DOM,复杂的数据状态维护交给MVVM统一来管理。在Vue.js中MVVM的体现: Vuejs中MVVM的体现

5.5服务端体系结构

服务端主要是作为存放在服务器的数据与前端页面数据交互提供HTTP API接口。而此次选用的Express框架是一种保持最低程度规模的灵活 Node.js Web 应用程序框架,为 Web 和移动应用程序提供强大的功能。 其Express框架对HTTP处理示意图如下: Express框架 其核心概念便是中间件以及路由。

该应用系统的架构图大致如下 express架构

图中

  • 蓝色的部分代表业务中间件
  • 橙黄色代表 核心中间件。
    • 应该包括 limiter 限流操作(可能不会用),这个中间件主要是防止爬虫;
    • htaccess 改写 url,这个中间件主要用,改写网站url, 为什么要改呢?因为一但网站线上运行时,路由的规则不应发生变化,但是有时候 seo 的时候,你需要兼容新老 url 的时候,这个中间件就会非常有用,网站的业务都不用变,只用在新url 到达时,变成老的再进行处理就行了(不用);
    • dispatch 不是一个中间件,它的思想是用来整合各个业务线的 subApplication 和主 application 的关系的;auth 鉴权,有些页面和接口需要有用户登录,如果没有用户登录,就需要跳转到登录页面,登录完成后跳回来;clientError 和
    • serverError 是对错误进行统一的处理,统一显示 404 , 如果是接口的话也会统一 404 的返回码。

业务端在开发时只需要在 dispatch 的地方加入自已的模块,然后就可以开始写自己的业务,不用但心自己的文件被别人改动。

5.6 数据模型

5.6.1 数据库的概念结构模型设计

概念设计以反映现实世界中的实体、属性和它们之间的关系等的原始数据形式,建立数据库的每一幅用户视图。ER图如图所示(不准了,因为已经修改了!仅供参考) ER

5.6.2 数据库的逻辑结构模型设计

数据库的逻辑设计是将各局部的E-R图进行分解、合并后重新组织起来形成数据库全局逻辑结构,包括所确定的关键字和属性、重新确定的记录结构、所建立的各个数据之间的相互关系。数据库表图如图所示,具体表的属性和意思此处不具体讲解了!大家结合需求认真阅读 数据库表图

5.6.3数据库管理物理结构模型设计(这块不大懂!就摘抄了一部分)

信息存储结构的设计在系统的设计中至关重要,要考虑到数据冗余、系统执行效率、信息控制以及维护等方面的要求。信息的管理离不开数据库的支持,我们采用Mysql数据库

5.7 WEB应用端模块设计(详细见详细设计文档)

5.8 服务端接口设计(详细见详细设计文档)

⚠️ **GitHub.com Fallback** ⚠️