用例描述了用户如何使用系统来实现特定目标。用例图由系统、相关用例和参与者组成,并将它们相互关联以可视化:描述了什么?(系统),谁在使用系统?(演员)以及演员想要达到什么目标?(用例),因此,用例有助于确保通过从用户的角度捕获需求来开发正确的系统。
用例的起源
如今,用例建模通常与 UML 相关联,尽管它是在 UML 存在之前引入的。其简史如下:
- 1986 年, Ivar Jacobson 首次制定了用于指定用例的文本和视觉建模技术。
- 1992 年,他与人合着了《 面向对象的软件工程——用例驱动方法》一书 ,帮助普及了捕获功能需求的技术,尤其是在软件开发中。
用例图的目的
用例图通常是在开发的早期阶段开发的,人们经常将用例建模用于以下目的:
- 指定系统的上下文
- 捕获系统的需求
- 验证系统架构
- 推动实施并生成测试用例
- 由分析师与领域专家共同开发
什么是 UML 中的用例图?
用例是一系列动作或事件步骤,通常定义参与者角色与系统之间的交互以实现目标。用例是一种用于识别、阐明和组织系统需求的有用技术。用例由系统和用户之间的一组可能的交互序列组成,这些交互序列定义了要实现的功能以及可能遇到的任何错误的解决方案。
虽然用例本身可能会深入了解每种可能性的大量细节(例如事件流和场景),但用例图可以帮助提供系统的更高级别视图,提供简化的图形表示系统实际上必须做什么。
一个用例(或一组用例)具有以下特征:
- 组织功能需求
- 对系统/参与者(用户)交互的目标进行建模
- 描述一个主要的事件流(主要场景)和可能的其他异常流(替代方案),也称为路径或用户场景
用例图符号
用例 定义外部参与者和系统之间的交互,以实现特定目标。用例图包含四个主要组件
演员
参与者通常是参与根据其角色定义的系统的个人。参与者可以是人或其他外部系统。
用例
用例描述了参与者如何使用系统来实现特定目标。用例通常由用户发起,以实现描述实现目标所涉及的活动和变体的目标。
关系
参与者和用例之间的关系。
系统边界
系统边界定义了与周围世界相关的感兴趣系统。
用例图的好处
- 用例是一种强大的技术,用于获取和记录黑盒功能需求。
- 因为,用例很容易理解,并提供了一种与客户和用户交流的绝佳方式,因为它们是用自然语言编写的。
- 用例可以帮助管理大型项目的复杂性,方法是将问题划分为主要的用户特征(即用例)并从用户的角度指定应用程序。
- 通常由序列图表示的用例场景涉及多个对象和类的协作,用例有助于识别将对象和类粘合在一起的消息(操作和所需的信息或数据——参数)。
- 用例为高级模型的验证(即参与者和一组协作对象之间的交互)和随后的功能需求验证(即白盒测试的蓝图)之间的链接提供了良好的基础。
- 用例驱动方法为项目跟踪提供了一个可追溯的链接,其中关键的开发活动,如实施、测试和交付的用例,从用户的角度实现了目标。
如何绘制用例图?
可以按照以下步骤开发用例模型。
- 识别系统的参与者(用户的角色)。
- 对于每一类用户,确定与系统相关的用户所扮演的所有角色。
- 确定用户需要执行哪些系统才能实现这些目标。
- 为每个目标创建用例。
- 构建用例。
- 对用户进行优先级排序、审查、估计和验证。
注意:为了使用例方法更“敏捷”,不要详细说明所有用例,而是在产品 backlog 中优先考虑它们,您应该根据开发阶段及时细化不同细节级别的用例和恰到好处的方式。
你也可以:
- 将用于用例逻辑分类的包绘制到相关子系统中。
构建用例
UML 定义了用例之间关联的三种原型:
<<include>> 用例
使用 <<include>> 关系的时间是在您完成所有主要用例的第一个剪辑描述之后。您现在可以查看用例并确定用户-系统交互的常见序列。
<<扩展>>用例
实际上,扩展用例是基本用例的替代过程。<<extend>> 用例通过在概念上将附加动作序列插入基本用例序列来实现这一点。
抽象和概括的用例
一般用例是抽象的。它不能被实例化,因为它包含不完整的信息。抽象用例的标题以斜体显示。
例子
此示例描述了几个业务用例(目标)的模型,它表示餐厅(业务系统)与其主要参与者之间的交互。
在第一次切割中确定了基本用例之后,也许我们可以在第二轮润色中使用 <<extend>> 和 <<include>> 用例进一步构建这些用例,如下图所示:
业务用例
业务用例是用 无技术术语描述的 ,它将业务流程视为一个黑盒并描述其业务参与者使用的业务流程,而普通用例通常在 系统功能级别进行描述 并指定功能或者系统为用户提供的服务。换句话说,业务用例表示在当前情况下如何手动完成工作,不一定由系统完成或打算在目标系统范围内自动化。
如何识别演员
通常,人们发现通过识别参与者来启动需求获取过程是最容易的。以下问题可以帮助您识别系统的参与者(Schneider 和 Winters — 1998):
- 谁使用系统?
- 谁安装系统?
- 谁启动系统?
- 谁维护系统?
- 谁关闭了系统?
- 还有哪些其他系统使用该系统?
- 谁从这个系统中获取信息?
- 谁向系统提供信息?
- 目前有什么事情会自动发生吗?
如何识别用例?
识别用例,然后通过询问每个参与者想要什么外部可见、可观察的价值来进行基于场景的启发过程。一旦确定了参与者,就可以提出以下问题来确定用例(Schneider 和 Winters — 1998):
- 参与者希望系统提供哪些功能?
- 系统是否存储信息?哪些参与者会创建、读取、更新或删除这些信息?
- 系统是否需要通知参与者有关内部状态的机会?
- 系统是否必须知道任何外部事件?什么参与者通知系统这些事件?
用例图提示
现在,查看以下提示,了解如何在您的软件项目中有效地应用用例。
- 始终从参与者的角度构建和组织用例图。
- 用例应该从简单和尽可能高的角度开始。只有这样才能进一步细化和细化。
- 用例图基于功能,因此应该关注“什么”而不是“如何”。
用例级别的详细信息
用例粒度是指在用例规范中组织信息的方式,在某种程度上,是指编写它们的详细程度。实现正确级别的用例粒度可以简化利益相关者和开发人员之间的沟通,并改进项目规划。
Alastair Cockburn 在 编写有效用例 中为我们提供了一种简单的方法,可以通过从海洋的角度来思考不同级别的目标级别:
注意:
- 虽然用例本身可能会深入了解每种可能性的大量细节,但用例图通常用于作为蓝图的系统的更高级别视图。
- 当不需要时,以较粗的粒度和较少的细节编写用例是有益的。
我希望您现在可以回答“什么是用例图”,并可以在您的项目中应用用例。如果您想了解更多关于其他 UML 图类型的信息,请查看 UML 指南: Overview of the 14 UML Diagram Types。
仅以UML表示法显示用例图 是不够的。每个用例都附有解释用例目的的文本以及执行用例时完成的功能。
用例规范通常在分析和设计阶段以迭代方式创建。
- 首先,只写了执行用例的正常流程所需的步骤的简要描述(即,用例提供了什么功能)。
- 随着分析的进行,这些步骤被充实以添加更多细节。
- 最后,将异常流添加到用例中
- 每个项目都可以采用标准用例模板来创建用例规范。
用例与用例规范
用例描述了由参与者执行的任务,该任务为企业产生了商业价值的结果。用例可以可视化为用例图或/和结构化文本规范格式:
用例(任务——客户想要执行)可能是:
- 交互式——系统用例描述了参与者与系统的交互,以实现已定义的业务目标
- 手动 – 演员执行的一系列动作
- 自动化 — 由程序或脚本执行的一系列步骤
用例的特征
一个用例有:
- 只有一个目标
- 单一起点
- 单一的终点
- 从头到尾的多种路径
- 即为各种可能的条件指定行为
- 每个条件可能需要特定的操作
例如——客户支付账单:
实现目标有多种途径:
- 电话支付
- 通过邮寄
- 亲自
- 通过支票
- 用现金等
不通向目标的路径:
- 信用卡被拒绝
敏捷用例方法
用例模型及其各个用例会随着时间的推移逐级演进。并非模型的所有用例都必须指定为相同的详细程度。
适时且恰到好处
用例可以在不同级别的数据和范围内编写,每个都有一个目的:
- 摘要:系统功能或业务流程的一般描述和全面概述。
- 用户级别:与任务相关的用户描述以及他们如何与系统交互;特定业务流程的描述。用户级用例通常被认为是用户主要工作的任务级别。
- 子功能:用于完成核心用例的子部分的较低级别活动的描述。
注意:某些用例可能被充分指定到 II 级。当使用及时和恰到好处的方式获得足够的细节时,您就会停下来。
详细的用例规范
详细用例是一种文本表示,它以某种格式说明一系列事件以及其他相关用例信息。人们通常采用标准用例模板来记录用例的详细信息
用例模板——ATM取款案例示例
如前所述,用例有几种符号样式(例如图表样式、统一建模语言、文本格式)。无论使用什么符号都应该易于理解。您可以使用模板,例如 Alistair Cockburn中的模板,但也可以选择最适合您团队的模板。
创建简单的用例图
如果您想绘制休闲案例图, Visual Paradigm Online 将是您的最佳选择。因为它永远完全免费,没有限制,零设置和配置。
您还可以使用 Visual Paradigm 社区版,它还可以免费为各种平台创建用例。
执行正式的用例建模和分析
如果您想执行和开发用例建模,建议您使用 Visual Paradigm 付费版本 ,它使您能够开发如上所述的正确和完整的用例规范。
现在用Visual Paradigm Online自己动手
立即尝试并享受所有这些可立即编辑的示例和模板,如下所示: