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分析阶段类图在分析模型中的给出的类图，并不需要为每个类详细定义方法和属性，在这个阶段的类图，主要反映的是系统中应该有的类和各个类之间的关系；当然，对于一些非常重要的方法和属性，特别是反映各个类之间的关系的方法和属性，在此阶段可以给出定义。
在排课管理系统的分析模型中，通过对排课系统的分析和几次迭代，找出了排课管理系统中涉及的类，并给出了如下的类图和各个类之间的关系：图5 排课管理类图(分析)在上面给出的类图中，选择了Rose提供的三种类的表示，即边界类、控制类、和实体类，并表示了各个类之间的关系。
边界类是与用户交互的界面类的抽象；控制类是系统中的一些计算、控制类的抽象；实体类是存储数据的类的抽象。
为了图的整洁，在上图中，没有给出类的关键方法和属性的定义，在实际的模型中，给出了一些类关键方法和属性。
上面类图中，将排课管理中的类分成三种，并构建了类图，这种表示方法能够清楚地表示各个类在系统中所处的位置，更加直观；当然，在实际建模中，也不一定要选择这种表示，开发人员可以根据自己项目的实际情况来选择相应的建模元素。
1.2.2实体类关系图在上面的类图中，我们仅仅给出了三种类之间的关系，但是这样表示还是不够的。
实体类之间也是有一定的关系的，对此，我们使用了另一个类图来表示各个实体类之间的关系，如下图：图6 排课管理实体类关系类图上图给出了排课管理系统中的实体类以及实体类之间的关系，在CRP系统中，很多实体类最后都对应数据库系统中相应的表。
建立实体类以及实体类之间的关系对于系统的数据库建模也是有很大的帮助的。
1.2.3序列图/协作图创建RRUP的第5步确定了在分析阶段所应该做的另一项工作，即把所要开发的用例所具有的功能用各个类的对象之间协作和通讯来表示。
在这之前，所做的所有模型都是属于UML的静态建模机制中的；而现在所要用到的建模元素是属于UML的动态建模机制的。
在RRUP的第5步中讲到可以使用UML中的序列图/协作图来表示在系统运行时，完成该用例功能系统的内部协作关系。
序列图和协作图是等价的，在Rose中，可以将序列图自动转换成等价的协作图，协作图也可以自动转换成相应的协作图。
到底采用哪种建模元素，完全取决于项目的实际需要，而且，这两种图只需要构造其中的一种就可以了。
在一般的实时系统中，一般采用序列图，在序列图中，能够清楚地看到各个对象之间交互时的时间与顺序关系。
而在其他的不强调时间与顺序的情况下，使用协作图来表示对象间的关系。
在对排课管理系统的动态建模中，根据不同用例的不同情况，我选择了这两种建模机制，当比较强调时间或顺序时，选择序列图来表示，否则，选择协作图来表示相应的用例的在系统运行时的动态执行情况。
在此，给出了自动排课用例的序列图，如下图所示：图7 自动排课序列图在创建用例的序列图的过程中，应该注意各个类的初级设计，即发现各个类的方法和属性，而且，一般在此阶段发现的类的属性和设计都是非常重要和关键的，当然对于这个阶段发现的方法和属性不需要进行严格的定义，对方法和属性的严格定义可以放在设计阶段去完成；但是，对于每一个发现的方法和属性应该记录下来，可以使用文字进行详细的描述。
对于方法，如果能够确定其参数，返回值，也必须进行描述，或者将其定义确定下来。
在创建和验证UML的过程中，要做如下工作：✧对于某个类，如果已经存在方法和属性，要详细描述，能够准确定义的，则需要进行准确定义。
✧对于某各类，如果发现新的方法或属性，也要进行详细描述，描述应该包括参数，返回值，功能等等。
✧如果在建模过程中，需要增加一些类或删除一些类，或对一些类进行合并，验证后，要立即修改相应的类图。
1.2.4类的描述在对自动排课用例的序列图创建过程中，也是经过这样的步骤，逐渐来增加该类的方法和属性的。
自动排课类在此阶段发现的方法和属性简要归纳如下，对于这些属性和方法的描述性的：自动排课类：属性：pClassSubject：保存各个班级的需要安排的科目信息。
pArranging：当前正在安排的科目信息。
pLimitInfo：当前安排科目和教师的限制信息。
方法：Arrange：为某科目安排一节位置。
GetClassSubject：得到排课信息。
ConflictCheck：冲突检测。
NotifyUser：通知用户。
AddCourseArrange：增加新的排课结果在上面的自动排课类的方法和属性会随着分析和设计的不断深入和迭代开发的不断进行而增加和优化；上面给出的属性和方法是一些不可缺少的，在以后的迭代中被修改的可能性也比较少，当然，也可能会被修改，这些方法和属性的确定，对一个类来说是非常重要的。
RRUP的第6步中，应该确定一些类的对象的状态图，当然这些类必须具有一些非常明显的状态。
在排课管理系统中，没有发现那些类的对象具有或可能具有的一系列的状态，对于一些对象只具有一到两个状态，就没有必要为其建立相应的状态图。
1.3 设计模型在对排课管理系统创建分析模型之后，应该进行设计模型的创建阶段，这是RRUP第7步和第8步中所规定的工作。
设计阶段的工作，在整个项目的开发过程中是一项非常重要的工作，该阶段完成的模型在最后直接向代码进行转化。
在RRUP中，设计阶段的工作必需在分析阶段所确定的模型的基础上进行，它所设计每一个类在分析阶段都是存在的，如果发现确实需要增加的类，则需要在分析模型中增加该类，并验证是否确实需要增加；在设计阶段，不赞成过多地回头去增加或删除分析模型中各个类图中类。
在设计阶段的工作，简单来说，是根据分析模型，建立相应的设计模型；确切地说，是定义分析阶段所确定的每一个类，即定义每个类的方法和属性，并确定每个成员的可见性；可见性包括每个类成员是私有、保护、还是公有的。
