系统架构设计说明书
1. 引言
1.1 编写目的
编写本文档主要用于说明关于高校问卷调查管理系统的具体系统架构设计。其中，具体说明了系统架构设计的目标和约束需求，规定了系统的开发环境和运行环境，阐述了逻辑架构设计的整体思想和具体设计的实现，介绍了系统的主要业务流程和系统的功能模块的划分以及模块之间的联系，表明了系统采用存储的数据库类型以及数据库又采用了什么设计编辑工具和数据库中存储的各种表的具体信息，最后是设计了系统核心功能的界面原型。
本文档是对系统架构设计的详细说明，通过编写该系统架构设计说明书，有利于了甲方更好地理解系统逻辑架构和系统相关功能，也便于系统管理员更好地管理系统以及在出现问题后能够更好地对系统进行维护。
1.2 读者对象
系统管理者：在系统正式运行后，系统的管理者，主要用来维护系统的正常运行，保证系统数据库信息的安全，能够及时应对系统在运行时出现的一些小问题。
系统开发人员：整个系统的主要开发人员，也是系统架构和功能的主要设计人员，负责系统的web前端和后端的开发。
系统测试人员：在系统完成了初步实现后，对系统进行各方面的测试，其中包括系统的功能是否全面，系统的响应和事件的处理是否快捷，系统的安全性以及系统整体的业务流程等方面。
1.3 参考资料
[1]李伟/吴庆海，《软件架构的艺术》，电子工业出版社，2009-04
[2]邓春晖/秦映波，《Web前端开发简明教程》，人民邮电出版社，2017-12
[3]Till Adam，《架构之美》，机械工业出版社，2009-11
[4]许令波，《深入分析Java Web技术内幕》，电子工业出版社，2012-09
[5]陈康贤，《大型分布式网站架构设计与实践》，电子工业出版社，2014-09
[6]施瓦茨 (Baron Schwartz)/扎伊采夫 (Peter Zaitsev)/特卡琴科 (Vadim Tkachenko)，《高性能MySQL》，电子工业出版社，2013-05
1.4 术语与缩写解释
|
缩写、术语 |
解 释 |
|
Web |
（World Wide Web）即全球广域网，也称为万维网，它是一种基于超文本和HTTP的、全球性的、动态交互的、跨平台的分布式图形信息系统。 |
|
UI |
用户界面（User Interface，简称 UI，亦称使用者界面[1]）是系统和用户之间进行交互和信息交换的媒介，它实现信息的内部形式与人类可以接受形式之间的转换。 |
|
Html5 |
HTML5是构建Web内容的一种语言描述方式。HTML5是互联网的下一代标准，是构建以及呈现互联网内容的一种语言方式．被认为是互联网的核心技术之一。 |
|
Css3 |
层叠样式表(英文全称：Cascading Style Sheets)是一种用来表现HTML（标准通用标记语言的一个应用）或XML（标准通用标记语言的一个子集）等文件样式的计算机语言。 |
|
JavaScript |
|
|
Java |
Java是一门面向对象编程语言，不仅吸收了C++语言的各种优点，还摒弃了C++里难以理解的多继承、指针等概念，因此Java语言具有功能强大和简单易用两个特征。 |
|
Windows |
MicrosoftWindows操作系统是美国微软公司研发的一套操作系统，它问世于1985年，起初仅仅是Microsoft-DOS模拟环境，后续的系统版本由于微软不断的更新升级，不但易用，也当前应用最广泛的操作系统。 |
2. 系统概述
高校问卷调查管理系统是一款能够设计问卷、发布问卷、收集问卷以及对问卷收集信息分析的多功能应用型系统。用户登陆系统，可以根据自己的需求设计问卷的主题性质和问卷的题目，题目可定义为单选题、多选题、判断题以及主观意见题；在完成问卷的设计后，用户在系统数据库中选择需要接受调查问卷的人群，通过系统将设计好的问卷发布给相关人员；当待问卷调查人员填写好并提交问卷后，系统会对该问卷进行收集并存储在相关数据库中；当大部分都被填写好，系统会对问卷中信息进行整理和分析，并将结果呈现给用户，以供用户参考。
高校问卷调查管理系统是为提高政府教育管理的针对性与有效性，便于政府人员从学生和教师获知其对学校、专业、教学情况、教学资源配套、学校管理水平等多方面评价的信息收集。互联网是效率最高、短时间内涉及人员广的渠道之一，所以依托互联网的调查问卷需求应运而生，通过信息的反馈，进行信息的初步帅选与分析，能够及时反应当前高校情况，为管理手段和政策方针提供依据。
高校问卷调查管理系统主要满足的功能需求如下：
（1）项目发布功能，根据调查内容和性质的不同可定义成不同的项目，在每个项目下可定义问卷。
（2）设计问卷，调查问卷可进行问卷题目编辑，题型包含单选题和填空题两种类型。
（3）待问卷人员导入，包括学生和教师两种角色，通过excel模板导入待问卷人员信息，学生包括 学号、姓名、所属学校、专业、班级、性别、手机号、电子邮箱。教师包括教师号、姓名、所 属院校、性别、手机号码、电子邮箱。
（4）发布问卷，通过系统将问卷发布到待问卷人员，可通过短信和邮件两种方式获得问卷链接地址。
（5）问卷被提交后，结果被记录。
（6）系统对问卷结果进行统计并进行分析，可查看总体参与人数，答题选项比例、不同学生、不同 学校、不同年级、不同专业、不同院校级别、不同性别的答题报表或图表分析。
3. 架构设计目标和约束
3.1 架构设计目标
架构设计的主要目的是为了解决软件系统复杂度带来的问题。
架构设计是宏观性考量，在整体上理解问题的复杂性，给出方案，并论证方案的可行性，提供一系列准则指导执行。
因此，架构设计的目标主要有以下几点：
（1）提前识别问题的复杂性和关注点，提供可行的经过论证的解决方案；
（2）建立服务质量指标，确定设计方案可以满足指定的质量指标；
（3）规划整体设计，提供长远的可扩展性；
（4）为实际开发确定基本框架。
3.2 约束需求
3.2.1软件、硬件环境（包括运行环境和开发环境）的约束
软件开发和运行是基于64位Windows操作系统，所以软件可在64位Windows操作系统上的网页浏览器中正常打开和运行。采用WebStorm-2020完成Web前端的开发，Eclipse IDE for Java Developers-2020完成后端开发，MySQL 8.0进行数据库的设计和编辑，最终在Windows 10操作系统上的Google Chrome浏览器完成系统的测试和最终运行。
3.2.2接口/协议的约束
（1）内部接口/协议的约束
在内部接口方面，各模块之间采用函数调用、参数传递、返回值等方式进行信息传递。接口传递的信息将是以数据结构封装的数据，以参数传递或返回值的形式在各模块间传输。
（2）外部接口/协议的约束
在输入方面，对于键盘、鼠标等外部设备的输入，可用VISUAL C++的标准输入/输出，对输入进行处理。
在输出方面，如打印机的连接及使用，也可用VISUAL C++的标准输入/输出对其进行处理。在网络传输部分和网络硬件部分，为了实现高速传输，将使用高速ATM。
3.2.3用户界面的约束
UI的设计开发基于html5、css3和JavaScript等前端开发语言。在UI的设计中要具备适用性，易于用户理解；当错误操作时会有提示信息和防错处理，整体的布局和色彩的适用要合理，在事件的响应方面要最高效率，整体界面可复用，控件设置满足单一应对原则。网络通信协议采用 HTTP和TCP/IP协议，调用接口采用 Web Service，系统通过内嵌浏览器技术与扩展对象插件接口集成。
3.2.4软件质量的约束
（1）正确性
UI上的控件能够正确且及时响应，实现该控件对应功能，错误操作会进行信息提示，同时添加防错处理，及时应对出现的错误操作。
（2）可靠性
设置备用服务器保证系统正常工作。当遇到断电重启的情况，能够实现系统断电后的自动重启，且较少人工维护量和实现系统稳定运行。
（3）效率
数据信息的采集通讯支持10秒以上的实时数据传输（受网络环境影响），并且要求系统的响应时间不超过5秒。
（4）安全性
用户注册/登录系统，关键数据操作，需要验证码进行验证，关于数据采用MD5加密技术。
（5）可扩展性
系统在整体设计上要充分考虑可扩展性，当用户的需求变化时，系统可进行相应的处理；当系统在运行中，客户如果对原有功能作调整或变更，系统应该能够灵活地修改。同时，预留接口，能扩展到其他监测系统。
3.3 开发与运行环境
|
类别 |
标准配置 |
最低配置 |
|
开发环境 |
Windows 10操作系统 |
Windows 8操作系统 |
|
WebStorm-2020 |
WebStrom-2018 |
|
|
Eclipse IDE for Java Developers-2020 |
Eclipse IDE for Java Developers-2018 |
|
|
MySQL 8.0 |
MySQL 8.0 |
|
|
测试环境 |
Windows 10操作系统 |
Windows 8操作系统 |
|
Google Chrome（64位） |
Google Chrome（32位） |
|
|
运行环境 |
Windows 10操作系统 |
Windows 8操作系统 |
|
Google Chrome（64位） |
Google Chrome（32位） |
4. 系统总体设计
4.1 设计思想
三层架构(3-tier architecture) 通常意义上的三层架构就是将整个业务应用划分为：界面层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）。区分层次的目的即为了“高内聚低耦合”的思想。3个层次中，系统主要功能和业务逻辑都在业务逻辑层进行处理。
图4.1 三层架构图
所谓三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交互。
4.2 软件逻辑架构设计
分层的原因：
（1）分层设计允许你分割功能进入不同区域。换句话说，层在设计中就是逻辑组件的分组。例如，A层可以访问B层，但B层不能访问A 层。
（2）用分层的方法，以提高应用程序的可维护性，并使其更容易扩展，以提高性能。
设计分层的原则
（1）层意味着组建的逻辑分组。例如，对用户界面，业务逻辑和数据访问组建应该使用不同的不同的层。
（2）在一个层内组建应该聚合的。如业务层组建仅应提供与业务逻辑相关的操作，而不是提供其他操作。
（3）在设计的每一个层接口时要考虑好物理边界。如果通信扩展了物理边界，使用基于消息操作；否则使用基于对象操作。
（4）考虑使用接口类型（interface）来定义每层的接口。这将允许你创建该接口的不同实现，提高可测性。
（5）对于Web应用程序，在表示层和业务逻辑层之间实现基于消息的接口是一个好主意，即使这两层没有跨越物理边界。基于消息的接口更适合于无状态的Web操作。
·数据访问层：
有时候也称为是持久层，其功能主要是负责数据库的访问，可以访问数据库系统、二进制文件、文本文档或是XML文档。简单的说法就是实现对数据表的Select，Insert，Update，Delete的操作。如果要加入ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。主要是对原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不是指原始数据，也就是说，是对数据的操作，而不是数据库,具体为业务逻辑层或表示层提供数据服务。
·业务逻辑层：
主要是针对具体的问题的操作，也可以理解成对数据层的操作,对数据业务逻辑处理，如果说数据层是积木，那逻辑层就是对这些积木的搭建。业务逻辑层（Business Logic Layer）无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，也即是说它是与系统所应对的领域（Domain）逻辑有关，很多时候，也将业务逻辑层称为领域层。业务逻辑层在体系架构中的位置很关键，它处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。由于层是一种弱耦合结构，层与层之间的依赖是向下的，底层对于上层而言是“无知”的，改变上层的设计对于其调用的底层而言没有任何影响。如果在分层设计时，遵循了面向接口设计的思想，那么这种向下的依赖也应该是一种弱依赖关系。因而在不改变接口定义的前提下，理想的分层式架构，应该是一个支持可抽取、可替换的“抽屉”式架构。正因为如此，业务逻辑层的设计对于一个支持可扩展的架构尤为关键，因为它扮演了两个不同的角色。对于数据访问层而言，它是调用者；对于表示层而言，它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上，如何实现依赖关系的解耦，则是除了实现业务逻辑之外留给设计师的任务。
·表示层：
位于最外层（最上层），离用户最近。用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。主要表示WEB方式,也可以表示成WINFORM方式,WEB方式也可以表现成:aspx, 如果逻辑层相当强大和完善,无论表现层如何定义和更改,逻辑层都能完善地提供服务。
4.3 系统主要业务流程设计
图4.2 业务流程图
4.4 功能模块划分
功能模块划分如下图所示：
图4.3 功能模块划分
4.4.1. 模块一描述
|
模块名称 |
模块功能（职责）概述 |
|
UI模块 |
该模块用户可见，是系统和用户之间进行交互和信息交换的媒介，它实现信息的内部形式与人类可以接受形式之间的转换。 |
|
系统管理模块 |
该模块是整个系统核心，它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计 |
|
数据库模块 |
数据库是“按照数据结构来组织、存储和管理数据的仓库”用来收集用户所填信息，注册信息及一切有关数据，对系统提供数据支持 |
4.4.2. 模块一接口设计
接口的变化，对于外部的表现来看，无非是输入和输出的变化，在实际的软件工程中，由于需求的变更，软件功能和规格的变化，接口的变化也在所难免，如何将修改的影响降低，在设计中还是有些方法来使用。
·应对输入变化的场景：
（1）尽量不要用参数的个数来变化；
（2）C语言中接口使用数据结构的变化来保证接口的兼容性；
（3）使用无值型的指针，通过强制转换来适应不同的结构体，同样保证了接口的兼容性，接口参数使用字符串，通过规范字符串的格式来进行不同参数的修改和传递，保证接口不变化，有点类似数据结构的方式，URL字串使用就是典型的方式。
·应对输出变化的场景：
（1）返回数据的定义需要进行规范，常用的方式是返回错误码；
（2）返回数据指针；
（3）返回数据结构/类。
5. 数据库设计概述
5.1 数据库环境说明
MySQL是一种关系型数据库管理系统，关系型数据库将数据保存在不同的表中，而不是将所有数据放在一个大仓库内，这样就增加了速度并提高了灵活性。这次采用的是开发设计工具是MySQL 8.0版本。
特点：
· 开源
· 支持大型的数据库
· 使用标准的SQL数据库语言形式
· 可以运行于多个系统上，并且支持多种语言
· 对PHP有很好的支持
· 可以定制
5.2系统概念架构设计
基于用例模型创建系统概念模型，创建实体类类图。
|
government |
|
-account:int -password:int |
|
+printInfo():void |
|
ts(teachers and students) |
|
+Id:int +name:string +sex:string +phone number:string +e-mail:string |
|
+printInfo():void |
|
questionnaire |
|
-type ：string +option：string |
|
+printInfo():void |
5.2 数据库逻辑架构设计
根据系统概念模型，以及根据需求分析和系统逻辑架构，进行数据库逻辑架构设计。
图5.1政府人员E-R图
图5.2问卷系统E-R图
图5.3师生E-R图
政府人员主要是问卷的设计及发布者，以及能够得到问卷反馈的信息的人。
高校授课老师和学生是问卷的填写人员，在规定时间内完成问卷的填写并提交问卷。问卷系统是数据库的一个模型，主要区分问卷类型，问卷的发布者登录系统从而发布具体类型的问卷，而发布的问卷由师生填写完毕后反馈给政府人员，整体体关系由E-R图展示如下。
图5.4概念模型关系图
5.3 表汇总说明
|
表汇总 |
用途 |
|
学生信息表 |
用于存储高校学生的各种信息，如学生的学校，学号，专业，姓名等。 |
|
教师信息表 |
用于存储高校教师的各种信息，如老师的姓名，所属学校，教职工号等。 |
|
用户信息表 |
用于存储用户的个人账户信息，如用户的账号，密码，个人信息等。 |
|
管理员信息表 |
用于记录管理员的个人账户信息，如管理员的账号，密码，个人信息等。 |
6. 用户界面设计
图6.1 登陆界面
图6.2 功能选择界面
