用 starUML 构建的用例图中插件的可视化表示答案

【问题标题】：Visual Representation of a plugin in a use case diagram built with starUML用 starUML 构建的用例图中插件的可视化表示
【发布时间】：2011-01-25 10:22:45
【问题描述】：

问题说明了一切，如何构建插件的可视化表示？我有一个想法，我应该将其视为其他东西，或者只是不显示，但我找不到任何证据（数量足够多）来确定这一点。

在任何情况下我都不应该在我的用例中显示插件吗？

我是否需要将插件表示为包或演员？（如果是，我应该有什么联系，包括？）

或者我应该把它当作一个界面来表示？

也许我只是在这里偏离了轨道，上次我制作 UCD 是一年前还是什么时候，当你不使用东西时，一切都会溜走！所以我不介意这里有一些“初学者”的建议:)

【问题讨论】：

标签： plugins diagram use-case staruml

【解决方案1】：

用例用于分析，而不是设计，因此它们应该省略架构结构。当你有一个插件时，它就是一个系统，因此可能是正在开发的系统或参与者。如果它是正在开发的系统并且用例仅考虑此插件，则使用包含用例的图表中的边界框显示它（某些工具不允许这样做，它们使其隐含）。否则，如果您有描述与插件交互的系统行为的用例，则将插件描述为参与者。

【讨论】：

那么我将如何表示依赖关系？这些只是 A 需要 B 的结构的一部分，而且似乎不符合分析要求吗？
@Proclyon 对，依赖关系是关系，它们是在结构化（设计）过程中建立的。为此，您可以使用 UML 结构图，例如类图、复合结构图等
@Proclyon 另一方面，作为正在开发的系统的插件和其他参与者之间会存在某种依赖关系（与 UML 不完全相关），因为它们与系统交互（此插件案子）。因此，如果您有其他插件作为演员，它们会隐含地暗示一些依赖关系——它们之间的一些接口进行交互（例如，人类演员和软件系统暗示必须有一些 UI）。当您选择插件作为参与者时，情况正好相反，因此您在系统和与之交互的插件之间存在隐式依赖关系。