基于三层架构高校教务管理系统设计

摘 要： 本文通过分析高校教务管理所服务的对象，定义了系统的功能需求；应用模块化设计思想将这些功能需求划归为基础信息、学籍管理、教务管理、信息查询和系统接口五个功能模块组；采用三层架构方式进行了系统总体设计，并详细设计了每层的主要职责。 关键字：教务管理；分布式系统；三层架构； 1 引言

教务管理是高校中一项极其繁重的任务，教务工作人员每天都需要接触和处理大量的数据和事务，如教师、学生、课程等基础信息，课程安排、考试安排、调课、补课等管理信息。这些信息的准确性和完整性，时时影响着教务管理及其相关工作的顺利开展，也为高校工作的正规化运作和标准化管理提供了依据。因此教务管理系统的设计在满足功能需求的同时，应突出方便性、实用性、易操作和自动化的特点；同时教务系统不应该设计成一个孤立的系统，而需要充分考虑与招生、就业、人事、财务等已有的系统的接口，以实现数据信息的有效共享。 2 系统的服务对象和功能需求

在对系统进行功能定义之前，有必要先对其服务的对象进行区分和定义，以便通过服务对象发掘系统的需求和功能。 2.1 服务对象

经调研分析知，教务系统的主要服务对象包括：教务人员、教师、学生及与教务相关的其他接口系统，这些对象与教务系统的主要交互为：

教务人员：维护系统中的基础信息的准确性和完整性，使用基础信息进行各种日常教务安排以及保证各类信息的及时更新。有权限对某些信息进行维护和审核的教师（如学院领导、系主任等）在他们行使这些权限时，也定义为教务人员，而在更多的情况下只需简单定义为普通教师。

教师：浏览课程安排、教学大纲、考试安排等信息；提交个人教学进度及其他材料。 学生：浏览课表、考试安排及其他与学生相关的信息。

接口系统：招生、就业、人事及财务等与教务有密切关系的其他系统，在教务系统中必须为它们提供相应的接口，以实现与这些系统数据的有效共享。 2.2 功能分析

通过对服务对象的定义和需求分析，可将系统划分为五个主要功能模块组，每个模块组包含若干子功能模块，如图 1 所示：

基础信息模块管理与教务相关的各类信息，是教务工作开展的基础；学籍管理模块实现对学生学籍信

息的维护；教务管理模块安排和管理各类日常教务工作；信息查询模块提供各类信息的查询和检索；系统接口模块实现教务系统与人事、财务等系统的资源共享。

由于教务管理系统涉及的信息量大，并且许多信息较敏感，因此系统的设计在保证功能完备的同时，必须充分考虑系统的执行效率和敏感数据的管理，保证系统安全、高效的运行。 (1) 基础信息维护

基础信息模块组主要维护与教务管理相关的组织结构信息、教师信息及教材、参考书等教学资料和各种设备、仪器等硬件设施的信息。各类人员对系统的访问权限也应该在本模块中实现，由于教务管理的人员涉及面广、各种业务逻辑互相交错，因此访问权限的控制也至关重要，应该为每类人员设置精确的权限，使他们在设定的范围内执行有限的操作。

学生信息本应属于基础信息，但考虑到其与学籍管理的紧密关系，将其划归学籍管理模块更能体现其业务逻辑，也更能体现模块化的设计思想。 (2)学籍管理

学籍管理负责维护学生自入学至毕业期间的各类信息。学籍管理是教务中最复杂、最繁琐，也是工作量最大的工作之一。学生每学期的注册、考试成绩录入、实习评价和毕业论文等都在此模块中完成。虽然学生信息产生自招生系统，教务管理系统通过接口从招生系统获得，但是由于教务是管理学生的主要部门，因此必须提供相应的模块实现学生信息的维护。 (3)教务管理

教务管理模块组提供了安排各类日常教务工作的功能，如学科培养方案、课程教学大纲及教学进度计划等教学资料的上传和下载，临时调课、补课等。课程安排和考试安排都涉及教师、班级、时间、教室等诸多因素，都是十分复杂、繁琐而且易出错的工作，设计时必须充分考虑这一特点，尽可能增加排课的自动化程度。 (4)信息查询

信息查询模块为教师提供浏览教学安排、检索授课班级情况的功能；为学生提供浏览课表、成绩等信息的功能；并为管理人员提供各种汇总信息。 (5)系统接口

通过系统的接口，教务管理系统从招生系统获得学生基础信息，从人事系统获得教师基础信息，为财务系统提供津贴核算等相关业务的支持，为就业系统提供每位学生在校情况汇总。 3 系统架构

在正式设计系统架构之前，有必要先简单介绍一下传统的两层C/S架构和在其基础上发展起来的三层 C/S和三层B/S架构。 3.1 传统两层架构

虽然在过去应用系统开发过程中，C/S（Client/Server，客户端/服务器）体系结构得到了广泛的应用，但是这种结构存在着很多体系结构上的问题。由于用户通过客户端直接与数据库连接并操作数据库，这就给系统留下了安全隐患，对于越来越多通过 Internet 共享数据的单位和企业更是如此；同时数据库服务器需要为每个客户端建立连接，使用者的增加大量消耗并浪费了紧张的服务器资源，也给传输网络带来了沉重的负担，且在业务高峰期容易造成网络流量骤增，形成网络阻塞；最后，业务规则是在客户端程序中实现，形成了所谓的胖客户端，它带来的直接危害就是大大增加维护量，造成维护工作困难，例如当业务逻辑发生变化时，不得不对所有的客户端程序进行及时更新或升级。因此人们提出了三层架构的概念。 3.2 三层架构介绍

在数据服务器与客户端之间加入一个组件层，或称为中间件，就形成了逻辑上的三层结构，分别称为数据层 - 业务层 - 表示层。这里的三层是逻辑上的三层，在物理上可以共存于一台计算机上，同时三层

只是这种架构方式的统称，每层可以继续细分而形成多层结构，但仍可称其为三层架构方式。其中，数据层一般就是传统的数据服务器；业务层也叫事务逻辑层，主要用于大批量事务处理、事务支持、大型配置、信息传送和网络通信；表现层提供数据显示的人机交互界面。从实现逻辑和设计的层次清晰考虑，可以将业务层深度细分为业务逻辑、功能逻辑和访问逻辑等层次，分别实现业务解释、功能实现和数据访问功能。由于这种结构中的系统业务主要被封装在业务层，使表现层比传统应用程序的业务逻辑大为减少，因而表现层的自由度极高，较容易实现基于客户端的程序（也称为C/S/S）、基于浏览器的 Web程序（也称为 B/S/S），或两种程序的混合实现。 3.3 本系统的架构方式

由需求和功能分析可知，教务人员是系统的主要服务对象，系统的多数功能都是为他们设计的。他们虽然比较分散，但通常都有专门的工作办公室，为他们提供专门的客户端程序将会为他们带来极大方便并可以大大提高他们的工作效率。因此考虑到他们的工作方式，需要设计基于分布式的多层 C/S结构，并为他们提供客户端。

考虑到教师和学生位置比较分散且不固定，同时他们只是偶尔利用系统浏览所需信息，所以没有必要为他们提供专门的客户端程序，利用浏览器为他们提供基于B/S的服务就能达到要求。

综合以上两个方面的考虑，系统是一个典型的分布式应用，并且应该同时包含C/S和B[1]/S两个层面。分布式技术的应用目前成熟的技术包括J2EE，CORBA 和.NET(DCOM) ，本文不打算涉及这些技术的细节及比较它们的优劣，也并没有指定某个作为实现系统的技术，而只是从分层设计的角度进行说明。 根据功能和架构的分析，可以设计系统的总体层次设计如图 2 所示。可以看出设计充分考虑了服务对象的需求，将系统设计成三层C/S和三层B/S的混合结构方式，由于业务层封装了系统大部分的逻辑，客户端和浏览器可以复用业务层及其逻辑，因此这并不会增加多少工作量。

4 系统设计

前面已经提到，本文将不从具体实现的角度进行描述，即不考虑使用的语言是Java、Jsp还是 C#、Asp.Net 或是其他方式，也不考虑架构采用的是J2EE、CORBA或是.NET(DCOM)技术，而是从设计的角度对系统进行分层探讨。 4.1 数据层

数据层是一般信息系统的最低层，它为系统定义、维护、访问和修改数据，并负责数据信息的存储、访问及其优化。数据层可以理解成传统的数据服务器，并在特定的数据库管理系统(DBMS)中实现。用 ER 模型描述数据库的逻辑视图如图 3所示。为了便于理解，已经对模型进行了简化，只保留了课程安排的视图，删除了与其业务关系不密切的实体(Entity)和属性(Attribute)，并且将保留的实体和属性用中文表述出来。

数据层的设计在充分考虑 1NF，2NF和 3NF的前提下也保留了部分冗余设计，以达到规范化和效率的平衡，保证数据库存储和访问的最优配置；同时避免使用复合主键，而将复[2]合主键的逻辑抽象到业务层实现，这样能极大的缓解数据层的资源开销和负担 。 4.2 业务层

业务层主要用于支持大批量事务处理、事务支持、大型配置、信息传送和网络通信。一个定义明晰的业务层扮演着应用程序入口的角色，为我们的表现层代码提供了一个简单统一的业务逻辑实现点。好的业务层也对我们的应用在执行何种操作，以及向用户表达怎样的逻[3]辑进行了明确的定义 。 (1) 业务逻辑

业务逻辑用来表示现实世界中的业务实体、业务规则并完成业务的合法性校验，例如教师，课程等属于实体，课程安排、考试安排等则需要使用到业务规则，而这些实体或规则的作用域及有效范围则属于合法性校验范畴，例如一个教师不可能在同一时间为两个不同的班级讲授不同的课程，一个教室在同一时间也不能安排两门不同的课程。业务逻辑层通过隐藏[4]来自更高层的事务逻辑和实施细节来提取业务事务 。 (2) 功能逻辑

将一些共性的逻辑操作的方法都集中封装在功能逻辑层中，当有多个功能相近的就可以调用封装好了的方法从而减少了应用程序中的重复代码，增强了代码的复用。 (3) 访问逻辑

数据访问逻辑为业务逻辑和功能逻辑提供对数据库执行以下任务的方法： 在数据库中创建记录。

读取数据库中的记录并把业务实体数据返回给调用程序。

使用调用程序提供的修改后的业务实体数据更新数据库中的记录。 删除数据库中的记录。

执行上述任务的方法通常称为“CRUD”方法 。通常，数据访问逻辑组件访问一个单一数据库，并封装了针对该数据库中一个表或一组相关表的数据相关操作。

在数据层设计时提到，为了缓解数据层的资源开销和负担，避免了使用复合主键，则与此相关的数据完整性校验也应在访问逻辑中实现。 4.3 表示层

表示层（也叫用户界面层）是将数据呈现给用户或处理用户输入的应用程序或系统一部分。它并不执行数据函数，而是通过输入向服务器请求数据，然后以一定的格式显示结果。表示层也可以实现部分简单的业务逻辑，例如进行课程安排时，教室的容量应该大于上课班级的人数等，这些逻辑可以直接在表示层中实现，以减少对服务器的无效访问，提高服务器的运行效率。

表示层的实现方式有基于 Web（浏览器）和基于非 Web（应用程序）两种客户端。由于业务层对业务的封装，因此无论是采用何种方式，表示层设计的重点都已经不再是业务逻辑和数据访问，而应是界面的易用性，即最好是用户无需去阅读操作手册就知道该如何使用，并且方便快速的使用界面。一致的界面、统一的功能、合理的布局和采用行业标准是界面设[6]计时应遵寻的原则 。 5 结束语

本文通过对教务管理服务对象的定义和分析，确定并模块化分解了系统的功能。基于三层架构方式的结构设计，使系统具有良好的复用性和伸缩性，十分有利于系统的开发，维护、部署和扩展，并可轻松地实现基于 Web和非 Web 的客户端之间的移植。 参考文献

[1]. 周斌．分布式系统架构的应用[J]．软件世界．2004（6）：50．

[2]. 何玉洁，梁琦．数据库设计教程[M]．北京: 机械工业出版社．2000．133-136．

[3]. RobHarrop,JanMachacek,ProSpring中文版[M]．夏昕(译)．北京: 电子工业出版社．2006． [4]. JohnA. Bocharov, SQLServer XML 和 Web 应用体系结构．MSDN．2002 [5]. Angela Crocker,AndyOlsenandEdwardJezierski, 设计数据层组件并在层间传递数据．MSDN．2002.8．