用例图的本质

Question

为了一项学校作业，我们需要制作一个用例图。但是我们所拥有的文档并不是很详尽，只说明了用例由哪些组件构成，并提供了一个例子。
我们需要制作一个关于图书馆系统的用例。我们找到了11个用例，但我不会让你们浪费时间把它们全部翻译出来。

据我所知，用例描述了系统的典型使用方式，对吧？但是，用例图中应该包含哪些内容，以及它们如何相互连接呢？

现在我们有四个参与者（会员，雇员，经理和会计）。我们最困扰的是会员和雇员。
雇员是使用系统的人。那么会员是否还应归为参与者？

我们有一些用例：

• 会员加入图书馆。
• 会员修改他的记录。
• 会员借书。
• 会员离开图书馆（取消订阅）。
• 会员预订文章。
• 会员归还书籍。
• 会员支付（部分）费用和罚款。

这些将成为图表上的用例。但是是否应该增加更多的用例，例如，雇员输入会员编号，雇员输入书号等（使用）？

能有人给我们一些建议吗？

编辑： 如何描述行动序列？我被告知可以将使用关联看作对某种程序的方法调用，这种程序重复出现。这样说对吗？那么扩展用于什么？

- Ikke

Answer 1

我IRC，用例描述了系统的典型使用情况，对吧？但是用例图中应该包含哪些内容，它们又是如何连接在一起的呢？

您的用例图（是的，一个典型的项目将会有多个）应该是UML套件中最简单的图之一。它们应该直接将您定义的角色/职能映射到您系统的用例上。实际上，它们应该主要关注单个角色，并且只在必须参与特定用例时才包括其他角色。

以下是我从谷歌上找到的一个示例： 示例用例图http://java.sun.com/mailers/newsletters/fundamentals/img/usecase.png 请注意其简洁性。一个角色，一个系统，5个用例。没有别的。

此外，正如@Eric P建议和我的示例图所示，您应该使用"[动词] [对象]"结构为您的用例命名；即"会员借书"变成了"借书"。您的用例句子中缺少的主语（"会员"）在您的用例图中被编码为与用例相关联的参与者。

员工是正在使用系统的人。会员作为演员仍然属于这里吗？

恐怕这个问题的答案是主观的。有些人会说不，因为系统只被员工使用，那么员工就是唯一的演员。我个人不同意。

为什么？首先，用例是需求收集阶段的一部分。它们的存在是为了帮助您组织系统的最终功能。但是，如果仅仅因为您目前认为技术不会被会员使用而否认会员参与者，那么您将在该阶段限制自己。

如果您的最终系统是自动化的，也就是说，Member自己去终端借书怎么办？如果在需求收集期间做出了假设，可能会错过重要的功能。 用例图是高层次的。它们应该展示您的高层次功能（以每个用例的形式）和使用它们的Actor，除此之外什么都不应该展示。不要在用例图中滥用extends和includes，应仅在罕见和特殊情况下使用。你可能犯的最大的新手错误（相信我，我也犯过！）是试图在用例图里将你的代码模块化。是的，我知道，任何值得一试的程序员都会尝试这样做，但用例图不是这样做的地方。

关于动作序列：在典型的UML图套件中，每个用例都与一个或多个活动图相关联。它们大致类似于流程图，并用作大多数软件工程教材鼓励的典型用例叙述结构的图形表示。无论如何，希望这可以帮到你。如果您有其他问题，请随时提问！

- Randolpho

Answer 2

我曾经学过，每个人使用用例图的方法都有所不同，所以我不知道这是否适用于您，但是演员通常是那些直接与系统接触的人。因此，除非会员扫描自己的图书馆卡或类似操作，否则成员不会成为演员，因为他必须通过员工进行操作。

用例应该覆盖所有内容，但不需要过于详细。因此，员工将检查会员资格，如果不存在，则转到创建会员资格用例，否则检查未付费用。如果会员资格状况良好，则扫描书籍等。

- Brandon

Answer 3

听起来你对用例的理解有些模糊。以下是一些资源，可以帮助你朝正确的方向前进：

• 用例 - 简介
• UML用例图

- Pesto

Answer 4

演员是使用系统的人，因此如果员工是唯一使用系统的人，则应该将其视为演员。如果某个功能可供员工和经理使用，则可能存在多个可能的演员。

因此，您可能希望将用例重新表述为“添加新成员”，“更改成员帐户”等。

至于详细程度，我建议您尽可能提供详细信息，但不要涉及“技术”方面。Brandon的建议非常好。

- Eric P