用例图的本质

Question

对于学校作业，我们必须制作用例图。但我们拥有的文档并不是很丰富。它只是描述了用例由哪些组件组成，以及一个示例。
我们必须制作一个关于图书馆系统的用例。我们已经找到了 11 个用例，但我不会用所有用例来打扰您。

IIRC，用例描述了系统的典型用法，对吧？但是哪些东西属于用例图，它们如何连接在一起？

我们现在有四个参与者（成员、雇员、经理和会计师）。我们遇到的问题最多的是会员和员工。
员工是使用该系统的人。成员作为演员还属于这里吗？

我们拥有的一些用例：

• 会员加入图书馆。
• 会员更改其记录。
• 会员借书。
• 会员部分图书馆（取消订阅）。
• 会员预订一篇文章。
• 会员归还书本。
• 会员支付（部分）费用和罚款。

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

任何人都可以阐明这一点吗？

编辑：如何描述动作顺序？有人告诉我，您可以看到使用关联，例如对某种重复出现的例程的方法调用？这是正确的吗？以及如何扩展使用？

Answer 1

IIRC，一个用途酶描述了系统的典型用法，对吗？但是，什么薄[g]属于用户酶图，以及它们如何将其连接在一起呢？

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

这是我从谷歌上得到的一个例子：

示例用例图 http://java.sun.com/mailers/newsletters/fundamentals/img/usecase.png

注意简单性。一名参与者、一个系统、5 个用例。没有其他的。

另外，如 @埃里克·P 建议和我的示例图像暗示，您应该使用“[Verb] [Object]”结构为您的用例命名；IE。“会员借书”变为“借书”。用例句子中缺失的主语（“成员”）在用例图中被编码为与用例关联的参与者。

员工是正在使用系统的人。成员仍然属于演员吗？

恐怕这个问题的答案是主观的。有人会说不，因为系统仅由员工使用，所以员工是唯一的参与者。我个人不同意。

为什么？其一，用例是需求收集阶段的一部分。它们可以帮助您组织系统的最终功能。但要否认的是 Member 演员只是因为您当前的信念是该技术不会被其他人使用 Member 就是把自己限制在那个阶段。

如果您最终的系统怎么办 是 自动化，意味着 Member 自己去终端机借书吗？如果您在需求收集期间做出假设，您可能会错过重要的功能。

编辑： 如何描述动作序列？有人告诉您，您可以看到一种用途的关联，例如一种方法来调用某种恢复的常规？这是正确的吗？以及如何使用扩展？

用例图是高层次的. 。它们应该展示您的高级功能（以每个用例的形式）以及使用它们的参与者，仅此而已。不要在用例图中乱扔扩展和包含；这些应该是罕见的和特殊的情况。您可能犯的最大的菜鸟错误（相信我，我已经犯了！）是尝试在用例图中模块化您的代码。是的，我知道，这是任何称职的程序员都会尝试做的第一件事，但用例图不适合这样做。

关于动作顺序：在一套典型的 UML 图中，每个用例都与其关联一个或多个 活动图. 。它们大致类似于流程图，并作为大多数软件工程教科书鼓励的典型用例叙述结构的图形表示。

无论如何，我希望这会有所帮助。如果您还有其他问题，请随时提问！

Answer 2

有人告诉我，每个人对用例图的处理方法都有点不同，所以我不知道这是否适用于你，但参与者通常是那些与系统直接接触的人。因此，会员除非扫描自己的借书卡或其他东西，否则就不会成为演员，因为他必须通过员工。

用例应该涵盖所有内容，但不要太详细。因此，员工将检查会员资格，如果不存在，则去创建会员资格用例，否则检查未付费用。如果会员资格良好，请扫描书籍等。

Answer 3

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

• 用例 - 简介
• UML 用例图

Answer 4

参与者是使用系统的人，因此如果员工是唯一使用系统的人，那么他们应该是参与者。例如，如果员工和经理都可以使用某个功能，那么您还可以有多个可能的参与者。

因此，您可能需要将用例改写为“添加新成员”、“更改成员帐户”等。

至于详细程度，我会在不涉及“技术”的情况下包含尽可能多的细节。布兰登的建议非常好。