自动排课系统的设计与实现毕业论文设计(编辑修改稿)

自动排课系统的设计与实现毕业论文设计(编辑修改稿)内容摘要：

富的教务人员在学期末依据人才培养方案、教学计划等资料集中时间、精力进行编排，协调出现的各种矛盾，在这个基础上再由排课专家反复检查合理性，修正课表，直至符合要求为止。 近几年，随着我院招生人数的持续增 加 ，教师规模的不断扩大 ， 手工排课的缺点就越来越突出。 排课实际过程中涉及数十个院系和部门、数千教师，上万学生、教师跨系上课和班级合班上课等复杂情况，排出合理的课表需要耗费大量的时间，且排出的课表调整起来困难。 同时因为人的思维的随意性，排课表时非常灵活，没有严格的工作步骤，所以人工排出的课表随意性大。 计算机由于具有运算速度快、处理能力强等特点，在教学工作中得到了普及应用。 用计算机来代替劳动强度大、工作效率低的手工排课势在必行。 为了解决手工排课 的问题， 我院 决定通过信息化手段来提高教务 管理水平，用计算机排课来代替 传统的手工排课。 国内外的研究现状 计算机排课，它是把排课问题化为计算领域的有约束的时空组合优化问题进行求解的。 它对课表上的时间进行了分片和编号处理，使分成的每个时间片和每个教室空间组合，构建了一个个大小不等的时空组合块，并根据求解规则，对每个教学计划进行时空组合块分配，并且分配的组合，必须在目标空间中表现出良好的人为满意度。 国外研究人员从 20 世纪 50年代就开始对课表编排问题的数学模型、解的存在性以及计算机求解算法等问题进行了研究。 1962 年 Gotlieb 提出了课表编排问题的数学模型，使之成为数学家 和计算机应用专家共同研究的课题。 由于实际中遇到种种难题，并未能取得满意成果。 1976 年 Bondy 提出了一个简单的排课表问题，将问题归结为一个图的边染色问题，并且对提出的简单排课表问题给出了一个算法。 但实际教学活动中提出的排课表问题远非如此简单，且由于它必须满足各种复杂约束条件而使这种算法实际上是无能为力的。 1976 年 Even 等人证明了课表问题属于 NP 完全类问题，把人们对计算机编排课表的复杂性的认识提高到了理论的高度。 进入 20世界 90年代以后，国外对课表问题的研究仍然十分活跃，比较有代表性的有印度的 Vastapur大学管理学院的 Arabinda Tripathy、加拿大 Montreal 大学的 Jean Aubin 和 Jacques Ferland 等。 目前， 国外 解决课表问题的方法 主要 有 ： 模拟手 工排课法、图论方法、拉格朗日松弛法、二次分配型法等。 在国内，对排课问题的研究始于 20 世纪 80 年代初期。 例如，西南交通大学在分析高校课表编排所遵循的基本原则和模糊性原则的基础上，定义了课元之间，关于教师的相关关系和关于自然班的相关关系，提出以课元相关运算和课元的候选时空片计算为核心的计算机排课算法；延边大学根据高校课程表的制作特点，设计了计算机自动排课的数据结构与算法；沈阳电力高等专科学校研制了基于 Client/Server 的开放式智能排课系统；山西大学在总结排课工作经验的基础上，提出了一种解决问题的形式化描述，在这种想法上实现了基于知识推理的排课系统；大连理工大学的智能教学组织管理与课程调度系统，清华大学的 TISER系统等等，所有这些系统都是模拟手工排课过程，以“班”为单位，运用启发式函数来进行编排的。 但是这些课表编排系统往往比较依赖于各个学校的教学体制，不宜于进行广泛推广。 高职教育在培养目标和办学 模式、教学方式等方面都有别于 传统学科式教育。 遵循理论“必需”，“ 够用”为度，理论为实践服务的原则，着重培养学生 的实践能力，培养面向生产、建设、 管理及服务一线的高等技术应用型人才。 由于培养目标和培养方式 的 特点，决定了高职教育的教务工作 面临 许多新的困难，其中 在 排课、调课、检查教学进度、质量、沟通教学双方 信息 等常规性工作中 的 问题尤为突出。 如何利用有限的师资力量和有限的教室资源，排出一个合理的课表， 3 对维护高职院校正常的 教学秩序 和提 高教学效果有重要 的作用。 系统解决的主要问题 随着 我院 办学规模的不断扩大 ，办学层次的不断提高，课表 的 编排管理 工作也显得越来越重要。 我院 在日常的手工排课过程中主要存在以下几个方面的问题： 需要大量的 有经验的 教务人员进行排课 ； 手工排课需要大量的时间，周期长； 课表编排完毕后很难进行调整； 容易出现教师冲突和教室冲突的现象； 排课没有严格的步骤，排出的课表随意性大 ； 课表信息共享程度低。 本文的主要工作 本文通过对淄博职业学院教务管理 中排课 业务 的需求 分析， 借鉴 RUP 模式 ，从架构设计开始，完成了 学院 计算机排课 系统的需求分析和系统设计。 采用 Visual Basic 为开发工具，完成了系统功 能的开发。 本系统开发过程总体上采用 RUP 模式，由于计算机排课系统开发的生命周期较短，因此，我们在使用 RUP 进行软件开发时，对 RUP 过程进行了适当的裁减，保留了 RUP 的特点 ,即仍然是一个用例驱动、以架构为中心、迭代的开发过程。 对裁减后的 RUP，我 们 取消了原来 RUP 四个阶段的定义，只给出了一些工作流程和一些原则，并且结合了 UML 建模机制，合理的选择了 UML 中的各种建模元素。 本文的组织结构 全文共分为 六 章。 第一章是绪论，主要介绍了系统的开发背景，以及国内计算机排课的研究现状，说明了系统需要解决的主要问 题和本文的组织结构。 第二章是 需求分析 ， 主要 通过对淄博职业学院排课业务的描述，说明 了 排课 系统的目标和解决的主要问题，并介绍了系统的开发模式，对系统的功能性需求和非功能性需求进行了详细的描述。 第三章 系统构架技术， 主要介绍了系统构架设计的目标和约束，分别对系统的总体框架、功能构架、技术构架和安全构架等进行详细描述。 第四章是 计算机排课系统的详细设计， 主要通过排课管理实体关系图和自动排课的序列图来介绍了系统的详细设计，并对数据库的构建进行了描述。 第五章是 计算机排课系统的实现过程， 简要介绍了排课系统的几个功能模 块的实现过程， 同时对教学计划和排课算法两个关键问题进行描述，说明了排课系统设计的理论依据。 第六 章总结与展望部分，对本文进行了总结，并对下一步的工作进行了展望。 山东大学 硕士毕业论文 5 第 2 章 需求分析 系统概述 总体业务描述 淄博职业学院管理体系实行系部的二级管理体制，在全院有 13 个系部和1000 多名教师。 学院排课管理系统的应用范围 包括 教务处 、 系部和教师 三级单位。 教务处和系部 作为 课表 的 设计者和管理者 ，重点在于对 课程的安排和 统计数据的分析 ；教师 作为 教学计划的执行者，是信息的源头。 在排课管理中，教务处 以 教学计划 为依 据， 安排 出一 学期 各个班级所开的课程，教师根据自己的专业选择自己能上的课程，各系部负责协调安排每门课程的具体上课的教师。 总体来看，淄博职业学院排课业务流程 如 图 21 所示 ： 图 21 排课业务流程图 系统的目标和解决的问题 根据 淄博职业学院信息 化 建设的总体要求 ， 淄博职业学院计算机 自动排课系统的 目标是： 运用计算机排课代替传统的手工排课，提高排课效率，使教务管 理申请自己的所上的课程 教务处 系部 教师 需本系教师上课的课程 按教学计划安排各系所开的课程 安排 教师 所上课程计划 安排全院的课程表 信息反馈或执行课表 人员的从繁重的排课工作中解脱出来，提高教务人员的工作效 率， 加强对学院基本信息的管理， 同时实现 教学管理 规范化 的目标。 本系统 的主要内容就是使用计算机实现课表的编排、基础数据的处理、课表的查询和报表的输出等多种功能，作为一个完整的 排课 系统，主要 解决以下问题 ： 基础数据的处理 排课过程中涉及到许多基础数据，这些基础数据包括院系、教师、学生、教室、课程等信息，对于这些基础信息要能够根据实际情况灵活进行增加、删除、修改等处理。 排课处理 课程的编排不是任意的，它是一个时间、教师、学生、教室四者的组合规 划问题，为了达到最好的教学效果应遵循一定的要求。 这些要求主 要有 ： （ 1） 要尽量为所排课程安排上该类课程效果最好的时 间； （ 2） 课程在一周上多次时要有一定的时间间隔 ； （ 3） 公共课等涉及面广、学时多的课程应优先处理 ； （ 4） 对同一教师，同一上课对象应尽量选择相对固定的几个教室 ； （ 5） 对于教师、学生、课程等提出特殊要求的情况，要根据具体情况予以处理。 另外，对于计算机初排的结果还应可以通过人工交互进行少量的修改等。 排课结果的处理 计算机编排完课程后，对这个结果进行各种条件的查询，并可以根据情况 输出各种形式的表格，以便于教务人员进行处理。 例如： 可查询某班的课程安排、某位教师的课程安排、以及某个教室的使用情况。 充分利用网络优势 充分利用网络优势，实行计算机分布式排课。 计算机排课需要计算机在全校范田内对各种时间是否发生冲突进行检查，因此早期的计算机排课系统大多实行集中式排课，一般由教务处负责完成。 但目前各校均在扩招，从而造成学生多、班级多，排课时所需要输入的基础数据多排课任务都由一个部门来完成是很不现实的。 实行计算机排课的唯一出路就是将排课任务分解，化整为零，实行分布式计算机排课。 现在各 高校大多建立了校园网络，这使得实行分布式计算机排课成为可能。 课程、教师、学生班级、教室等基本信息既可临时录入，又可从其它教山东大学 硕士毕业论文 7 学管理系统或校园网中获取，以减少数据录入工作量。 系统的 开发模式 RUP 是一个将用户需求转化为软件系统所需要的活动的集合，即软件开发过程。 RUP不是一个简单的过程，而是一个通用的过程框架，可用于各种不同类型的软件系统、各种不同的应用领域、各种不同类型的组织、各种不同的功能级别以及各种不同的项目规模。 RUP 可以用二维坐标来描述。 横轴通过时间组织，是过程展开的生命周期特征，体现 开发过程的动态结构，用来描述它的术语主要包括周期、阶段、迭代和里程碑；纵轴以内容来组织为自然的逻辑活动，体现开发过程的静态结构，用来描述它的术语主要包括活动、产物、工作者和工作流，如图 22所示。 图 22 RUP 二维开发模型 RUP 是一个以用例为驱动、以架构为中心、迭代和增量式开发过程。 RUP中的软件生命周期在时间上被分解为四个顺序的阶段， 分别是：初始阶段(Inception)、细化阶段 (Elaboration)、构造阶段 (Construction)和交付阶段(Transition)。 本系统开发过 程总体上采用 RUP 模式，由于计算机排课系统开发的生命周期较短，因此 ，我们 在 使用 RUP 进行软件开发时， 对 RUP 过程进行了适当的裁减，保留了 RUP 的特点 ,即仍然是一个用例驱动、以架构为中心、迭代的开发过程。 对裁减后的 RUP，我 们 取消了原来 RUP 四个阶段的定义，只给出了一些工作流程 和一些原则，并且结合了 UML 建模机制，合理的选择了 UML 中的各种建模元素。 裁减后 RUP 流程是一个不断迭代的开发流程，每一个迭代过程都需要经过下列步骤： 第一步：找出系统的功能需求和非功能性需求，功能需求使用用例表示，非功能性需求，可以 使用规定格式的文档表示；项目开始时，找出一些主要的关键的用例即可，其他次要的用例可在以后的迭代中补充，对这些主要用例的描述应该保持尽量简单，对用例的描述可以使用文档来表示，也可以使用 UML 中的建模元素来表示，本文在模型中，选择了 UML 中的活动图来表示。 对这些用例要标明其重要程度，对那些影响系统架构的用例要标以很高的重要程度。 第二步：为这些用例建立简单的系统初始模型 (可多个 )，可以使用用例图来表示。 从系统整个初始模型可以看出一个用例是否得当；也可以根据初始模型来确定团队的开发进度；并且根据系统原型能够得到系 统潜在的一些系统架构；能够这些系统架构中考虑选择一个最恰当的系统架构。 第三步：找出待开发系统领域的类，第一次可以找主要的类；并定义个各类的主要职责和各类之间的关系，创建 UML 中的类图来表示；将类分为边界类、控制类和实体类这三种类，并为实体类之间的关系创建一个类图，以便为以后的数据库设计打下基础。 第四步：编写整个项目全部迭代计划 (只此一次 )，每个迭代周期为 1 周～ 2周，迭代周期必应该过长。 选择要进行迭代开发的用例，这些用例的开发周期不能超过迭代周期。 迭代应该注意： 迭代计划内容应该包括迭代目标、人员安排、迭代 时间表、存在的风险、可交付的迭代结果；每个迭代期间按照需求，分析，设计，实现和测试来进行管理。 第五步：将要开发用例所应有的功能和类结合起来，即用类的对象来表示用力所具有的功能；创建 UML 中的序列图或者协作图来表示；通过讨论验证修改序列图 /协作图。 第六步：如果某个类的对象，具有一些非常重要的状态，则为该类创建状态图，状态图中的事件 ,动作和行为最后会转化成相应类的操作。 第七步：在设计。