2013年12月3日,星期二09:05

比较和对比用例模型元素第3部分

撰写者

介绍

本文的最后一部分比较并对比了三对用例模型元素,并建议不要以包含,扩展和泛化用例的方式实例化用例。

扩展使用案例VS。选项流程

“扩展用例”的概念在下面的[1]和“实例化包含和扩展用例?”部分中进行了探讨。

“选择流程”的想法在[2]中引入,并在[1.3]中进一步引用。

vgdec3 img01

综上所述:

  • 在我看来,使用扩展用例来表示条件行为,其结果反映在扩展用例的后置条件中,实际上是一种反模式(i)。
  • 正如Jacobson在[3]中所写的那样,“基本用例必须自己完成,并且不需要扩展。否则,您必须使用替代路径来描述其他行为。”
  • 当这种条件行为对于扩展用例而言不是必需的(即用例可以在没有行为的情况下实现其目标)时,选项流就是那些“替代路径”。

扩展使用案例VS。订户使用案例

“扩展用例”的概念在下面的[1]和“实例化包含和扩展用例?”部分中进行了探讨。
在[4]中引入了“订户用例”和“发布者用例”概念。

vgdec3 img02第[1.2]条提供了为什么&扩展用例不能反映事件驱动的体系结构,而发布者&订户用例。

可以包括和扩展使用案例吗?

我在哪里遇到这个主意

在[3]中,Jacobson似乎建议在执行具体的基本用例期间,可以实例化包含的或扩展的用例,如下所示。

  • 当用户启动具体的基本用例时,它将被实例化;
  • 在基本用例的包含点,包含的用例也被实例化。
  • 在基本用例的扩展点上,扩展用例也被实例化。

该印象基于:

  • 声明“具体用例可以扩展基本用例或包含在基本用例中。” (ii)
  • 具体的扩展和包容用例的定义是“与参与者互动并为其提供价值”并且具有“重大行为”的用例。

乍一看,这个定义让我望尘莫及,因为它似乎是任意的:

  • 抽象的扩展和包含用例也可以“与[用户]互动并为其提供价值”;他们只是无法由他们发起(实例化)。
  • 显然,“重大”是一个主观术语。

更重要的是,UML似乎不支持具体扩展用例和具体包含用例的概念(其中“包含用例”指的是[5.1]中定义的用例片段,而不是包含的用例)。如[5.2]中讨论的那样,这种情况本身就很具体)。

以下各节将对此进行更详细的探讨。

UML中的扩展用例

[6]中的16.3.3章的主要摘录是:

  • 扩展用例具有“扩展位置”,它是“扩展点[…]的有序列表,指定要在其中插入扩展用例的各个行为片段的位置”。
  • 扩展用例“由要插入扩展用例适当位置的一个或多个行为片段描述组成。”

之后的段落指出:

  • “达到扩展用例的相应扩展点时,将执行各个片段。一旦完成给定的片段,将继续执行扩展点之后的扩展用例的行为。请注意,即使涉及多个用例,也只有一个行为执行。”

然后没有具体的扩展用例

前面给我留下了以下印象。

  • 扩展用例并不意味着是具体的,因为它的规范不过是一堆“行为片段描述”,其唯一目的是“被插入扩展用例[specification]的适当位置”(它并不代表独立扩展用例实例的整个生命周期行为。
  • 换句话说,扩展用例的规范仅在扩展用例的行为的上下文中才有意义,并且仅在扩展用例的扩展点揭示有关该行为的线索的范围内(其余行为封装在扩展用例)。
  • 此外,引号的结论性说明进一步强化了这样的观念,即在执行时只有一个用例实例(“只是一个行为执行”),它当然是用户发起的具体用例的一个实例,其规格为,在这种情况下,与扩展用例的规范相结合,如[6]中详细描述的(扩展用例未实例化)。

有关[3]和事件驱动用例耦合的更多评论,请参见(iii)。

UML中的直接关系

更普遍地,在[6]中,包含,扩展和泛化关系是不同类型的有向关系。它们是用例之间的关系,但是如上所示,它们从根本上(在建模时和执行时)是有关用例的规范之间的联系。它们与相关用例的实例之间的链接(在执行时)无关,因为这是关联的目的(在建模时)。

功能依赖

这些关系表示相关用例的规范之间的功能依赖性,如下所述(为简洁起见,省略了启动器)。

vgdec3 img03该图以抽象形式显示了包含,扩展和泛化的用例。但是,决定它们不会被实例化的不是它们的抽象性质,而是它们包含,扩展和泛化用例的能力。

剩下的问题“包含的,扩展的或泛化的用例可以是超出相关用例能力范围的具体用例吗?”将在下面以及[5.2]和[7]中进行探讨。

vgdec3 img04然后不实例化包含,扩展和泛化用例

根据此阅读:

  • 我看不到如何有可能或有必要以用例的身份将用例实例化为包含,扩展或泛化用例。
  • 包含用例和泛化用例本身可以是具体的,但是我无法想到任何情况下扩展用例本身都可以是具体的。似乎扩展的用例总是抽象的。

功能依赖性VS。顺序依赖

在结束本文之前,本节将比较并对比用例之间的“功能”和“顺序”依赖性。这些在[8]和[5.2]中有详细说明。

注意,以下内容适用于给定系统内用例之间的依赖关系,而不适用于不同系统(iv)的用例之间的依赖关系。

vgdec3 img05总而言之,与将每个依赖项作为功能依赖项进行查看和建模(例如,将每个依赖项中的“登录”用例包括在内)相比,能够识别和建模用例之间的顺序依赖关系很可能会减少对用例之间关系的使用。需要用户登录的具体用例)。

结论

我希望本文能够帮助强调每个引用的用例模型元素的独特目的,对决定何时使用它们具有指导意义,并促进跨用例模型(即系统模型)的更大一致性。

笔记

(i)此反模式的一个示例是:

  • 下单用例由“应用折扣”用例扩展。
  • 下订单用例的后置条件指出,可能已应用了一个或多个折扣(例如,“对于每个批准的折扣,订单的税前总金额已减去折扣金额”)。

这是一种反模式,因为下订单无视“应用折扣”,因此既不了解折扣也无法在其后置条件中引用它们。

  • 如果要保留“应用折扣”作为扩展用例,则必须从下订单的后置条件中删除任何提及折扣的内容,因为应用折扣可能不是下订单目标的子目标;但是,“应用折扣”必须更新下订单的“税前总金额”这一事实使它不能作为扩展用例使用(请参见本文第2部分中的“关于模式3和4”部分)。
  • 因此,必须在下订单的后置条件中提及折扣,并且必须将“应用折扣”表示为选项流程,从而使应用折扣成为下订单目标的可选子目标。

(ii)第[5.2]条处理的是将已经本身是一个具体用例的用例包括在内,但是本节要探讨的问题是:

  • 就其作为附带用例的能力而言,是否可以实例化具体用例?
  • 扩展用例本身是否可以是具体用例?
  • 扩展用例是否可以全部实例化?

(iii)[3]中的图2涉及具体用例行为交易和检查交易失败之间的准事件驱动连接。

  • 扩展用例“注册失败”会“发布”在扩展用例《行为交易》中发生的“事件”(类型为“交易失败”)。
  • 具体用例“检查事务失败”和用例片段“注册失败”之间的“特殊”依赖性(没有明确的构造型)表示检查事务失败是“注册失败”“发布”的“事件”的“订阅者”。

既然如此,出于以下原因,我将改用[4]中概述的事件驱动架构方法对该连接进行建模。

  • [3]的图2处理异常事件。 [4]中的方法首先是关于正常事件的,但是也可以处理异常事件(为什么对于同一模式有两种方法?)。
  • [3]中的图2显示了从“检查事务失败”到“注册失败”到“进行事务”(紧密耦合)的“依赖关系”;使用[4]中的方法,订户用例与任何“上游”用例之间没有依赖关系,因为订户用例仅对事件感兴趣,而与发布事件的用例无关(松耦合) )。

在[3]的图2中,事件的发布由扩展用例处理;在[4]中的方法中,发布是遇到它们的用例的一部分。支持后一种模式的原因如下。

  • 发布事件通常意味着在发布的事件对象中包含事件数据;当然,此类数据可由遇到事件的用例轻松访问,但不一定由该用例的单独扩展用例访问或容易访问。
  • 根据使用方法的广泛程度,“发布者”扩展用例的数量可能会增加,用例图可能看起来很混乱。

最后,这是优先考虑的问题,因为这两种方法都有效。

(iv)当另一个系统是该系统用例的支持者时,该系统的用例在功能上取决于另一个系统的用例;这种依赖性显示为跨越系统边界的关联,应在给定用例的规范中进行详细说明(例如,“系统启动<其他系统的用例> of <other system>”).

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

参考资料

[1.1] 威廉·范·加伦,《挖掘扩展用例》,第1部分,2012年7月10日, http://www.amerkan.com/articles/excavating-the-extension-use-case.html

[1.2] 威廉·范·加伦,《挖掘扩展用例》,第2部分,2012年7月24日, http://www.amerkan.com/articles/excavating-the-extension-use-case-part-2.html

[1.3] 威廉·范·加伦,《挖掘扩展用例》,第3部分,2013年3月12日, http://www.amerkan.com/articles/excavating-the-extension-use-case-part-3-nuance.html

[2] 威廉·范·加伦,用例目标,场景和流程,2012年11月13日, http://www.amerkan.com/articles/use-case-goals-scenarios-and-flows.html

[3] Ivar Jacobson,用例:昨天,今天和明天,2003年11月20日,发现于 http://www.ibm.com/developerworks/rational/library/775.html (页面不再存在;请参阅: http://www.spinsp.org.br/grupo/Future_%20of_Cases.pdf)。

[4] 威廉·范·加伦,“松耦合案例的建模”,2012年4月30日, http://www.amerkan.com/articles/modeling-loosely-coupled-use-cases.html

[5.1] 威廉·范·加伦,着眼于包含性用例,2012年8月21日, http://www.amerkan.com/articles/putting-the-inclusion-use-case-in-focus.html

[5.2] 威廉·范·加伦,“包含关系的其他用途”,2013年6月18日, http://www.amerkan.com/articles/the-include-relationships-other-use.html

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

[7] 威廉·范·加伦,通用化和用例​​模型,第2部分,2013年9月2日, http://www.amerkan.com/articles/generalization-and-use-case-models-part-2.html

[8] 威廉·范·加伦,用例先决条件:最佳秘密?,2012年10月15日, http://www.amerkan.com/articles/use-case-preconditions-a-best-kept-secret.html

威廉·范·加伦

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

©BA Times.com 2020

麦格雷戈徽标白色网站