学生选课系统完整的UML建模.doc

UML系统分析设计与建模 以简单的学生选课系统进行详细的系统分析与建模。 (一)系统用例图 1.首先根据需求分析可知：管理员维护课程信息，对其进行添加、修改、删除等。学生可以在线查询课程信息，并进行选课，也可以在规定时间内更改选修的课程。我们发现系统中的参与者有：管理员和学生，然后从参与者的角度就可以发现系统的用例，并绘制出系统的用例图，如图1所示： 2.对部分用例进行描述： “添加课程”用例 用例名：添加课程 执行者：管理员 目的：管理员通过系统界面进入，添加所要开设的课程，确认无误后将其信息保存到数据库中，以供学生选择。 过程描述： 管理员选择进入管理界面，用例开设 系统提示输入管理密码 管理员输入密码 系统验证密码 A1:密码错误 进入管理界面，系统显示目前所建立的全部课程信息 管理员选择添加课程 系统提示输入新课程信息 管理员输入信息 系统验证是否和已有的课程冲突 A2：有冲突 10）系统添加新课程，提示课程添加成功 11）系统重新进入管理界面，显示所有课程 12）用例结束 异常事件流处理： A1：密码错误 ：1）系统提示再次输入。2)用户确认后进入第5)步。 A2：有冲突 ：1)系统提示冲突，显示冲突的课程信息。2）用户重新输入，验证无误后进入第10）步。 “选课”用例 用例名：选课 执行者：学生 目的：学生进入选课系统界面，浏览的课程，最后选择一门自己喜欢的课程并提交。 过程描述： 1）学生进入选课登录界面，用例开始 2) 系统提示输入学号与密码 3) 学生输入学号与密码 4）系统验证 A1：验证错误 5) 进入选课主界面 6）学生点击选课 7）系统显示所有课程信息 8）学生选择课程 9）系统验证课程是否可选 A2：不可选 10）系统提示课程选择成功 11）用例结束 异常事件流处理： A1：验证错误： 1）系统提示验证错误，提示重新输入。2）验证成功，进入第5）步 A2：不可选 1)系统提示课程不可选及原因。2）学生重新选课。3）验证成功后进入第10）步 “修改”用例 管理员选择进入管理界面，用例开设 系统提示输入管理密码 管理员输入密码 系统验证密码 A1:密码错误 进入修改主界面，系统显示目前所建立的全部课程信息 管理员选择要修改的课程 是否确定修改该课程 A2：不修改 系统显示全部课程信息 管理员输入新信息 验证是否有课程冲突 A3：冲突 系统修改课程，提示修改成功 系统重新进入主界面，显示所有课程 用例结束 异常事件流处理： A1:密码错误 ：1）系统提示再次输入。2)用户确认后进入第5)步。 A2：不修改：1) 系统提示重新选择。2)用户确认后进入第8)步。 A3：有冲突 ：1)系统提示冲突，显示冲突的课程信息。2）用户重新输入，验证无误后进入第11）步。 （二）系统活动图 活动图实际上也是一种流程图，它描述活动的序列，即系统从一个活动到另一个活动的控制流。所以常用活动图来进一步描述用例的具体功能实现流程，比文字描述跟形象直观，能够更准确地理解具体实现要求。 以 “增加课程”用例为例，建立系统的活动图。其它用例的活动图不在叙述。 1.对“增加课程”用例进行分析，描述完成该操作所需要的活动。首先从“输入课程各项信息”开始，在输入工作完成后，进入业务逻辑界面的“验证课程”活动，然后进行“创建课程对象”活动，并输入“在数据库中查询课程”，查看数据库中是否已存在该课程。根据查询的结果“判断增加课程是否合法”，如果不合法（如重名等），提示“重新输入”返回到“输入课程各项信息”；如合法，则在数据库中正式增加这个对象。最后进行“判断添加是否成功”，如果成功，返回用户界面“显示添加成功信息”提示用户活动结束：如失败，“显示添加失败信息”，提示任务没有完成，活动结束。 2.根据对“增加课程”用例的分析，画出其活动图，如图2： （三）系统顺序图 顺序图注重的是消息的时间顺序，它描述对象间的交互行为。而合作图强调对象间关系，这两种图可以有效地帮助我们观察和分析系统的交互行为。 以 “选课”用例为例，建立系统的顺序图。其它用例的顺序图不再叙述。 1.首先，查找“选课”用例的对象，它涉及到课程，界面，控制对象。设计的角色有student，database。然后通过选课事件流具体分析对象与角色之间的交互的消息。 2.根据以上分析，可以得到的顺序图如图3： （四）系统合作图 根据上述建立的顺序图，选中它然后按下F5键，生成对应的合作图（在设计中，只要做成其中的一种，就可生成另一种图） （五）系统状态图 状态图用来建模对象是如何改变其状态以响应事件和展示对象从创建到删除的生命周期。状态图的任务就是用来描述一个对象所处的可能状态以及状态之间的转