UML和算法
我对在哪里描述我可能在应用程序的某些部分使用的算法有点困惑。
假设我想创建一个用例来描述用户如何输入一组值，并且我的应用程序如何返回这些值的平均值（当然这是一个死的-简单的情况，但这样解释起来更容易）。
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.
现在，我应该在哪里说明计算数字平均值背后的算法？
如果我不是计算数字的平均值，而是必须更改游戏的配置、进入下一个级别、在给定一组条件的情况下将用户添加到数据库等，该怎么办？
我觉得我需要以某种方式形式化我所拥有的该领域的知识，否则我可能会忘记它，或者更糟糕的是，假设我知道只有写下来才能理解的东西。
在其他线程、主题中，有人谈论了业务规则。从我读到的内容来看，它们似乎是作为类图上的小注释。也许我错了？如果这就是它们的本质，我发现它们太麻烦而无法用于更复杂的算法。
谢谢
I am a bit confused about where to describe the algorithm I might use in some part of an application.
Let's say I want to create a Use Case that describes how the User inputs a set of values and my application returns the average of those values (of course this is a dead-easy case, but its easier to explain it this way).
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.
Now, where should I state the algorithm behind calculating the average of the numbers?
What if instead of calculating the average of numbers, I had to change the configuration of a game, go to the next level, add users to a database given a set of conditions, etc?
I feel like I need to in some way formalize the knowledge I have of the domain, otherwise I might either forget it or even worse, assume I know things that only by writing down would I understand I don't.
In other thread, topic, someone talked about business rules. From what I've read they seem to be put as small notes on class diagrams. Maybe I'm wrong? If that's what they are, I find they too cumbersome to use for more complex algorithms.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果您确实想坚持使用用例，您应该从系统功能的角度而不是最终用户的角度来编写用例。也许是这样的：
阅读 Alastair Cockburn 的优秀著作“编写有效的用例”。它解释了不同级别的用例。您最初的示例将被视为用户目标（或蓝色）用例，而上述步骤将是子功能（或靛蓝）用例的一部分（它非常简单，甚至可能被归类为黑色用例并只是合并）进入其父级）。
正如其他人肯定会说的那样，有时用例并不是描述算法的最佳方式，您应该使用旧的流程图、状态图、序列图或其他任何东西。这些工具是为了您的利益而存在的——当某个方法不适合您时，不要被强制使用它。
编辑
@devoured elysium：为了回应您的评论，我在下面添加了一些注释：
当您识别域对象时，有时您需要考虑不成文的对象。这完全取决于它是如何编写的。因此，在您给出的示例中，也许“系统”是一个“计算器”，用于将数字相加的变量是一个“累加器”，也许有一个接收数字的“队列”。如果数字本身可以具有不同的行为（例如范围验证或输入语法检查），则数字本身可能是“数字”类型的对象。您是否需要考虑“显示”对象？
这取决于您认为您正在处理的有界上下文中的内容。也许，从用户的角度来看，有一个上下文只处理“计算器”，但系统的角度来看，还有另一个上下文涉及“累加器”、“ALU”、“位”、“字”、“寄存器”、“时钟”、“锁存器”等。通过询问“如何？”，您在用例层次结构中走得越远。语言将变得越技术化。您需要决定哪些是领域对象，哪些只是实现对象，这在很大程度上取决于您试图描述和构建的事物的类型（并且在很大程度上取决于您的受众是谁 - 无处不在的语言等等） ！）。相反，你可以通过问“为什么？”来向上查看堆栈。该功能正在执行。
子功能用例的主要参与者通常与调用它的更高级别用例的参与者相同。但对于某些“技术”用例，主要参与者将是系统组件/子系统。例如，系统消息记录用例可能将调用子系统作为主要参与者 - 即具有启动操作的意愿/需要的实体，而不是执行导致该子系统需要记录的任务的参与者某物。
在这个例子中，算法非常简单，我可能只是将其嵌入到主要用例中。但是，如果它在多个其他更高级别的用例中使用，我会将其设为独立，以便我可以将其包含在其他文档中。只是一种功能分解方法。
对此没有硬性规定。这是一种随着时间的推移而演变的工作方式。正如其他人所说，请确保您熟悉其他形式的图表，以便您可以为工作选择正确的工具。请记住，虽然一张图片可能抵得上一千个单词，但有时您实际上也需要这些单词，所以不要仅仅依赖图表。
If you really want to stick with Use Cases you'd write one from the System's functional viewpoint rather than that of the end-user. Maybe something like this:
Have a read of Alastair Cockburns excellent book "Writing Effective Use Cases". It explains about having different levels of Use Case. Your initial example would be considered a User Goal (or Blue) Use Case whilst the steps above would be part of a Sub-Function (or Indigo) Use Case (it's so simple it might even be classed as a Black Use Case and just merged into its parent).
As other people are sure to say, sometimes a Use Case isn't the best way to describe an algorithm and you should fall back to good old flowcharts, state charts, sequence diagrams or whatever. These tools are there for your benefit - don't be constrained by forcing a particular method when it doesn't work for you.
EDIT
@devoured elysium: In response to your comments I've added a few more notes below:
When you're identifying domain objects sometimes you need to think about unwritten objects. It all depends on how it has been written. So, in the example you gave, maybe the "System" is a "Calculator", the variable being used to add the numbers up is an "Accumulator", maybe there's a "Queue" that receives the number. Could be that the number itself is an object of a type "Number" if that can have distinct behaviour like range validation, or input syntax checking. Is there a "Display" object that you need to consider?
It depends on what you consider to be in the bounded context you're dealing with. Maybe, from the User's perspective, there is one context that just deals with "Calculators", but the System's viewpoint there's another that speaks to a lower lever context with "Accumulators", "ALUs", "Bits", "Words", "Registers", "Clocks", "Latches", etc. The further you go down in the Use Case heirarchy by asking "How?" the more technical the language is going to become. You need to decide which are Domain Objects and which are just Implementation Objects and that depends very much on the type of thing you're trying to describe and build (and, to a great extent, who your audience is - ubiquitous langauge and all that!). Conversely, you can go up the stack by asking "Why?" the function is being performed.
The primary actor of a Sub-Function Use Case is generally the same actor as that of the higher-level use case that calls it. For some "technical" Use Cases though, the primary actor will be a system component/subsytem. For example, a system message logging Use Case might have the calling subsystem as the primary actor - i.e. the entity that had the will/need to initiate the action, rather than the actor that was performing the task that caused that subsytem to need to log something.
In this example, where the algorithm is so simple, I'd probably just Embed it into the main Use Case. However, if it was being used in multiple other higher-level Use Cases I'd make it Standalone so I could include it from the other documents. Just a functional decomposition approach.
There are no hard-and-fast rules with this. It's a style of working that you'll evolve over time. As others have said, make sure that you're familiar with the other forms of diagrams so that you can pick the right tool for the job. Remember that although a picture may be worth a thousand words sometimes you actually need those words too so don't just rely on diagrams.
您误用了用例：用例是静态视图:)
对于动态视图，您应该使用活动图或对象图/序列图。
You are misusing use case : use case is a STATIC view :)
For DYNAMIC View you should use activity diagram or object diagrams / sequence diagrams.
我有一个系统建模复杂问题，该问题与我解决的在模型中添加约束的算法无关。我不知道它是否有帮助，但在我看来，你可以使用与我相同的技巧。我的意思是在图表中添加模型信息并使用多个图表以获得用例的多个视图。
这种多图视图和用例保留其自己的属性非常酷，因为一旦我的用例保存在模型中，它就可以用于另一个图中，从而描述特定图中不可能的内容。
非常非常强大的概念，使用元模型作为 xmi 数据库，使用 UML 编辑器作为模型的查看器，而不是模型本身。我现在可以做以前不可能的事情，而且威力更大。它也更复杂，因为您应该查看图表级别，但也应该查看元模型级别，但一旦我使用它就很棒了:-)
替代文本 http://www.forum-omondo。 com/download/file.php?id=253&mode=view
I had a system modeling complex problem which was not related to algorithm that I solved adding constraints in the model. I don't know if it could help but it seems to me that you could use the same trick that I did. I mean adding model information in the diagram and using more than one diagram in order to have more than one view of the usecase.
This multi diagram view and usecase keeping it own property was really cool because once my usecase was saved in the model it could be used into another diagram and therefore describe what was not possible in a specific diagram.
Very very powerful concept using the metamodel as an xmi database and the UML editor as a viewer of the model and not the model itself. I can now do what was impossible before and it is a lot more powerful. It is also more complex because you should look at diagram level but also at metamodel level but once I got used it was wonderful :-)
alt text http://www.forum-omondo.com/download/file.php?id=253&mode=view