UML and Algorithms

Question

UML and Algorithms

4

我有点困惑在应用程序的某些部分描述算法的位置。

假设我想创建一个用例，描述用户输入一组值，我的应用程序返回这些值的平均值（当然，这是一个非常简单的情况，但这样更容易解释）。

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.

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

如果不是计算数字平均值，而是需要更改游戏配置、进入下一级别、根据一组条件向数据库添加用户等，怎么办？

我觉得我需要以某种方式正式化我对领域的知识，否则我可能会忘记它，甚至更糟糕的是，认为我知道的东西只有通过写下来才能理解我不知道。

在其他线程或主题中，有人谈到业务规则。从我所了解的内容来看，它们似乎被放置在类图上的小笔记中。也许我错了？如果是这样，我觉得它们对于更复杂的算法来说太麻烦了。

谢谢

- devoured elysium

3个回答

1

您正在误用用例：用例是一种静态视图 :)

对于动态视图，您应该使用活动图或对象图/序列图。

- Rebol Tutorial

1

我之前遇到一个复杂的系统建模问题，与算法无关，我通过在模型中添加约束条件来解决它。不知道这个方法是否有用，但我认为你也可以使用相同的技巧。我的意思是，在图表中添加模型信息，并使用多个图表以便拥有用例的多个视图。

这种多图表视图和保持用例本身属性的方式真的很棒，因为一旦我的用例保存在模型中，它就可以用于另一个图表中，从而描述在特定图表中不可能实现的东西。使用元模型作为xmi数据库，UML编辑器作为模型的查看器而不是模型本身的非常强大的概念。现在我能做以前不可能做的事情，效果更加强大。这也更加复杂，因为你不仅要看图表级别，还要看元模型级别，但一旦习惯了，就会觉得非常棒 :-) alt text http://www.forum-omondo.com/download/file.php?id=253&mode=view

- UML GURU

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Trevor Tippins · Accepted Answer

如果您真的想坚持使用用例，那么您将从系统的功能视角而不是最终用户的视角编写一个。也许像这样：

系统启动并将其总数和计数变量归零。
系统接收一个数字。
它将数字加到总数中并增加计数。
步骤2和3重复，直到系统被告知停止。
当被告知停止时，系统将总数除以计数并返回结果。

请阅读Alastair Cockburn的优秀书籍“Writing Effective Use Cases”。它解释了有不同级别的用例。您的初始示例将被视为用户目标（或蓝色）用例，而上面的步骤将成为子功能（或靛色）用例的一部分（它非常简单，甚至可以被归类为黑色用例并合并到其父级）。

作为其他人可能会说的，有时候用例并不是描述算法的最佳方式，你应该退而求其次，使用老式的流程图、状态图、序列图或其他工具。这些工具都是为了你的利益而存在的——当它不能满足你的需求时，不要被迫使用特定的方法。

编辑：

@devoured elysium：针对您的评论，我在下面添加了一些注释：

当您确定领域对象时，有时需要考虑未编写的对象。这完全取决于它的书写方式。因此，在您所提供的示例中，"System" 可能是 "Calculator"，正在使用的变量是 "Accumulator"，也许有一个 "Queue" 接收数字。如果数字本身可以具有不同的行为，例如范围验证或输入语法检查，则数字本身可能是 "Number" 类型的对象。是否需要考虑 "Display" 对象？

这取决于您认为所涉及的有界上下文是什么。也许，从用户的角度来看，有一个只处理“计算器”的上下文，但从系统的视角来看，另一个上下文与“累加器”、“ALU”、“位”、“字”、“寄存器”、“时钟”和“锁存器”等低层上下文相关。通过询问“如何？”来向用例层次结构深入探究，语言将变得更加技术性。您需要决定哪些是领域对象，哪些只是实现对象，这在很大程度上取决于您试图描述和构建的类型（以及您的受众是谁——普遍语言等！）。相反，您可以通过询问正在执行的功能的“为什么？”来向上走。

子功能用例的主要参与者通常是调用它的高级别用例的相同参与者。但对于一些“技术性”用例，主要参与者将是系统组件/子系统。例如，系统消息日志记录用例可能会将调用子系统作为主要参与者——即具有意愿/需要发起动作的实体，而不是执行导致该子系统需要记录某些内容的任务的参与者。

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

没有硬性规定。这是您随着时间演变的工作风格。正如其他人所说，确保您熟悉其他形式的图表，以便您可以选择适合工作的正确工具。请记住，尽管图片价值千言万语，有时您实际上也需要那些文字，因此不要仅依赖图表。