高校教务管理系统的研究Word文档下载推荐.docx
- 文档编号:4429375
- 上传时间:2023-05-03
- 格式:DOCX
- 页数:64
- 大小:541.39KB
高校教务管理系统的研究Word文档下载推荐.docx
《高校教务管理系统的研究Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《高校教务管理系统的研究Word文档下载推荐.docx(64页珍藏版)》请在冰点文库上搜索。
autogenerationofcurriculumscheduleandthemethodsofhowtodevelop
softwarecomponentinmiddle-tierisgivensimplyinrelationtotheresearch
achievementabroadandhome.
keywords:
Componentmodel;
Entity-Relationshipmodel;
Database;
modeling;
MTScomponent;
Educationaladministation;
Arithmeticofautogenerationofcurriculumschedule.
第一章绪论.......................................................2
1.1来源....................................................3
1.2国内研究成果综述.........................................3
1.3本论文研究的主要内容.....................................3
第二章系统总体设计............................................5
2.1系统分析..................................................5
2.1.1需求陈述........................................5
2.1.2数据流图..........................................6
2.1.3问题域划分.......................................6
2.2系统的网络运行环境....................................11
2.2.1组件模型概述...............................11
2.2.2模型设计.........................................15
第三章数据库的建模原理..........................................17
3.1数据库开发流程.........................................17
3.2数据库的标准化........................................19
3.3数据库的建模原理.........................................21
3.3.1实体一关系建模原理概述...........................22
3.3.2实体一关系建模的局限性............................23
3.3.3用面向对象思想对传统建模方法的改进................24
第四章数据库的建模实现..........................................27
4.1对象之间的关系..........................................28
4.2参照完整性的设计.........................................32
4.3应用逻辑的实现.........................................34
4.4查询模型的设计.........................................36
第五章中间层组件的开发..........................................37
5.1数据库访问技术概述.......................................38
5.2MTS中间层构件的开发原则和实现方法.......................40
5.3Web接口和专用接口的实现.................................42
第六章排课算法初探............................................46
6.1排课规则...............................................46
6.2算法设计............................................47
6.3其他问题的考虑............................................49
第七章课题展望..................................................50
致谢...............................................................51
参考文献.........................................................51
附录............................................................52
第一章绪论
1.1题目来源
从大多数高校目前的教务管理业务流程上来看:
首先,某一年级的总教学计划(在校期间的教学课程和教学进程)由各院教务员按照各学院各学科专业方向提出,主要是必修课或学位课以及任选课的总学分和总学时。
其次,在每一学期开课前一学期由各院教务员根据实际情况添加该学期的教学分计划(从审核后的总教学计划提取),主要补充院级任选课或非学位课。
最后,审核后的教学分计划为该学期的教学任务,即排课的源数据,经资源(上课的时间和教室)的统一分配产生课表。
此外,校级任选课也是在每一学期开课前一学期由各院系向教研科申请,并提交审核后加入选修学生的学期课表中;
校级任选课是单独排课,与教学分计划分开排课,学生每学期的课表因此包含校级选修课课表和由教学任务生成的课表。
在业务中,还包含学生成绩、学籍的管理,教师教学工作量、评估等管理,学生的校级选修课的管理。
但是,目前的操作方式仍然是教务员递交到教研科,教研科汇总后统一录入,审核通过手工校验,工作量太大,数据的完整性也不能得到充分保证。
我校目前采用的教务管理软件,是基于单用户的桌面数据库管理模式,无论是从信息量的存储、数据库的性能上,还是从系统的功能、安全和维护上,不能切合我校的教务管理的日常业务流程。
随着计算机的日益普及,网络的快速发展和数据库的广泛应用,使得利用校园Intranet进行教务管理已成为可能。
不但可以降低工作量、提高办公效率,而且使目前分散的教务信息得到集中管理。
然而,仅仅从某一环节去实现计算机的信息管理并不能解决所有的问题,需要从整个业务流程上考虑,基于三层网络计算体系结构,利用校园网构造我校的教务管理信息系统模型,这样才能做到事务的分布式处理,数据的集中式管理,信息的真正共享。
当然,从计算机诞生的那个时代到依照摩尔定律飞速前进的今天,关于教务管理信息系统的研究也有几十年的历史,但不是一劳永逸。
技术的发展、环境的变化、时代的要求,都为此带来了新的挑战和引起问题的再研究。
1.2国内研究成果综述
关于教务管理系统的研究已经很长时间了,同时也产生了丰硕的成果。
由于教学管理模式的不同,不再介绍国外关于教务管理的研究成果。
在国内,由于各种原因,各高校的教务管理系统都有自身的特点,不尽相同。
条件好的高校,依托校园网,围绕本校教务管理实际情况开发各管理模块;
条件差一些的高校,就采用单机版的教务管理系统,仅实现其中一些相关的模块,并不是全部教务管理环节,都采用计算机信息管理。
因此这里主要将近几年国内各高校教务管理系统的具有代表性的运行模式、功能特点作简要的概述:
在运行模式上,教务管理系统的基于网络使信息管理集中化,如浙江师范大学的教务管理系统,采用Client/Server网络结构,利用网络数据库存储信息,通过专用客户端界面,实现各院系与教务科的业务往来;
又如由长春光机学院开发的教务管理系统,采用文件共享的网络结构,利用桌面数据库存储信息,教务科内各模块管理人员通过专用客户端界面对各模块进行操作,但在各院系与教务科之间没有提供信息交互的手段。
在功能上,教务管理系统的模块划分大同小异,都是为了保证信息的充分共享。
如浙江师范大学的教务管理系统主要包含辅助模块、学籍模块、成绩模块、教学计划模块组、课室模块组、选课模块组、考试模块组;
如由长春光机学院开发的教务管理系统主要包含数据维护、基本数据管理、教学计划管理、开课管理、学籍管理、教室管理、排课管理、考务管理、毕业管理、教材管理。
各模块的功能划分又体现了开发者对数据库的建模思路,主要是把基本信息(如教室、班级、院系专业方向、教研室、开设课程等)集中管理,模块的划分映射到相应表对信息的划分。
在排课策略上,并没有对问题进行数学建模,把课表求解看作NP问题,选取求近似解的方法,即:
根据排课的约束条件,检测所有可能的候选解,从而得出最佳排课方案。
1.3本论文研究的主要内容
本论文就是在充分吸取以上这些研究成果的基础上,围绕性能,安全和维护这三大要素,基于三层网络计算体系结构,从我校的实际出发,构造教务管理信息系统模型,对数据库的进行分析和设计,使我校的教务管理更加科学化,规范化和标准化。
由于在校园网上面对的用户是各院教务员,可以实现教学计划的提交和审批,教学任务的下达和提交,学生成绩录入和管理,课表的查询,校级选修课的学生选课管理等功能;
在教务内部网上面对的用户是教学各环节的管理员,可以实现基本数据的录入和更新,教学计划的审核,课表的生成等功能。
在系统的设计中,还应将校级选修课和教学分计划合并,对课程、教师、教室、课时分布资源统一分配,生成课表。
当然,这样的要求同时也带来了相应的问题,如下所述:
(1)由于教学计划是以专业方向划分的,因而是针对每个专业方向所属的班级,但校级选修课是针对个别学生的,如何在数据库中设计教学计划的课程信息的表达,避免过分冗余,是数据库建模必须考虑的问题。
如果采用学位课制,则对非学位课的选择也会面临同样的问题。
本论文在第四章第一节给出了数据库的设计.
(2)在校级选修课中,由于学生选课的制约关系比较复杂,也会存在学生之间竞争课程、各门课程的先行后续、学生各门课程上课时间冲突等问题。
这些需要在查询学生相关信息后给出判断,才能保证学生选课信息的有效性。
这些有效性规则都需要中间层构件来实现校验。
本论文在第五章第二节给出了中间层组件的设计规则。
(3)课程表问题又称为时间表问题,课程表的编排就是解决对时间和空间资源争夺而引起的冲突.虽然排课表问题极其复杂,但可以采用一种分而治之(Divide&
Conquer)的观点来看待它,将其分为确定候选解—时空片和求取最佳方案两个不同的部分,分阶段地来解决它。
本论文在第六章进行了初步探讨,并结合应用逻辑给出了设计思路。
(4)任课教师提交学生成绩到各院教务员,审核后各院教务员通过校园网录入到数据库中,由此产生如何保证对数据库进行安全访问和数据一致性问题。
采用三层网络体系结构,不仅仅是网络结构的设计,还必须设计相应的数据库构件,对Web用户和内部网用户提供统一的数据访问接口以保证一致性和安全性。
本论文在第一章第二节和第五章第三节讨论了安全性问题。
当然,系统模型的建立和数据库的建模遇到的不只是上述几个问题,更重要的在于,使用面向对象的方法建立关系数据库以包含整个业务流程的数据信息,通过对三层网络体系结构的理解,构造中间事务层,为用户提供管理的方法和途径。
第二章系统总体设计
本章首先介绍了高校教务信息管理系统的基本需求,并概述了目前流行的三种软件组件模型。
在此基础上,根据校园网上教务科与各院系之间的业务关系,对系统运行的网络计算环境进行模型设计。
2.1系统分析
关于高校教务信息管理研究己有多年的历史,各高校在不断实践的基础上又形成了自己的风格,但基本管理模式都大同小异。
它们都是以教务管理决策部门(如教务处、教务科、教材科等部门)为控制中心,对所涉及的所有数据进行集中的、统一的管理。
其它部门(如各分院、系、专业等)分设教务员,在主管部门的授权下可以对数据进行录入、修改、查询、统计、打印等操作。
这样就将教务管理部门的绝大部分工作(如学籍数据录入与变更、教师管理、工作量计算、教师评估、教学计划、教材计划、学生选课、成绩录入与查询、课表查询、考试查询等)分解到各基层单位,从而能够及时、高效地进行数据处理。
其数据处理模型是以教学计划为中心,结合学生学籍数据、教师数据自动生成开课数据、教材计划数据,并生成排课数据及考试安排数据。
下面将从需求陈述、数据流图、问题域划分逐步对系统进行分析。
2.1.1需求陈述
教务信息管理系统是由基于三层模型的内部网和外部网组成的网络信息系统。
内部网由教务处(控制中心)的各子系统管理员组成,通过专用客户端软件进行数据库操作:
外部网由各院教务员组成,通过浏览器进行数据的提交和查询;
内部网与外部网之间由路由器做网关构建防火墙。
对于内部网来说,基础数据管理员将负责每一年的院系、专业方向、教研室、课程、教学区、教室以及每一年级的入学信息、学年学期的数据添加和更新;
学籍管理员将负责每一年的学生信息的添加和更新;
教师管理员将负责每一年的教师信息的添加和更新;
教学计划管理员将负责每一年级的教学总计划的制定和审核,并为排课管理提供每一学期的教学分计划的制定和审核;
排课管理员将负责每一学期的排课约束条件的制定及课表的生成;
考务管理员将负责每一学期的结业课程的考试时间、考试地点、监考教师的安排以及学生成绩管理。
对于外部网来说,各院教务员将负责向教学计划管理员提交本学院的每一年级的教学总计划,补充每一学期的教学分计划,接受每一学期的教学分计划(教学任务)并提交任课教师,查询课表、考试安排,学生成绩的录入和查询,公告栏的信息查询和信息发布。
除了对运行环境和功能的要求外,还必须在数据安全性、存储容量、事务处理的响应、数据维护等方面有所考虑。
2.1.2数据流图
从对上述的需求陈述的分析,可以导出整个业务详细的逻辑模型,如下面的数据流图所示。
图2-1教务信息管理系统的数据流图
2.1.3问题域划分
用传统的生命周期方法(SA-SD-SP)开发的软件在稳定性、可重用性和可维护性方面比较差,而面向对象方法学的基本原则,是按照人们习惯的思维方式建立问题域的模型,开发出尽可能直观、自然地表现求解方法的软件系统。
它基于构造问题域的对象模型,以对象为中心构造软件系统。
基本方法是使用对象模拟问题域中的实体,以对象间的联系刻画实体间的联系,从静态结构的五个层次(主题层、类一&
一对象层、结构层、属性层、服务层)划分问题域,确定关联及交互次序,定义服务,最终完成数据交换和处理的功能。
为了在需求分析的基础上,对数据库进行建模,这里采用面向对象的分析方法。
由上面的需求陈述,可以把系统分为以下几个主题:
.基础数据管理
.学籍管理
.教师管理
.教学计划管理
.排课管理
.考务管理
问题域之间的关联如下图:
图2-2问题域之间的关联
从以上问题域之间的关系,可以看出每个问题域都不是独立的,其划分是从用户需求的角度出发的。
面向对象的开发也是围绕用户的需求来做的,在开发的各个阶段也不同于传统的软件开发方法。
传统的软件开发方法可以用“瀑布”模型来描述,这种方法强调自顶向下按部就班地完成软件开发工作,对软件的需求在用户和系统分析员之间反复讨论,力图使之逐步趋于完善。
事实上,人们认识客观世界解决现实问题的过程,是一个渐进的过程,人的认识需要在继承以前的有关知识的基础上,经过多次反复才能逐步深化。
用面向对象方法开发软件时,阶段的划分是十分模糊的,通常在分析、设计和实现等阶段件多次迭代来完成开发,上面给出的问题域的划分和关联也是参考已有的经验经过一个反复的过程得出的。
在这里,系统把各院教务员和教务内部管理员一视同仁,因为都是通过服务器端基于MTS的组件访问数据库,不同的是前者需使用HTTP协议经网关由IIS调用组件,而后者是在内部网中通过DCOM远程调用(RPS)调用组件。
从对数据流图的分析可以得出的对象模型,但可以看出,在每个对象中列出很少几个最核心的服务。
必须把对象的行为以及数据处理,转换成由适当的对象所提供的服务,也正如前面指出的那样,“对象”就是由描述其属性的数据即可以对这些数据施加的操作(即服务)封装在一起构成的独立单元。
下面给出确定操作的目标对象(即应该在该对象所属的类中定义这个服务)的一些规则:
1)如果某个处理的功能是从输入流中抽取一个值,则该输入流就是目标对象。
2)如果某个处理具有类型相同的输入流和输出流,而且输出流实质上是输入流的另一种形式,则该输入/输出流就是目标对象。
3)如果某个处理从多个输入流得出输出值,则该处理是输出类中定义的一个服务。
4)如果某个处理把对输入流处理的结果输出给数据存储或动作对象,则该数据存储或动作对象就是目标对象。
当一个处理涉及多个对象时,为确定把它作为那个对象的服务,必须判断那个对象是否在这个处理中起主要作用。
通常在起主要作用的对象中定义这个服务。
一般情况下,如果处理影响或修改了一个对象,则最好把该处理与处理的目标(而不是触发者)联系在一起;
同时考查处理涉及的对象及这些对象之间的关联,从中找出处于中心地位的对象,如果其他对象围绕这个中心对象构成星型,则这个中心对象就是处理的目标。
如:
学生基本情况和教师基本情况。
对本系统而言,各对象从事件导出的服务定义可以从每个事件的描述动词中得到,因涉及许多数据表项,所以在第四章的数据库建模实现中给出详细的说明。
下面是各对象的状态图:
图2-3系统对象状态图
在教学计划管理中,实际上包含各教务员与教学计划管理员,教务员向管理员无论是提交年级各专业方向的所有学期的教学计划(课程安排),还是添加某个学期各年级各专业方向的教学分计划的课时分布表及任课教师,都需要从基础管理和教师管理中提取数据,并接受管理员的审核。
因此,这些事件可以看作是其他对象提供的服务,而事件引发的状态将成为某些对象的属性(如审核历史记录),通过状态记录决定是否提供服务。
下面同时也给出了系统的事件跟踪图,时间从上向下递增。
必须要说明的是,下面的事件跟踪仅是在正常情况下发生的,对异常情况的处理将加入系统的安全处理中,如在基础数据不完整的情况下的异常处理,在年级教学总计划未建立或未审核时操作教学分计划的异常处理等等,体现在中间层组件中就是对整个事务过程进行判断,对未成功的事务提供回滚。
由以上的分析,同时也给出了系统运行的功能模型。
以上是采用面向对象的方法对系统的业务流程及功能进行分析,下面将介绍该系统的网络运行环境。
2.2系统的网络运行环境
2.2.1组件模型概述
从某种程度上说,让标准软件组件分布到网络上相互调用是企业级计算期待的解决方案。
而在我们朝着增加组件化、装配式生成应用的方向发展时,企业级计算的合理方向则应是让各种混合平台上的不同类型对象之间采用一个标准通信界面。
基于对象的分布式计算所面临的挑战是建立一个系统让软件对象间透明地进行通信,彼此使用对方的服务,而不管这些对象是处于同一编址空间,还是不同的编址空间,或是根本不同的机器上。
当然,如果没有一种方法让对象在网络间可相互调用(借助于对象通道),应用就会被限定在某一桌面上。
三层应用一般使用一个事务处理监控器(TPM)实用程序。
TPM运行在中间层应用服务器上,支持对数据库的大容量事务处理。
TPM通常有以下几个特征:
(1)原子性全部事务不是全部提交就是回滚。
(2)一致性可以把多个事务(例如一个贷方和一个相关的借方)作为一个集合来提交或回滚。
(3)隔离性即使最终结果变化一致,多个相关的事务也好像是串联执行,看不到中间步骤。
(4)持久性一旦一个事务被提交,更新改变就在数据库内固定下来,不会因为通信故障、进程故障和服务器系统崩溃而失败。
在一个三层环境中,事务监视器(TM)是TP应用程序的一个分支,最初是主框架数据库管理系统中用来管理大量并发事务的工具,比起单独的客户/服务器RDBMS更加强壮并且可以处理更多的并发事务。
对于许多第三方YM—需要高额的许可费用—可用于UN工X,Netware和WindowsNT的数据库服务器无疑是很有应用价值的。
基于UURBA的UTS和基于DCUM的MTS都可以帮助建立和管理三层客户/服务器应用程序的中间层,同时作为一个URB存在,实现资源组合(Pooling),安全性,管理和客户发行。
CUBAse-CORBA(CommonObjectRequestBrokerArchitecture)组件模型的底层结构为对象请求代理ORB(objectrequestbroker)。
一个CORBA组件采用界面定义语言(IDL)进行描述。
CORBA提供了IDL到C,C++,Java,COBOL等语言的映射机制—IDL编译器。
IDL编译器可以生成Server方的Skeleton和Client方的Stub代码,通过分别与客户端和服务端程序的联编,即可得到相应的Server和Client程序。
同时提供了一系列的公共服务规范(COSS),其中包括名字服务、永久对象服务、生命周期服务、事务处理服务、对象事件服务和安全服务等,它们相当于一类用于企业级计算的公共组件。
此外,CORBA还针对电信、石油等
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 高校 教务 管理 系统 研究