基于三层架构的We b模式高校疫情管理系统设计

2015-06-05王亚妮

三门峡职业技术学院学报 2015年2期

关键词：系统管理员管理系统服务器

◎王亚妮

(陕西科技大学信息与网络管理中心，西安712000)

基于三层架构的We b模式高校疫情管理系统设计

◎王亚妮

(陕西科技大学信息与网络管理中心，西安712000)

通过解析系统软件架构的实现方法，详细阐述了基于三层架构的Web模式高校疫情管理系统设计的思路和方法，以此促使有关人员在高校疫情发生时，能够及时掌握全面情况，并做出有效决策，从而将疫情影响降低到最小状态。

三层架构；高校；管理系统；设计

引言

高校是人口密度相对较大的单位，人群流动性高，在突发疫情时，校方需要及时、准确地掌握疫情范围、疫情状态、隔离措施、服务人员等情况，通过Web模式的高校疫情管理系统，能够促使有关人员及时掌握全面情况，为正确的决策提供数据支持。因此，设计Web模式高校疫情管理系统显得十分重要。

1 .需求分析

通过对部分高校进行调查，获取到高校在疫情突发时运行机制的实际情况，在认真对高校疫情管控机制数据流分析的基础上，高校疫情管理系统需要实现基础数据管理、部门管理、用户管理、疫情上报管理、公告管理功能。

1.1 基础数据管理

基础数据管理实现由系统管理员进行的系统参数管理、系统风格管理、疫情基础数据管理三个功能。

系统参数管理，实现对注册系统使用单位、上传Logo、域名、敏感词语等管理功能[1]。系统风格管理，实现对系统整体风格的设置管理。疫情基础数据管理，实现对疫情的名称、发现时间、发现地点、发现人、接收报告人等管理。

1.2 部门管理

部门管理，实现由系统管理员进行的部门类型管理、部门信息管理功能。考虑到部分高校有二级学院，所以需要部门类型管理。部门信息管理，实现对部门名称、办公地点、办公电话、负责人、负责人电话等管理。

1.3 用户管理

用户管理，实现由系统管理员进行的用户角色管理、用户信息管理功能。用户角色管理，实现对系统用户种类和权限管理，用户角色包括系统管理员、部门疫情上报者、部门疫情审核者、公告发布者、公告审核者。

1.4 疫情上报管理

疫情上报管理，实现由系统管理员进行疫情上报流程管理、疫情上报者管理、疫情审核者管理、疫情上报管理、疫情汇总分析管理功能。

由于各个高校各级行政管理机构设置不同，所以疫情上报流程也有差别，实现疫情上报流程管理是为了使本系统适用于高校的复杂情况。系统管理员可对各部门的疫情上报者的所在部门、姓名、电话等信息进行管理。上报者上报疫情时，系统会自动记录上报时间、上报者、上报内容等内容。疫情上报者上报疫情后，系统并不能显示疫情信息，只有部门疫情审核者对疫情信息审核后，才能显示出来，此时审核者可直接发布疫情公告到公告栏，默认公告已通过审核。

1.5 公告管理

公告管理，实现由系统管理员进行公告发布者管理、公告审核权限管理、公告发布管理功能。设计公告栏的目的主要是为了方便高校各级人员及时了解疫情发展情况，稳定人心，所以公告发布者发布的疫情信息，要经过专门的审核者进行审核才能在公告栏中显示。

2 .系统设计

系统设计主要从系统运行环境、数据库设计、系统架构和系统功能性设计四个方面进行阐述。

2.1 系统运行环境

由于高校疫情管理系统是一个相对独立的信息管理系统，最好架设单独的服务器，Web服务器和数据库服务器可分设到两台服务器上，也可合并到一台独立的服务器上。服务器硬件配置环境（见表1）：

需要说明的是，客户端要求能通过互联网访问Web服务器就可以了，并不做更高的要求。服务器和客户端软件环境（见表2）：

表1 服务器硬件配置环境

表2 服务器和客户端软件环境

2.2 数据库设计

2.2.1 数据库逻辑设计[2]

通过对用户需求分析，可以确定系统的主要实体为：系统参数、疫情、部门类型、部门、角色、用户、公告等。系统参数实体属性：系统使用单位、Logo、域名、敏感词汇。疫情实体属性：疫情名称、症状、发现时间、发现人、发现地点、上报人、上报时间、接收报告人。由于篇幅所限，其他实体不再列出。

2.2.2 数据物理设计

尽管数据库不区分大小写，但为了提高易读性，设计数据库、数据表和列名时，采用了匈牙利命名方法，也就是说每个单词的首字母都要大写。

数据库名称定义为：EpidemicMS_DB，要求创建数据库时，存放在除了逻辑驱动器C以外的其他分区[3]，这样做的好处在于数据库文件不受数据库服务器操作系统的影响。主数据库文件名为EpidemicMS_DB.mdf，初始大小为10MB，增量为1MB，增长不受限制；日志文件名为EpidemicMS_DB. ldf，增量为5%，最大限制为1024MB。

主要数据表如表3所示：

2.3 系统软件架构设计[4]

系统拟采用经典的三层架构[5]，数据访问层为EpidemicDAL，业务逻辑层为EpidemicBLL，表示层为EpidemicWeb，实体类项目为Models，对数据库的操作借助了微软公司提供的经典的数据库访问助手SQLHelper，它所在的项目是DBHelper，从逻辑上属于数据访问层，所有的跨越三层的公共方法存放在Common类项目中。

项目之间的依赖关系为：表示层EpidemicWeb依赖业务逻辑层EpidemicBLL、实体类项目Models、公共类项目Common。业务逻辑层EpidemicBLL依赖数据访问层EpidemicDAL、实体类项目Models、公共类项目Common。数据访问层EpidemicDAL依赖DBHelper项目、实体类项目Models、公共类项目Common。实体类项目Models和公共类项目Common不依赖于任何项目。

2.4 系统功能性设计

2.4.1 系统参数管理设计

系统数据管理功能用于对系统使用单位、上传Logo、域名、敏感词语的管理。

系统参数管理使用管理员的后台管理页面AdminSysParameter.asp的类中的Register()方法保存参数到数据库中[6]，此方法在保存参数按钮的事件被调用，执行结果返回系统参数列表。页面加载时，在相应的Load事件中，读取系统参数，如果读取出来就显示在相应的控件中。

2.4.2 疫情上报流程管理设计

疫情上报流程管理功能用于对疫情上报、疫情审核、疫情公告工作流程的管理。这是系统的重要功能，是高校疫情管理的关键环节。疫情上报流程是否科学、合理直接影响着疫情上报速度、疫情防范措施，在很大程度上也影响着领导的决策。

发现疫情的人登录系统后，打开疫情上报页面Report.aspx，填写疫情表现的症状、疫情名称、发现时间、发现地点等内容，填写完毕后单击提交按钮，触发提交事件，在提交事件调用Submit()方法，将疫情信息上报到部门审核人员。