对于学校作业，我们必须制作一个Usecase图表。但是我们拥有的文档并没有得到很好的扩展。它只描述了一个用例包含哪些组件，以及一个例子 我们必须制作一个关于图书馆系统的用例。我们已经找到了11个用例，但是我不打扰所有这些用例。
我们现在拥有四名演员（成员，员工，经理和会计师）。我们遇到的问题最多的是会员和员工 员工是使用该系统的人员。成员是否仍然属于演员？
我们拥有的一些用例：
那些在图上成为用例。但是，如果有更多的用例，例如，员工进入会员编号，员工进入簿记号等（使用？）。
任何人都可以对此有所了解吗？
修改： 如何描述行动序列？我被告知你可以看到一个使用关联，就像一个方法调用某种常规再次出现？这是正确的吗？如何扩展使用？
答案 0 :(得分：8)
IIRC，一个用例描述了一个典型的 使用系统吧？但是什么 thin [g]属于用例图，并且 他们如何连接在一起？
您的用例图（是的，典型项目将有多个）应该是UML套件中最简单的图表。他们应该将您已定义的Actors / Roles直接映射到系统的Use Cases。事实上，他们应该主要关注单个Actor，如果他们必须参与特定的用例，则只包括其他Actors。
以下是我离开Google的一个例子：
Sample Use Case Diagram http://java.sun.com/mailers/newsletters/fundamentals/img/usecase.png
注意简单。一个演员，一个系统，5个用例。没别了。
此外，正如@Eric P建议的那样，我的示例图片暗示，您应该使用“[动词] [对象]”结构标题您的用例;即“会员借书”成为“借书”。您的用例句子（“成员”）中缺少的主题在您的用例图中被编码为与用例关联的Actor。
员工是使用者 系统。会员还在吗？ 在这里属于演员吗？
我担心答案是主观的。有些人会说不，因为系统只供员工使用，所以员工是唯一的参与者。我个人不同意。
为什么呢？例如，用例是需求收集阶段的一部分。它们可以帮助您组织系统的最终功能。但是否认Member演员只是因为你当前的信念是Member不会使用该技术就是限制你自己进入那个阶段。
如果您的最终系统 自动化，这意味着Member会到终端自行查看一本书，该怎么办？如果您在需求收集期间做出了假设，那么您可能会错过重要的功能。
编辑： 行动顺序如何？ 描述？我被告知你可以看到 a使用方法调用之类的关联 某种程序会再次出现？ 这是正确的吗？如何扩展 使用
用例图是高级。它们应该显示您的高级功能（以每个用例的形式）和使用它们的Actors而不是其他任何东西。不要使用扩展和包含来丢弃您的用例图;那些应该是罕见的，只有特殊情况。你可以做出的最大的新手错误（相信我，我已经成功了！）是试图在你的用例图中模块化你的代码。是的，我知道，这是任何值得他的盐尝试做的程序员的第一件事，但用例图不适合它。
关于行动序列：在典型的UML图表套件中，每个用例都与一个或多个Activity Diagrams相关联。这些大致类似于流程图，并作为大多数软件工程教科书鼓励的典型用例叙述结构的图形表示。
无论如何，我希望这会有所帮助。如果您有其他问题，请随时提出！
答案 1 :(得分：4)
我被告知每个人使用案例图的方法都有点不同，所以我不知道这是否适用于你，但演员通常是那些与系统直接接触的人。所以一个成员不会是演员，除非他扫描自己的图书馆卡或其他东西，因为他必须通过该员工。
用例应该涵盖所有内容，但不是非常详细。所以员工会检查会员资格，如果不存在，去创建会员用例，否则检查未付费用。如果会员资格良好，扫描书等
答案 2 :(得分：4)
听起来你对用例是什么有一个泥泞的理解。以下是一些可以帮助您朝着正确方向前进的资源：
答案 3 :(得分：3)
演员是使用该系统的人，因此如果Employee是唯一使用该系统的人，那么他们应该是演员。如果例如一个函数可供Employees和Managers使用，您也可以有多个可能的actor。
因此，您可能希望将您的用例改为“添加新成员”，“更改成员帐户”等内容。
至于详细程度，我会尽可能详细地包含“技术”。布兰登的建议非常好。
