对于学校作业，我们必须制作一个用例图。但是我们拥有的文档不是很扩展。它只是描述了一个用例由哪些组件组成，以及一个示例。
我们必须制作一个关于图书馆系统的用例。我们已经找到了 11 个用例，但我不会用所有这些用例来打扰您。
IIRC，用例描述了系统的典型用法，对吗？但是什么东西属于用例图，它们是如何连接在一起的？
我们现在有四个参与者（成员、员工、经理和会计师）。我们遇到最多的问题是会员和员工。
员工是使用该系统的人。成员仍然属于这里的演员吗？
我们拥有的一些用例：
这些成为图表上的用例。但是应该有更多的用例，比如员工输入会员编号，员工输入账簿编号等等（用途？）。
任何人都可以（？）对此有所了解吗？
编辑： 如何描述动作序列？有人告诉我，您可以看到使用关联，例如对某种重复例程的方法调用？这是正确的吗？以及如何扩展使用？
IIRC，用例描述了系统的典型用法，对吗？但是用例图上的东西是什么，它们是如何连接在一起的？
你的用例图（是的，一个典型的项目会有不止一个）应该是你的 UML 套件中最简单的图。它们应该将您定义的角色/角色直接映射到系统的用例。事实上，他们应该主要关注单个 Actor，并且仅在必须参与特定用例时才包含其他 Actor。
这是我从谷歌上下来的一个例子：
示例用例图 http://java.sun.com/mailers/newsletters/fundamentals/img/usecase.png
注意简单。一个参与者，一个系统，5 个用例。没有其他的。
此外，正如@Eric P所建议的和我的示例图像所暗示的那样，您应该使用“[Verb] [Object]”结构命名您的用例；即“会员借书”变成“借书”。用例句子中缺失的主题（“成员”）在用例图中编码为与用例关联的参与者。
员工是使用该系统的人。成员仍然属于这里的演员吗？
恐怕这个答案是主观的。有人会说不，因为该系统仅供员工使用，所以员工是唯一的参与者。我个人不同意。
为什么？一方面，用例是需求收集阶段的一部分。它们可以帮助您组织系统的最终功能。Member但是仅仅因为您当前的信念是该技术不会被该演员使用而否认该演员Member是在该阶段限制您自己。
如果您的最终系统是自动化的，这意味着您自己Member去终端检查一本书怎么办？如果您在收集需求时做出假设，您可能会错过重要的功能。
编辑：如何描述动作序列？有人告诉我，您可以看到使用关联，例如对某种重复例程的方法调用？这是正确的吗？以及如何扩展使用？
用例图是高级别的。它们应该显示您的高级功能（以每个用例的形式）和使用它们的 Actors，仅此而已。不要在你的用例图中乱扔扩展和包含；那些应该是罕见的和特殊情况。您可能犯的最大新手错误（相信我，我已经做到了！）是尝试在用例图中模块化您的代码。是的，我知道，这是任何称职的程序员都会尝试做的第一件事，但用例图不是做它的地方。
关于动作序列：在一套典型的 UML 图中，每个用例都与一个或多个Activity Diagrams相关联。这些大致类似于流程图，并用作大多数软件工程教科书鼓励的典型用例叙述结构的图形表示。
无论如何，我希望这会有所帮助。如果您还有其他问题，请随时提问！
我被告知每个人对用例图的处理方式都有些不同，所以我不知道这是否适用于您，但参与者通常是那些与系统直接接触的人。因此，除非他扫描自己的借书证或其他东西，否则成员不会成为演员，因为他必须通过员工。
用例应该涵盖所有内容，但不能非常详细。因此，员工将检查会员资格，如果不存在，则创建会员用例，否则检查未付费用。如果会员信誉良好，请扫描书籍等。
演员是使用系统的人，所以如果员工是唯一使用系统的人，那么他们应该是演员。例如，如果员工和经理都可以使用某个功能，您还可以有多个可能的参与者。
因此，您可能希望将您的用例重新表述为“添加新成员”、“更改成员帐户”等内容。
至于详细程度，我会尽可能多地包含细节，而不会获得“技术性”。布兰登的建议非常好。
