学籍管理系统(UML图综合实例)

学籍管理系统建模

1．实验目的

了解一个简单的软件项目的UML建模过程和主要建模元素。 2．实验内容与要求

根据学籍管理系统的主要需求，用Rose工具软件完成对学籍管理系统的建模。 3．实验工具和方法

需要在Windows下安装ROSE工具软件。 4．实验步骤/操作指导

在实验5—1的基础上，根据学籍管理系统的主要需求完成以下四个步骤的内容。

（1）分析并得出系统的主要参与者与主要用况,并画出系统的用况图。为所有的用况撰写脚本，将脚本放于单独的word文档中，并将文档与相应的用况相连接. 1）确定系统的使用者

通过对上面问题陈述的分析，我们可以发现系统的使用者主要有Student和Professor，同时还需要Registrar来维护这个系统。此外，由于需要打印Student列表，故需要参与者Billing System；由于需要自动维护课程目录的改变，故需要参与者Course Catalog.因此应该在用况视图中添加如图5—15所示的参与者。

图5—15 参与者

2）确定系统的用况

通过对上面问题陈述的分析,我们可以知道参与者Student主要要做view report cards和register for courses两件工作,而参与者Professor主要要做Select Courses to Teach和Submit Grades两件工作.参与者Registrar要维护信息，即要做Maintain Professor Information和Maintain Student Information两件工作，此外Registrar还要控制注册何时结束，即要做Close Registration的工作。由于安全性的原因，要使用系统还需要首先做Login的工作.因此，应在用况视图中添加如图5—16所示用况。

图5—16 用况列表

3）用况图

通过上面的分析我们确定了系统中的参与者，用况以及它们之间的关系，根据这些关系，可以画出系统用况视图中的Main用况图,如图5—17所示:

图5—17 用况图

(2)实现关键用例。做出相应的顺序图和协作图，对于每一个协作，说明其静态结构和动态结构. 为了说明协作的动态结构，我们可以画出其顺序图与协作图。对于Login协作而言,由于只有一个边界类LoginForm与系统的使用者交互,而任何系统的使用者都必须登陆，故可画出其顺序图和协作图,如图5-18和图5—19所示.

图5—18 Login顺序图

图5—19 Login协作图

上面我们通过构造Login协作实现了Login用况，这里再给出register for courses用况的顺序图和协作图,如图5—20所示。

图5—20 register for courses顺序图

图5—21 register for courses协作图

(3)做出系统的关键抽象，并设计相应的类和类图. 1）发现系统中的类

在设计时,可以从问题陈述中提炼出关键的概念，并将其抽象成相应的类.由上面的问题陈述可知，主要有Student和Professor使用系统，Student应该有Schedule，系统关键处理的是Course,而应该由CourseOffering来提供相应的Course.在系统之外还有遗留下来的CourseCatalog系统.

因此可以如下图所示抽象出这些关键概念，以及与之相关的一些概念。同时还可以绘制这些关键抽象的类图,如图5—22所示.

图5-22 关键抽象的类图

2)确定关键类的属性

以CourseOffering类的属性为例，由于实体类CourseOffering的属性指明了所提供课程的关键性质，故单独对其画出类图CourseOffering （attributes）,如图5—23所示。

图5—23 CourseOffering类的属性

3）类图

针对每个关键类给出类图.以CourseOffering为例，由于实体类Schedule与实体类CourseOffering存在着主修与选修两种关联，而对于不同的关联存在不同的特征信息与处理，故对于这两个关联分别设置关联类ScheduleOfferingInfo与PrimaryScheduleOfferingInfob,用关联类的属性刻画关联的特征信息，而将关联的处理映射为关联类的操作.这里应特别注意的是对于不同的关联,CourseOffering扮演的角色以及多重性都不同.

根据上面的分析，画出CourseOffering关联类图，如图5-24所示。

图5—24 CourseOffering类图

在分析过程中，我们已经知道了实体类Schedule与实体类CourseOffering之间的主修与选修两种关联关系，对于不同的关联关系设置了关联类并画出了类图。现在，我们只需要对于分析中得出的类图作进一步完善，加入实体类Schedule的详细设计信息后,画出类图Schedule,如图5—25所示。

图5—25 Schedule类图

对于实体类Professor而言，由于它要给出所提供的课程,因此它与CourseOfferingList类有关联，

且Professor在此关联中扮演instructor角色。故可画出类图Professor，如图5—26所示。

图5—26 Professor类图

对于实体类Student而言，由于它要被分成Fulltime和Parttime两类，因此建立类Classification,并通过实体类Student对于类Classification的聚合来表现出Student所具有的分类特征.此外还须建立类Classification的子类FulltimeClassification和ParttimeClassification，它们的构造型均为entity,故用它们具体表现不同类Student所具有的不同的特征属性.

除了分类之外，由于学生要选课并最终得到自己的课表,因此类Student也要聚合实体类Schedule以代表当前学生的课程表信息.

根据上面对于实体类Student的分析，可以画出类图Student，如图5—27所示.

图5—27 Student类图

（4)实施建模分析并得出系统的节点，设计系统的实施图.

1）设计节点

通过对上面问题陈述的分析，我们可以知道Student与Professor通过PC使用本系统,同时应该有一个服务器RegistrationServer维护系统信息并控制课程的注册,还有遗留下来的课程目录系统CourseCatalog System和列表打印系统BillingSystem。同时这些节点都进行相应的处理工作，故应该全部为处理节点.这里应特别注意的是CourseCatalog System和BillingSystem由于是遗留系统,其构造型应该为legacy。故应该给系统的实施视图中添加如图5—28所示的处理节点。

图5—28 实施视图

2)设计实施图

通过上面的分析我们已经确定了系统的处理节点。在这些节点中，PC机和遗留下来的CourseCatalog System和BillingSystem都不能作为系统的中心,故应该让RegistrationServer居中协调,其它的节点通过校园网络与RegistrationServer进行通讯。这里应特别注意的是由于是通过校园网络进行通讯，故连接的构造型应该为Campus LAN.

根据上面的分析,可以画出系统的实施图，如图5-29所示.

图5-29 系统实施图

5．实验结果（实验报告要求)

分析学籍管理系统的要求，根据实验操作指导进行练习，将练习结果保存为UML模型文件提交.