Fork me on GitHub

用例建模和分析

描述用例建模的优点
定义参与者和用例,并能够从上下文图以及其他资源中确定参考图和用例
描述四类参与者
描述用例模型图种可能出现的关系
描述准备用例模型图的准备
描述如何构造用例模型图
描述用例的各节内容
定义用例分级的目的、优先权矩阵,以及用例依赖关系图

关键术语

37.需求分析

clip_image001 以用户为中心的开发:一个系统开发过程,该过程基于对关联人员的需求,以及对开发该系统原因的充分理解之上

clip_image002 用例建模:使用业务时间、发起业务事件的人,以及系统如何相应这些事件来建模系统功能的过程

clip_image002[1] 用例图:描述系统与外部其他系统以及用户之间交互的图形。用例图描述了谁将使用系统,用户希望以什么方式与系统交互

功能分解:将一个系统拆分成子构件的活动

clip_image002[2] 用例描述:业务事件以及用户如何同系统交互以完成任务的文字描述

用例:一个行为上相关的步骤序列,既可以是自动的也可以是手工的 ,其目的是完成一个单一的业务任务

参与者:代表了需要同系统交互以交换信息的任何事物

时序事件:由时间触发的系统事件

关联关系:一个参与者与一个用例发生交互的关系

32用例

扩展用例:一个由从某个更复杂的用例中提取出来的步骤构成的用例,以便简化原始用例以扩展器功能

clip_image002[3] 抽象用例:通过组合几个用例中公共的步骤来降低用例之间的冗余

clip_image002[4] 依赖:用例之间的一种关系,表示一个用例需要等到另一个用例执行之后才能执行

clip_image002[5] 继承:参与者之间的一种关系,创建继承关系的目的是当一个抽象参与者继承多个实际参与者的角色时简化绘图

业务需求用例:在需求分析过程中为了捕捉用户与系统之间交互而建立的用例,并没有技术和实现细节,也称为基本用例

clip_image002[6] 用例分级和评估矩阵:用来评估用例决定其优先级的工具

clip_image002[7] 用例依赖关系图:用例之间的依赖关系的图形化表示

用例建模概述

33.用例建模

构建一个软件系统最困难的部分是正确地确定要构建什么。其他任何工作都不如建立详细的技术需求困难,这包括提供给人、机器和其他软件系统的界面和接口。如果做错了的话,没有任何工作会如此扭曲最终的系统。也没有任何一部分更难以在日后更改。

软件开发工业已经懂得了:为了成功地计划、分析、设计、构造和部署一个信息系统,系统分析员首先必须理解关联人员的需求,以及开发该系统的原因——以用户为中心的开发。通过关注系统的用户,分析员能够把重点放在系统如何使用,而不是系统如何构造上,用例建模是一种促进以使用为中心的开发方法。

用例建模促进并鼓励了用户参与,这是确保项目成功的主要关键因素之一。另外,用例建模具有以下的优点:

  1. 提供了捕捉功能需求的工具
  2. 有助于将系统范围分解成更易管理的小块
  3. 提供了与用户以及其他关心系统功能的关联人员进行交流的工具。用例是容易被各种关联人员理解的公共语言
  4. 提供了确定、分配、跟踪、控制和管理系统开发活动(尤其是增量开发和迭代开发活动)的手段
  5. 辅助估计项目范围、投入和进度
  6. 为定义测试计划和测试用例提供了一个基准
  7. 为用户帮助系统和手册以及系统开发文档提供了一个基准
  8. 提供了需求跟踪的工具
  9. 提供了确定数据对象或实体的起点
  10. 提供了设计用户和系统接口的功能规格说明
  11. 提供了定义数据库访问需求(增加、修改、删除和读取)的手段
  12. 提供了驱动系统开发项目的一个框架

用例建模的系统概念

用例建模主要有两个产物。第一个是用例图,它以图形化的方式将系统描述成用例、参与者(用户)及其之间的关系。用例图在高层交流了系统必须处理的业务事件的范围。第二个产物是用例描述,填充了每个业务事件,并说明了用户如何同系统交互的细节。

          用例

          参与者

          关系(关联关系、扩展关系、包含关系、依赖关系、继承关系)

需求用例建模过程

34.用例建模图示

第1步:确定业务参与者

第2步:确定业务需求用例

第3步:构造用例模型图

第4步:记录业务需求用例描述

用例和项目管理

35.需求

36.用户需求

分级和评估用例

确定用例依赖关系

(下图纯属玩笑)

 

image

image

38乙方

posted @ 2016-10-15 00:47  伊甸一点  阅读(6552)  评论(0编辑  收藏  举报