UML和算法

时间:2010-07-16 22:58:18

标签: oop uml use-case

我对在某个应用程序的某些部分可能使用的算法的描述有点困惑。

假设我想创建一个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.

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

如果不是计算数字的平均值,我必须改变游戏的配置,进入下一个级别,在给定一组条件的情况下将用户添加到数据库等等?

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

在其他帖子主题中,有人谈到了业务规则。从我所看到的,它们似乎被放在类图上的小笔记。也许我错了?如果这就是它们,我发现它们太麻烦,无法用于更复杂的算法。

由于

3 个答案:

答案 0 :(得分:3)

如果您真的想坚持使用用例,您可以从系统的功能角度而不是最终用户角度编写一个。也许是这样的:

  1. 系统启动并将其总计数和计数变量归零。
  2. 系统会收到一个号码。
  3. 它将数字添加到总数中并递增计数。
  4. 步骤2& 3重复,直到系统被告知停止。
  5. 当被告知要停止时,系统会将总数除以计数并返回结果。
  6. 阅读Alastair Cockburns优秀书籍“Writing Effective Use Cases”。它解释了具有不同级别的用例。您的初始示例将被视为用户目标(或蓝色)用例,而上述步骤将成为子功能(或靛蓝)用例的一部分(它非常简单,甚至可能被归类为黑色用例并且刚刚合并进入其父母)。

    正如其他人肯定会说的那样,有时用例不是描述算法的最佳方式,你应该回到旧的流程图,状态图,序列图等等。这些工具可以为您带来好处 - 当它不适合您时,不要强迫使用特定方法。

    修改

    @devoured elysium:为了回应你的评论,我在下面添加了一些注释:

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

    这取决于您认为在您正在处理的有限上下文中的内容。也许,从用户的角度来看,有一个上下文只涉及“计算器”,但系统的观点还有另一个与“累加器”,“ALU”,“比特”,“单词”,注册“,”“时钟”,“锁存器”等。通过询问“如何?”,您可以进一步了解用例层次结构。语言的技术性越强。您需要确定哪些是域对象,哪些只是实现对象,这在很大程度上取决于您尝试描述和构建的事物的类型(以及在很大程度上,您的受众是谁 - 无处不在的语言和所有这些!)。相反,你可以通过询问“为什么?”来上升。正在执行该功能。

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

    在这个算法如此简单的例子中,我可能只是将它嵌入到主用例中。但是,如果它在多个其他更高级别的用例中使用,我会将其设置为Standalone,因此我可以将其包含在其他文档中。只是一种功能分解方法。

    这没有严格的规则。随着时间的推移,这是一种工作方式。正如其他人所说,确保您熟悉其他形式的图表,以便您可以为工作选择合适的工具。请记住,虽然图片可能值得千言万语,但实际上你也需要这些词,所以不要只依赖图表。

答案 1 :(得分:1)

您滥用用例:用例是STATIC视图:)

对于DYNAMIC View,您应该使用活动图或对象图/序列图。

答案 2 :(得分:1)

我有一个系统建模复杂问题,这与我解决在模型中添加约束的算法无关。我不知道它是否有帮助,但在我看来,你可以使用我所做的同样的技巧。我的意思是在图表中添加模型信息并使用多个图表,以便拥有多个用例视图。

这个多图表视图和用例保留它自己的属性非常酷,因为一旦我的用例保存在模型中,它就可以用于另一个图表,因此描述了特定图表中不可能的内容。 非常强大的概念使用元模型作为xmi数据库,UML编辑器作为模型的查看者而不是模型本身。我现在可以做以前不可能的事情,而且它更强大。它也更复杂,因为你应该看图表级别,但也在元模型级别,但一旦我使用它很棒:-) alt text http://www.forum-omondo.com/download/file.php?id=253&mode=view