UML学籍管理系统.pdf

第1章系统需求

[1]

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

在学生学籍管理系统中，要为每个学生建立一个帐户，并给学生发

放帐户(帐户可以供应帐户号、帐户初始密码)，帐户中存储学生的个人

信息。持有帐户的学生可以登陆系统，能查看和修改本人的个人信息、

可查看但是不能修改选课信息、个人成果。在登陆时，须要输入自己的

账号和密码，系统验证学生是否有效(在系统中存在帐户)，若有效，则

登陆系统，否则重新输入，超过三次，则不允许再次输入，学生还可以

修改自己的密码。教务人员可以增加新的学生及他们的信息，也可以录

入学生的成果信息。教务人员也有自己的个人帐户，权限比学生高，可

以阅读学生信息，也可以编辑、添加、删除、学生信息。

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

需求：

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

学生可以登陆系统。

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

学生可以查看和修改个人信息，查看个人成果信息和选课状况。

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

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

教务人员可以登录系统。

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

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

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

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

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

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

第2章需求分析

采纳用例驱动的分析方法分析需求的主要任务是识别出系统中的参

加者和用例，并建立用例模型。

2.1识别参加者

通过对系统需求的分析，可以确定系统中有三个参加者：

StudentActor(学生)、AdminerActor（教务人员）。

参加者的描述如下：

(1)Student

描述：学生可以登录，查看系统信息、个人信息，提出看法，

修改个人信息，还可以查看学习成果，选课和取消选课。

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

(2)Adminer

描述：教务人员可以维护系统，可以创建、修改、删除学生

的信息，可以添加、编辑、删除学生信息，即维护书目。

示例：教务管理员。

2.2识别用例

前面已经识别出了参加者，通过对需求的进一步分析，可以确定系

统中有如下用例存在：

(1)Reservecourse(选课)

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

(2)Cancelcourse(取消选课)

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

（3）inputscore（输入成果）

本用例供应了老师上传学生成果功能。

（4）updatescore（更改成果）

本用例供应了修改成果的功能。

（5）MaintainstudentInfo(维护学生信息)

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

（6）MaintainsystemInfo(维护系统信息)

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

（7）LogIn(登录)

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

在识别出参加者和用例后，要想建立用例图，还须要识别出他们

之间的关系。“Reservecourse”(选课)“Cancelcourse”(取消选

课)这些动作是由“Student”执行的，“inputscore”(输入成

果)、“updatescore”(更、改成果)是由“Adminer”执行的，但是

对于软件系统来说，这些操作是由“Adminer”通过系统给予给他们

的，也即以上操作事实上是操作者在允许条件下与系统的交互。

“Student”和参加者“Adminer”之间存在着依靠关系，即

“Student”借助“Adminer”完成这些工作。用例“Maintain

studentInfo”(维护学生信息)、“MaintainsystemInfo”(维

护物系统信息)也是与参加者“Adminer”交互。为了系