使用序列图编码

Question

当我在大学时，一位讲师说了一些人如何使用序列图设法编码，这对我来说似乎是一种很好的编程方式，但当然魔鬼是在细节中。我有几个问题。

• 这是真的发生还是我 误解他说什么？
• 有 这里的任何人实际上都是这样做的？
• 更高效吗？
• 有什么缺点？
• 使用Java时需要什么工具？

Answer 1

我发现“正常”序列图几乎总是比他们的价值更痛苦（尽管我发现它们对于在LINQ中显示数据流有用）。做一个“粗糙和准备好”的图，并解释它（最好是亲身体验，但用大量的文字说明）在我的经验中效果更好。

我认为最好有一个图表（或多个图表）展示应用程序的一种“垂直切片” - 每个图层如何与另一个图层进行对话，并且可能在适当的情况下显示请求/响应的过程。然而，这并不需要处于“个别方法调用并始终100％准确”的水平 - 确保您传达正确的总体印象更重要，假设读者可以深入实际的代码。在说完所有这些之后，我对UML的看法大体上是相同的，所以如果你是一个精确图表的忠实粉丝，并始终与现实保持一致，那么就用一点盐:)

Answer 2

我认为序列图是可视化复杂的多线程程序的最佳方法之一，其中线程之间传递大量消息。我没有在设计中使用它们，但有时它们是调试的最佳方式。

Answer 3

我发现，序列图功亏一篑真正的应用程序，因为：

1. 我可以用英语做的只是使用轮廓以及从层解释调用层次结构层，当有单线程控制。 MS Word中的轮廓样式在这里做得很好。

2. 我的英文解释比UML图片更详细，占用的空间也更小。

3. 对于英语，我可以解释其他细节，例如保护条件和循环比序列图更好。

4. 我可以写起轮廓比起草UML更快。

如果你真的需要一个具有这些细节的“图片”，也许一个活动图表就可以做到。

另一方面，序列图非常适合高层次概述。

就Java而言，我的项目团队非常喜欢Jude，因为它可以反向设计Java 5代码库的类层次结构。

Answer 4

一个序列图将显示一个交互，它通常是通过您的代码的单一路径。另一方面，你的代码必须定义每条路径，每个if-then-else和edge条件等。你可以在序列图上显示所有的东西，但它们往往变得太复杂和笨拙。我建议你在设计阶段使用序列图来帮助可视化你的代码，如果这对你有用的话，那么你应该尽可能地去做。

Answer 5

序列图适用于过程语言。它们不适用于OO语言。

Answer 6

序列图有自己的位置。我从来不担心让UML图与代码更改保持同步。这就是说，我是使用序列图作为头脑风暴工具的忠实粉丝。您希望您的团队了解并就底层流程和调用结构达成一致。当你也跟踪参数和实例创建时，它可以突出你理解中的漏洞。如果你需要数据'x'作为参数，它已经是本地的或者需要被传入，“我们正在从数据库请求报告数据，它需要我们发送报告类型，我们记得把它包括为传入的参数，对吧？

这适用于高层次的设计，之后它可以作为一般文档给晚来者，他们会明白你的前进方向以及他们什么时候看到代码，将不会如此困惑的变化