用例图

• 前言
• 用例图
• 场景
• 关于用例
• 用例图
• • 参与者
  • • 怎样识别参与者
  • 用例
  • • 怎样获取用例/li>
    • 确定系统用例应注意：
    • • 1. 可观测，用例止于系统边界
      • 2. 用例是有意义的目标（结果值）
      • 3. 结果值由系统生成（系统执行）
      • 4. 业务语言、用户观点（由参与者观测）
      • 5. 用例的粒度
  • 关系
  • • 四种基本关系：
    • • 关联（association）
      • 包含（include）
      • 扩展（extend）
      • 泛化（generalization）
  • 网上求职招聘系统用例建模案例分析
• 用例规约（即用例说明）
• • 例：“修改密码”用例规约
• 建立用例模型步骤
• • 例 某校网上选课系统的用例分析
  • 例
  • • 1. 由此可得出系统的参与者及用例。
    • 2. 区分用例的优先次序
    • 3、细化每个用例
    • 4.建立用例模型结构
• 建模要点
• 用例模型
• 事件流

前言

       copy自老师的PPT，不只有知识点，还有一些相关内容的介绍顺便复制进来了。 如有问题请多指教

用例图

       用户模型视图也称为用例图，它从用户的角度来描述系统功能，并指出各功能的操作者。用例图是捕获用户需求的强有力工具，它描述了系统应该实现什么样的功能
       用例图是外部参与者所能观察到的系统功能的模型图，它将系统、子系统和类的行为可视化

• 用例图是获取需求的直接方法
• 用例图还是软件测试人员进行测试的指导
  

  参与者

  定义

  • 是直接与系统（系统、子系统或类）相互作用的外部实体的抽象。它是用户所扮演的角色，是系统的用户
  • 每个参与者定义了一个角色集合。通常，一个参与者可以代表一个人、一个计算机子系统、硬件设备或者时间等角色。
  • 典型的参与者如销售部经理、销售员和结帐系统。

  图形表示
         用小人图符表示

  

  怎样获取用例/h3>

  在确定了参与者之后，就要确定参与者要做什么，下面的问题可以帮助我们识别用例：

  • 特定参与者希望系统提供什么功能/li>
  • 系统是否要存储和检索信息（涉及创建、存储、修改、删除等）/li>
  • 需要将外界的哪些信息提供给系统/li>
  • 需要将系统的哪个事件告诉参与者/li>
  • 如何维护系统/li>

  确定系统用例应注意：

  1. 可观测，用例止于系统边界

  要点：可观测，指用例是软件系统完成的功能，并且是参与者激活的，并可以反馈处理结果给参与者看。
  要点：用例止于系统边界
  

  

  2. 用例是有意义的目标（结果值）

  

  4. 业务语言、用户观点（由参与者观测）

  要点：用户观点而非系统观点即从使用者角度考虑用例的名字。
  

  

关系

       关系反应了参与者和用例之间、用例和用例之间以及参与者和参与者之间的相互作用。
       在一个用例图中，可能会出现关联关系、依赖关系、泛化关系以及这三种关系的扩展形式：扩展关系、包含关系和精化关系。

四种基本关系：

关联（association）

• 描述参与者与用例之间的关系；
• 用单向箭头，表示谁启动用例；
• 每个用例都有角色启动，除包含和扩展用例；
  
  
  执行基用例时，必须执行被包含用例，被包含用例也可单独执行。
  

扩展（extend）

• 一个用例可以被定义为基础用例的增量扩展，称作扩展关系。
• 扩展关系是把新的行为插入到已有用例中的方法。
• 基础用例即使没有扩展用例也是完整的。一般情况下基础用例的执行不会涉及扩展用例，只有特定条件发生，扩展用例才被执行。
  

网上求职招聘系统用例建模案例分析

1.对系统的求职者模块进行用况建模

用例规约（即用例说明）

       所谓规约，就是业务规则的规格说明。针对每一个用况，都应该有一个用况规约文档与之相对应，以描述该用况的细节内容。每一个用况的用况规约，都应该包含以下内容
(1) 用例名称(Use Case Name).用例的名称一般由“动词+名词”构成，简单说明“做什么”。
(2) 简要说明(Brief Description).简要介绍该用例的作用和目的。
(3) 前置条件(Previous Condition).系统在执行该用例前必须处在的状态。
(4) 事件流(Flow of Event) 描述该用例所有可能的场景，它包括基本流和备选流。

• 基本流：描述该用例在正常情况下的场景。
• 备选流：描述用例执行过程中一场情况或突发情况。

(5) 用例场景(Use Case Scenario).包括成功场景和失败场景，场景主要由基本流和备选流组合而成。
(6) 特殊需求(Special Requirement).描述与该用例相关的非功能性需求(性能、可靠性、可用性和可扩展性等)以及涉及约束(所使用的操作系统、开发工具等)。
(7) 后置条件(Post Condition).系统在执行完该用例之后应该处在的状态 。

例：“修改密码”用例规约

• 用例名称：修改密码
• 参与者：多个求职者
• 简要说明：求职者为了密码安全且方便使用，修改了密码
• 前置条件：
  1. 求职者已经登录网上求职招聘系统
  2. 求职者输入旧密码
  3. 求职者输入新密码

基本事件流：

1. 求职者鼠标单击“修改密码”按钮
2. 系统出现一个对话框，显示“密码修改成功”
3. 求职者单击“确定”按钮
4. 用例结束

其他事件流A1：在单击“修改密码”按钮之间，求职者随时可以按“清空”按钮，文本框清空，可以重新填写内容。
异常事件流E1:

1. 系统出现一个对话框，显示“旧密码输入错误”
2. 求职者单击“确定”按钮
3. 返回到修改密码页面，旧密码文本框被清空

异常事件流E2:

1. 系统出现一个对话框，显示“密码要设在6~10位之间”
2. 求职者单击“确定”按钮
3. 返回到修改密码页面，新密码文本框被清空

异常事件流E3：

1. 系统出现一个对话框，显示“旧密码输入错误3次”
2. 系统自动将该用户注销
3. 系统返回到首页

后置条件：求职者的密码被重置，再次登录时必须使用新密码。

例

例：有一业务需求列表如下，要求我们为其构建一个用例图。
系统可以供教师使用来为学生记录成绩
系统根据需要创建报告卡
系统允许用户浏览记录的成绩

教师可以对已经输入的信息进行更新吗/em>
可以！
谁来创建报告卡，是教师吗/em>
不！有一位管理人员来做这项工作。
报告卡创建后，我们还可以对它做些什么工作/em>
在报告卡创建后，我们的管理人员要检查其准确性。当报告卡核准后，教师应该通过计算机分发报告卡。
谁需要浏览成绩/em>
教师和学生。

• 我们需要的系统可以供教师使用，来为学生记录并更新成绩。
• 系统根据需求由管理人员创建报告卡，管理人员要检查报告卡的准确性。
• 教师需要通过计算机分发报告卡。
• 系统允许教师和学生浏览记录的成绩。

1. 由此可得出系统的参与者及用例。

参与者

• 教师、学生、管理员

用例

• 记录成绩
• 更新成绩
• 生成报告卡
• 检查报告卡的准确性
• 分发报告卡
• 浏览成绩

2. 区分用例的优先次序

• 记录成绩
• 浏览成绩
• 更新成绩
• 生成报告卡
• 检查报告卡的准确性
• 分发报告卡

3、细化每个用例

对“记录成绩”用例进行细化，下面是该用例的主事件流。

1. 教师确定出要记录哪些学生的成绩。
2. 系统要确保学生在数据库中。
3. 教师说明要记录哪项作业的成绩。
4. 系统开始数据库的一项事务处理。
5. 系统为学生把作业加入数据库。
6. 教师输入学生作业的成绩。
7. 系统核对输入的成绩以确保其属于正确的范围。
8. 系统记录作业的成绩。
9. 系统结束事务的处理。
10. 系统提示教师成绩已经记录。

细化过程中可添加新发现的用例，并根据优先级重新排列。

• 登录
• 保存成绩
• 记录成绩
• 加载成绩
• 浏览成绩
• 更新成绩
• 生成报告卡
• 分发报告卡

4.建立用例模型结构

建模要点

（1）构建结构良好的用例

• 为系统和部分系统中单个的、可标识和合理的原子行为命名；
• 将公共的行为抽取出来，放到一个被包含用例中，再将它《include》进来；
• 对于变化部分，将其抽取出来，放到一个扩展用例（用《extent》连接）中；
• 清晰地描述事件流
  （2）构建结构良好的用例图
  （3）根据系统实际情况控制粒度

用例模型

一个用例模型由一个或者多个用例图和所有的支持文件（诸如用例规范和参与者定义等）所构成。用例规范是大多数用例模型的产物，而用例图充当将需求模型综合在一起的粘胶剂。
用例模型应当从项目投资者的角度进行开发，而不是从开发者的（通常是技术）观点去开发。

事件流

执行用例时，其动作的有序集合称为事件流

• 事件流描述的目的是建立用例中逻辑流程的文档，详细描述系统用户的工作和系统本身的工作，既包括正常状态下系统完成需求行为的事件，也包括在其他状态下不能完成需求行为的事件。

事件流描述通常包括：

• 简要说明
• 前置条件
• 事件流
• 后置条件

来源：来一粒4869