软件工程复习笔记 用例图

用例图

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

前言

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

用例图

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

  • 用例图是获取需求的直接方法
  • 用例图还是软件测试人员进行测试的指导
    软件工程复习笔记 用例图_第1张图片
    棋牌馆管理系统用例图

场景

用例是对场景的抽象,是对一组场景共同行为的抽象
关于场景

  • 在系统中,按照某个顺序执行了一系列相关的动作后,即可实现某种功能,把完成这一功能操作的集合称为场景。
  • 场景就是用户使用系统的一个实际的、特定的场面
  • 一个场景就是描述软件使用者与系统之间的一系列交互活动,系统具体执行的行为路径,即一次完成的事件流。

e.g.小刘ATM机取款3000元的场景

  1. 小刘将银行卡插入柜员机
  2. 柜员机要求客户输入卡密码
  3. 小刘输入卡密码,并确认密码
  4. 柜员机屏幕提示,请客户选择服务类型
  5. 小刘选择取款服务
  6. 柜员机提示:请客户输入取款数目
  7. 小刘输入3000,并确认
  8. 柜员机出钱口输出30张100元面值的人民币
  9. 小刘取回30张100元面值的人民币
  10. 柜员机提示服务类型:确认、继续或退卡
  11. 小刘选择服务类型退卡,结束服务

关于用例

用例是对场景的抽象,体现在两方面:
1)用例是对一组场景的抽象
2)用例的取名是对场景(事件)的概括

用例图

用例图是描述用例、参与者及其关系的图。与UML的其他图一样,用例图可以包括注释、约束。
用例图由三部分构成:

  • 参与者、一组(个)用例、关系

软件工程复习笔记 用例图_第2张图片

参与者

定义

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

图形表示
       用小人图符表示软件工程复习笔记 用例图_第3张图片

怎样识别参与者

在定义用例之前要先确定系统的参与者,下面的问题有助于我们找出系统的参与者:

  • 谁向系统提供信息?
  • 谁从系统获取信息?
  • 谁操作系统?
  • 谁维护系统?
  • 系统使用哪些外部资源?
  • 系统是否和已经存在的系统交互?
  • 由于系统对时间进行相应,“时间”是否也是一个参与者?

用例

定义

  • 对一组动作序列的描述,系统通过执行这一组动作序列为参与者产生一个可观察的结果
  • 描述参与者使用系统,以达到某个目标时所涉及到的一系列场景的集合。

用例特征

  • 说明了一个参与者与系统执行的一个相关的事务序列
  • 提供了一种获取系统需求的方法
  • 提供了一种与最终的用户和领域专家进行沟通的方法
  • 提供了一种测试系统的方法

图形表示–用椭圆形表示,用例的名字显示在图标的下面
在这里插入图片描述

怎样获取用例?

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

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

确定系统用例应注意:

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

要点:可观测,指用例是软件系统完成的功能,并且是参与者激活的,并可以反馈处理结果给参与者看。
要点:用例止于系统边界
软件工程复习笔记 用例图_第4张图片
把系统内部活动当用例
软件工程复习笔记 用例图_第5张图片

2. 用例是有意义的目标(结果值)

软件工程复习笔记 用例图_第6张图片

3. 结果值由系统生成(系统执行)

软件工程复习笔记 用例图_第7张图片

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

要点:用户观点而非系统观点即从使用者角度考虑用例的名字。
软件工程复习笔记 用例图_第8张图片

5. 用例的粒度

怎样确定用例的粒度?

  • 用例的粒度(用例的大小)可大可小,一般一个系统易控制在20个用例左右。
  • 用例是系统级的、抽象的描述,不是细化的(是做什么,非怎样做)
  • 对复杂的系统可以划分为若干个子系统处理。
    软件工程复习笔记 用例图_第9张图片

关系

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

四种基本关系:

关联(association)
  • 描述参与者与用例之间的关系;
  • 用单向箭头,表示谁启动用例;
  • 每个用例都有角色启动,除包含和扩展用例;
    软件工程复习笔记 用例图_第10张图片
包含(include)
  • 是指两个用例之间的关系。其中一个用例(基本用例,base use case)的行为包含了另一个用例(包含用例,inclusion use case)的行为。
  • 一个用况的执行需要依赖于另一个用况的实现
    软件工程复习笔记 用例图_第11张图片
    软件工程复习笔记 用例图_第12张图片
  • 如果两个以上用例有大量一致的功能,则可以将这个功能分解到另一个用例中,其他用例可以和这个用例建立包含关系。
    软件工程复习笔记 用例图_第13张图片
    执行基用例时,必须执行被包含用例,被包含用例也可单独执行。
    软件工程复习笔记 用例图_第14张图片
  • 如果一个用例的功能太多时,可用包含关系建模成两个或多个小用例。
    软件工程复习笔记 用例图_第15张图片
扩展(extend)
  • 一个用例可以被定义为基础用例的增量扩展,称作扩展关系。
  • 扩展关系是把新的行为插入到已有用例中的方法。
  • 基础用例即使没有扩展用例也是完整的。一般情况下基础用例的执行不会涉及扩展用例,只有特定条件发生,扩展用例才被执行。
    软件工程复习笔记 用例图_第16张图片
泛化(generalization)
  • 一个用例和其几种情形的用例间构成泛化关系。
  • 往往父用例表示为抽象用例。
  • 任何父用例出现的地方子用例也可出现。
    软件工程复习笔记 用例图_第17张图片

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

1.对系统的求职者模块进行用况建模
软件工程复习笔记 用例图_第18张图片
2.对系统的招聘者模块进行用况建模

软件工程复习笔记 用例图_第19张图片
3.对系统的管理员模块进行用况建模
软件工程复习笔记 用例图_第20张图片
4.对系统总体功能进行建模
软件工程复习笔记 用例图_第21张图片

用例规约(即用例说明)

       所谓规约,就是业务规则的规格说明。针对每一个用况,都应该有一个用况规约文档与之相对应,以描述该用况的细节内容。每一个用况的用况规约,都应该包含以下内容
(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. 系统返回到首页

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

软件工程复习笔记 用例图_第22张图片

建立用例模型步骤

  1. 确定系统的边界范围,找出系统中的参与者和用例。
  2. 区分用例的优先次序。
  3. 细化每个用例。
  4. 建立用例模型结构。

例 某校网上选课系统的用例分析

       管理员通过系统管理界面登录后进入系统,建立本学期要开设的各种课程,将课程信息保存到系统中,并可以对课程能进行改动和删除。
       学生可通过客户机浏览器登录后进入系统,选择课程。选课流程为:查询可选课程,选择课程并支付课程费用(可用支付宝和网银、微信三种支付方式)。
软件工程复习笔记 用例图_第23张图片

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

   我们需要询问业务需求的提出者以获取更多的信息。

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

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

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

参与者

  • 教师、学生、管理员

用例

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

2. 区分用例的优先次序

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

3、细化每个用例

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

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

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

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

4.建立用例模型结构

软件工程复习笔记 用例图_第24张图片

建模要点

(1)构建结构良好的用例

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

用例模型

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

事件流

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

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

事件流描述通常包括:

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

你可能感兴趣的:(软件工程)