关于与类型描述字段相关的UML用例图的一些澄清？

我对UML用例图有一个疑问

如果我的申请中存在以下情况：

用户可以单击名为“我的驱动器”选项卡中的按钮，该选项卡显示一个显示虚拟驱动器列表的视图。在此视图中，我还有一个名为：添加新虚拟驱动器的按钮，如果用户单击此按钮，则可以添加新虚拟驱动器

现在什么是虚拟驱动器不是很重要，不管在这种特定情况下，虚拟驱动器是我系统上的虚拟硬盘

所以我必须用UML用例图形式化这种情况

参与者是与我的应用程序交互的用户

因此，我认为我有了第一个用例，它代表了用户点击我的驱动器按钮并查看当前可用虚拟驱动器列表的情况

使用此用例的表格演示，如下所示：

ID:UC01用例：显示有关可用资源的详细信息 虚拟驱动器

说明：表示用户请求的功能操作 显示详细信息 有关其有权访问的虚拟驱动器的信息

类型：PRIMARY，是系统的一个函数，由 用户

参与者：用户（主要参与者）、应用程序/服务器（次要参与者）

前提条件：用户必须登录到系统，并且 支持 必须显示与它的交互

主要场景（操作的正常过程）：用户单击 我的驱动器按钮 进入主表格菜单和详细信息 有关可用虚拟驱动器的信息 如表所示

成功后的后置条件：对于每个可用的虚拟驱动器 显示以下内容： 信息：一些信息（此处不重要）

发生故障时的后置条件：预计不会出现这种情况， 不应该有这种情况 执行此操作失败

好的，我认为这个模板是正确的，前面的用例是正确的。此时，我只对上一个模板的类型字段有疑问

我有：

类型：PRIMARY，是系统的一个函数，由 用户

我在搜索关于这个描述字段的信息，但没有发现任何东西……因此，我对它的推理是这样解释的：“如果用户直接调用系统上的函数，则表示该函数的用例的类型将主要作为类型字段的值”

行不行

现在我必须描述与第二个功能相关的用例：重要的观察结果是，只有在第一次运行第一个操作（显示可用虚拟驱动器列表）时，我才能执行第二个操作（添加新的虚拟驱动器）。

所以我有这样的想法：

ID:UC02用例：将新虚拟驱动器添加到可用驱动器列表中 虚拟驱动器

说明：表示用户请求添加新虚拟机的功能操作 驱动器到可用虚拟驱动器列表

类型：

参与者：用户（主要参与者）、应用程序/服务器（次要参与者）

前提条件：用户必须登录到系统，并且用户必须已显示视图 与“我的驱动器”按钮相关

成功后的后置条件：显示一个新视图，允许用户添加新的虚拟资源 驱动器到可用虚拟驱动器的列表

发生故障时的后置条件：不应出现这种情况，不应出现故障 执行此操作失败

现在，我的疑问与这个次要用例的类型描述字段有关

此函数由用户直接调用，因此，根据前面的推理，它必须是主要的（与前面的用例相同）

但是在其他地方（在另一个例子中），我发现在这种用例中，Typedescription字段的值必须是SECONDARY，因为它取决于第一个用例（因为用户首先必须调用显示所有可用虚拟驱动器列表的操作，然后才能添加新的虚拟驱动器）

那么，你能帮我澄清一下这个话题吗

Tnx

---

安德里亚

就像你偶然发现这个问题一样，你的读者可能不熟悉所使用的术语（“type=primary”）。然而，你的反对意见是要明确一点

所以我会选择最清晰的解决方案：

您可以使用UC 2到UC 1之间的

关系来澄清对UC 1的依赖关系。在UC前提条件描述中删除一条书面注释，该注释以纯文本形式说明依赖关系的执行顺序

用例并不意味着在执行时间或顺序上指定依赖关系。如果需要，请使用UML活动图或UML序列图，因为它们使这一点更加清晰。您还可以大大降低您的点被thre意外忽略的风险