假设我们有一个简单的在线商店。用户希望通过商店实现的目标是：
但是，用户可以启动某些功能，但不是他们使用系统的主要目标：
我认为登录和注销之类的东西不应该出现在 UML 用例图中。原因是用户不想仅仅为了登录而去在线商店；他们总是有另一个目标，即查看/编辑帐户信息或浏览和购买东西。
同样，两个选择“语句”是浏览项用例的一部分。我不会使用泛化，因为可能有很多部门。
最后，输入交付详细信息是“结帐”或“编辑帐户信息”用例的一部分。我通常会将其与“编辑帐户信息”用例混为一谈，否则您可能还会有“编辑名称”、“编辑电子邮件”等用例。
我主要担心的是，如果你有一个非常复杂的用例图，它就会违背拥有一个的目的，因为它不容易阅读。
所以，我的问题如下。我这背后的想法正确吗？最好只在用例图中建模“真实”目标或参与者可以启动的所有内容？
UML 的使用是否可以显示参与者可以做的所有事情（功能）或参与者想要做的所有事情（目标）？
它可以是任何一种——UML 规范在这方面没有规定。Alistair Cockburn为用例创建了一个分类，表明他们关注的级别。
话说回来：
我主要担心的是，如果你有一个非常复杂的用例图，它就会违背拥有一个的目的，因为它不容易阅读。
这是一个非常现实的风险。就我个人而言，我发现通过关注用户和他们的目标，我从 UC 中获益最多。他们希望从系统中获得什么价值？
将其保持在该级别可以防止“只见树木不见森林”的情况 - 并且还会阻止 UC 成为完整的功能分解设计。
hth。
从图表中排除一些用例并没有错，而且确实可能是个好主意。例如，如果您要向业务部门展示您的图表，您可以绘制一个描述操作用例的 UML 模型。如果你要将你的图表交给程序员，你会想要给他们一个关于他们必须实现什么的完整描述。这些只是您系统的模型。
绘制用例图时，通常还会写下每个用例的行为（如自由文本描述、伪代码或使用交互图）。
UML 规范说：
用例是系统执行的一组操作的规范，它产生一个可观察的结果，通常对系统的一个或多个参与者或其他利益相关者有价值。
用户可以观察到登录和注销。虽然用户不会以登录的唯一目的访问您的站点，但这样的用例肯定有一些您也想描述的执行流程。如果您不允许用户自己发起登录，则会出现包含login功能的用例。用户也可能有兴趣在离开站点之前注销，以便没有会话数据将保留在他的计算机中。
选择“电子”部门，选择“车辆”部门......为什么不只是选择部门（我想他们并没有太大的不同）。
我会画出这个和其他用例，只要它们与模型相关。