问用例图中的扩展:库管理示例？

EN

用例图中有两种关系--包括和扩展。

当一个用例将行为添加到另一个用例时，就会使用扩展关系。在这种情况下，将执行基本情况。然后，根据在执行该用例期间发生的情况，可能会执行一个或多个其他用例。请注意，并不需要实际执行扩展--这只是一种可能性。这也表明了特性之间的某种程度的重用。

当一个用例包含另一个用例的功能时，使用包含关系。具体的行为并不重要，但最终结果是，这意味着所包含的用例可能有不同的实现，但步骤和结果相同。在这种关系类型中，包含的用例通常不能作为独立的用例使用。

在您的特定示例中，我开发了两个我认为更合适的用例模型。在这两种情况下，我把演员从“会员”改为“图书馆员”。看起来，实际与软件交互的人不是图书馆成员，而是图书管理员。

在本例中，图书管理员可以执行两种功能--查看一本书或预订一本书。这两个例子都要求图书管理员使用成员提供的信息查找图书。但是，搜索功能不能作为独立实体使用。我不确定这是不是你想要的。

在本例中，图书管理员可以执行三种功能--查找书籍、签出书籍和记录预订。签出书籍和记录预订都使用查找图书用例，但是添加额外的行为。实现细节留作附加规范的练习，但这表明，要想签出一本书或预订，图书管理员必须首先查找图书。我相信这更符合您在问题中描述的功能。

最近，我在研究面向对象设计时碰巧遇到了这种情况。

我很难理解用例图中的扩展关系，有时有些关系看起来是可扩展的。

如果一个用例扩展了另一个用例的行为，则存在扩展关系。前者是延伸，后者是基础。在扩展关系中，基础本身是独立的和有意义的。扩展的情况不是这样的--这取决于基础。它不是靠自己维持的。

一般说来，找出扩展关系的经验法则是什么？

当一个用例具有可选行为时，或者当它具有仅在某些条件下执行的行为时，使用扩展关系。

预订可以是借到的吗？

如果一个成员可以独立预订(不管出于什么原因)，即使有书(就像他达到了借款限额)，那么就不可能是借入的延伸。储备可以靠自己维持。会员不用借就可以预订。否则，是的，它是借阅的延伸，因为它只在借来一本不可用的书时执行。我希望这能帮到你。

哦，如果储备是借来的延伸，不要像在图表中那样画。为了显示扩展关系，扩展用一个打开的箭头连接到基座。添加关键字extend。箭头指向从延伸到基部的方向。

我说你不应该费心想弄清楚你是否应该使用扩展/包含。这只会使你失去你真正想要完成的事情的焦点，也就是描述你的系统必须做些什么。他们有“罕见的”有益用途，但这是例外。当然，对于每一个琐碎的“公共”步骤，您都不需要它们。

我过去常常仔细考虑这些细节，直到我“事后”意识到，这些细节并没有真正为整个过程增加多少价值，而专注于这些细节最终会推动您在用例级别上实现真正不应该关注的细节。例如，尽管您的设计可能会以相同的方式保留一本书，无论您是如何获得的，但一旦您开始设计，您可能会发现它不能以同样的方式完成。现在，您必须“取消扩展”用例，因为您在需求级别上做出了设计决策。

当适当的时候使用扩展/包含，你会知道，如果我使用它，你就不用问自己了。

直接回答你的“规则是什么”的问题:如果没有明确的规则，那就不用费心了。

另外，就像FYI一样，步骤1和步骤2应该只是“成员请求预订图书”/“成员借阅请求”。您的描述没有明确的启动操作来启动每个特定的用例，这对于编写良好和有用的用例至关重要。

此外，也没有必要提及请求中已经暗示的“书中的信息”。一旦您开始分析用例并进行设计，那么您将确定请求所需的信息。