通过导入CSV执行各种功能的插件的UML用例图。

Question

我正在创建一个插件，在核心应用程序的基础上增加各种功能。该插件使管理员能够上传CSV文件，并根据文件中输入的信息执行以下功能（通过对核心应用程序的数据库进行操作）。

• 创建用户
  • 可以是管理员或普通用户
• 创建项目
  • 可以是母项目，也可以是母项目的子项目。
  • 子项目从给定的父项目中复制出来（所以插件也增加了创建子项目的选项，这些子项目是从父项目中复制出来的）。
• 将用户分配给具有特定权限的项目

我想为这个插件画一个UML用例图，但是搞不清楚什么应该放在哪里，尤其是CSV文件的上传。我也很困惑，如何画出这里的核心应用的角色。在这种情况下，它唯一直接做的就是授权。插件也是通过对核心应用的数据库进行操作来实现这些功能的，我在想是不是应该有一些关联来自于比如创建用户，因为这个。

我的一个尝试可以在这里找到。

先谢谢你的帮助

Answer 1

前言：我的回答是基于BittnerSpence（以及其他人）和 不 在UML规范中找到的定义。

---

一个用例是关于正在考虑的系统给主要角色带来的附加价值。你的系统有（看起来）三个用例。

• Create user (删除和修改它们呢？)
• Create project (这里也一样)
• Assigning user to project (也在这里)

这些都是你的用例，没有更多的用例（我从你的解释中读到的）。你放在那里的所有其他气泡都是来自于功能分解，并不是用例，而是（很可能）用例中的一些活动步骤。干脆把它们扔掉。

行为者 Core Application 看起来像是代表正在考虑的系统。如果是：扔掉它，因为那是错误的。

该 Authorize 泡沫是（我猜）一个约束，你需要附加到用例中，并意味着你必须对数据库进行授权。这不是用例。

你的系统看起来会像

现在你的插件只是使用现有的用例，并根据上传的CSV中的一些脚本来执行它们。所以这是一个新的用例。根据设计，这可能只是一个新的用例添加到现有系统中。UC的名称可以是 Upload control file 来描述实际的工作。

如果你允许系统的动态扩展，那就不一样了。 你可以像这样设计它。

你可以这样设计： Value added system 只是有了 "上传 "的UC，并将核心系统作为一个角色。

---

为什么不顾规范？嗯，对很多人来说，原因很简单：没有用。这是一个纯粹的技术描述，按照这个说法，你的 设计 最终会陷入蜘蛛网。关注附加值是项目开始时就需要的。如果你不具备这些，你从一开始就会迷失方向。有几个知名的作者在宣传这个方法。我从BitterSpence那里学到的，从此发现它很有用。