UML学籍管理系统.docVIP

第1章 系统需求 学生学籍管理系统的域[1]描述如下： 在学生学籍管理系统中，要为每个学生建立一个帐户，并给学生发放帐户(帐户可以提供帐户号、帐户初始密码)，帐户中存储学生的个人信息。持有帐户的学生可以登陆系统，能查看和修改本人的个人信息、可查看但是不能修改选课信息、个人成绩。在登陆时，需要输入自己的账号和密码，系统验证学生是否有效(在系统中存在帐户)，若有效，则登陆系统，否则重新输入，超过三次，则不允许再次输入，学生还可以修改自己的密码。教务人员可以增加新的学生及他们的信息，也可以录入学生的成绩信息。教务人员也有自己的个人帐户，权限比学生高，可以浏览学生信息，也可以编辑、添加、删除、学生信息。 对上述学生学籍管理系统的域描述进行分析，可以获得如下功能性需求： 学生持有帐户 (帐户号和密码)。 学生可以登陆系统。 学生可以查看系统消息内的信息。 学生可以查看和修改个人信息，查看个人成绩信息和选课情况。 在学期结束时，学生可以选课。 教务人员持有账户（帐户号和密码）。 教务人员可以登录系统。 教务人员可以注册新的学生帐户。 教务人员可以修改学生的帐户信息。 教务人员可以删除已存在的学生帐户。 教务人员可以在系统中添加学生信息。 教务人员可以编辑学生信息。 教务人员可以删除学生信息。 第2章 需求分析 采用用例驱动的分析方法分析需求的主要任务是识别出系统中的参与者和用例，并建立用例模型。 2.1 识别参与者 通过对系统需求的分析，可以确定系统中有三个参与者：StudentActor(学生)、AdminerActor（教务人员）。 参与者的描述如下： Student 描述：学生可以登录，查看系统信息、个人信息，提出意见，修改个人信息，还可以查看学习成绩，选课和取消选课。 示例：持有帐户的任何学生。 Adminer 描述：教务人员可以维护系统，可以创建、修改、删除学生的信息，可以添加、编辑、删除学生信息，即维护目录。 示例：教务管理员。 2.2 识别用例 前面已经识别出了参与者，通过对需求的进一步分析，可以确定系统中有如下用例存在： 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.1 系统用例图 图2.1 系统用例图 2.3 用例的事件流描述 用例的事件流是对完成用例行为所需的事件的描述。它描述系统应该做什么，而不是描述系统应该怎样做。 开始，只是对执行用例的常规流所需的步骤的简单描述。随着分析的进行，通过添入更多的详细信息，步骤不断细化。最后，将例外流添加到用例的事件流描述中。 学生成绩管理系统的用例事件流描述如下： 2.3.1 选课 在这个用例开始前，student必须登录到系统中。如果这个用例成功，在系统中建立并存储选课记录，否则，系统的状态没有变化。 当学生选课时，用例启动。学生打开系统的选课系统，出现