UML学籍管理系统

第1章系统需求

学生学籍管理系统的域[1]描述如下：

在学生学籍管理系统中，要为每个学生建立一个帐户，并给学生发放帐户(帐户可以提供帐户号、帐户初始密码)，帐户中存储学生的个人信息。持有帐户的学生可以登陆系统，能查看和修改本人的个人信息、可查看但是不能修改选课信息、个人成绩。在登陆时，需要输入自己的账号和密码，系统验证学生是否有效(在系统中存在帐户)，若有效，则登陆系统，否则重新输入，超过三次，则不允许再次输入，学生还可以修改自己的密码。教务人员可以增加新的学生及他们的信息，也可以录入学生的成绩信息。教务人员也有自己的个人帐户，权限比学生高，可以浏览学生信息，也可以编辑、添加、删除、学生信息。

对上述学生学籍管理系统的域描述进行分析，可以获得如下功能性需求：

学生持有帐户 (帐户号和密码)。

学生可以登陆系统。

学生可以查看系统消息内的信息。

学生可以查看和修改个人信息，查看个人成绩信息和选课情况。

在学期结束时，学生可以选课。

教务人员持有账户（帐户号和密码）。

教务人员可以登录系统。

教务人员可以注册新的学生帐户。

教务人员可以修改学生的帐户信息。

教务人员可以删除已存在的学生帐户。

教务人员可以在系统中添加学生信息。

教务人员可以编辑学生信息。

教务人员可以删除学生信息。

第2章需求分析

采用用例驱动的分析方法分析需求的主要任务是识别出系统中的参与者和用例，并建立用例模型。

2.1 识别参与者

通过对系统需求的分析，可以确定系统中有三个参与者：StudentActor(学生)、AdminerActor（教务人员）。

参与者的描述如下：

(1)Student

描述：学生可以登录，查看系统信息、个人信息，提出意见，修改个人信息，还可以查看学习成绩，选课和取消选课。

示例：持有帐户的任何学生。

(2)Adminer

描述：教务人员可以维护系统，可以创建、修改、删除学生的信息，可以添加、编辑、删除学生信息，即维护目录。

示例：教务管理员。

2.2 识别用例

前面已经识别出了参与者，通过对需求的进一步分析，可以确定系统中有如下用例存在：

(1)Reserve course(选课)

本用例提供了选课的功能。

(2)Cancel course(取消选课)

本用例提供了取消选课的功能。

（3）input score（输入成绩）

本用例提供了教师上传学生成绩功能。

（4）update score（更改成绩）

本用例提供了修改成绩的功能。

（5）Maintain student Info (维护学生信息)

本用例提供了创建、修改以及取消学生帐户的功能。

（6）Maintain system Info (维护系统信息)

本用例提供了添加、修改以及删除系统信息的功能。

（7）Log In (登录)

本用例描述了用户如何登录进入软件系统。

在识别出参与者和用例后，要想建立用例图，还需要识别出他们之间的关系。“Reserve course”(选课)“Cancel course”(取消选课)这些动作是由“Student”执行的，“input score” (输入成绩)、“update score” (更、改成绩)是由“Adminer”执行的，但是对于软件系统来说，这些操作是由“Adminer”通过系统赋予给他们的，也即以上操作实际上是操作者在允许条件下与系统的交互。“Student”和参与者“Adminer”之间存在着依赖关系，即“Student”借助“Adminer”完成这些工作。用例“Maintain student Info” (维护学生信息)、“Maintain system Info”(维护物系统信息)也是与参与者“Adminer”交互。为了系统的安全性，系统还需要提供进行身份验证的功能，以确保只有具有权限的“Adminer”才可以使用系统的功能，所以“Adminer”必须与用例“登录”交互，也即“Adminer”在使用系统前，要使用用户名和密码进行登录，系统验证用户的密码正确后，用户才可以在自己的权限范围内执行进一步的操作。

系统的用例图如下图所示：

2.3 用例的事件流描述

用例的事件流是对完成用例行为所需的事件的描述。它描述系统应该做什么，而不是描述系统应该怎样做。

开始，只是对执行用例的常规流所需的步骤的简单描述。随着分析的进行，通过添入更多的详细信息，步骤不断细化。最后，将例外流添加到用例的事件流描述中。

学生成绩管理系统的用例事件流描述如下：

图2.1 系统用例图

2.3.1 选课

在这个用例开始前，student必须登录到系统中。如果这个用例成功，在系统中建立并存储选课记录，否则，系统的状态没有变化。

当学生选课时，用例启动。学生打开系统的选课系统，出现选课界面，支流S-1：开课目录。支流S-2：选课情况。

S-1：选课目录

(1)提供学期分类。

(2)检索课程类别(kind)

(3)检索要选课程名（coursename）

(4)创建选课记录。

(5)存储选课记录。

S-2: 选课情况

(1)提供是否要书。

(2)是否加权分。

(3)是否撤销。

(4)查看选课记录。

2.3.2 取消选课

在这个用例开始前，student必须登录到选课系统中。如果这个用例成功，系统删除该选课记录。否则，系统的状态没有变化。

当学生取消选课时，用例启动。

(1)检索选课程名(E-1)。

(2)删除选课记录。

E-1: 若选课记录不存在，系统显示提示信息，用例终止。

2.3.3 输入成绩

在这个用例开始前，Adminer必须登录到系统中。如果这个用例成功，系统建立输入成绩记录。否则，系统的状态没有变化。

当教务员输入成绩时，用例启动。

(1)检索学生。（E-1）

(2)输入成绩。

(3)将选课成绩存储在系统中。

E-1: 该学生不存在，系统显示提示信息，用例终止。

E-2:系统中不存在该学生，系统显示提示信息，用例终止。

2.3.4 更改成绩

在这个用例开始前，Adminer必须登录到系统中。如果这个用例成功，系统修改选课成绩。否则，系统的状态没有变化。

(1)检索学生 (E-1)。

(2)修改成绩记录。

(3)将修改记录存入系统

E-1:该学生不存在，系统显示提示信息，用例终止。

2.3.5 维护学生信息

在这个用例开始前，Adminer必须登录到系统中。如果这个用例成功，系统添加、修改或删除学生信息。否则，系统的状态没有变化。当Adminer 想维护学生信息时，用例启动。系统要求Adminer选择所想执行的活动(添加学生、删除学生、修改学生)。如果所选的活动是“注册学生”，则执行分支流S-1：注册学生。如果所选的活动是“删除学生”，则执行分支流S-2：删除学生。如果所选的活动是“修改学生”，则执行分支流 S-3：修改学生。

S-1:注册学生

(1)提供学生的信息，如姓名、学号等。

(2)系统存储学生信息(E-1)。

S-2:删除学生

(1)提供学生的信息。

(2)查询学生 (E-2)。

(3)查询学生的记录 (E-3)。

(4)从系统中删除学生的信息，以及学生的选课记录。

S-3：更改学生

(1)提供学生的信息。

(2)查询并显示学生的信息 (E-2),修改相应的信息。

(3)更新系统中学生的信息。

E-1: 若学生已存在，系统显示提示信息，用例终止。

E-2: 若查询不到学生，系统显示提示信息，用例终止。

E-3: 若无记录，系统显示提示信息，用例终止。

2.3.6 维护系统信息

在这个用例开始前，Adminer必须登录到系统中。如果这个用例成功，系统添加、修改或删除系统信息。否则，系统的状态没有变化。当Adminer 想维护系统信息时，用例启动。系统要求Adminer选择所想执行的活动(添加信息、删除信息、修改信息)。如果所选的活动是“添加系统消息”，则执行分支流S-1：添加系统信息。如果所选的活动是“删除系统信息”，则执行分支流S-2：删除系统信息。如果所选的活动是“修改系统信息”，则执行分支流S-3：修改系统信息。

S-1:添加系统信息

(1)提供添加信息种类。

(2)查询信息种类(kind),确定系统中已存在该书刊种类 (E-1)。

(3)创建信息名。

(4)将系统信息存储到系统中。

S-2: 删除系统信息

(1)提供系统信息种类。

(2)查询信息名(newname) (E-2)。

(3)删除系统信息。

(4)从系统中删除系统信息后，并更新相关信息。

S-3：修改物理学生信息

(1)提供系统信息种类。

(2)查询系统信息种类(kind)(E-1)。

(3)查询并显示该系统信息的所有消息。

(4)选择信息名修改其信息。

(5)更新系统中系统信息的信息。

E-1:若系统中不存在该信息种类，添加该书刊种类信息

E-2：若存在该信息，则删除。

2.3.7 登录

如果用例成功，参与者可以启动系统并使用系统所提供的功能。反之，系统的状态不变。当用户希望登录到系统中时，用例启动。

(1)系统提示用户输入用户名和密码。

(2)用户输入用户名和密码。

(3)系统验证输入的用户名和密码，若正确(E-1),则用户登录到系统

中。

E-1: 如果用户输入无效的用户名和/或密码，系统显示错误信息。

用户可以选择返回基流的起始点，重新输入正确的用户名和/或密码；或者取消登录，用例结束。

第3章静态结构模型

进一步分析系统需求，发现类以及类之间的关系，确定它们的静态结构和动态行为，是面向对象分析的基本任务。系统的静态结构模型主要用类图和对象图描述。

3.1 定义系统对象

系统对象的识别可以通过寻找系统域[8]描述和需求描述中的名词来进行。从前述的系统需求描述中可以找到的名词有：学生(student)、教务人员（adminer），这些都是对象图中的候选对象。

判断是否应该为这些候选对象创建类的方法是：是否有与该对象相关的身份和行为？

（1）学生(student)

学生是有身份的，具有相同名字和不同账号的两个人也是不同的。在这个系统中，学生有相关的行为，学生可以选课、取消选课，所以学生应该成为系统中的一个对象。

（2）教师（teacher）

教师也有身份，具有相同名字和不同账号的两个人也是不同的。

在这个系统中，教师有相关的行为，教师可以上传成绩、修改成绩，所以教师应该成为系统中的一个对象。

（3）选课记录(course load)

选课记录也有身份，选课记录可以被彼此区别，不会被搞混。例如，同一个人关于不同课程的选课记录是不同的，同一门课程被不同学生的选课记录也是不同的。

（4）成绩记录（score load）

成绩记录也有身份的，成绩记录可以被彼此区别，不会被搞

混。例如，同一个人关于不同课程的成绩记录是不同的，同一门课程被不同学生的成绩记录也是不同的。

上述4个类都是实体类，都是持久性的，需要存储在数据库中。本系统采用面向对象数据库[9]模型，为了便于从数据库文件中引用和检索对象，需要一个描述对象ID的类。另外，由于上述4个类都是持久性类，因此还可以抽象出一个代表持久性的父类，该类实现了面向对象数据库文件的读、写、存储、检索、删除、更新等操作。综上所述，系统中还应该有两个与数据库有关的类：对象ID(OID)和持久类(Persistent) （5）类Persistent

类Persistent为商业对象的持久存储提供了支持，它的子类必须实现从数据库文件中读、写对象属性的操作。

（6）类OID实现了对象ID。

类OID的对象可用来引用系统中的持久[10]对象，使得从数据库文件中引用和检索对象变得容易。

抽象出系统中的类后，需要确定这些对象的属性和行为。可以根据前述的系统需求分析、用例图、用例的事件流描述和描述脚本的交互作用图，来确定并细化系统中的类、类的操作和属性。下面对系统中的类、类的属性及操作逐一进行描述。(未标注返回值类型的方法使用缺省返回类型void)。

类student属性、方法见下图3.1

类Adminer属性、方法见下图3.1

Score 属性、方法见下图3.2

类Persistent属性、方法见下图3.3

类OID属性、方法见下图3.4

Windows属性、方法见下图3.1

Control属性、方法见下图3.1

图3.3类Persistent 图3.4 类OID

图3.2 类scoreload

图3.1

在定义类、类的方法和属性时，建立动态模型的时序图是很有帮助的，类图和时序图的建立是相辅相成的，因为时序图中出现的消息基本上都会成为类中的方法，因此在设计阶段绘制系统的时序图时，要尽量使用类的已识别出的方法来描述消息[11]，若出现无法用类的已识别出的方法来描述的消息，就要考虑消息是否是类的一个待识别的方法，若是，就要将这个方法及时添加到类的操作类表中，并用这个新方法来描述消息。

3.2 定义用户界面类

通过对系统的不断分析和细化，可识别出下述界面类、类的操作和属性。

(1)类MainWindow

MainWindow是系统的主界面，不同的用户登陆界面不一样。系统的主界面具有菜单和菜单项，当选择不同的菜单项时，用户可以执行不同的操作。当程序退出时，主界面窗口关闭。

(2)类studentDialog

界面类studentDialog是进行操作“添加学生”、“修改学生”

或“删除学生”时所需的对话框。

当选择主窗口中的菜单项“添加学生”时，对话框弹出，学生成绩管理员输入学生信息，然后单击按钮“添加”，系统创建学生账户并将之存储在系统中。当选择菜单项“修改学生”或“删除学生”

时，对话框FindSDialog弹出，学生成绩管理员输入要修改或删除的学生的studentID，单击按钮“OK”提交。系统查询数据库检索到学生信息后弹出对话框studentDialog，显示学生的详细信息，如若是“修改学生”，学生成绩管理员编辑修改学生的有关信息，然后单击按钮“更新”，更新系统中存储的学生信息；如若是“删除学生”，学生成绩管理员则单击按钮“删除”，系统删除所存储的该学生信息，当然，与该学生有关的其他信息业也一并删除。

(3)类FindSDialog

界面类FindSDialog是用来根据学生ID号查找学生的对话框。

当主窗口中的菜单项“删除学生”或“修改学生”被选择时，该对话框弹出，学生成绩管理员输入学生ID,单击按钮“OK”,系统查询数据库中具有指定ID号的学生信息。

(4)类InpUDialog

界面类InpUDialog是进行输入成绩操作或更改成绩操作时所需的对话框。当主窗口中的菜单项“输入”被选择时，该对话框弹出，教师输入分数，然后单击按钮“OK”,输入动作被确认，系统创建并保存成绩记录。

当选择菜单项“更改成绩”时，也弹出该对话框，教师输入学号，修改相应信息，然后单击按钮“更改”，系统中的更新记录。

(5)类ResCDialog

界面类ResCDialog是进行操作“选课”或“取消选课”时所需的对话框。当主窗口中的菜单项“选课”被选择时，该对话框弹出，学生输入要选课的信息，然后单击按钮“选课”，选课动作被确认，系统创建并保存选课记录。

当选择菜单项“取消选课”时，也弹出该对话框，学生输入课程名及信息，然后单击按钮“取消选课”，系统中的选课记录被删除。

(6)类MessageWindow

信息窗口类LoginDialog是用来显示提示信息的对话框。

(7)类LoginDialog

界面类LoginDialog是用来输入用户名和密码的对话框。

类MessageWindow属性及方法见下图3.5

类LoginDialog属性及方法见下图3.6

部分类与类之间的关系图如下所示

图

3.5MessageWindow 图3.6类LoginDialog

第4章动态行为模型

系统的动态行为模型由交互作用图(时序图和协作图)、状态图、活动图描述。

4.1 建立交互作用图

描述系统用例的主要场景的交互作用图如下所示。

4.1.1 注册新学生

“注册学生”的过程是：学生成绩管理员选择菜单项“注册新学生”，对话框弹出，学生成绩管理员输入学生信息，提交，系统根据学生ID号查询数据库，看数据库中是否已存在学生，若不存在，创建学生帐户，并存储学生信息。“注册新学生”的时序图如图4.1所示，学生成绩管理员选择菜单项“添加学生”，类MainWindow的方法addstudent()被调用，然后通过调用类studentDialog的方法createDialog()创建对话框，学生成绩管理员输入学生信息后，提交信息，类studentDialog 的方法addstudentr()被调用，通过调用类student的findBorrower()方法来确定该学生的帐户是否已存在，若不存在，则调用类student的方法newstudent()为学生创建帐户，并调用类student的方法store()存储学生信息。“注册新学生”的协作图如图4.2所

DB : DataBase 图4.2注册学生协作图

4.1.2 登录

“登录”的时序图如图4.11所示，教务人员和学生登陆系统的方式相同，只是所拥有的权限不同，所以，本登陆系统以教务人员登录为例说明。教务人员员运行系统，类LoginDialog的方法createDialog()被调用，创建对话框。学生成绩管理员键入用户名和密码，提交，类LoginDialog的方法validate()被调用，验证用户名和密码是否正确，如若正确，发送消息createWindow()给类Window，启动系统，显示系统主界面。教务人员登录系统的时序图和协作图分别如下图4.3和图4.4所示

DB : DataBase

DB : DataBase

4.1.3学生个人信息的查询和修改

学生打开系统界面后，首先输入自己的账号和密码，经过数据库验证后若密码或者账号错误，则返回到登录界面，登录失败。若数据库验证成功，登录后打开修改个人信息的窗口，可以查询信息或者输入修改信息命令，然后将命令传给数据库Database ，修改成功。个人信息查询的时序图和修改时序图分别如下图4.5和图4.6

图4.4教务员登录协作图

图4.6 学生修改个人信息时序图

4.1.4教务人员对学生信息的查询

这里的学生信息包括学生的个人信息以及选课信息和学生的成绩。我们就以查询学生的个人信息为例来进行学生的信息查询。教务员输入学号信息查询命令，数据库Database接受到Control命令之后进行相应的查询和匹配，若无查询的信息，直接返回界面给出无查询信息的结果显示。若能查询到信息就将信息经过对象Control处理将查询到的信息发送到查询的窗口。图4.7和图4.8为这个查询过程的时序图和协作图。

图4.7 教务人员查询信息时序图