实验二 用例图
【实验目的】
- 掌握用例的概念。
- 掌握UML中用例图的组成、作用以及使用场合。
- 掌握用例与用例之间的各种关系。
- 学习针对具体场景使用用例图进行分析说明的方法。
- 掌握用例描述的概念和基本结构,以及用例描述的作用。
【实验性质】
设计性实验。
【实验要求】
- 学习针对具体场景识别参与者和用例的方法,设计其用例图。
- 学习通过Rational Rose绘制用例图的方法。
- 掌握如何对每个用例进行用例描述。
【实验内容】
一.网上选课系统需求分析
1.某学校的网上选课系统主要包括如下功能:管理员通过系统管理界面进入,建立本学期要开的各种课程,将课程信息保存在数据库中并可以对课程进行改动和删除;学生通过客户机浏览器根据学号和密码进入选课界面,在这里学生可以进行三种操作:查询已选课程、选课以及付费。同样,通过业务层,这些操作结果存入数据库中。
2.对本系统的的用例、参与者进行分析:
本系统拟使用java语言通过三层模型实现:数据核心层、业务逻辑层和接入层。数据核心层包括对数据库的操作;业务逻辑层作为中间层对用户输入进出逻辑处理,在映射到相应的数据层操作;接入层包括用户界面、系统登录界面、管理界面、用户选课界面等。
本系统涉及的用户包括管理员和学生,是用例图中的活动者,他们的主要特征类似,都有学号和姓名等信息,可抽象出“基”活动者people,而register和student则从people诞生,数据库管理系统是另外一个活动者。
- 写出系统中出现的一些事件流,如添加课程事件流、删除课程事件流、修改课程事件流,选课事件流等。
下面是系统中出现的一些事件流。
添加课程事件流:
- 管理员选择进入管理界面,用例开始。
- 系统提示输入管理员密码。
- 管理员输入密码。
- 系统验证密码。
A1:密码错误
- 进入管理界面,系统显示目前所建立的全部课程信息。
- 管理员选择添加课程。
- 系统提示输入新课程信息。
- 管理员输入信息。
- 系统验证是否和已有课程冲突。
A2:有冲突
- 系统添加新课程,提示课程添加成功。
- 系统重新进入管理主界面,显示所有课程。
- 用例结束。
其他事件流:
A1:密码错误
- 系统提示再次输入密码
- 用户确认
- 三次错误,拒绝再次访问。
- 否则进入添加课程事件流第e)步。
A2:有冲突
- 系统提示有冲突,显示冲突课程信息
- 用户重新输入
- 继续验证直到无冲突
- 进入添加课程事件流第j)步
删除课程事件流和修改课程事件流于此类此。
选课事件流:
- 学生进入选课登录界面,用例开始。
- 系统提示输入学号和密码
- 学生输入学号和密码
- 系统验证课程是否可选
A1:验证失败
- 进入选课主界面
- 学生点击选择课程
- 系统显示所有课程信息
- 学生选择课程
- 系统验证选课是否成功
A2:选课不成功
- 系统提示课程选择成功,提示学生交费
- 用例结束。
错误流:
A1:验证失败
- 系统提示验证失败,提示重新输入
- 三次错误,拒绝再次访问
- 成功,转选课事件流第e)步
A2:选课不成功
- 系统提示课程不可选以及原因
- 学生重新选课
- 重新验证直至成功
- 转选课事件流第j)步。
因为付费方式多样,再次不必讨论付费用例。查询事件流比较简单,在这里也不用详细描述。
根据以上描述,绘制系统的用例图。并选择其中一个用例(如添加课程Add Course)给出其用例描述。
用例的描述格式(参考模板)
描述项 | 说明 |
用例名称 | 表明用户的意图或用例的用途,如“预订图书” |
标识符[可选] | 惟一标识符,如“UC1701”,在文档其他地方可用标识符来引用这个用例 |
用例描述 | 概述用例的几句话 |
参与者 | 与此用例相关的参与者列表 |
优先级 | 一个有序的排列,1代表优先级最高 |
状态[可选] | 用例的状态,通常为以下几种之一:进行中、等待审查、通过审查或未通过审查 |
前置条件 | 访问用例前必须满足的条件列表 |
后置条件 | 用例完成以后得到满足的条件列表 |
基本操作流程 | 描述用例中各项工作都正常进行时用例的工作方式 |
可选操作流程 | 描述变更工作方式、出现异常或发生错误的情况下所遵循的路径 |
被泛化的用例 | 此用例所泛化的用例列表 |
被包含的用例 | 此用例所包含的用例列表 |
被扩展的用例 | 此用例所扩展的用例列表 |
修改历史记录[可选] | 关于用例的修改时间、修改原因和修改人的详细信息 |
问题[可选] | 与此用例的开发相关的问题列表 |
决策[可选] | 关键决策的列表,将这些决策记录下来以便维护时使用 |
频率[可选] | 参与则访问此用例的频率,如用户是每日访问一次还是每月访问一次 |
用例“添加图书”的描述
用例名称 | 添加图书 |
标识符 | UC0001 |
用例描述 | 图书管理员在收到新采购的图书后对之进行入库。 |
参与者 | 图书管理员 |
优先级 | 1 |
状态 | 通过审查 |
前置条件 | 图书管理员登录进入系统 |
后置条件 | 在库图书数目增加 |
基本操作流程 |
|
可选操作流程 | 系统检查图书书目不存在,系统添加新的图书书目; |
被泛化的用例 | 无 |
被包含的用例 | 无 |
被扩展的用例 | 无 |
修改历史记录 | 张三,定义基本操作流程,2009年3月20日 张三,定义可选操作流程,2009年3月20日 |
网上选课系统的参考用例图如下:
二.“学生信息管理系统”需求分析
1.功能性需求包括以下内容:
(1)系统管理员登录后可以对班级的基本信息进行增加、删除、修改、查询等操作。学校领导登录后可以对班级基本信息进行查询操作。
(2)教师登录后可以对学生的考试成绩进行录入、删除、修改、查询等操作。学生登录后可以对考试成绩进行查询操作。
(3)学生登录后可以了解所有选修课程的具体信息,可以根据自己的需要选择不同课程。系统管理员登录后可以增加、修改、查询、删除选修课程。
(4)系统管理员可以对账号进行创建、设置、查看、删除等操作。
2. 识别参与者
(1)对于一个学校来说,最重要的就是教育学生成才,所以我们首先要考虑到的参与者就是学生。
(2)要给学生上课,必然就需要教师。教师负责教育学生、并且在日常管理中可以查询学生的基本信息、查询学生的考试成绩。
(3)作为一个学校,除了教师和学生,还有不可或缺的就是校领导。为了便于校领导掌握学校的基本情况,加强对学校的管理导。
(4)不管什么系统,基本都会有比较专业的人员来负责管理系统,本系统也不例外。系统管理员除了负责维护系统的日常运行,还要进行录入学生基本信息、维护选课信息等工作。
3. 构建用例模型
(1)系统管理员直接参与的用例为登录、找回密码、查看班级基本信息、删除班级基本信息、修改班级基本信息和录入班级基本信息。校领导直接参与用例登录、找回密码和查看班级基本信息。当登录过程中发生忘记密码的情况,就需要使用找回密码的功能来找回密码,而在正常情况下用不到找回密码这个功能所以用例“找回密码”和用例“登录”之间是扩展关系。 根据以上分析,绘制出系统管理员和校领导作为参与者的用例图。
(2)学生作为参与者直接参与用例查看课程信息、按课程编号查看、按课程名查看、选择课程、删除已选课程、登录和找回密码。系统管理员参与用例登录、找回密码和“维护课程信息”。其中查看课程信息有两种方式,一种是按照课程名查看,另一种是按照课程编号查看。所以查看课程信息是父用例,而按照课程名查看和按照课程编号查看是子用例,他们之间的关系是泛化关系。用例找回密码和用例登录之间是扩展关系。根据以上分析,绘制出学生和系统管理员作为参与者的用例图。
(3)教师参与用例录入成绩、修改成绩、保存成绩、查询成绩、删除成绩和登录。学生参与用例登录和查询成绩。因为修改成绩和录入成绩的时候都要保存成绩,所以将保存成绩抽象出来作为单独的一个用例。用例录入成绩、修改成绩和用例保存成绩之间是包含关系,用例找回密码和用例登录之间是扩展关系。根据以上分析,绘制出教师和学生作为参与者的用例图。
(4)系统管理员参与用例创建新账号、设置账号、设置账号基本信息、设置账号权限、查看账号和删除账号。在设置帐号时,主要分为设置账号的基本信息和设置账号的权限,为了便于修改和维护,将这两个功能分别抽象为两个用例。所以用例设置账号基本信息、设置账号权限和用例设置账号之间是包含关系。根据以上分析,绘制出系统管理员的用例图。