2012年8月21日,星期二,10:37

关注包容性用例

撰写者

功能八月21日介绍

使我从头开始分析扩展用例的情况(请参阅 [1])还促使我研究了包含用例。 像扩展用例一样,包含用例有时也会被误解和错误应用。 就像扩展用例一样,一旦从基本原理上理解后,包含用例的目的就比有时想像的还要专门。 本文提到了六个基本点,这些基本点有助于创建质量用例模型(包括或不包括用例)。

注意:第16.1节 [2] 使用“主题”来指代“使用案例所考虑的系统”。 本文改用“系统”。

要点1:包含关系不能跨越系统边界

基本用例和包含用例之间的包含关系只能在同一系统的用例之间定义。

该断言基于以下原理。

 

只有关联才能跨越系统边界

关联是系统用例图的核心元素。

  • 参与者始终在系统外部,而用例始终在系统内部。
  • 参与者和用例只能通过关联来连接,因此跨越了系统边界。

下图中对此进行了说明,其中包含一个“定向”关联以显示控制流(参与者发起与系统的交互)。

威廉·奥格212

包含关系不是关联

当一个系统的用例A可以启动另一个系统的用例B时,则:

  • 在第一系统的用例图中,第二系统显示为用例A的支持者。
  • 在第二个系统的用例图中,第一个系统可以显示为用例B的发起方。

因此,跨越系统边界的两个用例之间的关系只能是一种关联。 由于包含关系不是关联,因此它不能跨越系统边界,因此只能在系统边界内使用。

支持性UML上层结构摘录

关键摘录来自 [2] 支持上述内容的是:

  • “ Actor为[...]建模与[系统]交互但在[系统]外部的实体。” 第16.3.1节,说明。
  • “参与者只能与用例建立联系[…]。  此外,这些关联必须是二进制的。” 第16.3.1节,约束。

要点2:参与者,协会和用例是类

这一点连接点1和3。

班级

关联连接两个类(*)。

  • 最简单的说,类是某种类型的一组实体(对象,实例)。
  • 关联表示一个类中的实例可以通过链接连接到另一类中的实例。
  • 链接是关联的实例。

(*) 在UML中,“分类器”之间是一个关联,这是一个广泛的类别,其中包括此处使用的较窄(有些非正式)的“类别”类别。

因此,用例图表示一个类视图,其中:

  • 角色是一类可能的角色实例。
  • 用例是一类可能的用例实例。
  • 参与者与用例之间的关联是参与者实例与用例实例之间的一类链接。

类视图是模型时视图,实例视图是运行时视图。

在本文中,“用例”和“用例类”可互换使用。

支持性UML上层结构摘录

摘录自 [2] 支持上述内容的是:

  • “关联描述了一组元组,其值引用类型化的实例。 关联的实例称为链接。  链接是一个元组,在关联的每个末端都有一个值,其中每个值都是末端类型的一个实例。”  Section 7.3.3.

要点3:包含用例不是真正的用例

UML上部结构关键摘录

第16.3.5条 [2] 状态:

  • “包含关系应在两个或更多用例[(*)]的行为存在共同部分时使用。 然后,将这个公共部分提取到一个单独的用例中,以供具有该部分相同的所有基本用例所包括。” 

(*) 基于上述内容,可以将其增强为“…单个系统的两个或更多用例”。    

Thus, an inclusion use case is simply a common 分段 lifted from two or more use case specifications 和 defined as the specification of a single inclusion use case.  The inclusion use case is then referenced from the base use case specifications by an include statement in place of the original 分段.

威廉·奥格213 

Inclusion use cases (and extension use cases) are 分段s

第16.3.6条 [2] 声明一个用例“由发起方来描述[系统]的完整使用”。 如上所示,由于包含用例仅表示基本用例的一部分,因此包含用例永远不会“描述[系统]的完整用法”,因此不是真实用例。  In [3] Jacobson建议将其称为“碎片”,而不是用例,甚至建议使用单独的符号。 在当前的UML表示法中,我使用自定义<<fragment>>包含用例(以及扩展用例)的构造型,如下图所示。   

包含用例(和扩展用例)是抽象用例

UML将实际和非实际用例称为具体和抽象用例。 

  • 具体的用例是可以实例化的用例。
  • 抽象用例是无法实例化的用例。

用例图中的具体和抽象用例

  1. 与发起方有关联的任何用例都是具体用例(*)。
  • 在执行时,由actor实例(在actor类内)发起用例的创建会创建一个用例实例(在use case类内)(**)。 
  • 用例实例的行为符合用例规范,该规范附加在用例类上,并适用于其所有实例。
  1. 与发起方没有关联的任何用例都是抽象用例(*)。
  • 在执行时,抽象用例的规范与相关具体用例的规范结合在一起,具体用例的实例根据组合后的规范运行。 
  • 抽象用例无法实例化,因此永远不会有仅基于抽象用例的用例实例。

(*) 例外是通用用例,它不在本文的讨论范围之内。

(**) 如果演员是一个人,这适用。 当参与者是一个系统时,该用例是由该系统的特定用例的实例发起的,而不是由系统本身的实例发起的。

关于符号:

  • 具体用例的名称以纯字体显示,抽象用例的名称以斜体显示。
  • 包含关系(以及扩展关系)以虚线箭头(与用于定向关联的实心箭头相反)显示,表示该关系在相关用例的规范之间,而不是在这些使用实例之间案件。

参见上图。 

Public 和 private use cases

由于参与者只能启动系统的具体用例,因此这些是在系统外部可见的唯一用例,而系统的抽象用例在系统外部是不可见的。 因此,系统的具体用例是其公共用例,而系统的摘要是<<fragment>>用例是其私有用例。 

这样做的主要后果是,如果根本要引入抽象用例,则应该在首先定义了具体用例之后才引入它们。    

要点4:包含性用例有两种

一种变体是“文本包含”包含用例。 包含用例的规范文本通过按名称直接引用那些规范文本中的元素,从而与基本用例的规范文本无缝连接。 文本包含的用例是上下文感知的。 

  • 根据第16.3.5节 [2],“ [包含]用例的行为已插入[基本]用例的行为。”
  • 对于我们这些年龄足够大的人来说,它们就像是COBOL程序的“程序部门”中的抄写本。

另一个变化是“参数化”包含用例。 包含用例的上下文由输入参数表示,输入参数的值由基本用例设置并由包含用例使用。 包含用例的结果由输出参数表示,输出参数的值由包含用例设置并由基本用例使用。 参数化的包含用例与上下文无关。 

  • 第16.3.5条 [2] 补充说:“ [基本]用例可能仅取决于[包含]用例的结果(值)。”
  • 继续使用COBOL类推,它们就像静态调用的子程序一样。

要点5:包含用例可能是可选的

UML上层结构语句

第16.3.5条 [2] 状态:

  • “请注意,[包含]用例不是可选的,并且对于[基本]用例的正确执行始终是必需的。” 

引起混乱的原因

有些人似乎将其解释为意味着在每个基本用例执行期间都必须执行一个包含用例。 

没有什么比真理更遥远了,真理很简单。

简单的道理

Whether an inclusion use case is mandatory or optional to a base use case depends on where in the base use case the 分段 was defined that is now replaced with an include statement for the inclusion use case.

  • If that 分段 was part of the base use case’s unconditional flow (steps that always get executed), the inclusion use case is mandatory. 
  • If that 分段 was part of a conditional flow (steps that get executed optionally), the inclusion use case is optional.  

那么,UML语句是什么意思?

UML语句的目的似乎是将包含关系与扩展关系进行如下对比。

在扩展点(不是针对整个基本用例),扩展用例的执行是可选的。 

  • 当基本用例的执行到达扩展点时,可能会或可能不会插入扩展用例,因为扩展条件可能附带条件。

但是,在“包含点”(不是针对整个基本用例),必须执行包含用例。

  • 当基本用例的执行到达包含点(即,基本用例中的include语句)时,将始终执行包含用例,因为没有规定将条件附加到包含关系上。 

要点6:包含用例不适用于功能分解

同时,创建包含用例以表示“(单个系统)两个或多个用例行为的共同部分”的原则是反对将包含用例用于功能分解的关键论点,其中基本用法用例将分解为几个包含用例,这些用例仅包含在该基本用例中。 由于此类包含用例不会被“两个或更多用例”共享,因此功能分解有悖于上述原理。 

这强调了引入包含用例的关键原因是通过重用包含用例来优化系统的用例模型。 

  • 但是,必须注意不要将其极端化。 
  • Sometimes it’s “better” to introduce an inclusion use case 和 sometimes it’s “better” to describe a common 分段 in multiple use case specifications.  

结论

这些观点对于某些人而言似乎微不足道,但是牢记这些观点不可避免地导致更好的用例模型。 实际上,忽略前三个可能会导致更大的遗漏。 由于篇幅所限,必须等到以后。

本文是关于包含抽象用例的,但这不是include关系的唯一用途。 第[4]条 处理包括一个具体的用例。

不要忘记在下面留下您的评论。


参考文献

[1] 威廉·范·加伦,《挖掘扩展用例》,2012年7月10日, (第1部分) 和 24 July 2012, (第2部分).

[2] 对象管理组(OMG),OMG统一建模语言TM值 (OMG UML),上层结构,版本2.4.1.

[3] Ivar Jacobson, 用例:昨天,今天和明天,2003年11月20日。

[4] 威廉·范·加伦, 包含关系的其他用途,2013年6月19日。

威廉·范·加伦

威廉·范·加伦(Willem Van Galen)是退休的高级系统分析师,之前曾在加拿大安大略省伦敦的一家大型金融服务公司任职。 从2008年至2016年,他的职责之一是设计,提供和加强用例建模培训,实践和标准。 在2011年,他增强了这些功能,以反映面向服务的架构和事件驱动的架构。

©BA Times.com 2020

麦格雷戈徽标白色网站