使用序列图编码
当我在大学时，一位讲师说过有些人如何使用序列图进行编码，这对我来说似乎是一种很好的编程方式，但当然问题在于细节。 我有几个问题。
- 这真的发生过还是我发生过 误解他所说的话？
- 有 这里有人真的这样做过吗？
- 是不是更有生产力？
- 有什么缺点？
- 使用Java时需要哪些工具？
When I was at university a lecturer said how some people managed to code using sequence diagrams, this to me seems a good way of programming but of course the devil is in the details. I have a few questions.
- Does this actually happen or was I
misinterpreting what he said? - Has
anyone here actually done this? - Is it more productive?
- What are the disadvantages?
- What tools would be needed when using Java?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我发现“正常”序列图几乎总是比它们的价值更令人痛苦（尽管我发现它们对于在 LINQ 中显示数据流很有用）。 根据我的经验，制作一个“粗略且准备好的”图表并对其进行解释（最好是亲自进行，但无论如何都要使用大量文字）效果更好。
我认为用一个（或多个）图表显示应用程序的某种“垂直切片”是个好主意 - 每层如何与另一层对话，也许还可以显示在适当情况下请求/响应的过程。 然而，这并不需要达到“单独的方法调用并且始终 100% 准确”的水平 - 确保传达正确的总体印象更为重要，假设读者可以深入了解真正的代码。
说了这么多，我对 UML 的看法大体上是一样的，所以如果您是精确图表的忠实粉丝，总是与现实保持一丝不苟的同步等，那么请对这一切持保留态度:)
I've found that "normal" sequence diagrams are almost always more of a pain than they're worth (although I have found them useful for showing data flow in LINQ). Doing a "rough and ready" diagram and explaining it (preferably in person, but with plenty of words either way) works better in my experience.
I think it's a good idea to have a diagram (or several) showing a sort of "vertical slice" of your application - how each layer talks to another, and perhaps showing the course of a request/response in suitable cases. However, this doesn't need to be at the "individual method call and always 100% accurate" level - making sure that you convey the right general impression is more important, assuming the reader can then dive into the real code.
Having said all of this, my views on UML in general are much the same, so if you're a big fan of precise diagrams always being kept meticulously in sync with reality etc, take it all with a pinch of salt :)
我认为序列图是可视化复杂的多线程程序的最佳方法之一，其中线程之间传递大量消息。 我在设计中很少使用它们，但有时它们是调试的最佳方法。
I think that sequence diagrams are one of the best ways to visualize complex, multithreaded programs with lots of messages being passed between threads. I don't use them much in design, but sometimes they are the best way to debug.
我发现序列图无法满足实际应用程序的需要，因为：
当存在单个控制线程时，我可以使用英文大纲很好地解释从一层到另一层的调用层次结构。 MS Word 中的大纲样式在这里表现得很好。
我的英文解释比 UML 图片更详细，占用的空间更少。
用英语我可以比序列图更好地解释其他细节，例如保护条件和循环。
我可以比绘制 UML 更快地写出大纲。
如果您确实需要一张包含如此详细信息的“图片”，也许活动图就可以解决问题。
另一方面，序列图非常适合高级概述。
就 Java 而言，我的项目团队非常喜欢 Jude 作为它可以对 Java 5 代码库的类层次结构进行逆向工程。
I've found that sequence diagrams fall short for real applications because:
I can do just well using an outline in English explaining the call hierarchy from layer to layer, when there's a single thread of control. The outline styles in MS Word do just fine here.
My English explanation has more detail and takes up less space than a UML picture.
With English I can explain other details such as guard conditions and loops better than a sequence diagram.
I can write up the outline quicker than drawing up the UML.
If you really need a "picture" with this much detail, perhaps an activity diagram will do the trick.
On the other hand, a sequence diagram is great for a high-level overview.
As far as Java is concerned, my project team really likes Jude as it can reverse engineer a Java 5 codebase's class hierachy.
序列图将显示交互，这通常是代码中的单个路径。 另一方面，您的代码必须定义每个路径，以及每个 if-then-else 和边缘条件等。您可以在序列图上显示所有这些内容，但它们往往会变得太多复杂且笨重。 我建议您使用序列图来帮助在设计阶段可视化您的代码（如果这对您有用），但这只是您应该做的。
A sequence diagram will show an interaction, which is typically a single path through your code. Your code, on the other hand, has to define every path, with every if-then-else and edge condition etc. You can show all that stuff on sequence diagrams, but they tend to get much too complex and unwieldy. I would recommend you use sequence diagrams to help visualise your code at the design stage, if that is useful to you, but that is as far as you should probably go.
序列图有其用武之地。 我从来都不会担心 UML 图与代码更改保持同步。 话虽这么说，我非常喜欢使用序列图作为头脑风暴工具。 您希望您的团队了解并就底层流程和调用结构达成一致。 当您还跟踪参数和实例创建时，它可能会突出您理解中的漏洞。 如果您需要数据“x”作为参数，它要么已经是本地的，要么需要传入，“我们正在从数据库请求报告数据，它需要我们发送报告类型，我们记得将其包含为传入参数，对吧？
这适用于设计的高级传递，之后，它可以作为后来者的通用文档，而当他们看到代码时，他们就不会明白。对这些变化感到困惑。
Sequence diagrams have their place. I've never been one to worry about keeping a UML diagram in sync with code changes. That being said, I'm a big fan of using sequence diagrams as a brainstorming tool. You want your team to understand and agree on the underlying process and call structure. When you also track arguments and instance creation, it can highlight holes in your understanding. If you need data 'x' as an argument, it is either already local or needs to be passed in, "We are requesting the report data from the database and it needs us to send the report type, we remembered to include it as an incoming parameter, right?
This works for the high-level pass over the design. After that, it can serve as general documentation for late comers. They'll understand where you were headed and when they see the code, they won't be so confused by the changes.
序列图适用于过程语言。 它们对于 OO 语言没有那么有用。
Sequence diagrams work for procedural languages. They are not as useful for OO languages.