什么是用例?
用例是系统分析中用于识别、阐明和组织系统需求的方法。
用例图
用例 图 模拟不同类型的用户与系统交互以解决问题。因此,它描述了用户的目标、用户与系统之间的交互以及系统为满足这些目标所需的行为。
用例 定义外部参与者和系统之间的交互,以实现特定目标。用例图包含四个主要组件
用例图由许多模型元素组成。最重要的模型元素是:
演员
参与者通常是参与根据其角色定义的系统的个人。参与者可以是人或其他外部系统。
用例
用例描述了参与者如何使用系统来实现特定目标。用例通常由用户发起,以实现描述实现目标所涉及的活动和变体的目标。
关系
参与者和用例之间的关系。
系统边界
系统边界定义了与周围世界相关的感兴趣系统。
用例特征
一个用例(或一组用例)具有以下特征:
- 组织功能需求
- 对系统/参与者(用户)交互的目标进行建模
- 记录从触发事件到目标的路径(称为 场景)
- 描述一个主要的事件流(也称为基本行动方案),以及可能的其他事件流,称为 异常 事件流(也称为替代行动方案)
- 是多层次的,因此一个用例可以使用另一个用例的功能。
用例和用例场景?
用例由系统和用户在特定环境中并与特定目标相关的一组可能的交互序列组成。
用例里面有什么?
它由一组元素(例如,类和接口)组成,它们可以一起使用,其效果大于单独元素组合的总和。用例应该包含对用户有意义的所有系统活动。
用例类型
基本用例 以相对没有技术和实现细节的理想形式表达;设计决策是延迟和抽象的,尤其是与用户界面相关的决策。
具体或真实用例 具体描述了过程的真实当前设计,致力于特定的输入和输出技术等。当涉及用户界面时,他们通常会显示屏幕截图并讨论与小部件的交互。
抽象用例 不完整,没有启动它的参与者,但被另一个用例使用。
构建用例
UML 定义了用例之间关联的三种原型:
<<include>> 用例
使用 <<include>> 关系的时间是在您完成所有主要用例的第一个剪辑描述之后。您现在可以查看用例并确定用户-系统交互的常见序列。
<<扩展>>用例
实际上,扩展用例是基本用例的替代过程。<<extend>> 用例通过在概念上将附加动作序列插入基本用例序列来实现这一点。
抽象和概括的用例
一般用例是抽象的。它不能被实例化,因为它包含不完整的信息。抽象用例的标题以斜体显示。
例子
此示例描述了几个业务用例(目标)的模型,它表示餐厅(业务系统)与其主要参与者之间的交互。
在第一次切割中确定了基本用例之后,也许我们可以在第二轮润色中使用 <<extend>> 和 <<include>> 用例进一步构建这些用例,如下图所示:
使用包构建用例
用例图可能包含用于构建用例以简化系统的分析、开发和维护的包。
用例模型与用例图
大部分用例模型实际上是文本的,文本捕获在 与每个用例模型元素相关联的用例规范中。这些规范描述了用例的事件流。
用例模型作为整个系统开发的统一线程。它被用作系统功能需求的主要规范、分析和设计的基础、迭代计划的输入、定义测试用例的基础和用户文档的基础。
示例:用例描述
- 要编写用例的内容,首先要选择其中一个场景作为主要场景。
- 您可以通过将主要成功场景编写为一系列编号的步骤来开始用例的主体。
- 然后,您可以采用其他方案并将它们编写为扩展。扩展可以是成功的,如下面的 3a 所示,也可以是失败的,如下面的 6b 所示。
- 每个用例都有一个主要参与者,它调用系统来提供服务。
- 用例中的每个步骤都是用户和系统之间交互的一个元素。
- 一个用例中的共享活动卡车可以通过 <include> 用例被另一个用例重用。
- 在 UML 术语中,我们说第一个用例包括第二个用例。
购买产品 (取自 UML Distilled p101)
主要成功场景:
- 客户浏览目录并选择要通过的项目。
- 顾客去结账。
- 客户填写发货信息
- 系统提供完整的定价信息
- 客户填写信用卡信息
- 系统授权购买
- 系统确认销售
- 系统向客户发送确认邮件
扩展
3a:客户是常客
.1 系统显示当前发货信息
.2 客户可以接受或推翻
6a:系统无法授权信用购买
.1 客户可以重新输入信用卡信息或取消
Visual Paradigm 说明的用例描述
事件流和扩展
- 记录从触发事件到目标的路径(称为 场景)
用例和 UML 建模
可以在软件开发的多个阶段使用用例,例如规划系统需求、验证设计、测试软件以及为在线帮助和用户手册创建大纲。那么用例图与SDLC中的其他UML图有什么关系呢?
模型的选择很重要
选择创建什么模型对如何解决问题以及如何形成解决方案有着深远的影响。我们需要很好地选择您的模型。
- 正确的模型将突出最关键的发展问题。
- 错误的模型会误导你,导致你专注于不相关的问题。
例如:我们可以在软件开发的不同阶段使用不同类型的图表。