没有发起人

Question

我需要在果园中建模一些业务流程。应该使用我需要构建的系统来增强这些业务流程。在我的情况下，这些是：

• 商店流程
• 销售流程
• 收获过程

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

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

Ofc，这是现实生活中的简化。

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

或许我应该像一些演员一样：经理。他会开始流动。但是我可以把他放在我的商业用例图中呢？

有人可以给我一些建议吗？

Answer 1

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

如果你是经理，你应该考虑附加价值。开始一个过程听起来很简单但实际上需要一点点（或者为什么他的薪水如此之高？）。所以很可能有一个用例。通常很难找到。

Answer 2

您说您需要创建业务用例图。你为什么需要？您是否正在使用您必须遵循的特定方法，例如Rational Unified Process？

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

Answer 3

为获得业务的高层次视图，有时我们会与非技术人员进行交谈，以通过访谈收集业务故事，从而确定业务的功能要求。上下文和系统DFD可以是一种与客户/您重新了解业务的好方法，当再次与业务/客户会面时可能很方便。

这些任务可能会导致进一步讨论您可以为企业做些什么；即，改善他们用作业务目标一部分的系统。例如，通过扩展功能来改进会计程序。