Uml 没有初始参与者的业务用例图

我需要对果园中的一些业务流程进行建模。这些业务流程应该通过我需要构建的系统来增强。就我而言，这些是：

• 存储过程
• 销售流程
• 收获过程

首先，我需要创建一个业务用例图。我创造了这样的东西：

让我解释一下。当我们需要收获的时候，我们会联系工作机构找一些工人，我们会给他们一份工作等等。。。 当我们想要销售或储存我们的收成时，我们需要打电话给运输公司，将我们的东西运到仓库或批发销售

Ofc，这比现实生活中要简单得多

我的问题是：因为我构建的系统将在公司/果园内部使用，所以在这个图中没有使用用例的外部参与者。没有人可以使用用例。对吗？下一步是创建序列图，看起来Orchard需要启动流程

或者我应该原谅一些演员，比如：经理。他将启动流程。但是我可以把他放在我的业务用例图中的什么地方呢

---

有人能给我一些建议吗？

一个用例和一个参与者有1:1的关系（尽管你可能会读到关于次要参与者的内容）。用例描述了参与者收到的附加值。如果您同时识别了参与者和附加值，那么您可以描述用例。否则你不能。如果你有一个演员没有扮演某个角色，那么他就不是演员。也不要考虑“内部”和“外部”参与者。演员总是外在的。用例位于所考虑的系统的边界。还有外面的演员

---

对于您的经理，您应该考虑附加值。开始一个过程听起来很简单，但实际上需要一点时间（或者为什么他的工资这么高？）。所以很可能存在一个用例。通常很难找到。

您说需要创建业务用例图。你为什么要这么做？您是否使用了一种特殊的方法，比如必须遵循的Rational统一过程

---

就我个人而言，我认为业务用例图不是一种很好的指定业务流程的技术。正如您所指出的，它们不能用于内部流程。相反，我会使用活动图。业务流程是一个UML“活动”。这为使用流程流建模的活动图进一步分解每个业务流程提供了一个良好的起点。我在论文中更详细地解释了我对业务用例图的反对意见。请参阅标题为“更多业务分析”的段落。

为了获取业务的高层视图，有时我们会与非技术人员交谈，通过访谈收集业务故事，以确定业务的功能需求。上下文和系统DFD是一种很好的方式，可以让您在与客户/业务部门再次会面时，更好地理解业务

这些任务很可能导致进一步讨论您可以为业务做些什么；i、 e.改进作为其业务目标一部分使用的系统。例如，通过扩展功能来改进会计程序