我正在创建一个在核心应用程序之上添加各种功能的插件。该插件使管理员能够上传 CSV 文件，并根据文件中输入的信息执行以下功能（通过对核心应用程序的数据库执行操作）：
我想为这个插件绘制一个 UML 用例图，但不知道应该去哪里，尤其是 CSV 文件的上传。我也对如何在这里绘制核心应用程序的角色感到困惑。在这种情况下，它唯一直接做的就是授权。该插件还通过对核心应用程序的数据库执行操作来执行这些功能，我想知道是否应该有一些来自创建用户的关联，例如因此。
我的尝试之一可以在这里找到：
提前感谢您提供的任何帮助！
前言：我的回答是基于 Bittner/Spence（和其他人），而不是基于 UML 规范中的定义。
用例是关于所考虑的系统为主要参与者带来的附加值。你的系统有（看起来）三个用例
Create user（删除和修改它们呢？）Create project（同样在这里）Assigning user to project（也在这里）这些是您的用例，仅此而已（我从您的解释中读到）。您放在那里的所有其他气泡都来自功能分解，并且不是用例，而是（可能）用例内活动的一些步骤。只需将它们扔掉即可。
演员Core Application看起来像是代表正在考虑的系统。如果是这样：扔掉它，因为那是错误的。
气泡是（我猜）您需要附加到用例的约束，这Authorize意味着您必须对数据库进行授权。这不是用例。
你的系统看起来像
现在您的插件只是使用现有的用例并根据上传的 CSV 中的一些脚本执行它们。所以这是一个新的用例。根据设计，这可能只是添加到现有系统的新用例。UC 的名称可以Upload control file用来描述实际所做的事情。
如果您允许对系统进行某种动态扩展，那将是另一回事。你可以像这样设计它：
刚刚拥有“Value added system上传”UC，并使用核心系统作为演员。
为什么无视规范？好吧，原因很多，而且很简单：它没用。这是一个纯粹的技术描述，因此您的设计最终将出现在蜘蛛网中。专注于附加值正是项目开始时需要做的。如果你没有，你从一开始就迷路了。有几位知名作者在宣传这种方法。我从 Bitter/Spence 那里学到了东西，从那以后我发现它很有用。