The include relationship allows one use case to include the steps of another use case.
For example, suppose you have an Amazon Account and you want to check on an order, well it is impossible to check on the order without first logging into your account. So the flow of events would like so...
The extend relationship is used to add an extra step to the flow of a use case, that is usually an optional step...
Imagine that we are still talking about your amazon account. Lets assume the base case is Order and the extension use case is Amazon Prime. The user can choose to just order the item regularly, or, the user has the option to select Amazon Prime which ensure his order will arrive faster at higher cost.
However, note that the user does not have to select Amazon Prime, this is just an option, they can choose to ignore this use case.
I like to think of "includes" as a necessary prerequisite/accompaniment of the base use case. This means that the base use case cannot be considered complete without the use case it includes. I'll give the example of an e-commerce website that sells items to customers. There's no way you can pay for an item without first selecting that item and putting it in the cart. This implies that the use case "Pay for Item" includes "select item".
There are varying uses of extends but I like to think of it as an alternative that may or may not be used. For example - still on the e-commerce site. When paying for an item, you may choose to pay on delivery, pay using paypal or pay by card. These are all alternatives to the "pay for item" use case. I may choose any of these options depending on my preference.
For more clarity and the rules surrounding use cases, read my article here:
The relationships between use cases are used to organize use case specifications.
If you are not yet able to write qualified use case specifications, I suggest not considering the issue of use case relationships first, because at this stage, many of the "included" and "extended" use cases you are thinking about are likely not actual use cases, and such thinking is a waste of effort.
Extend is used when a use case adds steps to another first-class use case.
For example, imagine "Withdraw Cash" is a use case of an Automated Teller Machine (ATM). "Assess Fee" would extend Withdraw Cash and describe the conditional "extension point" that is instantiated when the ATM user doesn't bank at the ATM's owning institution. Notice that the basic "Withdraw Cash" use case stands on its own, without the extension.
Include is used to extract use case fragments that are duplicated in multiple use cases. The included use case cannot stand alone and the original use case is not complete without the included one. This should be used sparingly and only in cases where the duplication is significant and exists by design (rather than by coincidence).
For example, the flow of events that occurs at the beginning of every ATM use case (when the user puts in their ATM card, enters their PIN, and is shown the main menu) would be a good candidate for an include.
This may be contentious but the “includes are always and extends are sometimes” is a very common misconception which has almost taken over now as the de-facto meaning. Here’s a correct approach (in my view, and checked against Jacobson, Fowler, Larmen and 10 other references).
Relationships are dependencies
The key to Include and extend use case relationships is to realize that, common with the rest of UML, the dotted arrow between use cases is a dependency relationship. I’ll use the terms ‘base’, ‘included’ and ‘extending’ to refer to the use case roles.
include
A base use case is dependent on the included use case(s); without it/them the base use case is incomplete as the included use case(s) represent sub-sequences of the interaction that may happen always OR sometimes. (This is contrary to a popular misconception about this, what your use case suggests always happens in the main scenario and sometimes happens in alternate flows simply depends on what you choose as your main scenario; use cases can easily be restructured to represent a different flow as the main scenario and this should not matter).
In the best practice of one way dependency the base use case knows about (and refers to) the included use case, but the included use case shouldn’t ‘know’ about the base use case. This is why included use cases can be: a) base use cases in their own right and b) shared by a number of base use cases.
extend
The extending use case is dependent on the base use case; it literally extends the behavior described by the base use case. The base use case should be a fully functional use case in its own right (‘include’s included of course) without the extending use case’s additional functionality.
Extending use cases can be used in several situations:
The base use case represents the “must have” functionality of a project while the extending use case represents optional (should/could/want) behavior. This is where the term optional is relevant – optional whether to build/deliver rather than optional whether it sometimes runs as part of the base use case sequence.
In phase 1 you can deliver the base use case which meets the requirements at that point, and phase 2 will add additional functionality described by the extending use case. This can contain sequences that are always or sometimes performed after phase 2 is delivered (again contrary to popular misconception).
It can be used to extract out subsequences of the base use case, especially when they represent ‘exceptional’ complex behavior with its own alternative flows.
One important aspect to consider is that the extending use case can ‘insert’ behavior in several places in the base use case’s flow, not just in a single place as an included use case does. For this reason, it is highly unlikely that an extending use case will be suitable to extend more than one base use case.
As to dependency, the extending use case is dependent on the base use case and is again a one-way dependency, i.e. the base use case doesn’t need any reference to the extending use case in the sequence. That doesn’t mean you can’t demonstrate the extension points or add a x-ref to the extending use case elsewhere in the template, but the base use case must be able to work without the extending use case.
SUMMARY
I hope I’ve shown that the common misconception of “includes are always, extends are sometimes” is either wrong or at best simplistic. This version actually makes more sense if you consider all the issues about the directionality of the arrows the misconception presents – in the correct model it’s just dependency and doesn’t potentially change if you refactor the use case contents.
"Fill the petrol" may not be required at all times, but may optionally be required based on the amount of petrol left in the car. "Drive the car" is a prerequisite hence I am including.
包含关系旨在当两个或多个用例的行为有共同部分时使用。这
然后，公共部分被提取到一个单独的用例，并由具有该公共部分的所有基本用例包含。作为
Include 关系的主要用途是重用公共部分，基本用例中剩下的内容通常不完整
本身，但依赖于所包含的部分才有意义。这反映在关系的方向上，表明
基本用例取决于添加，但反之则不然。
...
Use cases are used to document behavior, e.g. answer this question.
A behavior extends another if it is in addition to but not necessarily part of the behavior, e.g. research the answer.
Also note that researching the answer doesn't make much sense if you are not trying to answer the question.
A behavior is included in another if it is part of the including behavior, e.g. login to stack exchange.
To clarify, the illustration is only true if you want to answer here in stack overflow :).
These are the technical definitions from UML 2.5 pages 671-672.
I highlighted what I think are important points.
Extends
An Extend is a relationship from an extending UseCase (the extension) to an extended UseCase (the extendedCase) that specifies
how and when the behavior defined in the extending UseCase can be inserted into the behavior defined in the extended UseCase.
The extension takes place at one or more specific extension points defined in the extended UseCase.
Extend is intended to be used when there is some additional behavior that should be added, possibly conditionally, to the behavior
defined in one or more UseCases.
The extended UseCase is defined independently of the extending UseCase and is meaningful independently of the extending
UseCase. On the other hand, the extending UseCase typically defines behavior that may not necessarily be meaningful by itself.
Instead, the extending UseCase defines a set of modular behavior increments that augment an execution of the extended UseCase
under specific conditions.
...
Includes
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.
您最常会发现扩展的第二种用法（即可选功能），因为如果功能不是可选的，那么大多数时候它会内置到用例本身中，而不是作为扩展。至少这是我的经验。 （Julian C 指出，当项目进入第二阶段时，您有时会看到扩展的第一次用法（即添加新功能））。
I think it's important to understand the intention of includes and extends:
"The include relationship is intended for reusing behaviour modeled
by another use case, whereas the extend relationship is intended for adding parts to existing use cases as well as for modeling optional system services" (Overgaard and Palmkvist, Use Cases: Patterns and Blueprints. Addison-Wesley, 2004).
This reads to me as:
Include = reuse of functionality (i.e. the included functionality is used or could be used elsewhere in the system). Include therefore denotes a dependency on another use case.
Extends = adding (not reusing) functionality and also any optional functionality. Extends therefore can denote one of two things:
1. adding new features/capabilities to a use case (optional or not)
2. any optional use cases (existing or not).
Summary:
Include = reuse of functionality
Extends = new and/or optional functionality
You will most often find the 2nd usage (i.e. optional functionality) of extends, because if functionality is not optional, then most times it is built into the use case itself, rather than being an extension. At least that's been my experience. (Julian C points out that you sometimes see the 1st usage (i.e. adding new features) of extends when a project enters it's 2nd phase).
I think what msdn explained here are quite easy to understand.
Include [5]
An including use case calls or invokes the included one. Inclusion is used to show how a use case breaks into smaller steps. The included use case is at the arrowhead end.
Extend [6]
Meanwhile, an extending use case adds goals and steps to the extended use case. The extensions operate only under certain conditions. The extended use case is at the arrowhead end.
whenever there are prerequisites to a usecase then,go for include.
for usecases having authentication,worst case scenario,or are optional then go for extend..
example:for a use case of seeking admission,appointment,ticket reservation
YOU MUST FILL A form (registration or feedback form)....this is where include comes..
example:for a use case verifying login or sign in your account,your authentication is a must.also think of worst case scenarios.like returning book with fine..NOT getting a reservation..paying the bill AFTER DUE DATE..this is where extend comes to play...
do not overuse include and extend in the diagrams.
Both <include> and <extend> are dependent on the base class but <extend> is optional i.e., it is derived from the base class but in the point of users view it may be used or may not be used.
<include> is incorporated in base class i.e., it is compulsary to use <include> in your use case or else it would be considered incomplete.
eg:
In ATM machine construction (according to users point of view):
1: Withdrawal,deposit of cash and checking the account comes under <extend> because it depends on the user whether to withdraw or deposit or check. These are optional things the user does.
2: "Enter the pin, placing card, removal of card" these are the things that come under <include> because the user must, and should, place a card and enter a valid pin for verification.
"Include" is used to extend the base use case and it is a must condition i.e. included use case run must run successfully to complete base use.
e.g.
Consider a case of Email Service, here "Login" is a included use case which must be run in order to send a Email (Base use case)
"Exclude" on the other hand is optional use case which extends the base use case, base use case can run successfully even without invoking/calling the extending use case.
e.g.
Consider "Laptop Purchase" as base use case and "Additional Warranty" as extending use case, here you can run base use case "Laptop Purchase" even without taking additional warranty.
Also beware of the UML version : it's been a long time now that << uses >> and << includes >> have been replaced by << include >>, and << extends >> by << extend >> AND generalization.
For me that's often the misleading point : as an example the Stephanie's post and link is about an old version :
When paying for an item, you may choose to pay on delivery, pay using paypal or pay by card. These are all alternatives to the "pay for item" use case. I may choose any of these options depending on my preference.
In fact there is no really alternative to "pay for item" ! In nowadays UML, "pay on delivery" is an extend, and "pay using paypal"/"pay by card" are specializations.
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.
I don't recommend the use of this to remember the two:
My use case: I am going to the city.
includes -> drive the car
extends -> fill the petrol
I would rather you use:
My use case: I am going to the city.
extends -> driving the car
includes -> fill the petrol
Am taught that extend relationship continues the behaviour of a base class. The base class functionalities have to be there.
The include relationship on the other hand, are akin to functions that may be called. May is in bold.
The difference between both has been explained here. But what has not been explained is the fact that <<include>> and <<extend>> should simply not be used at all.
If you read Bittner/Spence you know that use cases are about synthesis, not analysis. A re-use of use cases is nonsense. It clearly shows that you have cut your domain wrongly. Added value must be unique per se. The only re-use of added value I know is franchise. So if you are in burger business, nice. But everywhere else your task as BA is to try to find an USP. And that must be presented in good use cases.
Whenever I see people using one of those relations it is when they try to do functional decomposition. And that's plain wrong.
To put it simple: if you can answer your boss without hesitation "I have done ..." then the "..." is your use case since you got money for doing it. (That will also make clear that "login" is not a use case at all.)
In that respect, finding self standing use cases that are included or extend other use cases is very unlikely. Eventually you can use <<extend>> to show optionality of your system, i.e. some licensing schema which allows to include use cases for some licenses or to omit them. But else - just avoid them.
发布评论
评论（22）
包含关系允许一个用例包含另一用例的步骤。
例如，假设您有一个亚马逊帐户并且您想要检查订单，那么如果不先登录您的帐户就不可能检查订单。所以事件的流程就像这样......
扩展关系用于向用例流程添加额外的步骤，这通常是可选步骤...
想象一下我们仍在谈论您的亚马逊帐户。我们假设基本用例是“订单”，扩展用例是“Amazon Prime”。用户可以选择定期订购商品，或者，用户可以选择选择 Amazon Prime，这确保他的订单将以更高的成本更快到达。
但请注意，用户不必选择 Amazon Prime，这只是一个选项，他们可以选择忽略此用例。
The include relationship allows one use case to include the steps of another use case.
For example, suppose you have an Amazon Account and you want to check on an order, well it is impossible to check on the order without first logging into your account. So the flow of events would like so...
The extend relationship is used to add an extra step to the flow of a use case, that is usually an optional step...
Imagine that we are still talking about your amazon account. Lets assume the base case is Order and the extension use case is Amazon Prime. The user can choose to just order the item regularly, or, the user has the option to select Amazon Prime which ensure his order will arrive faster at higher cost.
However, note that the user does not have to select Amazon Prime, this is just an option, they can choose to ignore this use case.
当您了解您的用例过于复杂时，可以使用扩展。因此，您可以将复杂的步骤提取到它们自己的“扩展”用例中。
当您在两个用例中看到常见行为时，请使用包括。因此，您将常见行为抽象为单独的“抽象”用例。
（参考：Jeffrey L. Whitten、Lonnie D. Bentley，系统分析和设计方法，McGraw-Hill/Irwin，2007 年）
Extends is used when you understand that your use case is too much complex. So you extract the complex steps into their own "extension" use cases.
Includes is used when you see common behavior in two use cases. So you abstract out the common behavior into a separate "abstract" use case.
(ref: Jeffrey L. Whitten, Lonnie D. Bentley, Systems analysis & design methods, McGraw-Hill/Irwin, 2007)
我喜欢将“包含”视为基本用例的必要先决条件/伴随。这意味着如果没有基本用例所包含的用例，则不能认为基本用例是完整的。我将举一个向客户销售商品的电子商务网站的例子。如果不先选择该商品并将其放入购物车，您就无法支付该商品的费用。这意味着用例“支付商品”包括“选择商品”。
扩展有不同的用途，但我喜欢将其视为可能使用也可能不使用的替代方案。例如——还在电子商务网站上。支付商品时，您可以选择货到付款、PayPal支付或刷卡支付。这些都是“按商品付费”用例的替代方案。我可以根据我的喜好选择这些选项中的任何一个。
为了更清楚地了解有关用例的规则，请阅读我的文章：
http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics
I like to think of "includes" as a necessary prerequisite/accompaniment of the base use case. This means that the base use case cannot be considered complete without the use case it includes. I'll give the example of an e-commerce website that sells items to customers. There's no way you can pay for an item without first selecting that item and putting it in the cart. This implies that the use case "Pay for Item" includes "select item".
There are varying uses of extends but I like to think of it as an alternative that may or may not be used. For example - still on the e-commerce site. When paying for an item, you may choose to pay on delivery, pay using paypal or pay by card. These are all alternatives to the "pay for item" use case. I may choose any of these options depending on my preference.
For more clarity and the rules surrounding use cases, read my article here:
http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics
我记忆的一种方式是通过电子游戏。例如，
（下面并不是 100% 的所有情况，而只是一个用例的示例）
扩展：主菜单扩展了一些功能，这意味着它们具有一些功能，但不必按下
包括：为了触发电子游戏中的武器，您必须首先拥有一个。
A way I remember it is by video games. For example,
(the below is not for 100% of all cases but just an example of a use case)
Extends: The main menu extends some functionality, which means they have some functionality on them but not necessary to be pressed
Includes: in order to fire a weapon in a video game you must have one first.
前面的答案都提出了很好的观点。
用例之间的关系用于组织用例规范。
如果您还不能编写合格的用例规范，我建议先不要考虑用例关系的问题，因为在这个阶段，您正在考虑的许多“包含”和“扩展”用例很可能不是实际的用例，这样的思考是浪费精力。
The previous answers all made excellent points.
The relationships between use cases are used to organize use case specifications.
If you are not yet able to write qualified use case specifications, I suggest not considering the issue of use case relationships first, because at this stage, many of the "included" and "extended" use cases you are thinking about are likely not actual use cases, and such thinking is a waste of effort.
Include 表达了遏制的想法。
Extend表达了继承的思想。
Include expresses the idea of containment.
Extend expresses the idea of inheritance.
当用例将步骤添加到另一个一流用例时，使用扩展。
例如，假设“提取现金”是自动柜员机 (ATM) 的一个用例。 “评估费用”将扩展提款现金并描述当 ATM 用户不在 ATM 所属机构办理银行业务时实例化的条件“扩展点”。请注意，基本的“提取现金”用例是独立的，没有扩展。
包含用于提取在多个用例中重复的用例片段。包含的用例不能单独存在，如果没有包含的用例，原始用例就不完整。应谨慎使用此方法，并且仅在重复严重且有意为之（而非巧合）的情况下使用。
例如，在每个 ATM 用例开始时发生的事件流（当用户放入 ATM 卡、输入 PIN 并显示主菜单时）将是一个很好的包含候选者。
Extend is used when a use case adds steps to another first-class use case.
For example, imagine "Withdraw Cash" is a use case of an Automated Teller Machine (ATM). "Assess Fee" would extend Withdraw Cash and describe the conditional "extension point" that is instantiated when the ATM user doesn't bank at the ATM's owning institution. Notice that the basic "Withdraw Cash" use case stands on its own, without the extension.
Include is used to extract use case fragments that are duplicated in multiple use cases. The included use case cannot stand alone and the original use case is not complete without the included one. This should be used sparingly and only in cases where the duplication is significant and exists by design (rather than by coincidence).
For example, the flow of events that occurs at the beginning of every ATM use case (when the user puts in their ATM card, enters their PIN, and is shown the main menu) would be a good candidate for an include.
这可能是有争议的，但“总是包含，有时是扩展”是一个非常常见的误解，现在几乎已经成为事实上的含义。这是一个正确的方法（在我看来，并对照 Jacobson、Fowler、Larmen 和其他 10 篇参考资料进行了检查）。
关系是依赖关系
包含和扩展用例关系的关键是要认识到，与 UML 的其余部分一样，用例之间的虚线箭头是依赖关系。我将使用术语“基础”、“包含”和“扩展”来指代用例角色。
包含
基本用例依赖于包含的用例；没有它/它们，基本用例是不完整的，因为包含的用例代表可能总是或有时发生的交互的子序列。 （这与对此的流行误解相反，您的用例所建议的内容总是发生在主要场景中，有时会发生在备用流程中，这仅取决于您选择的主要场景；可以轻松地重构用例以表示不同的流程作为主要场景，这应该不重要）。
在单向依赖的最佳实践中，基本用例知道（并引用）包含的用例，但包含的用例不应该“知道”基本用例。这就是为什么包含的用例可以是：a）本身的基本用例和b）由多个基本用例共享。
扩展
扩展用例依赖于基本用例；它实际上扩展了基本用例描述的行为。基本用例本身应该是一个功能齐全的用例（当然包括“include”），而没有扩展用例的附加功能。
扩展用例可以在多种情况下使用：
需要考虑的一个重要方面是，扩展用例可以将行为“插入”到基本用例流程中的多个位置，而不仅仅是像包含的用例那样插入到单个位置。因此，扩展用例不太可能适合扩展多个基本用例。
至于依赖性，扩展用例依赖于基本用例，并且又是单向依赖性，即基本用例不需要对序列中的扩展用例进行任何引用。这并不意味着您无法演示扩展点或向模板中其他位置的扩展用例添加外部引用，但基本用例必须能够在没有扩展用例的情况下工作。
总结
我希望我已经表明“总是包含，有时是扩展”的常见误解要么是错误的，要么充其量是过于简单化了。如果您考虑到误解所呈现的有关箭头方向性的所有问题，这个版本实际上更有意义——在正确的模型中，它只是依赖关系，并且如果您重构用例内容，则可能不会改变。
This may be contentious but the “includes are always and extends are sometimes” is a very common misconception which has almost taken over now as the de-facto meaning. Here’s a correct approach (in my view, and checked against Jacobson, Fowler, Larmen and 10 other references).
Relationships are dependencies
The key to Include and extend use case relationships is to realize that, common with the rest of UML, the dotted arrow between use cases is a dependency relationship. I’ll use the terms ‘base’, ‘included’ and ‘extending’ to refer to the use case roles.
include
A base use case is dependent on the included use case(s); without it/them the base use case is incomplete as the included use case(s) represent sub-sequences of the interaction that may happen always OR sometimes. (This is contrary to a popular misconception about this, what your use case suggests always happens in the main scenario and sometimes happens in alternate flows simply depends on what you choose as your main scenario; use cases can easily be restructured to represent a different flow as the main scenario and this should not matter).
In the best practice of one way dependency the base use case knows about (and refers to) the included use case, but the included use case shouldn’t ‘know’ about the base use case. This is why included use cases can be: a) base use cases in their own right and b) shared by a number of base use cases.
extend
The extending use case is dependent on the base use case; it literally extends the behavior described by the base use case. The base use case should be a fully functional use case in its own right (‘include’s included of course) without the extending use case’s additional functionality.
Extending use cases can be used in several situations:
One important aspect to consider is that the extending use case can ‘insert’ behavior in several places in the base use case’s flow, not just in a single place as an included use case does. For this reason, it is highly unlikely that an extending use case will be suitable to extend more than one base use case.
As to dependency, the extending use case is dependent on the base use case and is again a one-way dependency, i.e. the base use case doesn’t need any reference to the extending use case in the sequence. That doesn’t mean you can’t demonstrate the extension points or add a x-ref to the extending use case elsewhere in the template, but the base use case must be able to work without the extending use case.
SUMMARY
I hope I’ve shown that the common misconception of “includes are always, extends are sometimes” is either wrong or at best simplistic. This version actually makes more sense if you consider all the issues about the directionality of the arrows the misconception presents – in the correct model it’s just dependency and doesn’t potentially change if you refactor the use case contents.
我经常用它来记住两个：
我的用例：我要去城市。
包括->驾驶汽车
延伸->加油
“加油”可能并不总是需要，但可以根据车内剩余汽油量选择性地要求。 “驾驶汽车”是先决条件，因此我将其包括在内。
I often use this to remember the two:
My use case: I am going to the city.
includes -> drive the car
extends -> fill the petrol
"Fill the petrol" may not be required at all times, but may optionally be required based on the amount of petrol left in the car. "Drive the car" is a prerequisite hence I am including.
用例用于记录行为，例如回答这个问题。
如果一个行为是另一个行为的补充但不一定是该行为的一部分，则该行为会扩展另一个行为，例如研究答案。
另请注意，如果您不想回答问题，那么研究答案就没有多大意义。
如果一个行为是包含行为的一部分，则该行为会包含在另一个行为中，例如登录堆栈交换。
澄清一下，只有当您想在堆栈溢出中回答时，该插图才是正确的:)。
这些是来自 UML 2.5 第 671-672 页。
我强调了我认为重要的几点。
扩展
扩展是一种从扩展用例（扩展）到扩展用例（扩展用例）的关系，它指定
如何以及何时可以将扩展用例中定义的行为插入到扩展用例中定义的行为中。
扩展发生在扩展用例中定义的一个或多个特定扩展点。
扩展旨在当需要添加一些附加行为时使用，可能有条件 , 到行为
在一个或多个用例中定义。
扩展用例的定义独立于扩展用例，并且独立于扩展用例而有意义
用例。另一方面，扩展用例通常定义本身不一定有意义的行为。
相反，扩展用例定义了一组模块化行为增量，用于增强扩展用例的执行
...
包含
包含是两个用例之间的定向关系，表明包含的用例的行为（加法）是
插入到包含用例（includeCase）的行为中。它也是一种 NamedElement，因此它可以有一个
其所属用例（includeCase）上下文中的名称。包含的用例可能取决于所产生的变化
执行包含的用例。包含的用例必须可供包含的用例的行为使用
完整描述。
包含关系旨在当两个或多个用例的行为有共同部分时使用。这
然后，公共部分被提取到一个单独的用例，并由具有该公共部分的所有基本用例包含。作为
Include 关系的主要用途是重用公共部分，基本用例中剩下的内容通常不完整
本身，但依赖于所包含的部分才有意义。这反映在关系的方向上，表明
基本用例取决于添加，但反之则不然。
...
Use cases are used to document behavior, e.g. answer this question.
A behavior extends another if it is in addition to but not necessarily part of the behavior, e.g. research the answer.
Also note that researching the answer doesn't make much sense if you are not trying to answer the question.
A behavior is included in another if it is part of the including behavior, e.g. login to stack exchange.
To clarify, the illustration is only true if you want to answer here in stack overflow :).
These are the technical definitions from UML 2.5 pages 671-672.
I highlighted what I think are important points.
Extends
An Extend is a relationship from an extending UseCase (the extension) to an extended UseCase (the extendedCase) that specifies
how and when the behavior defined in the extending UseCase can be inserted into the behavior defined in the extended UseCase.
The extension takes place at one or more specific extension points defined in the extended UseCase.
Extend is intended to be used when there is some additional behavior that should be added, possibly conditionally, to the behavior
defined in one or more UseCases.
The extended UseCase is defined independently of the extending UseCase and is meaningful independently of the extending
UseCase. On the other hand, the extending UseCase typically defines behavior that may not necessarily be meaningful by itself.
Instead, the extending UseCase defines a set of modular behavior increments that augment an execution of the extended UseCase
under specific conditions.
...
Includes
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.
...
为了简化，
对于
include一个典型的例子：登录和验证密码
（登录）之间---<<包括>> --->（验证密码）
登录过程要成功，“验证密码”也必须成功。
for
extend一个典型的例子：登录和显示错误消息之间（仅有时发生）
（登录）<--- <<延伸>> ---（显示错误消息）
“显示错误消息”仅在登录过程失败时有时会发生。
To simplify,
for
includea typical example: between login and verify password
(login) --- << include >> ---> (verify password)
for the login process to success, "verify password" must be successful as well.
for
extenda typical example: between login and show error message (only happened sometimes)
(login) <--- << extend >> --- (show error message)
"show error message" only happens sometimes when the login process failed.
我认为理解包含和扩展的意图很重要：
这对我来说是：
Inclusion = 功能的重用（即包含的功能已被使用或可以在系统的其他地方使用）。用例。
扩展=添加（不重用）功能以及还有任何可选功能，因此扩展可以表示以下两件事之一：
1. 向用例添加新特性/功能（可选或不可选）
2. 任何可选用例（存在或不存在）。
摘要：
包含=功能的重用
扩展 = 新的和/或可选的功能
您最常会发现扩展的第二种用法（即可选功能），因为如果功能不是可选的，那么大多数时候它会内置到用例本身中，而不是作为扩展。至少这是我的经验。 （Julian C 指出，当项目进入第二阶段时，您有时会看到扩展的第一次用法（即添加新功能））。
I think it's important to understand the intention of includes and extends:
This reads to me as:
Include = reuse of functionality (i.e. the included functionality is used or could be used elsewhere in the system). Include therefore denotes a dependency on another use case.
Extends = adding (not reusing) functionality and also any optional functionality. Extends therefore can denote one of two things:
1. adding new features/capabilities to a use case (optional or not)
2. any optional use cases (existing or not).
Summary:
Include = reuse of functionality
Extends = new and/or optional functionality
You will most often find the 2nd usage (i.e. optional functionality) of extends, because if functionality is not optional, then most times it is built into the use case itself, rather than being an extension. At least that's been my experience. (Julian C points out that you sometimes see the 1st usage (i.e. adding new features) of extends when a project enters it's 2nd phase).
我认为msdn此处的解释非常容易理解。
包括 [5]
延长 [6]
I think what msdn explained here are quite easy to understand.
Include [5]
Extend [6]
让我们把这一点说得更清楚。每当我们想要表达一种情况的存在取决于另一种情况的存在这一事实时，我们都会使用
include。示例：
用户只有登录帐户后才能进行在线购物。换句话说，在登录帐户之前，他无法进行任何购物。
在材料上传之前，用户无法从网站下载。
所以，如果没有上传任何内容，我就无法下载。
你明白了吗？
这是关于条件后果的。 如果我以前没有这样做，我就不能这样做。
至少，我认为这是我们使用
Include的正确方式。我倾向于认为上面的笔记本电脑和保修示例是最有说服力的！
Let's make this clearer. We use
includeevery time we want to express the fact that the existence of one case depends on the existence of another.EXAMPLES:
A user can do shopping online only after he has logged in his account. In other words, he can't do any shopping until he has logged in his account.
A user can't download from a site before the material had been uploaded.
So, I can't download if nothing has been uploaded.
Do you get it?
It's about conditioned consequence. I can't do this if previously I didn't do that.
At least, I think this is the right way we use
Include.I tend to think the example with Laptop and warranty from right above is the most convincing!
每当用例有先决条件时，就去包含。
对于具有身份验证、最坏情况场景或可选的用例，然后进行扩展。
例如：对于寻求入场、预约、订票的用例
您必须填写表格（注册或反馈表）....这就是 include 出现的地方..
示例：对于验证登录或登录帐户的用例，您的身份验证是必须的。还要考虑最坏的情况。例如退回书本并罚款..未获得预订..在到期日后支付账单..这就是扩展发挥作用的地方...
不要在图表中过度使用包含和扩展。
保持简单愚蠢！
whenever there are prerequisites to a usecase then,go for include.
for usecases having authentication,worst case scenario,or are optional then go for extend..
example:for a use case of seeking admission,appointment,ticket reservation
YOU MUST FILL A form (registration or feedback form)....this is where include comes..
example:for a use case verifying login or sign in your account,your authentication is a must.also think of worst case scenarios.like returning book with fine..NOT getting a reservation..paying the bill AFTER DUE DATE..this is where extend comes to play...
do not overuse include and extend in the diagrams.
KEEP IT SIMPLE SILLY!!!
例如：
在ATM机建设中（根据用户的观点）：
1：取款、存入现金和查看账户属于
2：“输入 PIN、放置卡、取出卡”这些是
Both
<include>and<extend>are dependent on the base class but<extend>is optional i.e., it is derived from the base class but in the point of users view it may be used or may not be used.<include>is incorporated in base class i.e., it is compulsary to use<include>in your use case or else it would be considered incomplete.eg:
In ATM machine construction (according to users point of view):
1: Withdrawal,deposit of cash and checking the account comes under
<extend>because it depends on the user whether to withdraw or deposit or check. These are optional things the user does.2: "Enter the pin, placing card, removal of card" these are the things that come under
<include>because the user must, and should, place a card and enter a valid pin for verification.“包含”用于扩展基本用例，这是一个必须条件，即包含的用例运行必须成功运行才能完成基本使用。
例如
考虑电子邮件服务的情况，这里“登录”是一个包含的用例，必须运行它才能发送电子邮件（基本用例），
“排除”另一方面是扩展基本用例的可选用例，基本即使不调用扩展用例，用例也可以成功运行。
例如
将“笔记本电脑购买”视为基本用例，将“附加保修”视为扩展用例，在这里您可以运行基本用例“笔记本电脑购买”，甚至无需额外保修。
"Include" is used to extend the base use case and it is a must condition i.e. included use case run must run successfully to complete base use.
e.g.
Consider a case of Email Service, here "Login" is a included use case which must be run in order to send a Email (Base use case)
"Exclude" on the other hand is optional use case which extends the base use case, base use case can run successfully even without invoking/calling the extending use case.
e.g.
Consider "Laptop Purchase" as base use case and "Additional Warranty" as extending use case, here you can run base use case "Laptop Purchase" even without taking additional warranty.
还要注意 UML 版本：<< 已经过去很长时间了。使用>>和<<包括>>已替换为 <<包括>>和<<延伸>>通过 <<延伸>>和概括。
对我来说，这通常是误导点：例如，斯蒂芬妮的帖子和链接是关于旧版本的：
事实上，除了“付费购买”之外，没有其他真正的选择！在当今的UML中，“货到付款”是一种扩展，“使用paypal付款”/“通过卡付款”是专业化。
Also beware of the UML version : it's been a long time now that << uses >> and << includes >> have been replaced by << include >>, and << extends >> by << extend >> AND generalization.
For me that's often the misleading point : as an example the Stephanie's post and link is about an old version :
In fact there is no really alternative to "pay for item" ! In nowadays UML, "pay on delivery" is an extend, and "pay using paypal"/"pay by card" are specializations.
图表元素
参与者：也称为角色。可以在“属性”选项卡中更改参与者的名称和构造型。
继承：细化参与者之间的关系。这种关系可以带有名称和构造型。
用例：这些可以有扩展点。
扩展点：定义可以添加扩展的位置。
关联：角色和用例之间。给关联命名很有用。
依赖关系：用例之间。依赖关系通常有一个构造型，以更好地定义依赖关系的角色。要选择构造型，请从图表或导航窗格中选择依赖项，然后在“属性”选项卡中更改构造型。有两种特殊类型的依赖项：
<> 和<> ，Poseidon 为其提供了自己的按钮（见下文） .扩展关系：两个用例之间的单向关系。用例B和用例A之间的扩展关系意味着B的行为可以包含在A中。
包含关系：两个用例之间的单向关系。用例A和B之间的这种关系意味着B的行为总是包含在A中。
系统边界：系统边界实际上并未在 UML 的 Poseidon 中作为模型元素实现。您可以简单地绘制一个矩形，将其发送到后台，然后将所有相应的用例放在矩形内，将其用作系统边框。
Diagram Elements
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.
这是很棒的资源，有很好的解释：
用例中包含什么？
什么是用例扩展？
This is great resource with great explanation:
What is include at use case?
What is Extend at use case?
我不建议使用这个来记住两个：
我的用例：我要去城市。
包括->驾驶汽车
延伸->加满汽油
我希望你使用：
我的用例：我要去城市。
延伸->驾驶汽车
包括->加满汽油
我被教导扩展关系延续了基类的行为。基类功能必须存在。
另一方面，包含关系类似于可以调用的函数。五月以粗体显示。
这可以从
用例模型中的敏捷建模重用
I don't recommend the use of this to remember the two:
My use case: I am going to the city.
includes -> drive the car
extends -> fill the petrol
I would rather you use:
My use case: I am going to the city.
extends -> driving the car
includes -> fill the petrol
Am taught that extend relationship continues the behaviour of a base class. The base class functionalities have to be there.
The include relationship on the other hand, are akin to functions that may be called. May is in bold.
This can be seen from
agilemodeling Reuse in Use-Case Models
两者之间的区别已在此处进行了解释。但没有解释的是，
<> 和<> 根本不应该被使用。如果您读过 Bittner/Spence，您就会知道用例是关于综合，而不是分析。重复使用用例是无稽之谈。它清楚地表明您错误地剪切了域名。附加值本身必须是独一无二的。据我所知，唯一的增值再利用是特许经营权。所以如果你从事汉堡生意，那就太好了。但在其他任何地方，作为 BA，你的任务就是尝试找到 USP。这必须在良好的用例中呈现。
每当我看到人们使用其中一种关系时，他们都会尝试进行功能分解。这完全是错误的。
简而言之：如果你可以毫不犹豫地回答老板“我已经做了……”，那么“……”就是你的用例，因为你这样做是有钱的。 （这也表明“登录”根本不是一个用例。）
在这方面，找到包含或扩展其他用例的独立用例是非常不可能的。最终，您可以使用
<> 来显示系统的可选性，即一些许可模式，允许包含某些许可证的用例或省略它们。但除此之外——就避开它们吧。The difference between both has been explained here. But what has not been explained is the fact that
<<include>>and<<extend>>should simply not be used at all.If you read Bittner/Spence you know that use cases are about synthesis, not analysis. A re-use of use cases is nonsense. It clearly shows that you have cut your domain wrongly. Added value must be unique per se. The only re-use of added value I know is franchise. So if you are in burger business, nice. But everywhere else your task as BA is to try to find an USP. And that must be presented in good use cases.
Whenever I see people using one of those relations it is when they try to do functional decomposition. And that's plain wrong.
To put it simple: if you can answer your boss without hesitation "I have done ..." then the "..." is your use case since you got money for doing it. (That will also make clear that "login" is not a use case at all.)
In that respect, finding self standing use cases that are included or extend other use cases is very unlikely. Eventually you can use
<<extend>>to show optionality of your system, i.e. some licensing schema which allows to include use cases for some licenses or to omit them. But else - just avoid them.