学生成绩管理系的分析及设计-应用UML建模.doc

第1章 系统需求 学生成绩管理系统的域[1]描述如下： 在学生成绩管理系统中，要为每个学生建立一个帐户，并给学生发放帐户(帐户可以提供帐户号、帐户初始密码)，帐户中存储学生的个人信息、选课信息以及课程成绩。持有帐户的学生可以登陆系统，只能查看本人的个人信息、选课信息、个人成绩。在登陆时，需要输入自己的账号和密码，系统验证学生是否有效(在系统中存在帐户)，若有效，则登陆系统，否则重新输入，超过三次，则不允许再次输入。老师可以修改学生成绩信息，但仅限于学生选修的那门课程。老师也有自己的个人帐户，权限比学生高，可以浏览学生信息。学生成绩管理系统的管理员，可以编辑、添加、删除、学生信息。 对上述学生成绩管理系统的域描述进行分析，可以获得如下功能性需求： 学生持有帐户 (帐户号和密码)。 学生可以登陆系统。 学生可以查看系统消息内的信息。 学生可以查看个人信息，个人成绩信息和选课情况。 在学期结束时，学生可以选课。 学生可以给管理员发消息。 老师可以修改选修自己课程的学生的成绩信息。 老师可以浏览选修自己课程的学生的信息。 学生成绩管理员可以创建新的学生帐户。 学生成绩管理员可以修改学生的帐户信息。 学生成绩管理员可以删除已存在的学生帐户。 学生成绩管理员可以在系统中添加学生信息。 学生成绩管理员可以编辑学生信息。 学生成绩管理员可以删除学生信息。 第2章 需求分析 采用用例驱动的分析方法分析需求的主要任务是识别出系统中的参与者和用例，并建立用例模型。 2.1 识别参与者 通过对系统需求的分析，可以确定系统中有三个参与者：StudentActor(学生)、TeacherActor(教师)、AdminerActor（管理员）。 参与者的描述如下： Student 描述：学生可以登陆、选课、查看系统信息、个人信息、提出意见，还可以取消选课。 示例：持有帐户的任何人或组织。 Teacher 描述：可以修改学生部分信息，浏览学生信息。 示例：持有帐户的任何人和组织。 Adminer 描述：学生成绩管理员维护系统，可以创建、修改、删除学生的信息，可以添加、编辑、删除学生信息，即维护目录。 示例：学生成绩管理员。 2.2 识别用例 前面已经识别出了参与者，通过对需求的进一步分析，可以确定系统中有如下用例存在： Reserve course(选课) 本用例提供了选课的功能。 (2)Cancel course(取消选课) 本用例提供了取消选课的功能。 （3）input score（输入成绩） 本用例提供了教师上传学生成绩功能。 （4）update score（更改成绩） 本用例提供了修改成绩的功能。 （5）Maintain student Info (维护学生信息) 本用例提供了创建、修改以及取消学生帐户的功能。 （6）Maintain teacher Info (维护教师信息) 本用例提供了添加、修改、以及删除教师帐户的功能。 （7）Maintain system Info (维护系统信息) 本用例提供了添加、修改以及删除系统信息的功能。 （8）Log In (登录) 本用例描述了用户如何登录进入软件系统。 在识别出参与者[3]和用例后，要想建立用例图，还需要识别出他们之间的关系。“Reserve course”(选课)“Cancel course” (取消选课) 这些动作是由“Student”执行的，“input score” (输入成绩)、“update score” (更、改成绩)是由“teacher”执行的，但是对于软件系统来说，这些操作是由“Adminer”通过系统赋予给他们的，也即以上操作实际上是操作者在允许条件下与系统的交互。“Student”“teacher ”和参与者“Adminer”之间存在着依赖关系，即“Student”借助“Adminer”完成这些工作。用例“Maintain student Info” (维护学生信息)、“Maintain teacher Info” (维护教师信息)、“Maintain system Info”(维护物系统信息)也是与参与者“Adminer”交互。为了系统的安全性，系统还需要提供进行身份验证的功能，以确保只有具有权限的“Adminer”才可以使用系统的功能，所以“Adminer”必须与用例“登录”交互，也即“Adminer”在使用系统前，要使用用户名和密码进行登录，系统验证用户的密码正确后，用户才可以执行进一步的操作。 系统的用例图如下图所示： 2.3 用例的事件流描述 用例的事件流[4]是对完成用例行为所需的事件的描述。它描述系统应该做什么，而不是描述系统应该怎样做。 开始，只是对执行用例