oop - UML 和算法

Question

我对在哪里描述我可能在应用程序的某些部分使用的算法感到有些困惑。

假设我想创建一个 Use Case描述了 User输入一组值，我的应用程序返回这些值的平均值(当然，这是一个非常简单的案例，但用这种方式解释起来更容易)。

1. The User tells the System he wants to calculate the average of a set of numbers.
2. The System asks the User for a number.
3. The User tells the System a number.
Repeat steps 2-3 until the User tells the System there are no more numbers left.
4. The System returns the average of all those numbers.

现在，我应该在哪里说明计算数字平均值背后的算法？

如果不是计算数字的平均值，我必须更改游戏的配置，进入下一个级别，将用户添加到给定一组条件的数据库等，该怎么办？

我觉得我需要以某种方式形式化我对该领域的知识，否则我可能会忘记它，甚至更糟，假设我知道只有通过写下来才能理解我不知道的事情。

在另一个主题中，有人谈到了业务规则。从我读到的内容来看，它们似乎是作为小笔记放在类图上的。也许我错了？如果这就是它们，我发现它们太麻烦而无法用于更复杂的算法。

谢谢

Answer 1

如果你真的想坚持使用用例，你会从系统的功能角度而不是最终用户的角度编写用例。也许是这样的:

系统启动并将其总数和计数变量清零。

系统收到一个号码。

它将数字添加到总数中并增加计数。

重复步骤 2 和 3，直到系统被告知停止。

当被告知停止时，系统将总数除以计数并返回结果。

阅读 Alastair Cockburns 的优秀著作“Writing Effective Use Cases”。它解释了具有不同级别的用例。您的初始示例将被视为用户目标(或蓝色)用例，而上述步骤将是子功能(或 Indigo)用例的一部分(它非常简单，甚至可能被归类为黑色用例并刚刚合并进入其父级)。

正如其他人肯定会说的那样，有时用例并不是描述算法的最佳方式，您应该回到良好的旧流程图、状态图、序列图或其他任何东西。这些工具是为了您的利益而存在的 - 不要在特定方法对您不起作用时强制使用它。

编辑

@devoured elysium:为了回应您的评论，我在下面添加了更多注释:

当您识别域对象时，有时您需要考虑未成文的对象。这一切都取决于它是如何编写的。因此，在您给出的示例中，也许“系统”是“计算器”，用于将数字相加的变量是“累加器”，也许有一个接收数字的“队列”。如果数字本身具有不同的行为，例如范围验证或输入语法检查，则可能是数字本身是“数字”类型的对象。是否有您需要考虑的“显示”对象？

这取决于您认为您正在处理的有界上下文中的内容。也许，从用户的角度来看，有一个上下文只处理“计算器”，但从系统的角度来看，还有另一个上下文与“累加器”、“ALU”、“位”、“字”、“寄存器”、“时钟”、“锁存器”等。通过询问“如何？”在用例层次结构中越往下走？语言将变得越技术化。你需要决定哪些是领域对象，哪些只是实现对象，这在很大程度上取决于你试图描述和构建的事物的类型(在很大程度上，你的受众是谁 - 无处不在的语言等等!)。相反，你可以通过问“为什么？”来上堆栈。该功能正在执行中。

子功能用例的主要参与者通常与调用它的更高级别用例的参与者相同。但是，对于某些“技术”用例，主要参与者将是系统组件/子系统。例如，系统消息记录用例可能将调用子系统作为主要参与者 - 即有意愿/需要启动操作的实体，而不是执行导致该子系统需要记录的任务的参与者某物。

在这个例子中，算法非常简单，我可能只是将它嵌入到主用例中。但是，如果它在多个其他更高级别的用例中使用，我会将其设为独立，以便我可以将其从其他文档中包含在内。只是一种功能分解方法。

对此没有硬性规定。这是一种您会随着时间的推移而发展的工作方式。正如其他人所说，确保您熟悉其他形式的图表，以便为工作选择合适的工具。请记住，尽管一张图片可能值一千个单词，但有时您实际上也需要这些单词，因此不要仅仅依赖图表。