Uml 用例图关系和应用程序工作流

我想为我的应用程序创建一个用例图（以及用例场景），但我对它不是很熟悉。我的应用程序有两个屏幕，每个屏幕都包含一些用户可以交互的功能。
假设它是一个汽车共享应用程序，第一个屏幕包含两个操作：

• 浏览汽车→ 当用户可以看到汽车列表时，它会将用户移动到另一个屏幕
• 查看租赁历史记录→ 这会将用户移动到另一个屏幕，当用户可以看到他过去租车的列表时

我认为这两个动作是两个用例，例如动作“浏览汽车”就是带有工作流的用例“浏览汽车”：

应用程序显示一个列表

应用程序下载数据(→ 它可能会在此处失去连接等）

应用程序显示数据

我说得对吗？然后，图表应该是这样的（A是参与者）：

A_uuUC1
|___UC2

接下来，从“浏览汽车”屏幕，我可以查看汽车的详细信息，从详细信息我可以租用汽车等等…
我不确定这些操作是否应该被视为

关系，或者它应该只是actor的独立用例。
我不认为租车、展示清单或汽车的详细信息真的应该相互依赖。这取决于应用程序，因为屏幕是按功能分组的，在我的情况下这是预期的工作流程，但在其他UI设计中可能会有所不同。我是否应该关心预期的工作流程

应该是这样的：
A--UC1←扩展--UC3←扩展--UC4
|___UC2

或者这个：
A_uuUC1
|___UC2
|___UC3
|___UC4

我的应用程序包含许多功能（目前定义了大约40个），我必须在图表上展示每个用例。
在第一种情况下，它看起来像一棵树，与此类似：

[]

（摘自）

它是一个有效的用例图吗

在第二种情况下，它看起来像一大列椭圆，如下图所示，但有更多的用例：

我应该选择哪一个？如果我把它画成例子2，那么

的目的是什么？另外，“浏览汽车”和“展示汽车的细节”是两个独立的用例，还是应该合并为一个

还有一个问题是，如果我有两个参与者可以做相同的事情，但结果不同，那么应该是两个不同的用例还是一个，我应该在用例场景中包含某种条件

---

谢谢你，你的第一种方法是功能分解，这是错误的。用例是考虑中的系统给参与者带来的附加值。所以第二张图片很好。我没有读过你描述的细节

---

我建议（一如既往）阅读Bittner/Spence关于用例建模的内容。

感谢您的回答和建议，开始阅读这本书。这将需要一段时间来消化。我是一个天生的黑客（至少在我年轻的时候是这样），我很难从我的科技马上下来。然而，这本书确实把它带到了点子上。