CRP排课管理系统

CRP模型

CRP系统包括学籍管理、成绩管理、排课管理、考试管理、教师管理、备品管理、系统维护和系统登陆平台。对于每一个子系统，都对应相应的模型，即各种各样的UML图。由于篇幅所限和各子系统具有相同的结构特征，这里只介绍的排课管理子系统的各种模型的建立。

CRP排课管理子系统是为了解决中小学繁杂的排课任务而设计开发的，其基本的要求是要实现排课的半自动或自动化，排出的课程表必须合理，实用。

在这里，结合RRUP过程来介绍各个排课管理系统在实际开发中使用UML 表示的各个模型。

1.1 需求模型

我们使用用例模型来表示需求阶段的系统模型，用例模型主要有用例图组成，从该子系统开始到子系统最终的发布，每一个迭代其用例模型都不相同；在CRP系统的开发过程中，随着迭代的不断进行，用例模型也在不断地发生变化，由于篇幅所限，本文只给出第一次迭代确定的用例模型和现今最后一次迭代所确定的用例模型。

RRUP过程的第一步，就是找出系统的功能需求和非功能需求，并建立相应的需求模型(用例模型)。

通过需求分析，确定了排课管理的功能需求，其需求简要概括如下：

✧排课信息设置：包括科目信息，上课时间，科目和教师限制信息，班级

排课信息，排课管理系统根据这些排课信息和限制信息对系统进行自动

排课。

✧自动排课和手工排课：对于用户设定了排课信息之后，系统能够自动对

课表进行安排，而且能够手工对安排完的课表进行调整，在排课过过程

当中，能够对不合理的排课结果给用户进行提示。

✧课表报表和课表查询，给出全校教师，班级课表；在课表查询中，用户

可以选择不同的教师，班级，科目，系统根据用户的选择给出相应的课

表。

需求描述是整个系统在初始阶段的开端，RRUP中，不赞成使用文档对需求进行描述，而是使用用例图和用例模型对系统建立整个需求模型。

1.1.1初始用例图

在项目开始阶段，需求不是非常清楚，但是，其需求的中心内容仍然是上面几点，在通过对需求的分析，我们确立了如下几个非常重要的用例：

✧科目信息设置

✧班级排课信息设置

✧自动排课

✧课表调整

✧课表显示与打印

上面所列出的用例即为排课管理系统的主要用例。根据这些主要用例，在项目的初始阶段，为排课管理系统确定了初始用例模型，描述了排课管理系统应该完成的功能，即从用户的角度看，系统应该具有哪些功能。初始用例模型表示如下：

图2 排课管理初始用例图

上面所列出的用例模型，基本上描述了排课系统的主要的功能，将这些基本功能实现，就形成了一个简单的排课管理系统。在项目开发的第一次迭代开发中，就是以上面确定的系统原型为基础的，这也确定了系统排课管理系统的初始架构。在排课管理系统以后的迭代开发中，都是在该模型的基础上进行扩展的。

1.1.2最后用例图

通过几次迭代，在新的需求的增加下和对系统的进一步理解，逐步完善了排课管理系统的用例模型，下面给出的用例图是当前排课系统的最新的用例模型：

图3 排课管理用例图

上面给出的排课管理用例图包括了排课管理子系统中的全部角色和用例，在实际的UML模型中，为了系统模型的清晰，一个用例模型可以使用好几个用例图来表示。在排课管理的实际建模中，我使用了三个用例图来表示用例模型，这里为了表示方便和节约篇幅，将三个用例图合并成一个。

这里给出的用例模型是当前迭代中进行的，并不表示该模型是最优最全的，模型会随着迭代开发的不断深入而不断优化和完善。

1.1.3用例描述

上面给出了系统的用例模型，对于用例图中的每个用例，只是给出了用例的名字，而没有给出该用例的描述与说明。在建模时，必须给出每个用例的说明，

描述该用例所完成的功能，以及完成该用例功能的步骤。在对CRP的用例描述中，我选了UML中的活动图来表示，当然，对用例的描述也可以使用用例说明文档来表示。为了说明如何使用活动图来表示一个用例的行为，在此给出“自动排课”用例的活动图，如下所示：

图4 自动排课活动图

上面的活动图详细地描述了自动排课用例在实际的执行的时候，它应该有哪些步骤，包括了它成功之行得到用户期望的结果和不成功执行所走的步骤。在使用活动图对自动排课用例进行描述的步骤中，有些活动可能需要优化，包括增加一些活动或者合并一些步骤，这些都会随着迭代开发的不断进行而进行优化。

1.2 分析模型

RRUP的第3步，确定了在建立分析模型开始过程中应该做的工作。分析模型的创建在整个项目的开发中是至关重要的，因为，这是一个将用例模型转化成系统中应该存在的类的阶段，是将系统功能用类如何实现的阶段。整个项目开发的后面工作，都是在分析阶段所完成的分析模型的基础上进行的，所以，在项目

的开发过程中，要确保该阶段工作的质量，严格完成该阶段应该完成的各种UML 图。

在这个阶段，找出排课管理系统中涉及的主要的类，并并且结合用例模型中的用例，将各个类与用例有机结合起来。对系统中的类，建立相应的类图来表示各个类之间的关系。而如何让用例与这些类进行结合，则需要建立相应的序列图/协作图来进行建模。

分析模型的建立，并不是一个或几个类图所能实现了，为了对一个系统进行充分建模，对于不同的项目可以选用不同的建模元素和建模机制。在对排课系统的建模中，选择了类图和序列图来构建其对应的分析模型。

1.2.1分析阶段类图

在分析模型中的给出的类图，并不需要为每个类详细定义方法和属性，在这个阶段的类图，主要反映的是系统中应该有的类和各个类之间的关系；当然，对于一些非常重要的方法和属性，特别是反映各个类之间的关系的方法和属性，在此阶段可以给出定义。

在排课管理系统的分析模型中，通过对排课系统的分析和几次迭代，找出了排课管理系统中涉及的类，并给出了如下的类图和各个类之间的关系：