【毕业学位论文】（Word原 稿）基于Jsp教学一体化管理系统-软件工程

基于 学一体化管理系统 摘 要 I 摘 要 随着计算机技术和 网络 技术的飞速发展， 它 应用的范围越来越广泛，并已深入到各种行业领域中。为了适应社会的发展，学校的信息化水平要求也越来越高，将具有跨平台特性的 术用于实现各类管理信息系统，不但可以提高学校的信息化水平，也可以提高学校管理工作效率。 本文以 为页面的主要编程语言 ,从 计模式和 架技术的应用展开论述，介绍了该系统纵向上各个业务模块、 以及数据库 的设计和实现，其中对该系统 据 持久层的设计进行了详细介绍 ,并对系统中的各个模块进行 了 详细的说明 。 关键词 教学 一体化 管理 系统 , 式， s eb go to of In to to of of of sp of of of sp as VC of in of 目 录 录 摘要 . 录 . 1 章 绪 论 . 1 题研究的背景和意义 . 1 绍 . 1 绍 . 2 . 4 成 . 4 模型组件 . 5 视图组件 . 5 运行流程 : . 6 基本配置 . 6 . 6 系结构的概要图： . 7 系结构 . 7 久的对象及其集合 . 8 例状态 . 8 . 9 第 2 章 用户对系统的要求 . 10 统对教学管理总的需求 . 10 务处工作人员对教学管理系统的要求 . 11 生管理模块 . 11 师管理模块 . 12 务处管理 . 12 师对管理系统的需求 . 12 生对管理系统的需求 . 13 统功能需求 . 13 第 3 章 数据库系统的实现 . 14 据实体描述 . 14 体间联系描述 . 14 据实体 . 15 数据库逻辑模型设计 . 17 设计 . 17 据约束设计 . 20 据完整性设计 . 21 第 4 章 系统实现 . 22 统开发及运行环境 . 22 架实现 . 22 示层买现 . 22 据库持久层的实现方法 . 24 统部分功能实现 . 25 录模式的设计 . 25 生学籍管理系统设计 . 28 师管理系统设计 . 35 本章小结： . 42 第五章 总结和展望 . 43 总结 . 43 展望 . 43 参考文献 . 45 第 1 章 绪 论 1 第 1章 绪 论 随着因特网技术的迅速发展，教育手段信息化成了现在 学校 教学的一种趋势，尤其是在 素质 教育受到日益重视的今天，如何借助 网络 信息技术更好的为学生 、教师 、学校 服务，更好的管理教学环节以方便 学校 各级管理人员成了一个值得思考的方向。基于 学 一体化 管理 系统 ，其教学 管理 过程不受时间、地域的限制，同时教育资源及公共信息能同时在广大范围内实现共享。 学校开学时，新生报到是每个高中学校所面临的一个 繁重任务，按照以往的工作方式，在学生报到前，学校要发放录取通知书，然后是学生分班、缴费和相应的住宿管理，在上面的各个环节中，要相互协作，环环相扣，如果信息 资源交流 不充分，那么就容易出现问题， 同时在组织学生的升、留学时由于人为手工因素的原因，造成了信息不通畅，产生一些意 想不到的问题，影响了学校的正常的管理，给学校的 教学 管理带了不便 ； 再者 ，随着当前学校规模的不断扩大，学生数量的不断增加，学生信息量也成倍增长 ； 学生数量的增长给教学管理带来了很大的冲击，教学管理的高低直接影响到学生培养的质量 和学校的效率 。 针对上面的问题， 为有效的提高教学管理工作的效率， 本人 设计开发了此教学管理系统。 在以下的小结中把该课题中的相关技术进行简单介绍。 一种利用 平台来简化企业解决方案的开发、部署和管理相关的复杂问题的体系结构。 术的基础就是核心 台或 平台的标准版， 仅巩固了标准版中的许多优点，例如 “ 编写一次、随处运行 ”的特性、方便存取数据库的 术以及能够在 用中保护数据的安全模式等等，同时还提供了对 及 术的全面支持。其最终目的就是成为一个能够使企业开发者大幅缩短投放市场时间的体系结构。 系结构提供中间层集成框架用来满足无需太多费用 而又需要高可用性、高可靠性以及可扩展性的应用的需求。通过提供统一的开发平台， 时提供对现有应用程序集成强有力支 2 持，完全支持 良好的向导支持打包和部署应用，添加目录支持，增强了安全机制，提高了性能 。 构是 缩写，中文译为 “ 模型 控制器 ” 。 用程序总是由这三个部分组成 ； 事件导致 变 者同时改变两者 ； 只要 变了 数据或者属性，所有依赖的 会自动更新。类似的，只要 变了 获取数据来刷新自己 。 构的对应关系是 :常是 页面显示部分。页面显示的逻辑部分 ，通常用 实现 。 务逻辑部分 ，通常用服务端的 者 现。 文即 把一个应用的输 入、处理、输出流程按照 方式进行分离，这样一个应用被分成三个层 模型层、视图层、控制层。 视图 视图 (表用户交互界面，对于 用来说，可以概括为 面，但有可能为 个应用可能有很多不同的视图， 计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型 (理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用 户界面的输入数据和请求传递给控制和模型。 模型 模型 (就是业务流程 /状态的处理以及业务规则的制定。业务模型的设计可以说是 主要的核心。它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减少了技术上的困难。对一个开发者来说，就可以专注于业务模型的设计。 计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。 没有提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高 重用性。 业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据保存。 第 1 章 绪 论 3 控制 控制 (以理解为从用户接收请求 , 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求 ， 控制层并不做任何的数据处理。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。 模型、视图与控制器的分离，使得一个模型可以具有多个显示视图。如果用户通过某个视图的控制器改变了模型的数 据，所有其它依赖于这些数据的视图都应反映到这些变化。因此，无论何时发生了何种数据变化，控制器都会将变化通知所有的视图，导致显示的更新。模型、视图、控制器三者之间的关系和各自的主要功能，如图 1 所示。 台企业版 (其他的各种框架不一样， 模型对象(义了一个规范。 视图 ( 在 用程序中，视图 (能由 担。生成视图的代码则可能是一个 一部分，特别是 在客户端服务端交互的时候。 控制器 ( 用中，控制器可能是一个 现在一般用 现。 模型 ( 模型则是由一个实体 实现。 计模式的扩展 通过在 的 构编写的，具有极其良好的可扩展性。它可以轻松实现以下功能： 实现一个模型的多个视图； 采用多个控制器； 当模型改变时，所有视图将自动刷新； 所有的控制器将相互独立工作。 这就是 构的好处，只需在以前的程序上稍作修改或增加新的类，即可轻松增加许多程序功能。以 前开发的许多类可以重用，而程序结构根本不再需要改变，各类之间相互独立，便于团体开发，提高开发效率。 优点 求对应用分层，虽然要花费额外的工作，但产品的结构清晰，产品的应用通过模型可以得到更好地体现。 首先，最重要的是应该有多个视图对应一个模型的能力。在目前用户需求的快速变化下，可能有多种方式访问应用的要求。这样减少了代码的复制，即减少了代码的维护量，一旦模型发生改变，也易于维护。 其次，由于模型返回 4 的数据不带任何显示格式，因而这些模型也可直接应用于接口的使用。 再次，由于一个应用被分离 为三层，因此有时改变其中的一层就能满足应用的改变。一个应用的业务流程或者业务规则的改变只需改动 模型层。 最后，它还有利于软件工程化管理。由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化产生管理程序代码。 不足 不足体现在以下几个方面： （ 1）增加了系统结构和实现的复杂性。对于简单的界面，严格遵循 模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。 （ 2）视图与控制器间的过于紧密的连接。视图与控制器是相 互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。 （ 3）视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。 （ 4） 目前，一般高级的界面工具或构造器不支持 构。改造这些工具以适应 要和建立分离的部件的代价是很高的，从而造成使用 由图中可以看出， 架由 3 个部 分组成：核心控制器 业务控制器和用户实现的业务逻辑组件。在这 3 个部分里， 架提供了核心控制器 用户需要实现业务控制器和业务逻辑组件。 核心控制器 ： 架的核心控制器，该控制器作为一个 行在 用中，它负责拦截所有的用户请求，当用户请求到达时，该 过滤用户请求。如果用户请求以 尾，该请求将被转入 架处理。 架获得了 *求后，将根据*求的前面部分决定调用哪个业务逻辑组件。 于处理用户请求的 例，并不是用户实现的业务控制器，而是由 架提供了系列拦截器，该系列拦截器负责将 入到 ，并回调 法第 1 章 绪 论 5 来处理用户请求。显然，上面的处理过程是典型的 向切面编程）处理方式。 上图中 显示了这种处理模型。 从图中可以看出，用户实 现的 仅仅是 理的代理目标。用户实现的业务控制器 （ 则包含了对用户请求的处理。用户的请求数据包含在 象里，而用户的 无需访问象。拦截器负责将 的请求数据解析出来，并传给业务逻辑组件 例。 业务控制器 正如从图中所看到的，业务控制器组件就是用户实现 的实例，里通常包含了一个 法，该方 法返回一个字符串 ， 该字符串就是一个逻辑视图名，当业务控制器处理完用户请求后，根据处理结果不同，法返回不同字符串 每个字符串对应一个视图名。程序员开发出系统所需要的业务控制器后，还需要配置 每个 要处理一个用户请求，而用户请求总是包含了指定 当 截到用户请求后，根据请求的 理 实际上，模型组件己经超出了 架的覆盖 范围。对于 架而言，通常没有为模型组件的实现提供太多的帮助。 E 应用里的模型组件，通常指系统的业务逻辑组件。而隐藏在系统的业务逻辑组件下面的，可能还包含了 域对象等组件。 通常， 架里的业务控制器会调用模型组件的方法来处理用户请求。业务控制器只是中间负责调度的调度器，这也是称 控制器的原因。如图 示 视图组件 经改变了 能使用 为视图技术的现状， 许使用其他的模板技术 ，如 为视图技术。当 控制器返回逻辑视图名时，逻辑视图并未与任何的视图技术关联，仅仅是返回一个字符串，该字符串作为逻辑视图名。当我们在 件中配置 ，不仅需要指定 性和 性，还要为 素指定系列 元素，每个 元素定义一个逻辑视图和物理视图之间的映射。 图 行过程 6 流程：在客户端提交信息之后，信息会转到对应的 ，在理完之后，又会转到 ，又从 跳转到 面。全部都是用的 请求转发 ,也就是在一个 。 前面大致了解了 框架的基本内容，但这些基本内容都必须建立在 的配置文件基础之上，这些配置文件的配置信息也是 应用的核心部分。 配置 件 任何 架都需要与 用整合，这就不得不借助于 件，只有配置在 件中 会被应用加载。通常，所有的 架都需要 用加载一个核心控制器，对于 架而言，需要加载要 用负责加载 会加载应用的 架。因为 核心控制器设计成 不是一个普通 为了让 用加载 只需要在 件中配置 可。 置文件 架的核心配置文件就是 置文件，该文件主要负责管理 框架的业务控制器 默认情况下， 框架将自动加载放在径下的 件。在大部分应用里，随着应用规模的增加，系统中 量也大量增加，导致 置文件变得非常臃肿。为了避免 件过于庞大、臃肿，提高 件的可读性，我们可以将一个 置文件分解成多个配置文件，然后在 件中包含其他配置文件。 今日的企业环境中，把面向对象的软件和关系数据库一起使用可能是相当麻烦、浪费时间的。 一个面向 境的对象 /关系数据库映射工具。对象 /关系数据库映射 (这个术语表示一种技术，用来把对象模型表示的对象映射到基于 关系模型数据结构中去。 仅仅管理 到数据库表的映射（包括 据 类型到 还提供数据查询和获取数据的方法，可以大幅度减少开发时第 1 章 绪 论 7 人工使用 理数据的时间。 目标是对于开发者通常的数据持久化相关的编程任务，解放其中的 95%。对于以数据为中心的程序来说 ,它们往往只在数据库中使用存储过程来实现商业逻辑 ,能不是最好的解决方案 ;对于那些在基于 中间层应用中，它们实现面向对象的业务模型和商业逻辑的应用， 最有用的。不管怎样， 定可以帮助你消除或者包装那些针对特定厂商的 码，并且帮你把结果集从表格式的表示形式转换到一系列的对象去。 用数据库和配置信息来为应用程序提供持久化服务以及持久的对象。 我们来更详细地看一下 行时体系结构。由于 常灵活，且支持多种应用方案， 所以我们这只描述一下两种极端的情况。“轻型”的体系结构方案，要求应用程序提供自己的 接并管理自己的事务。这种方案使用了 最小子集： “全面解决”的体系结构方案，将应用层从底层的 抽象出来，而让 处理这些细节。 图中各个对象的定义如下： 针对单个数据库映射关系经过编译后的内存镜像，是线程安全的（不可变）。 它是生成 工厂，本身要用到 该对象可以在进程或集群的级别上，为那些事务之间可以重用的数据提供可选的二级缓存。 表示应用程序与持久储存层之间交互操作的一个单线程对象，此对象生存期很短。 其隐藏了 接，也是 工厂。 其会持有一个针对持久化对象的必选（第一级）缓存，在遍历对象图或者根据持久化标识查找对象时会用到。 8 带有持久化状态的、具有业务功能的单线程对象，此对象生存期很短。 这些对象可能是普通的 一特殊的是他们正与（仅仅一个）关联。 一 旦这个 关闭，这些对象就会脱离持久化状态，这样就可被应用程序的任何层自由使用。 瞬态 (脱管 (对象及其集合 那些目前没有与 联的持久化类实例。 他们可能是在被应用程序实例化后，尚未进行持久化的对象。 也可能是因为实例化他们的 经被关闭而脱离持久化的对象。 事务 （可选的）应用程序用来指定原子操作单元范围的对象，它是单线程的，生命周期很短。 它 通过抽象将应用从底层具体的 及 务隔离开。 某些情况下，一个 内可能包含多个 象。 尽管是否使用该对象是可选的，但无论是使用底层的 是使用 象，事务边界的开启与关闭是必不可少的。 （可选的）生成 接的工厂（同时也起到连接池的作用）。 它通过抽象将应用从底层的 离开。仅供开发者扩展 /实现用，并不暴露给应用程序使用。 （可选的）生成 象实例的工厂。 仅供开发者扩展 /实现用，并不暴露给应用程序使用。 扩展接口 供了很多可选的扩展接口，你可以通过实现它们来定制你的持久 层 的 行 为 。 在 特 定 “ 轻 型 ” 的 体 系 结 构 中 ， 应 用 程 序 可 能 绕 过 及 接跟 交道。 一个持久化类的实例可能处于三种不同状态中的某一种。 这三种状态的定义则与所谓的持久化上下文 (关。 象就是这个所谓的持久化上下文： 瞬态（ 第 1 章 绪 论 9 该实例从未与任何持久化上下文关联过。它没有持久化标识（相当于主键值）。 持久化 ( 实例目前与某个持久化上下文有关联。 它拥有持 久化标识（相当于主键值），并且可能在数据库中有一个对应的行。 对于某一个特定的持久化上下文，证持久化标识与 识（其值代表对象在内存中的位置）等价。 脱管 ( 实例曾经与某个持久化上下文发生过关联，不过那个上下文被关闭了， 或者这个实例是被序列化 (另外的进程。 它拥有持久化标识，并且在数据库中可能存在一个对应的行。 对于脱管状态的实例 ， 保证任何持久化标识和 识的关系。 用 下文相关的” 定的 整个特定的上下文范围内始终有效。然而，对不同类型的应用程序而言，要为什么是组成这种“上下文”下一个定义通常是困难的；不同的上下文对“当前”这个概念定义了不同的范围。在 本之前，使用 上下文 么采用样的辅助类，要么采用第三方框架（比如 它们提供了基于代理 (者基于拦截器 (上下文相关 10 第 2章 用户对系统的要求 教学管理 总的需 求 本 学一体化 管理 系统 由教师、教务处和学生三个子系统组成， 但是这三个部分又是相辅相成的，他们通过一定的关系又能联系在一起。 其中教师管理模块主要 分为课程设置和教师基本信息，教务处 模块 主要的任务 分为教学管理和学生管理，学生部分功能 模块主要 分为学生信息输入和教务信息输入和学生个人查询修改部分，具体的功能图如下图所示： 图 教学一体化信息系统功能模块图 教学 管理 信息 系统 教 师 教 务 处 学 生 课程 设置 学生 成绩 输入 统计 工作量 教师 基本 信息 教师 个人 信息 教师 进修 情况 教学 安排 学生 成绩 单生成 年级 班级 课表 生成 学生 管理 学生 宿舍 安排 学生 缴费 管理 学生 信息 输入 教务 信息 输入 个人 信息 查询 修改 学籍 变更 奖学 金评定 学生 处罚 记录 第 2 章 用户对系统的要求 11 本系统的主要分系统如下： 用户登陆系统（不同的用户登录到不同的应用系统中，也就是在程序中设定不同的用户权限，不同的用户所显示的界面也就不同，所对就的权限就不同，功能也就不同 。 ） 学生信息录入系统（ 主要是处理学生的日常的教务处的学生工作，包括学生的基本信息的录入，学生的基本信息的修改，以及学生的奖惩情况的录入和修改，学生的分班，学生和老师的课表的管理，考试考场的编排，此项功能中只有 教务处工作人员类才能进入，其中包含了 学籍管理、班级分班管理、课表管理、 奖惩管理 ）。 学生信息查询修改系统（学生类进入，可以对 基本的学生 自己的 信息 数据进行查询 、 修改 ，对自己的 考试成绩和 奖惩信息只能进行浏览，但不能修改 ）。 课 表 系统（教务处工作人员类才能进入 ，可以设置相应课程的上课节数，上课时间、地点，相应的授课老师，授课的节课等 ）。 教师信息录入系统（教务处工作人员类才能进入 ，可以对教师的基本信息进行录入、修改、查询 。 ） 教师信息查询修改系统（教师 可以 进入 相应的模块 ，可以对数据进行查询修改 ，但是有的信息不能修改，只有在 教务系统中才可能进入修改 ）。 学生 课表 系统（教务处和 老师 都能进入 ，可 以对学校和学生的课表进行相应的调整和修改 ）。 成绩录入系统（教师可 以 进 入本系统，进行相应的学生考试成绩的分数的录入， 且录入后 如有错误可以进行 再修改 ，但是有时间的限制，超过期限就无权修改 ）。 成绩查询系统（教务处、教师、学生可进，但 教师和学生 只能对成绩进行相应的 查询操作， 不能修改，而教务处系统 可对其进行 查询和 修改操作）。 本模块 可以进行新生基本信息的录入 包括学号、姓名、性别、班级、年级、出生日期、籍贯、家庭住址 、父母姓名，父母的工作单位及联系电 话等相关的信息 。 学生流动情况的输入：包括转学、体学、复学、退学、毕业 。 可以对学生实现分班，分班可以按照相应的功能来进行，如按分数，男女生比例等问题进行相关条件的分班。 12 可以对学生分班后的情况进行相应的微调。 可以实现帮助学生实现 所在班级的 课 表生成 功能。 可以实现对学生档案中的奖惩处罚进行记录、修改。 学生个人信息的查询和修改，包括流动情况和奖罚情况。 可以对学生进行文理科二次分班，对文科和理科进行单独分班，分班的原始的记录可以保存。 可以实现对学生课程成绩进行查询 、成绩单生成 和异动管理。 理模块 本模块 可以实现对教师基本信息的录入和档案管理。 包括教职工编号、姓名、性别、年龄、出生年月、毕业院校、所授课程、所授班级、所授年级、 获得学位、工作年限。 管理教师进修档案（教师姓名、进修日期、进修科目、进修单位、进修成绩）。 教师课 程管理 统计（ 教师所教授的班级、 统计教师工作量 、学生成绩录录入 ）。 可以对相应的学生和班级进行档案进行查询，以了解学生和相应班级相关的情况。 可以查询课表，包括按年级、班级、教师浏览课程表，可以打印相应的课程表。 理 本模块 可以实现 对学生的信息的基本修改以 及教师信息录入和 课程进行排课管理 以及生 成 相应的年级和班级课程报表 。 实现 年级班级成绩单 功能实现 并根据情况做好相关课程的统计 。 师对管理系统的需求 实现对自己的基本信息的查询。 实现对选修自己所教授课程的学生的基本信息（但不能修改）。 实现对自己所教授课程的课程信息进行查询（时间地点）。 可以查询每次考试后所授课程的相关学业成绩信息，包括及格率，合格率，班级学生的名次，以及相应的年级名次。 实现自己课程的学生成绩的录入（录入后 提交后 不能再进行修改）。 第 2 章 用户对系统的要求 13 实现对自己的基本信息 的查询和修改。 实现课 表 查询（课程教师、课程时间、地点）。 实现选课、退课等选课相关事项 （本校的选、退课有学校统一管理） 。 本 系统应当完成的 上面所述的基本 信息处理 及 能够 实现学生的基本情况的录入，教师的基本情况的录入，学生和老师的相关信息的删除、学生和教师相关错误信息的修改，以及能够按照相应的要求进行学生和教师的相应信息的查询 、生成相应的班级及年级的课程表的报表，以及学生有关成绩的报表 等 相关基本的功能。 14 第 3章 数据库系统的实现 实体一览： 学生、教师、课程、选课。 实体描述： （ 1） 生），属性包含 生学号）、 名）、 别）、 日）、 学时间）、 学生联系 电话号码）、在班级） ， 在年级 )、 贯 )（ 号为候选码、学号为主键） （ 2） 学生学籍变更（ ,属性包含 录号）， 生学号）、更代码）、 录时间）、 述） (3)师）， 职工编号）、 别）、 师姓名）、在教授的 学科 ）、 毕业学校 ）、 T