0 引言

随着信息化技术的迅猛发展, 为了提升研究生管理的质量, 全国高等院校都搭建了符合各自研究生管理业务规范的研究生信息系统^[1].近几年来, 随着教育部对研究生招生与培养等政策的不断调整^[2-3], 以及高校研究生招生规模的不断扩大, 原有的研究生管理业务也随之发生了大量的变化与调整.华东师范大学(简称华东师大)于2005年开始构建现有的研究生系统, 前后经历了三期历时6年的系统研发.在系统开发之初在校研究生数量为7千人左右, 而目前已达1万6千人, 并且专业学位的学生数量和种类增加迅速, 系统业务量也随之增大.随着研究生管理制度的不断完善和管理需求的不断变化, 当初系统的功能设计的局限性和各种弊端逐渐暴露出来, 给日常的研究生管理工作带来了很大的影响.经调研, 华东师大现有研究生信息系统存在如下问题:

$\bullet$元数据和学籍模型不完整或缺失, 很难便利地与国家研招网和学信网等进行信息交换, 不得不依赖大量的手工数据映射和数据补全等操作来完成国家教育部所要求的研究生管理业务;

$\bullet$不提供对学籍异动的申请与流程审批管理;

$\bullet$不提供基于业务可配置的角色权限管理, 无法灵活地为各个院系负责不同年级或专业的研究生秘书或分管领导配置相应的权限;

$\bullet$缺乏与华东师大其他职能部门之间的信息交换接口, 不仅无法提供准确的统计数据, 而且也无法为现有的新业务场景提供数据分析与报表等功能, 需要研究生院的管理人员直接在数据库上编写SQL统计查询;

$\bullet$招生系统、学籍系统、培养系统和学位系统的功能界面和交互设计各异, 完成一个业务需要多步操作, 信息查询与更新的响应速度慢, 浏览器的兼容性差;

$\bullet$不支持移动端的业务与信息访问.

基于上述分析, 可以看出:从业务角度来看, 现有的研究生院信息系统已经无法有效地支持从国家教育部到华东师大自身研究生管理的新需求, 造成了大量的信息缺失与不一致, 使得研究生院教职工不得不花费大量的时间与精力以人工辅助的方式完成研究生的信息维护与业务流程管理; 从技术角度来看, 与现代基于移动互联的系统设计思维^[4-5]相比, 现在使用的研究生院信息系统所采用的系统框架与软件产品比较落后, 这在现实使用中带来了诸如用户体验差, 系统响应速度缓慢以及浏览器兼容性差等问题.因此, 无论从业务角度还是技术角度, 研究生院必须以新业务需求为导向, 基于互联网时代的一些先进软件设计理念, 采用能满足一定业务流变更的系统框架, 实现信息系统的换代, 达到提升系统效率和降低运维成本的目标.

经过充分调研, 华东师大于2016年8月组建了研发团队, 依托与印孚瑟斯技术中国有限公司联合成立的实验室项目, 采用自主研发模式, 启动了下一代信息平台的研发.本文重点研究如何将基于Web 3.0的技术框架应用于华东师大研究生院的学籍业务中, 支持基于传统PC端浏览器和移动端的研究生管理, 使得全校师生可以随时随地访问与学籍相关的业务.目前新一代学籍系统正处于上线测试阶段, 覆盖了现有研究生院学籍管理的大部分业务规范.具体而言, 本文主要工作如下:

第一, 重新梳理了华东师大研究生院的学籍业务需求, 在学籍子系统中增加了元数据和学籍异动管理, 提供了与其他职能部门进行信息交互的数据接口, 完善了角色与权限管理, 使得学籍管理员可以方便地为负责不同年级和专业的研究生秘书配置相应的业务;

第二, 基于AngularJS与Bootstrap重新设计系统功能界面和用户交互模式, 不仅支持基于传统PC端浏览器的访问, 而且还允许教职工和研究生通过移动端实现随时随地的访问学籍业务, 达到了改善用户体验和改善浏览器兼容性的目标;

第三, 基于Spring Boot框架实现了基于RESTful接口的业务逻辑, 不仅便于实现当前学籍业务的研发以及未来业务功能升级和改造, 还通过Spring Boot提供的各种组件(如安全组件, 缓存组件和数据访问组件等)达到提升系统性能的目标.

1 相关工作

随着IT技术的发展, 信息管理系统主要经历了三种架构模式.第一种是客户端/服务器(C/S)架构^[6], 主要涉及到瘦客户端与胖客户端的设计, 中间件和基于组件的设计, 以及基于可视化组件拖拽为主的开发模式, 采用的典型开发语言和框架包括Dephi的PowerBuilder, 微软的VB或MFC等基于C/S的信息管理系统.

随着互联网技术的兴起^[7], 出现了基于浏览器/服务器(B/S)技术架构的信息系统^[8-9], 如微软的ASP技术, J2EE, JSP, Ajax和Web服务与框架等技术.近几年, 随着JavaScript语言和浏览器内核技术的成熟与壮大, 甚至出现了基于Chrome V8引擎的服务器框架, 这极大地促进了基于B/S架构的开源框架的发展.例如, 前端的流行框架包括Reative, AngularJS和NodeJS, 而后端的流行框架则有Spring Boot, Django和Struts2.

随着智能手机的普及和移动互联网的兴起, 传统的信息系统正在向基于移动端的方向发展.除了采用Android和iOS的手机应用开发模式, HTML5的出现有希望将更多信息管理系统的前端推向移动端, 使得终端用户可以随时随地的办公或访问系统服务.不同于传统基于C/S架构或基于B/S架构的信息管理系统, 新的研究生学籍系统充分考虑到未来面向移动端的业务实现^[10-11], 采用了基于AngularJS前端框架和基于HTML5的自适应屏幕的Bootstrap风格样式, 使得研究生、研究生院和各个院系的管理人员可以方便地使用手机上的浏览器来访问学籍系统的各种服务, 这将会给研究生管理业务的使用提供极大的便利.

2 业务设计

新一代华东师大研究生院信息系统的第一期研发工作主要是依据新的学籍业务需求, 在统一信息平台之上重构现有学籍子系统, 为招生子系统、培养子系统和学位子系统的系统重构与迁移进行技术验证. 图 1展示了学籍子系统的四个主要业务功能模块:新生模块, 在校生模块, 异动模块和毕(结)业模块.

2.1 新生模块和在校生模块

对于新生而言, 每年暑期研招办会对招生系统中的研究生信息进行学号编制, 以及基于学籍系统的元数据对相关的招生数据进行转换后, 批量导入到学籍系统中, 完成新生学籍入库的操作.接下来, 在新生入学之后, 研究生院会要求所有新生完成两个基本入学操作:入学测试和个人信息修改.其中, 入学测试会以问卷的形式帮助新生了解华东师大的一些基本学籍管理规定(例如, 如何申请转专业等学籍异动的申请以及相应的申请条件), 而个人信息修改则是帮助新生完善个人学籍信息.在入学测试和个人信息修改都完成后, 学籍管理员会在新生入学后的90 d内完成新生的入籍操作, 将符合入籍条件的新生转为正式在校生.

另一方面, 新生模块和在校生模块会共用学籍注册, 刷卡报到与缴费三种操作.对于每个研究生而言, 如果不能顺利完成学籍注册, 则无法在培养系统中进行选课等操作.具体而言, 研究生(包括新生和在校生)每学年都必须缴纳学费, 学籍系统每年会从财务处把缴费信息导入学籍系统, 每学期会从信息办把刷卡报到信息导入学籍系统; 如果完成了刷卡报到和缴费这两个操作, 才算完成了学籍注册.此外, 对于一些特殊情况, 学籍系统允许学籍管理员或者院系秘书进行手工学籍注册操作.需要注意的是, 学工部每年会提供一个助困生名单, 学籍系统会对助困生提供一个绿色注册通道.

相比于现有的学籍系统, 新系统的优点主要包括三方面:第一, 新系统提供了丰富的数据接口, 便于与其他职能部门之间的数据交换; 第二, 基于新的业务需求, 新系统提供了入学测试与正式入籍等功能, 旨在改善新生入籍管理; 第三, 由于新生导入是学籍系统的入口点, 新系统完善了全部学籍业务的元数据, 达到了提升学籍信息质量的目标.

2.2 学籍异动模块

现有的研究生院学籍系统不具备学籍异动的业务功能, 主要原因是当时的学籍异动业务管理仅支持少数常见类型(如休学等)且无法支持基于流程的审批模式.此外, 借鉴教育部学信网和其他兄弟院校的学籍异动管理, 华东师大研究生院已经完成了新版学籍异动的业务管理规范, 且对于每一种学籍异动都规定了申请条件和审批流程.

在学籍异动的业务调研中, 我们发现三个重要的功能需求:第一, 异动审批流程会随着业务需求的变化而相应的调整.例如, 转专业的异动审批流程可能会从两个步骤变成三个步骤.第二, 异动审批流程与角色权限管理联系紧密.例如, 异动审批流程的每一步都需配置不同的审批角色, 且不同角色的用户仅能审批该角色所定义的审批范围(即该角色可以查看并审批哪些院系研究生的异动申请).第三, 新系统必须提供方便的查询接口使得申请人和审批人可以随时随地的查询审批进度.

基于上述需求, 新系统必须为每一种学籍异动类型提供对应的可配置的流程管理, 能够实时查询申请的审批进度, 便于申请者与中间环节的审批者了解审批的整体进展状况.具体而言, 新系统的异动模块包含学籍异动的审批流程配置和异动审批两部分功能.

2.2.1 流程配置

学籍异动的审批流程配置主要包括异动类型配置和审批步骤配置. 图 2展示了学籍异动的审批流程配置图.

对于异动类型配置而言, 学籍异动分为异动大类和异动小类, 即每种异动大类可以包括若干种异动小类.新系统包括延期、休学、复学、退学、结业和肄业等17种常见大类.对于延期来说, 异动小类包含硕士延期和博士延期, 复学包含休学复学和推迟入学复学, 其他异动大类也类似, 系统中总共包含了28种小类.

对于审批步骤配置而言, 新系统允许学籍管理员根据大类和小类为每个具体的学籍异动配置审批步骤, 可以依据未来的业务变更对已有的审批流程进行增加或者删除审批步骤的操作, 并对审批人的角色和权限进行配置(即配置审批属性).

2.2.2 异动审批

图 3展示了一种异动审批流程的泳道图.从图中我们可以看出不同的审批阶段需要不同角色和权限的用户对学籍异动申请进行浏览并执行相应的审批操作.

例如, 一名研究生首先发起一个学籍异动的申请, 然后系统会通知该研究生所在的院系秘书; 院系秘书执行审批操作并提交审批理由后, 系统会通知申请者当前审批状态.如果院系秘书否决了该申请, 审批立即终止; 如果审批通过, 则该申请会被系统提交到下一个审批环节, 即被系统推送给该院系的分管领导, 院系分管领导可以查阅院系秘书的审批意见以及申请人的申请理由执行审批操作.如果审批通过, 系统则将该申请继续推送给下一阶段的审批人, 即学籍管理员; 如果审批未通过, 则系统会通知申请人审批被否决及其原因.学籍管理员是整个异动审批流程的最后一个步骤, 与前两级的审批流程一样, 学籍管理员会参考申请人申请理由, 以及院系秘书和院系分管领导的审批理由后进行审批; 如果通过, 该学籍异动申请最终顺利通过; 否则, 将驳回申请的状态并将理由反馈给申请人.

2.3 毕(结)业与离校模块

毕(结)业模块包括预毕(结)业和离校两个业务功能.对于预毕(结)业, 学籍系统会对符合毕(结)业条件的研究生提前半年开放学籍信息审核的功能页面, 便于这些研究生提前对个人学籍信息中的重要信息(如身份证号)进行核实确认.一旦发现任何学籍信息的错误, 研究生可以通过提交学籍信息的变更申请, 通过学籍管理员的审核, 以流程审批的模式完成学籍信息的变更操作.对于处于毕业离校状态的研究生, 学籍系统会为华东师大各个职能部门提供研究生的离校状态审核操作.例如, 图书馆会审核每个申请毕业离校的研究生是否已经完成了借阅图书的归还操作:如果完成了, 则会同意其离校申请; 否则, 系统会帮助图书馆管理员通知该研究生归还所借图书.每个申请毕业离校的研究生都可以查询各个职能部门的离校审批状态和通知, 以便于了解自己的离校手续办理进度.

相比于现有的学籍系统, 新系统的优点主要包括两方面:第一, 新系统实现了基于信息平台提供的流程引擎的预毕(结)业和离校的流程申请与审批, 使得学籍管理员能够依据业务需求的变更, 通过新系统提供的流程配置快速实现业务功能变更; 第二, 预毕(结)业允许学籍管理员根据每年教育部的要求对不同类型的学籍信息设置相应的流程审批操作, 使得新系统可以在不改变任何代码的情况下, 实现审批流程的变更操作.

3 系统架构

新一代华东师大研究生院信息系统采用了基于浏览器/服务器(B/S)的系统架构, 如图 4所示, 主要分为负载均衡器, 前端展示层, 业务逻辑层以及数据库.对于前端展示层和业务逻辑层之间, 系统采用基于JSON数据格式的RESTful接口机制, 通过面向契约的软件设计原则, 实现了前后端开发的分离, 使开发人员在修改前端展示风格的同时无需担心对后端业务逻辑的影响.

在系统研发中, Web前端采用了谷歌AngularJS框架和Bootstrap风格样式, 后端应用采用了Spring Boot框架来实现具体业务逻辑, 而业务数据则存储在关系模型中.在实际部署中, 采用Nginx服务器作为整个系统的访问入口, 按照前端展示层与后端业务逻辑层的实际负载情况来处理访问请求, 并结合基于Docker^[12]的应用部署模式, 有效地实现了系统处理能力的水平扩展.具体而言, Nginx首先会接受每个用户访问请求, 并将该请求路由给当前工作负载最低的Web前端服务器; Web前端服务器分析并验证用户请求是否有效, 然后调用业务逻辑的RESTful接口; 基于安全性考虑, 业务逻辑服务器会分析并再次验证从Web前端发过来的请求, 调用相应的业务逻辑并将结果以JSON格式返回给Web前端; Nginx最后把Web前端的展示结果返回给用户.

3.1 负载均衡层

负载均衡是改善系统响应吞吐量和速度的有效途径, 而且通过负载均衡器的访问请求日志还可以记录用户访问系统的行为, 再结合ELK等开源日志分析框架, 可以进一步解决系统访问优化等问题.在实现中, 我们采用了开源的Nginx负载均衡器, 结合基于Docker的应用部署模式, 使得每个访问的系统的请求都可以被路由给当前负载最轻的服务器, 达到提升响应速度的目的.此外, 基于Nginx还可以很方便的增加或减少Docker实例, 帮助系统方便的实现按需的水平扩展.

3.2 前端展示层

前端展示层采用了Google的AngularJS框架, 主要原因是AngularJS框架对Web服务开发的组件支持, 以及采用了MVVM的编程模式. AngularJS是基于JavaScript构建的一套优秀的开源Web应用程序框架, 可以有效地改进前端代码的开发质量和维护成本, 加速软件开发周期.另一方面, 在展示风格方面, 系统采用了Bootstrap, 使得基于AngularJS的前端展示层页面不但拥有良好的浏览器兼容性, 还可以方便的支持移动端的浏览器, 解决了现有学籍系统的浏览器兼容性差的问题. 图 5展示了新系统的主界面, 包括常用功能, 学籍管理, 培养管理和系统管理.

3.3 业务逻辑层

对于业务逻辑层, 本系统采用Spring Boot的后台框架构建基于RESTFUL的Web服务, Spring Boot框架为各种领域提供了各种通用组件, 如安全组件, 数据访问组件, 会话管理组件等.这些组件不仅保证了系统开发的敏捷性, 保证了系统服务与功能的高可靠性和高扩展性^[7], 同时还考虑了实际部署的便捷性.采用面向数据接口的编程模式, 使得前端和后端的服务完全分开.方便开发人员更好的设计和开发浏览器和移动端的展示与功能.

对于用户认证与权限管理, 系统采用了基于Spring Security的安全模型, 通过单点登录(SSO), 可以有效地支持华东师大校园统一用户身份认证以及用户权限管控, 使得整个系统具备高可靠和高安全性.对于权限控制方面, 既要实现对各业务系统的统一授权管理, 降低权限管理模块与各业务系统之间的耦合度, 同时还要实现对权限的粒度控制.系统为学籍管理员提供了权限管理模块来帮助管理员定义不同的角色, 以及为每个角色定义可以信息访问范围, 即可以访问哪些院系和专业的研究生.

3.4 数据的访问

新系统采用Oracle的MySQL关系型数据库作为学籍数据的存储系统.在实现中, 我们采用了Spring Data JPA组件以ORM(对象关系映射)的开发模式, 不仅可以有效地以基于实体对象的模式对数据表进行各种操作, 而且还可以通过懒加载等优化策略和基于Redis的缓存机制来缓存各种元数据以减少不必要的数据库访问请求.

4 系统实现

本节将以学籍异动流程管理为案例, 对学籍业务系统的设计与实现进行详细说明.由于篇幅所限, 对其他功能模块的设计与实现不做介绍.

4.1 学籍异动模型

学籍异动流程管理要求系统为学籍管理员提供为每一个学籍异动类型设置审批流程的功能界面, 这存在三个技术挑战.第一, 审批流程的步骤可以随需增加或减少; 第二, 每一步审批流程的审批人需要按照角色进行配置; 第三, 不同类型的异动申请在最终通过后, 该申请需要按照学籍异动管理规范更新学籍表中相关的字段值.对于前两个需求, 我们设计了图 6所示的学籍异动ER图; 对于最后一个需求, 目前我们采用了硬编码的模式, 在未来会对这一步采用配置文件的方式以适应未来业务变化的需求.

从图 6中可以看到, 学籍异动模型的实现由两个实体类AuditRecord(审批记录)和ApplyRequest(异动申请)组成, 其中ApplyRequest类的每个实例对应于研究生的每个具体的学籍异动申请, 包括了学生申请学籍异动时的各种申请条件: applyDate(申请日期), reason(申请理由), auditState(审批状态)和editable(学生是否可以修改申请); AuditRecord类的每个实例则用于存放审批过程及其每个步骤的审批状态, 包括每个异动申请(auditRequestID), 该申请的审批流程的每步审批的标识(auditStepID), 审批人(auditor), 审批日期(auditDate), 审批理由(comment)和每个审批步骤的审批状态(auditState). AuditRecord和ApplyRequest之间的关系为多对一, 即对于每一个学籍异动的申请实例, 会有多个不同部门的人员对该申请的不同步骤进行审批, 且每个部门的审核结果都会生成一条审核记录, 从而也就会生成多条审核记录.

为了实现学籍异动的可配置性, 即依据不同类别的学籍异动提供可配置的异动流程管理, 学籍异动模型又在实体类AuditRecord和ApplyRequest的基础上增加了用于配置审批流程的实体类AuditFlowStep(审批步骤). AuditRecord和AuditFlowStep之间的关系为多对一, 即同一个审批步骤可以对应多条审批记录.这种设计的好处在于最大程度的复用不同学籍异动审批流程中相同的审批步骤.

最后, 对于一名发起申请学籍异动的研究生而言, 系统通过实体类StudentApplyRequest(学籍异动申请)记录该申请, 以及具体的异动类型; 而实体类StateChangeRequest则定义了学籍系统中提供了哪些类型的学籍异动, 并供研究生在申请学籍异动时通过Web功能界面进行选择.

4.2 学籍异动流程管理

对于学籍异动模型的实现分为两部分: Web功能界面和业务逻辑.对于业务逻辑的实现, 系统采用了Spring Boot提供的Data JPA组件实现了相应的实体类.采用Spring Data JPA的好处在于:第一, Spring Boot可以自动将实体类转换为对应的关系表, 并在数据库中将这些表创建出来; 第二, 通过扩展Spring Data JPA的数据访问接口的模式, 可以很方便的增加自定义的数据访问接口, 并通过基于实体类的中间查询语言实现基于分页等数据库查询, 而不需要像传统的编程方式一样书写大量数据访问代码, 不仅大大地提升了开发效率, 而且使得数据访问接口独立于不同厂商提供的数据库系统, 便于在不同的关系数据库系统之间进行迁移.

对于Web功能界面, 我们实现了如图 7和图 8所示的学籍异动流程管理, 其中图 7为学籍异动申请流程的配置界面, 而图 8则展示了一个处于审批中的申请示例.基于学籍异动模型, 流程配置引擎可以为每一种类别的学籍异动申请设置具体的审批流程, 其中每一步审批都包括审批序号, 显示名称, 拒绝策略, 审批角色, 步骤可选和默认理由.

审批序号定义了当前审批步骤在审批流程中的审批顺序.多个审批步骤可以具有相同的审批序号, 这是因为在实际的学籍异动审批流程中, 同一院系中可能存在多个角色的教职工都可以审批该申请且只需要一个教职工审批通过后, 该申请即可进入到下一个审批步骤.此外, 如果步骤可选的取值为假, 则表明当前步骤必须通过审批流程才能进入下一序号对应的审批步骤; 否则, 同一序号中只要有一个通过流程即进入下一序号.步骤可选是学籍异动模型的新颖之处, 其便捷之处在于, 对于拥有相同审批序号的审批步骤, 可以由一个或多个职能部门进行审批, 既增加了审批的灵活性, 同时又可以将审批业务分配给多个教职工, 实现业务负载均衡.

显示名称规定了申请人在查看当前审批状态时所能看到的名称, 可以使用单位或者部门名称.拒绝策略包括:学生修改重新审批、拒绝申请和允许拒绝, 其中学生修改重新审批规定了如果申请被拒绝, 申请人可以修改已有申请并提交审批, 审批重新开启.拒绝申请规定了申请被审批人拒绝以后, 整个审批流程终止, 允许拒绝是一种待审批状态, 申请者被拒绝并重新提交申请后无需从头开始审批, 直接提交到之前拒绝的角色下继续审批.审批角色定义了审批人的所属角色, 包括常见的导师, 学籍管理员等; 默认理由的设置方便管理员预先设置好常用的审批理由, 避免审批时输入审批理由, 提升了系统易用性.

综上所述, 可配置学籍异动流程管理可以满足华东师大研究生院潜在的业务需求变更, 在最大程度上解耦业务变化与系统实现.对于其他业务流程管理, 如预毕(结)业和离校, 我们也采用了相似的模型设计, 以应对研究生管理系统中的业务变更需求.

5 实验

性能测试环境为一台Centos7服务器, 配备了8个主频为2.40 GHz的Intel Xeon CPU E5-2630芯片, 内存为16 GB, 磁盘容量为4 TB, 转速为7 200 r/s.实验数据包括华东师大40 000名研究生的学籍信息, 以及华东师大一部分教职工的账号(约600名).

我们测试了七种不同访问请求的响应时间:用户登录, 激活角色, 获取授权页面, 获取用户角色, 获取角色列表, 学生分页查询与单个学生查询.之所以选取上述七种访问请求是因为这些请求类型是系统最常处理的请求, 具备代表性, 能反映出系统的真实业务处理水平.在实验中, 每种访问请求被随机执行了10次, 实验结果为10次访问请求的平均响应时间. 图 9展示了对于实验中不同请求的响应时间.从实验结果中可以看到, 不同访问请求的响应时间基本维持在100 ms以内, 确保了用户访问系统服务的良好体验.

6 结论

从业务设计角度来看, 新一代研究生院信息系统充分考虑了新的学籍业务需求, 旨在解决现有研究生院系统不支持学籍异动功能, 用户体验不好, 以及浏览器兼容性差等问题; 从系统设计与实现角度看, 新一代研究生院信息系统首先采用了基于负载均衡与Docker部署的B/S系统架构, 通过基于JSON数据格式的RESTful服务设计原则, 使得Web前端与后端服务的设计与开发相分离; 其次, Web前端采用了基于AngularJS框架和Bootstrap样式的开发模式, 使得系统不仅支持PC端的浏览器, 而且还支持移动端的自适应访问; 再次, 后端业务逻辑采用Spring Boot框架, 通过数据访问组件和安全组件, 不仅简化了业务逻辑的开发与维护, 而且还实现了基于Docker部署的敏捷开发和部署.

目前新系统还处于上线测试阶段, 基于院系秘书和学籍管理员的实际测试反馈, 新的学籍系统在用户体验和业务功能等方面性能良好, 可以有效地改善基于华东师大签报系统的学籍异动管理所面临的无法定义审批流程, 以及系统响应速度慢等问题.此外, 新系统还充分考虑了与华东师大其他职能部门之间的数据交换问题, 设计了丰富的数据访问接口, 极大地方便了研究生院与信息办、学工部和财务处之间的信息共享.