我需要为果园中的一些业务流程建模。这些业务流程应该通过我需要构建的系统来增强。就我而言，这些是：
首先，我需要创建一个业务用例图。我创造了这样的东西：
让我解释一下。当我们需要收获时，我们会与工作机构联系以获取一些工人，我们会给他们一份工作等...... 当我们想出售或储存我们的收成时，我们需要打电话给运输公司将我们的东西运到仓库或批发出售。
Ofc，这比在现实生活中要简单得多。
我的问题是：因为我正在构建的系统将在公司/果园内使用，所以此图中没有使用用例的外部参与者。没有人可以使用用例。这是正确的吗？下一步是创建一个序列图，看起来 Orchard 需要启动流程。
或者我应该排除一些演员，例如：经理。他将启动流程。但是我可以把他放在我的业务用例图中的什么地方呢？
有人能给我一些建议吗？
【问题讨论】：
标签： uml actor analysis use-case
一个用例和一个参与者具有 1:1 的关系（尽管您可能会读到关于次要参与者的内容）。用例描述了它的参与者收到的附加值。如果您确定参与者和附加值，您可以描述用例。否则你不能。如果你有一个不扮演角色的演员，那么它就不是演员。还要忘记“内部”和“外部”演员。演员总是外在的。用例位于所考虑系统的边界。还有外面的演员。
对于您的经理，您应该考虑附加值。开始一个过程听起来很简单，但实际上需要一点时间（或者为什么他的薪水这么高？）。所以很可能有一个用例。通常很难找到。
【讨论】：
您说您需要创建一个业务用例图。为什么需要？您是否正在使用某种特定的方法，例如 Rational Unified Process，您必须遵循该方法？
就我个人而言，我认为业务用例图并不是指定业务流程的一种很好的技术。正如您所指出的，它们不能用于内部流程。相反，我会使用活动图。业务流程是 UML 的“活动”。这为使用对流程建模的活动图进一步分解每个业务流程提供了一个很好的起点。我已经在我的论文"Which UML models should we make? 中更详细地解释了我对业务用例图的反对意见。请参阅标题为“更多业务分析”的段落。
【讨论】：
为了获得业务的高级视图，有时我们会与非技术人员交谈，通过访谈收集业务故事，以确定业务的功能需求。上下文和系统 DFD 可能是一种很好的方式，可以让您与客户重新了解业务/在再次与业务/客户会面时可能会派上用场。
这些任务很可能会引发关于您可以为企业做些什么的进一步讨论；即改进他们用作业务目标一部分的系统。例如，通过扩展功能来改进会计程序。
【讨论】：