如何确定应该添加到用例图表中的内容？每个按钮/表格1个？是否应该包括排序和搜索等内容？或者他们是否在“列表项目”下？虽然，似乎理解了一系列项目？
答案 0 :(得分：4)
用例图旨在帮助定义重要的高级业务任务，而不是系统功能列表。例如，用于客户服务的系统可能涉及查找信息以帮助某人进行支持呼叫的研究任务。
大多数文献都将用例描述为定义系统需要完成的内容的起点。诱惑一直是尽可能完整的;添加更多细节以将用例定义到功能（代码级）级别。尽管全面了解需求非常有用，但用例图并非旨在提供该级别的文档。
使问题变得更糟的一件事是我在工作项目中从未见过的语法。这并不是说这些术语没用，而是由于在何时对某个特定用例使用任一术语缺乏共识。 UML工件期望一个更专注于业务语言而不是实现语言的流程 - 而且我并不是指计算机语言。一些人倾向于以法律主义倾向接近图表并担心诸如何时用于相关用例或如何将错误处理表达为定义的过程任务列表的例外。
如果您曾经尝试过自动柜员机（ATM）示例，您就会明白我的意思。在UML学习的太阳能系统中，ATM示例是一个黑洞，会让你深入细节。避免使用它来理解UML或面向对象的分析和设计。它具有许多典型的现实领域的问题，即使它能够进行良好的高级研究，也会分散对整体理解的注意力。
是的，代码最终将来自UML工件，但这并不意味着它们必须像参议院的条约一样进行辩论。
答案 1 :(得分：1)
用例是指定系统所需用法的一种方法。通常，它们用于捕获系统的要求，即系统应该做什么。与用例相关的关键概念是参与者，用例和主题。该主题是用例适用的系统。用户和任何其他系统 可能与主题交互的人被表示为演员。演员总是模拟系统外部的实体。
主题的必需行为由一个或多个用例指定，这些用例是根据actor的需要定义的。严格地说，术语“用例”指的是用例类型。用例的实例是指出现的 符合相应用例类型的紧急行为。此类实例通常由交互规范描述。
演员指定用户或与主题交互的任何其他系统所扮演的角色。 （使用术语“角色”） 非正式地在这里，并不一定意味着在本说明书的其他地方找到的该术语的技术定义。）
现在大多数人都同意商业和用户级互动是最佳选择，但没有限制。想想你所关注的主要系统/系统之外的角色/角色。但是在一种观点中，系统可以是一个参与者，而在另一种视图中则是其他用例的实现者。