当我在大学时，一位讲师说有些人如何设法使用序列图进行编码，这对我来说似乎是一种很好的编程方式，但当然魔鬼在细节中。我有几个问题。
- 这是真的发生还是我误解了他所说的？
- 这里有人真的这样做过吗？
- 是不是更有生产力？
- 有什么缺点？
- 使用 Java 时需要哪些工具？
问问题
1487 次
6 回答
9
我发现“正常”序列图几乎总是比它们的价值更痛苦（尽管我发现它们对于在 LINQ 中显示数据流很有用）。根据我的经验，做一个“粗略和准备好的”图表并解释它（最好是亲自进行，但无论哪种方式都有大量的文字）效果更好。
我认为有一个（或多个）图表来显示您的应用程序的一种“垂直切片”是一个好主意——每一层如何与另一层通信，并可能在合适的情况下显示请求/响应的过程。但是，这并不需要处于“单独的方法调用且始终 100% 准确”的级别——确保您传达正确的总体印象更为重要，前提是读者可以深入了解真实代码。
说了这么多，我对UML的看法大体上是一样的，所以如果你是精确图表的忠实粉丝，总是一丝不苟地与现实保持同步等，那就用一点盐吧:)
于 2008-11-09T21:09:43.763 回答
4
我认为序列图是可视化复杂的多线程程序的最佳方式之一，其中有大量消息在线程之间传递。我在设计中很少使用它们，但有时它们是最好的调试方式。
于 2008-11-09T21:31:43.890 回答
1
我发现序列图不适合实际应用，因为：
当有一个控制线程时，我可以很好地使用英语大纲来解释从层到层的调用层次结构。MS Word 中的大纲样式在这里做得很好。
我的英文解释比 UML 图片更详细，占用的空间更少。
用英语，我可以比序列图更好地解释其他细节，例如保护条件和循环。
我可以比绘制 UML 更快地写出大纲。
如果你真的需要这么详细的“图片”，也许活动图就可以了。
另一方面，序列图非常适合高级概述。
就 Java 而言，我的项目团队非常喜欢Jude，因为它可以对 Java 5 代码库的类层次结构进行逆向工程。
于 2008-11-10T17:40:35.183 回答
0
序列图将显示交互，这通常是通过代码的单一路径。另一方面，您的代码必须定义每条路径，每个 if-then-else 和边缘条件等。您可以在序列图上显示所有这些东西，但它们往往变得过于复杂和笨拙。我建议您在设计阶段使用序列图来帮助可视化您的代码，如果这对您有用的话，但您可能应该这样做。
于 2008-11-10T21:52:17.140 回答
0
序列图有它们的位置。我从不担心保持 UML 图与代码更改同步。话虽如此，我非常喜欢使用序列图作为头脑风暴工具。您希望您的团队理解并就底层流程和调用结构达成一致。当您还跟踪参数和实例创建时，它可以突出您理解中的漏洞。如果你需要数据'x'作为参数，它要么已经是本地的，要么需要传入，“我们正在从数据库中请求报表数据，它需要我们发送报表类型，我们记得把它作为一个传入参数，对吧？
这适用于设计的高级传递。之后，它可以作为后来者的通用文档。他们会明白你的目标，当他们看到代码时，他们不会对这些变化感到困惑。
于 2010-12-07T21:15:50.637 回答
-4
序列图适用于过程语言。它们对 OO 语言没有那么有用。
于 2008-11-10T22:14:46.207 回答