什么时候使用用例关系的扩展(Extend)与包含(Include)?

   UML用例关系的包含和扩展对于许多业务分析师来说仍然是一个混乱的问题。        

       
   包含关系和扩展关系都是建立在一个基本用例上的。理论上,业务分析师可以编写一个不使用包含或扩展关系的基本用例,。然而,随着用例变得越来越大和更复杂,选择使用include或extension的众多备用流可以减少基本用例的复杂性,并提高用例模型的整体可理解性。             
   那么,业务分析师何时会选择包含用例呢?             
   创建包含用例的最主要原因是重用。包含关系可以用来分割出一系列连续的步骤,这些步骤随后可以被其他用例重用。包含用例通常可以是它自己的独立用例,它直接由actor发起,但不是必须的。但是,它是包含它的use can中的必需步骤,并且它包含在基本用例中的单个特定位置。这意味着如果没有包含用例,基本用例就不完整。另外,根据关联箭头的方向,您可以看到基本用例知道所包含的用例的存在。但是,包含的用例不知道包含它的用例。 

    业务分析师何时使用扩展关系?             
   扩展关系用于分割条件或可选功能,并且可与替代流相媲美。通常在编写用例时,备用流可能变得非常复杂,或者可能跨越其他子流。这就是将备用流提取为扩展基本用例的单独用例的意义。这称为扩展用例。当然,如果要从主流中提取的流是合理的,则这是有利的。如果这两者太混杂,那么扩展用例将难以理解             
   扩展用例知道并可以修改基本用例的行为。但是,基本用例不了解扩展用例。扩展用例可以有一个或多个称为段的行为序列,用于修改基本用例。每个段在基本用例中指出的特定扩展点处扩充基本用例。另外,扩展用例定义了扩充基本用例的条件。 

   总结一下:
   包括关系
   用于分割出可重复使用的一系列步骤
   如果没有包含用例,则基本用例不完整(使用包括所需的行为)
   包含用例不知道使用它的用例(从系统编码的角度来看,这变得更加重要)

   扩展关系
   与备用流类似,它包含可选或条件行为
   没有基本用例的扩展用例是不完整的
   扩展用例通常用于将在以后实施的行为
   如果增强现有系统,使用Extend可以帮助将新功能与旧功能分开

业务分析

猜你喜欢