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个类都是持久性类，因此还可以抽象出一个代表持久性的父类，该类实现了面向对象数据库文件的读、写、存储、检索、删除、更新等操作。