摘 要:学生学籍管理一直是高校教务管理的重点。介绍了高校学生学籍管理信息系统设计的一种方案。首先分析了c/s、b/s两种管理模式的各自特点,进而提出了c/s、b/s两种模式交叉并用的学生学籍管理信息系统的设计思想和结构形式,并具体介绍了该系统在高校学生学籍管理当中的应用,以及如何做好系统的维护工作。
关键词:高校;学生学籍管理信息系统;c/s模式;b/s模式
1 系统平台模式的分析
1.1 c/s模式
c/s模式(client/server),是由客户机与服务器合作完成的二层结构系统平台模式, 在c/s环境中,表示层与功能层包括显示逻辑和事物处理逻辑部分被放在客户端,而资料层包括数据处理逻辑和数据库放在服务器端。
在c/s 模式中, 由服务器承担对数据库的全面管理, 在客户机和服务器上各自运行应用程序,这种模式的优点主要有以下几点:(1) 因为在客户端上有一套完整的系统软件,具有很强的交互性,系统工作人员在运用系统时可以获得出错提示、在线帮助等较强功能;(2)由于c/s 模式是配对的点对点的结构模式,因此多采用局域网的协议,并且通常是学校内部固定的从事学生学籍管理工作的用户群,所以安全性较高;(3) 因为c/s 模式只有两层逻辑结构,因此网络通讯量低,传输速度快,占用网络资源少。但c/s模式的缺点同样明显,主要是以下几点:(1) 因为每个客户端都要安装该系统软件,不便于维护;(2) 这种模式限制了网上信息的发布,如学生学籍信息、学生成绩、排名查询、教务通知等信息都无法面向全校发布;(3) 伴随着学分制的推行,学生网上选课也是势在必行,c/s模式明显存在缺陷,安装过多的客户端会使得系统不稳定甚至崩溃;(4) 因为教务管理系统环节较多,比较庞大,操作性很强,因此每个客户端上使用该系统软件的教务管理人员还需进行培训。www.lw881.com
1.2 b/s模式
b/s 模式把传统的c/s 模式中的服务器部分分解为一个数据服务器和一个或多个应用服务器(web 服务器), 从而构成一个三层结构的客户服务器体系, 表示层、功能层和资料层被分成三个相对独立的单元。表示层中包括显示逻辑,位于客户端,它的任务是向web服务器提出服务请示,并接受web服务器的主页信息并进行显示;而在功能层中则包含了事务处理逻辑,它位于web服务器端,其任务是接受客户端的请示并与数据库进行连接,向数据服务器提出数据处理请求,并将结果传送到客户端;而处于第三层的资料层则包含了系统的数据处理逻辑,位于数据库服务器上,它接受web服务器对数据进行操作的请求,对数据库进行查询、 修改及更新等, 并将结果提交给web服务器。
采用b/s 模式有着较为突出的优势。(1)在客户端安装的是标准、易用的通用浏览器,无需像c/s 模式那样在不同的客户机上都要安装该系统软件, 对学生学籍管理系统而言, 这就简化了成绩查询、学生信息查询等客户端; (2)b /s 模式的功能都在web 服务器上实现, 使开发和维护工作简单易行;(3)全校教师、学生及其他管理人员, 在校内、校外任何地方,只要可以上网,就可以使用该管理系统,使系统维护的限制因素更少;(4)b /s 模式适用于网上信息发布。但由于b/s 模式采用点对多点、多点对多点的开放结构模式, 因此其弊端也不少,主要表现在以下两个方面。首先,该模式采用tcp/ip这类运用于internet的开放性协议, 其安全性通常依靠数据服务器上管理数据密码的数据库来保证, 因此安全性不高, 这对安全性要求极高的学生学籍管理系统来说是不容小视的; 其次, 由于b/s 模式在逻辑结构上比c/s 模式多一层, 对于相同的任务,b/s 完成的速度较c/s 慢, 不利于处理大量数据。
1.3 c/s和b/s两种模式相结合
通过以上分析可以看到, 在高校学生学籍管理系统中若单独应用c/s 模式或b/s 模式都各有利弊。针对该系统的特殊性与复杂性, 如果在安全性要求高、交互性强、处理数据量大、数据查询灵活且地点固定的小范围内使用c/s 模式, 通过客户端软件访问数据库,例如学籍管理、课表编排、成绩处理等,可在各院系教学单位、教务处各科室等相关管理部门安装客户端程序、各用户凭帐户、密码访问系统;而在安全性和交互性不高、地点灵活的广域范围内使用b/s 模式,例如网上成绩查询、课表查询、网上信息发布、网上选课等,本校学生可以随时随地地通过internet网凭学号和密码访问系统。
充分利用两种模式各自的优势, 为不同的子系统选用不同的系统平台, 构建一种将两种模式交叉并行使用的混合模式。这样可以保证敏感数据的安全性, 特别是对数据库的修改和新增记录的操作;还可以简化一部分客户端程序,保证复杂功能的交互性和一般功能的易用性; 此外, 它还使得系统的维护简便、布局合理且网络效率高。其结构如下图所示:
2 系统主要功能模块及其应用
学籍管理系统由招生管理子系统、校级教务管理子系统、院系级教务管理子系统、学籍管理子系统和排课表子系统组成。在权限的限制下共同实现记录的保存、增加、删除,信息的查询,打印成表输出等功能。各个子系统的功能如下:
2.1 招生管理子系统
该系统主要是制定招生计划,并为整个教务管理系统提供新生数据。它主要提供以下功能:
(1)招生计划的管理:对每年的招生计划进行录入、维护,并可生成和打印有关的报表。
(2)新生数据的管理:对新生信息进行录入、维护,并可按各种条件对新生信息进行查询,另外还可生成、打印有关新生的各种统计报表。
2.2 教务管理子系统
该系统是教务管理人员使用的界面,对学生及教学进行管理,包括以下几个功能模块:
(1)基本信息管理:包括对学生的某些信息进行修改;对教职工信息的录入、维护和查询;在允许注册的时间内,对学生进行注册处理,正常注册的学生置正常标志,非正常注册的学生置非正常标志,并说明原因及处理结果;对已录入的学生信息、教职工信息进行维护时,它们必须是未审查通过的,有审查标志的不能对其修改,也不能将其删除。
(2)教学管理:主要包括对课程及其每门课的先修课程信息进行录入、维护和查询;对各院系、专业的教学计划信息进行录入、维护和查询,教学计划是对学生进行毕业审查的依据;对下学期所要开设的课程及其相关的信息进行录入、维护和查询,它是进行排教室和学生选课的基础;对已录入的课程信息、教学计划信息、开课计划信息进行维护时,它们必须是未审查通过的,有审查标志的不能对其修改,也不能将其删除。
(3)成绩管理:主要包括在规定的成绩录入时间内,对学生成绩进行录入、修改;对学生的毕业论文成绩进行录入和维护;对已录入的学生成绩进行维护时,它们必须是未审查通过的,有审查标志的不能对其修改,也不能将其删除。
(4)查询功能:根据用户所给条件对学生信息、课程信息、教学计划信息、开课计划信息、选课信息等进行查询。
(5)统计报表:提供学生名册、教师名册、学生注册信息、选课分析、教师授课情况、学生成绩分析、学业监控、学位监控等各种统计报表。
2.3 学籍管理子系统
该系统是主管学籍工作人员的工作界面,可以对全校学生的信息进行录入、维护和查询;对学生的异动信息进行录入、维护和查询;还可提供学生异动情况表等各种统计报表的生成和打印功能。
2.4 排课表子系统
该系统主要是为开课计划中所列的每门课程分配上课教室,它包括以下功能:
(1)信息维护:对教学楼、教室等信息进行录入、维护和查询;对申请要教室的课程信息根据教室分配情况进行适当的修改等。
(2)教室分配:可对申请要教室的课程进行批量教室分配处理、单门课程教室分配处理,分配完成后将相应信息送回开课计划中,供院系查询、打印,另外可提供临时借用教室处理等功能。
(3)信息查询:提供对教室资源信息使用情况的查询、统计、打印,课表的查询、打印等功能。
3 系统的安全与管理
由于学生学籍管理系统的开放性,在促进数据信息充分利用和共享的同时,应当防止各种类型的威胁和侵害,采用合理的信息安全技术和体制来保护系统的数据资源是十分必要的。(1)硬件支撑:
选购两台以上服务器,其中一台作为数据库服务器,一台作为web服务器,保证web服务器internet、校园网畅通,而数据库服务器保证校园网畅通、internet禁止连接。这样一方面可以提高系统的效率、加快用户访问速度,另一方面可以保护数据库的安全。(2)网络安全:因为一般学生学籍系统通常会选用microsoft公司的internet information server作为系统的web应用服务器,而它是面向全球未知用户的,因此安全性非常重要。通常采用防火墙技术(firewall),在系统中设立两级防火墙,一级为软件防火墙,另一级为硬件防火墙(可选),确保网络安全,防止黑客破坏。(3)授权管理: 本系统采用二级安全保障。
第一级:依赖于网络本身对用户使用权限的规定;第二级:在程序模块中通过使用密码控制功能,对用户使用权限加以限制。
每学期考试完毕由各系录入成绩,然后由教务科收集。
4 结束语
基于b /s和c/s模式交叉并用的信息系统,的确为高校学生学籍管理工作提供了较好的技术选择。既考虑了b/s 模式的先进性, 又考虑了到c/s 模式的成熟性, 具有较强的实用性。同时这种设计与传统的学生学籍管理系统相比有着较为突出的优点, 不仅能提供方便安全高效的服务, 而且易于系统的维护。
参考文献
[1]黄立新. 某校学生学籍管理系统的设计开发方案[j]. 电力学报, 2006,(03).
[2]李靖,支雅君. 学籍管理系统的设计与实现[j]. 内蒙古科技与经济, 2005,(13).
[3]张澎,刘松梅,孙波. 高校二级学院学生学籍管理信息系统的设计[j]. 西南民族大学学报(自然科学版), 2004,(01).
[4]贺展,刘菲. 基于c/s和b/s模式的高校教务管理信息系统 [j].武汉科技学院学报, 2006,(11).