在用例图中包含和扩展之间的区别是什么?


当前回答

<include>和<extend>都依赖于基类,但<extend>是可选的,也就是说,它是从基类派生的,但在用户的角度来看,它可以被使用,也可以不被使用。

<include>被合并到基类中,也就是说,在用例中必须使用<include>,否则它将被认为是不完整的。

eg:

在ATM机构造上(根据用户角度):

1:提现、存现、支票账户属于<extend>,因为它取决于用户是提现、存款还是支票。这些都是用户可以选择做的事情。

2:“输入pin,放置卡片,移除卡片”这些是在<包括>下的事情,因为用户必须,而且应该,放置卡片并输入有效的pin进行验证。

其他回答

当您理解您的用例过于复杂时,可以使用Extends。因此,您将复杂的步骤提取到它们自己的“扩展”用例中。

Includes用于在两个用例中看到相同的行为。因此,您将常见的行为抽象到一个单独的“抽象”用例中。

(参考:Jeffrey L. Whitten, Lonnie D. Bentley,系统分析与设计方法,McGraw-Hill/Irwin, 2007)

用例用于记录行为,例如回答这个问题。

一种行为延伸了另一种行为,如果它是行为的补充,但不一定是行为的一部分,例如研究答案。

还要注意的是,如果你不试图回答这个问题,研究答案也没有多大意义。

如果一个行为是包含行为的一部分,则该行为被包含在另一个行为中,例如登录到堆栈交换。

为了澄清,只有当你想在堆栈溢出中回答这个问题时,这个例子才成立。

这些是UML 2.5第671-672页的技术定义。

我强调了我认为重要的几点。

扩展

扩展是一个从扩展UseCase(扩展)到扩展UseCase (extendedCase)的关系 如何以及何时将扩展UseCase中定义的行为插入到扩展UseCase中定义的行为中。 扩展发生在扩展的UseCase中定义的一个或多个特定扩展点上。

当有一些额外的行为应该被添加到行为中时(可能是有条件的)使用Extend 定义在一个或多个用例中。

扩展的UseCase的定义独立于扩展的UseCase,并且具有独立于扩展的意义 UseCase。另一方面,扩展的UseCase通常定义了本身不一定有意义的行为。 相反,扩展的UseCase定义了一组模块化行为增量,以增加扩展UseCase的执行 在特定条件下。

...

包括

Include is a DirectedRelationship between two UseCases, indicating that the behavior of the included UseCase (the addition) is inserted into the behavior of the including UseCase (the includingCase). It is also a kind of NamedElement so that it can have a name in the context of its owning UseCase (the includingCase). The including UseCase may depend on the changes produced by executing the included UseCase. The included UseCase must be available for the behavior of the including UseCase to be completely described.

The Include relationship is intended to be used when there are common parts of the behavior of two or more UseCases. This common part is then extracted to a separate UseCase, to be included by all the base UseCases having this part in common. As the primary use of the Include relationship is for reuse of common parts, what is left in a base UseCase is usually not complete in itself but dependent on the included parts to be meaningful. This is reflected in the direction of the relationship, indicating that the base UseCase depends on the addition but not vice versa.

...

“包含”用于扩展基本用例,这是一个必须条件,即包含的用例运行必须成功运行以完成基本使用。

如。 考虑一个电子邮件服务的案例,这里“Login”是一个包含的用例,必须运行它来发送电子邮件(基本用例)

另一方面,“Exclude”是扩展基本用例的可选用例,基本用例即使不调用/调用扩展用例也可以成功运行。

如。 考虑“Laptop Purchase”作为基本用例,“Additional Warranty”作为扩展用例,在这里你可以运行基本用例“Laptop Purchase”,甚至不需要额外的保证。

图元素

Actors: Also referred to as Roles. Name and stereotype of an actor can be changed in its Properties tab. Inheritance: Refinement relations between actors. This relation can carry a name and a stereotype. Use cases: These can have Extension Points. Extension Points: This defines a location where an extension can be added. Associations: Between roles and use cases. It is useful to give associations speaking names. Dependencies: Between use cases. Dependencies often have a stereotype to better define the role of the dependency. To select a stereotype, select the dependency from the diagram or the Navigation pane, then change the stereotype in the Properties tab. There are two special kinds of dependencies: <<extend>> and <<include>>, for which Poseidon offers own buttons (see below). Extend relationship: A uni-directional relationship between two use cases. An extend relationship between use case B and use case A means that the behavior of B can be included in A. Include relationship: A uni-directional relationship between two use cases. Such a relationship between use cases A and B means, that the behavior of B is always included in A. System border: The system border is actually not implemented as model element in Poseidon for UML. You can simply draw a rectangle, send it to the background and use it as system border by putting all corresponding use cases inside the rectangle.

这里已经解释了两者之间的区别。但没有解释的是,<<include>>和<<extend>>根本不应该被使用。

如果你读过Bittner/Spence,你就知道用例是关于综合的,而不是分析的。用例的重用是毫无意义的。它清楚地表明您已经错误地切割了您的域名。附加值本身必须是唯一的。我所知道的唯一附加值再利用方式就是特许经营。如果你是做汉堡生意的,很好。但在其他任何地方,你作为BA的任务是试图找到一个USP。这必须在良好的用例中呈现。

每当我看到人们使用其中一种关系时,都是在尝试进行功能分解的时候。这是完全错误的。

简单地说:如果你可以毫不犹豫地回答你的老板“我做了……”,那么“……”就是你的用例,因为你这样做得到了钱。(这也清楚地表明“登录”根本不是一个用例。)

在这方面,找到包含或扩展其他用例的独立用例是非常不可能的。最终,您可以使用<<extend>>来显示您的系统的可选性,即一些许可模式,它允许包含某些许可的用例或省略它们。但除此之外,就避免他们。